Why isn't my reliable data reader receiving all data samples?

Submitted by Juanjo Martin on Thu, 01/17/2013 - 08:35

Note: Relevant RTI Connext version 4.x and above.

In order to guarantee that RTI Connext will deliver all messages, both the data writer and data reader must be configured for strict reliable communication. Strict reliability ensures that every message will be received by all known data readers. In addition, a write call will block while the send queue is full. Messages are only cleared from the send queue when all known data readers have acknowledged receiving them.

Strict reliability requires the following QoS settings: 

  • Reliability QoS kind = DDS_RELIABLE_RELIABILITY_QOS
  • History QoS kind = DDS_KEEP_ALL_HISTORY_QOS

If those QoS policies are set, you may still lose issues in the following cases: 

  • The data reader is not up when the data writer starts sending. It is important to realize that a data writer will only guarantee reliable data delivery to known data readers. In this example, there are no known data readers when the first samples are sent, so they are dropped. In order to make sure a late joining data reader also receives previously written issues, you must use the Durability QoS policy. See solution Why does my DDS DataReader miss the first few samples? for more details.
  • A data reader loses its liveliness, e.g. due to a network failure. The data writer will keep issues in the send queue until they have been acknowledged by all known data readers. In this case, the data reader fails to send acknowledgements. When it also looses its liveliness, it is no longer considered a known data reader, so the issues are dropped from the send queue and lost forever. Note that again, when the data reader reappears, the loss may be minimized by using the Durability QoS.

As mentioned above, the data writer will block when the send queue is full. The maximum blocking time can be set as part of the Reliability QoS of the data writer. The amount of time a writer will block can be minimized by ensuring a large enough send queue. The size of the send queue is determined by the Resource Limits QoS of the data writer. As the History QoS kind is set to DDS_KEEP_ALL_HISTORY_QOS, the size of the queue in this case also determines the number of issues than can be made available to late joining data readers.

Product:
Keywords: