Chapter 11 Quality of Service (QoS)
Quality of Service Policies are a standardized mechanism that allows application developers to configure many aspects of how and when data is distributed between applications. The overall QoS of the Connext system is made up of the individual QosPolicies for each Entity. There are QosPolicies for Topics, DataWriters, Publishers, DataReaders, Subscribers, DomainParticipants, and the DomainParticipantFactory.
On the publishing side, the QoS of each Topic, the Topic’s DataWriter, and the DataWriter’s Publisher all play a part in controlling how and when DDS samples are sent to the middleware. Similarly, the QoS of the Topic, the Topic’s DataReader, and the DataReader’s Subscriber control behavior on the subscribing side.
Users can employ QosPolicies to control a variety of behaviors. For example, the DEADLINE policy sets up expectations of how often a DataReader expects to see DDS samples. The OWNERSHIP and OWNERSHIP_STRENGTH policy are used together to configure and decide whose data is passed to the DataReader when there are multiple DataWriters for the same instance of a Topic. The HISTORY policy specifies whether a DataWriter should save old data to send to new subscriptions that join the network later. Many other policies exist; see Chapter 54 All QosPolicies.
Some QosPolicies represent “contracts” between publications and subscriptions. For communications to take place properly, the QosPolicies set on the DataWriter side must be compatible with corresponding policies set on the DataReader side.
For example, the RELIABILITY policy is set by the DataWriter to state whether it is configured to send data reliably to DataReaders. Because it takes additional resources to send data reliably, some DataWriters may only support a best-effort level of reliability. This implies that for those DataWriters, Connext will not spend additional effort to make sure that the data sent is received by DataReaders or resend any lost data. However, for certain applications, it could be imperative that their DataReaders receive every piece of data with total reliability. Running a system where the DataWriters have not been configured to support the DataReaders could lead to erratic failures.
To address this issue, and yet keep the publications and subscriptions as decoupled as possible, Connext provides a way to detect and notify when QosPolicies set by DataWriters and DataReaders are incompatible. Connext employs a pattern known as RxO (Requested versus Offered). The DataReader sets a “requested” value for a particular QosPolicy. The DataWriter sets an “offered” value for that QosPolicy. When Connext matches a DataReader to a DataWriter, QosPolicies are checked to make sure that all requested values can be supported by the offered values.
Note that not all QosPolicies are constrained by the RxO pattern. For example, it does not make sense to compare policies that affect only the DataWriter but not the DataReader or vice versa.
If the DataWriter cannot satisfy the requested QosPolicies of a DataReader, Connext will not match the two DDS entities and will notify the applications on each side of the incompatibility if so configured.
- For example, a DataReader sets its DEADLINE QoS to 4 seconds—that is, the DataReader is requesting that it receive new data at least every 4 seconds.
- In one application, the DataWriter sets its DEADLINE QoS to 2 seconds—that is, the DataWriter is committing to sending data at least every 2 seconds. This writer can satisfy the request of the reader, and thus, Connext will pass the data sent from the writer to the reader.
- In another application, the DataWriter sets its DEADLINE QoS to 5 seconds. It only commits to sending data at 5-second intervals. This will not satisfy the request of the DataReader. Connext will flag this incompatibility by calling user-installed listeners in both DataWriter and DataReader applications and not pass data from the writer to the reader.
For a summary of the QosPolicies supported by Connext, see Chapter 54 All QosPolicies or the
See the API Reference HTML documentation for complete QoS details, including functional categories, defaults, and other QoS attributes. (API References are here: <NDDSHOME>/doc/api/connext_dds/api_<language>) For example,
Besides the QoS Policies, there are additional properties that you can configure through the 59.19 PROPERTY QosPolicy (DDS Extension) . These are not exposed through the formal QoS policies and are described in the
Properties are typically added for very specific use cases and may eventually be promoted to QoS fields if and when they are found to be more generally useful in many situations. It is not necessary to be familiar with all of the possible properties. More popularly used and generally useful properties are typically documented in this User’s Manual and other documentation where their use is applicable.