Data Distribution Service (DDS) relies on the use of QoS. A QoS is a set of characteristics that controls some aspect of the behavior of DDS. A QoS is comprised of individual QoS policies (objects conceptually deriving from an abstract QosPolicy class).
The QosPolicy provides the basic mechanism for an application to specify quality of service parameters. It has an attribute name that is used to uniquely identify each QosPolicy.
QosPolicy implementation is comprised of a name, an ID, and a type. The type of a QosPolicy value may be atomic, such as an integer or float, or compound (a structure). Compound types are used whenever multiple parameters must be set coherently to define a consistent value for a QosPolicy.
QoS (i.e., a list of QosPolicy objects) may be associated with all DDS.Entity objects in the system such as DDS.Topic, DDS.DataWriter, DDS.DataReader, DDS.Publisher, DDS.Subscriber, and DDS.DomainParticipant.
QosPolicies can be set programmatically when an DDS.Entity is created, or modified with the DDS.Entity's Entity_set_qos procedure.
QosPolicies can also be configured from XML resources (files, strings). With this approach, you can change the QoS without recompiling the application. For more information, see NDDSXmlConfigurationModule.
To customize a DDS.Entity's QoS before creating the entity, the correct pattern is:
Each QosPolicy is treated independently from the others. This approach has the advantage of being very extensible. However, there may be cases where several policies are in conflict. Consistency checking is performed each time the policies are modified via the Entity_set_qos operation, or when the DDS.Entity is created.
When a policy is changed after being set to a given value, it is not required that the new value be applied instantaneously; RTI Connext is allowed to apply it after a transition phase. In addition, some QosPolicy have immutable semantics, meaning that they can only be specified either at DDS.Entity creation time or else prior to calling the DDS.Entity.enable operation on the entity.
Each DDS.Entity can be configured with a list of QosPolicy objects. However, not all QosPolicies are supported by each DDS.Entity. For instance, a DDS.DomainParticipant supports a different set of QosPolicies than a DDS.Topic or a DDS.Publisher.
In several cases, for communications to occur properly (or efficiently), a QosPolicy on the publisher side must be compatible with a corresponding policy on the subscriber side. For example, if a DDS.Subscriber requests to receive data reliably while the corresponding DDS.Publisher defines a best-effort policy, communication will not happen as requested.
To address this issue and maintain the desirable decoupling of publication and subscription as much as possible, the QosPolicy specification follows the subscriber-requested, publisher-offered pattern.
In this pattern, the subscriber side can specify a "requested" value for a particular QosPolicy. The publisher side specifes an "offered" value for that QosPolicy. RTI Connext will then determine whether the value requested by the subscriber side is compatible with what is offered by the publisher side. If the two policies are compatible, then communication will be established. If the two policies are not compatible, RTI Connext will not establish communications between the two DDS.Entity objects and will record this fact by means of the DDS.OFFERED_INCOMPATIBLE_QOS_STATUS on the publisher end and DDS.REQUESTED_INCOMPATIBLE_QOS_STATUS on the subscriber end. The application can detect this fact by means of a DDS.Listener or a DDS.Condition.
The following properties are defined on a QosPolicy.