Download RTI Core Libraries and Utilities Getting Started Guide

Reliable Messaging
be resent. RTI offers the user a comprehensive set of tunable parameters that control how many
and how often metadata packets are sent, how much memory is used for internal buffers that
help overcome intermittent data losses, and how to detect and respond to a reliable subscriber
that either falls behind or otherwise disconnects.
When users want applications to exchange messages reliably, there is always a need to trade-off
between performance and memory requirements. When strictly reliable communication is
enabled, every written sample will be kept by Connext inside an internal buffer until all known
reliable subscribers acknowledge receiving the sample1.
If the publisher writes samples faster than subscribers can acknowledge receiving, this internal
buffer will eventually be completely filled, exhausting all the available space—in that case, further writes by the publishing application will block. Similarly, on the subscriber side, when a
sample is received, it is stored inside an internal receive buffer, waiting for the application to
take the data for processing. If the subscribing application doesn't take the received samples fast
enough, the internal receive buffer may fill up—in that case, newly received data will be discarded and would need to be repaired by the reliable protocol.
Although the size of those buffers can be controlled from the QoS, you can also use QoS to control what Connext will do when the space available in one of those buffers is exhausted. There
are two possible scenarios for both the publisher and subscriber:
Publishing side: If write() is called and there is no more room in the DataWriter’s buffer, Connext
can:
1. Temporarily block the write operation until there is room on this buffer (for example,
when one or more samples is acknowledged to have been received from all the subscribers).
2. Drop the oldest sample from the queue to make room for the new one.
Subscribing side: If a sample is received (from a publisher) and there is no more room on the
DataReader’s buffer:
1. Drop the sample as if it was never received. The subscribing application will send a negative acknowledgement requesting that the sample be resent.
2. Drop the oldest sample from the queue to make room for the new one.
6.2.1
Implementation
There are many variables to consider, and finding the optimum values to the queue size and the
right policy for the buffers depends on the type of data being exchanged, the rate of which the
data is written, the nature of the communication between nodes and various other factors.
The RTI Core Libraries and Utilities User’s Manual dedicates an entire chapter to the reliability protocol, providing details on choosing the correct values for the QoS based on the system configuration. For more information, refer to Chapter 10 in the User’s Manual.
The following sections highlight the key QoS settings needed to achieve strict reliability. In the
reliable.xml QoS profile file, you will find many other settings besides the ones described here.
A detailed description of these QoS is outside the scope of this document, and for further information, refers to the comments in the QoS profile and in the User’s Manual.
1. Connext also supports reliability based only on negative acknowledgements ("NACK-only reliability"). This feature is described in detail in the User's Manual (Section 6.5.2.3) but is beyond the scope of this document.
6-4