|Specifies the desired kind of destination order. |
|<<eXtension>> Allowed tolerance between source timestamps of consecutive samples. |
This QoS policy controls how each subscriber resolves the final value of a data instance that is written by multiple DDSDataWriter entities (which may be associated with different DDSPublisher entities) running on different nodes.
The default setting, DDS_BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS, indicates that (assuming the OWNERSHIP_STRENGTH policy allows it) the latest received value for the instance should be the one whose value is kept. That is, data will be delivered by a DDSDataReader in the order in which it was received (which may lead to inconsistent final values).
The setting DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS indicates that (assuming the OWNERSHIP_STRENGTH allows it, within each instance) the
source_timestamp of the change shall be used to determine the most recent information. That is, data will be delivered by a DDSDataReader in the order in which it was sent. If data arrives on the network with a source timestamp that is later than the source timestamp of the last data delivered, the new data will be dropped. This 'by source timestamp' ordering therefore works best when system clocks are relatively synchronized among writing machines.
When using DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS, not all data sent by multiple DDSDataWriter entities may be delivered to a DDSDataReader 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. This is the only setting that, in the case of concurrently publishing DDSDataWriter entities updating the same instance of a shared-ownership topic, ensures all subscribers will end up with the same final value for the instance.
This QoS 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.DDS_DestinationOrderQosPolicy::kind are considered ordered such that DDS_BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS < DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS
Specifies the desired kind of destination order.
<<eXtension>> Allowed tolerance between source timestamps of consecutive samples.
When a DDSDataWriter sets DDS_DestinationOrderQosPolicyKind to DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS, when when writing a sample, its timestamp must not be less than the timestamp of the previously written sample. However, if it is less than the timestamp of the previously written sample but the difference is less than this tolerance, the sample will use the previously written sample's timestamp as its timestamp. Otherwise, if the difference is greater than this tolerance, the write will fail.
When a DDSDataReader sets DDS_DestinationOrderQosPolicyKind to DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS, the DDSDataReader will accept a sample only if the difference between its source timestamp and the reception timestamp is no greater than this tolerance. Otherwise, the sample is rejected.