QoS policies for configuring reliability

DDS provides a reliability protocol that can be tuned for optimum performance on a per data stream basis. The reliability protocol is configured and tuned by these QoS policies: Reliability, History,  Resource Limits, DataWriter Protocol, and DataReader Protocol. 

Reliability 

Specifies whether or not DDS will deliver data reliably.

• The reliability of a connection between a DataWriter and DataReader is entirely user configurable. A connection may be configured to be "best effort" which means that DDS will not use any resources to monitor or guarantee that the data sent by a DataWriter is received by a DataReader.
• For some use cases, such as the periodic update of sensor values to a GUI displaying the value to a person, "best effort" delivery is appropriate. It is certainly the fastest, most efficient, and least resource-intensive (CPU and network bandwidth) method of getting the newest/latest value for a topic from DataWriters to DataReaders. But there is no guarantee that the data sent will be received. It may be lost due to a variety of factors, including data loss by the physical transport such as wireless RF or even Ethernet.
• There are data streams (topics) in which you want an absolute guarantee that all data sent by a DataWriter is received reliably by DataReaders. This means that DDS must check whether or not data was received, and repair any data that was lost by resending a copy of the data as many times as it takes for the DataReader to receive the data.
• The Reliable QoS policy is simply a switch to turn on the reliability protocol for a DataWriter/DataReader connection. The level of reliability provided by the middleware is determined by the configuration of the aforementioned QoS policies.
• You can configure the middleware to deliver ALL data in the order they were sent (also known as absolute or strict reliability). Or, as a tradeoff for less memory, CPU, and network usage, you can choose a reduced level of reliability where only the last N values are guaranteed to be delivered reliably to DataReaders (where N is user-configurable). In the reduced level of reliability, there are no guarantees that data sent before the last N are received; only the last N data packets are monitored and repaired if necessary.

History

Specifies how much data must be stored by the middleware for the DataWriter or DataReader. This QoS policy affects the Reliability and Durability QoS policies.

• When a DataWriter sends data or a DataReader receives data, the data sent or received is stored in a cache whose contents are controlled by the History QoS policy. The History QoS policy can tell the middleware to store ALL of the data that was sent or received, or only store the LAST N values sent or received. If the History QoS policy is set to keep the last N values, then after N values have been sent or received, any new data will overwrite the oldest data in the queue. The queue acts like a circular buffer of length N.
• For keyed Topics, this QoS policy applies on a per instance basis. If the History depth is set to size N, then N samples of each instance will be kept.
• This QoS policy interacts with the Reliable QoS policy by controlling whether or not DDS guarantees that (a) all of the data sent is received (using the ALL setting of the History QoS policy) or (b) that only the last N data values sent are received (a reduced level of reliability, using the KEEP LAST setting of the History QoS policy). See the Reliability QoS policy for more information.
• The physical size of the send and receive queues are not controlled by the History QoS Policy. The memory allocation for the queues is controlled by the Resource Limits QoS policy.

Resource Limits

Controls the amount of physical memory allocated for middleware entities, if dynamic allocations are allowed, and how they occur. Also controls memory usage among different instance values for keyed topics.

• For the reliability protocol (and the Durability QoS policy), this QoS policy determines the actual maximum queue size when the History QoS policy is set to KEEP ALL.
• In general, this QoS policy is used to limit the amount of system memory that DDS can allocate. For embedded real-time systems and safety-critical systems, pre-determination of maximum memory usage is often required. In addition, dynamic memory allocation could introduce non-deterministic latencies in time-critical paths.
• This QoS policy can be set so that an entity does not dynamically allocate more memory after its initialization phase.

DataWriter Protocol, DataReader Protocol

Along with the Wire Protocol QoS, this QoS configures the DDS on-the-wire protocol (RTPS).

• DDS has a standard protocol for packet (user and meta data) exchange between applications using DDS for communications. The Protocol QoS gives you control over configurable portions of the protocol, including the configuration of the reliable data delivery mechanism of the protocol on a per DataWriter or DataReader basis.
• These configuration parameters control timing and timeouts, and give you the ability to tradeoff between speed of data-loss detection and repair, versus the network and CPU bandwidth used to maintain reliability.
• It is important to tune the reliability protocol (on a per DataWriter and DataReader basis) to meet the requirements of the end-user application so that data can be sent between DataWriters and DataReaders in an efficient and optimal manner in the presence of data loss. You can also use this QoS to control how DDS responds to "slow" reliable DataReaders or ones that disconnect or are otherwise lost.