Keyed data: Advanced

Concept

Topics come in two flavors: those whose associated data type has specified some fields as defining the key, and those whose associated data type has not. If the data type has some fields that act as a key, the Topic essentially defines a collection of data instances whose values can be independently maintained.

Since the key fields are contained within the data structure, Connext could examine the key fields each time it needs to determine which data instance is being modified. However, for performance and semantic reasons, it is better for your application to declare all the data-instances it intends to modify, prior to actually writing any samples. This is known as registration.

Example Description

This example complements the previous Keyed Data example with some advanced concepts related to keyed data,

First, we show how the Ownership QoS interacts with the registration, unregistration, and disposal of instances of multiple DataWriters. Also, we explore how the on_data_available callback on the DataReader can delegate to other handlers based on instance state changes. Finally, we will show how to read only certain keys. Note that this is an entirely separate mechanism than content based filters. "Filtering" in this case is done on the DataReader side, and thus saves no network overhead. An example of when such a scheme may be useful is when a DataReader is receiving many samples via multicast. After filtering in on_data_available, the rest of the application does not need to deal with keys it doesn't care about.

The example creates two DataWriters:

• DW1 : It writes positive numbers. Has a OWNERSHIP strenght of 10.
• DW2 : It writes negative numbers. Has a OWNERSHIP strenght of 5.

These DataWrites have the following behavior:

• At t=0 DW1 starts continously writting to an instance (ins0).
• At t=0 DW2 starts continously writting to an instance (ins1).
• At t=4 DW1 registers two instances (ins1and ins2).
  Since DW1 has the greater OWNERSHIP strength, only its ins1 updates are delivered to the DR.
• At t=8 DW1 disposes ins1.
  Since DW1 has not unregistered the instance, the DR does not receive ins1 updates from DW2.
• At t=10 DW1 unregisters ins1.
  The DR starts receiving ins1 updates from DW2.
• At t=12 DW1 unregisters ins2 and re-registers ins1.
  The DR receives ins1 updates from DW1.
• At t=16 DW1 re-registers ins2 and DW2 disposes ins1.

Download Example

Browse Example