Some QosPolicies that apply to Entities on the sending and receiving sides must have their values set in a compatible manner. This is known as the policy’s ‘requested vs. offered’ (RxO) property. Entities on the publishing side ‘offer’ to provide a certain behavior. Entities on the subscribing side ‘request’ certain behavior. For Connext DDS to connect the sending entity to the receiving entity, the offered behavior must satisfy the requested behavior.
For some QosPolicies, the allowed values may be graduated in a way that the offered value will satisfy the requested value if the offered value is either greater than or less than the requested value. For example, if a DataWriter’s DEADLINE QosPolicy specifies a duration less than or equal to a DataReader’s DEADLINE QosPolicy, then the DataWriter is promising to publish data at least as fast or faster than the DataReader requires new data to be received. This is a compatible situation (see DEADLINE QosPolicy).
Other QosPolicies require the values on the sending side and the subscribing side to be exactly equal for compatibility to be met. For example, if a DataWriter’s OWNERSHIP QosPolicy is set to SHARED, and the matching DataReader’s value is set to EXCLUSIVE, then this is an incompatible situation since the DataReader and DataWriter have different expectations of what will happen if more than one DataWriter publishes an instance of the Topic (see OWNERSHIP QosPolicy).
Finally there are QosPolicies that do not require compatibility between the sending entity and the receiving entity, or that only apply to one side or the other. Whether or not related Entities on the publishing and subscribing sides must use compatible settings for a QosPolicy is indicated in the policy’s RxO property, which is provided in the detailed section on each QosPolicy.
For those QosPolicies that follow the RxO semantics, Connext DDS will compare the values of those policies for compatibility. If they are compatible, then Connext DDS will connect the sending entity to the receiving entity allowing data to be sent between them. If they are found to be incompatible, then Connext DDS will not interconnect the Entities preventing data to be sent between them.
In addition, Connext DDS will record this event by changing the associated communication status in both the sending and receiving applications, see Types of Communication Status. Also, if you have installed Listeners on the associated Entities, then Connext DDS will invoke the associated callback functions to notify user code that an incompatible QoS combination has been found, see Types of Listeners.
For Publishers and DataWriters, the status corresponding to this situation is OFFERED_INCOMPATIBLE_QOS_STATUS. For Subscribers and DataReaders, the corresponding status is REQUESTED_INCOMPATIBLE_QOS_STATUS. The question of why a DataReader is not receiving data sent from a matching DataWriter can often be answered if you have instrumented the application with Listeners for the statuses noted previously.
© 2017 RTI