DESTINATION_ORDER QosPolicy

When multiple DataWriters send data for the same topic, the order in which data from different DataWriters are received by the applications of different DataReaders may be different. Thus different DataReaders may not receive the same "last" value when DataWriters stop sending data.

This policy controls how each subscriber resolves the final value of a data instance that is written by multiple DataWriters (which may be associated with different Publishers) running on different nodes.

This QosPolicy can be used to create systems that have the property of "eventual consistency." Thus intermediate states across multiple applications may be inconsistent, but when DataWriters stop sending changes to the same topic, all applications will end up having the same state.

Each DDS sample includes two timestamps: a source timestamp and a destination timestamp. The source timestamp is recorded by the DataWriter application when the data was written. The destination timestamp is recorded by the DataReader application when the data was received.

This QoS includes the member in Table 40 .

Table 40 DDS_DestinationOrderQosPolicy

Type	Field Name	Description
DDS_Destination-OrderQosPolicyKind	kind	Can be either: DDS_BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS
DDS_Duration_t	source_timestamp_tolerance	Allowed tolerance between source timestamps of consecutive DDS samples. Only applies when kind (above) is DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS.

Each DataReader can set this QoS to:

• DDS_BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS

Assuming the OWNERSHIP_STRENGTH allows it, the latest received value for the instance should be the one whose value is kept. Data will be delivered by a DataReader in the order in which it was received (which may lead to inconsistent final values).

• DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS

Assuming the OWNERSHIP_STRENGTH allows it, within each instance, the source_timestamp shall be used to determine the most recent information. This is the only setting that, in the case of concurrent same-strength DataWriters updating the same instance, ensures all subscribers will end up with the same final value for the instance.

Data will be delivered by a DataReader in the order in which it was sent. If data arrives on the network with a source timestamp earlier than the source timestamp of the last data delivered, the new data will be dropped. This ordering therefore works best when system clocks are relatively synchronized among writing machines.

Not all data sent by multiple DataWriters may be delivered to a DataReader and not all DataReaders will see the same data sent by DataWriters. However, all DataReaders will see the same "final" data when DataWriters "stop" sending data.

• For a DataWriter with kind
  DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS:
  When writing a DDS sample, its timestamp must not be less than the timestamp of the previously written DDS sample. However, if it is less than the timestamp of the previously written DDS sample but the difference is less than this tolerance, the DDS sample will use the previously written DDS sample's timestamp as its timestamp. Otherwise, if the difference is greater than this tolerance, the write will fail.

  See also: Special Instructions for deleting DataWriters if you are using the ‘Timestamp’ APIs and BY_SOURCE_TIMESTAMP Destination Order:.

• A DataReader with kind
  DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS will accept a DDS sample only if only if the source timestamp is no farther in the future from the reception timestamp than this tolerance. Otherwise, the DDS sample is rejected.

Although you can set the DESTINATION_ORDER QosPolicy on Topics, its value can only be used to initialize the DESTINATION_ORDER QosPolicies of either a DataWriter or DataReader. It does not directly affect the operation of Connext DDS, see Setting Topic QosPolicies.

Properties

This QosPolicy cannot be modified after the Entity is enabled.

This QoS must be set compatibly between the DataWriter and the DataReader. The compatible combinations are shown in Table 41 .

Table 41 Valid Reader/Writer Combinations of DestinationOrder

Destination Order		DataReader requests:
		BY_SOURCE	BY_RECEPTION
DataWriter offers:	BY_SOURCE	4	4
	BY_RECEPTION	incompatible	4

If this QosPolicy is set incompatibly, the ON_OFFERED_INCOMPATIBLE_QOS and ON_REQUESTED_INCOMPATIBLE_QOS statuses will be modified and the corresponding Listeners called for the DataWriter and DataReader respectively.

Related QosPolicies

• OWNERSHIP QosPolicy
• HISTORY QosPolicy

Applicable DDS Entities

• Topics
• DataWriters
• DataReaders

System Resource Considerations

The use of this policy does not significantly impact the use of resources.

© 2015 RTI