Figure 2 Scenario: Delegated Reliability

The DDS-RTPS reliability protocol requires the DataWriter to periodically send HeartBeat messages to the DataReaders, process their ACKs and NACK messages, keep track of the DataReader state, and send the necessary repairs. The additional load caused by the reliability protocol increases with the number of reliable DataReaders matched with the DataWriter. Even if the data is sent via multicast the number of ACKs and NACKs will increase with the number of DataReaders.

In situations where there many DataReaders are subscribing to the same Topic, the reliability and repair traffic may become too much for the DataWriter to handle and negatively impact its performance. To address this situation, Connext DDS provides the ability to configure the DataWriter so that it delegates the reliability task to a separate service. This approach is known as delegated reliability.

To take advantage of delegated reliability, both the original DataWriter and DataReader must be configured to enable an external service to ensure the reliability on their behalf. This is done by setting both the dds.data_writer.reliability.delegate_reliability property on the DataWriter and the dds.data_reader.reliability.delegate_reliability property on the DataReader to 1.

With this configuration, the DataWriter creates a reliable channel to Persistence Service, yet sends data using ‘best-effort’ reliability to the DataReaders directly. If a DDS sample is dropped, Persistence Service will repair the DDS sample. Persistence Service is configured with push_on_write (in the DATA_WRITER_PROTOCOL QosPolicy (DDS Extension)) set to false. This way, DDS samples will only be sent from Persistence Service to the DataReaders when they are explicitly NACKed by the DataReader.

Figure 3 Delegated Reliability Scenario

© 2015 RTI