Quality of Service (QoS) policies. More...
Topics | |
| FILTER | |
| <<eXtension>> The FILTER QoS policy allows you to configure the content filter capabilities and resource limits for a DDS_DomainParticipant and all of its child entities. | |
| CONTENT_FILTER | |
| <<eXtension>> Filter that allows a DDS_DataReader to specify that it is interested only in (potentially) a subset of the samples on its topic. | |
| DISCOVERY | |
| <<eXtension>> Specifies the attributes required to discover participants in the domain. | |
| USER_TRAFFIC | |
| <<eXtension>> <<cert>> Specifies user-traffic transport settings | |
| TRUST | |
| <<eXtension>> <<cert>> Specify trust settings for secure communication. | |
| DEADLINE | |
| Expresses the maximum duration or deadline within which an instance is expected to be updated. | |
| LATENCY_BUDGET | |
| Provides a hint as to the maximum acceptable delay from the time the data is written to the time it is received by the subscribing applications. | |
| OWNERSHIP | |
| Specifies whether it is allowed for multiple DDS_DataWriter(s) to write the same instance of the data and if so, how these modifications should be arbitrated. | |
| OWNERSHIP_STRENGTH | |
| Specifies the value of the strength used to arbitrate among multiple DDS_DataWriter objects that attempt to modify the same instance of a data type (identified by DDS_Topic + key). | |
| LIVELINESS | |
| Determines the mechanism and parameters used by the application to determine whether a DDS_Entity is alive. | |
| RELIABILITY | |
| Indicates the level of reliability offered or requested by RTI Connext DDS Micro. | |
| HISTORY | |
| Specifies the behavior of RTI Connext DDS Micro in the case where the value of an instance changes (one or more times) before it can be successfully communicated to one or more existing subscribers. | |
| DURABILITY | |
| <<eXtension>> Specifies the Durability properties used by a DDS_DataWriter and/or DDS_DataReader. | |
| TRANSPORT_ENCAPSULATION | |
| Configuration for the wire encoding primarily used by Zero Copy v2. | |
| DATA_REPRESENTATION | |
| A list of data representations supported by a DDS_DataWriter or DDS_DataReader. | |
| RESOURCE_LIMITS | |
| Specifies the resources that RTI Connext DDS Micro can consume in order to meet the requested QoS. | |
| PRESENTATION | |
| Specifies how the samples representing changes to data instances are presented to a subscribing application. | |
| DESTINATION_ORDER | |
| <<eXtension>> Specifies the DestinationOrder policy. | |
| ENTITY_FACTORY | |
| A QoS policy for all DDS_Entity types that can act as factories for one or more other DDS_Entity types. | |
| Extended Qos Support | |
| <<eXtension>> Types and defines used in extended QoS policies. | |
| SYSTEM_RESOURCE_LIMITS | |
| <<eXtension>> Specifies the system-specific resources that RTI Connext DDS Micro can use. | |
| WIRE_PROTOCOL | |
| <<eXtension>> Specifies the wire protocol related attributes for the DDS_DomainParticipant. | |
| DATA_READER_PROTOCOL | |
| <<eXtension>> Specifies the DDS_DataReader specific protocol QoS. | |
| DATA_WRITER_PROTOCOL | |
| <<eXtension>> Specifies the DDS_DataWriter specific protocol QoS. | |
| TRANSPORT | |
| <<eXtension>> <<cert>> Specifies transport settings | |
| DOMAIN_PARTICIPANT_RESOURCE_LIMITS | |
| <<eXtension>> Specifies the DomainParticipant-specific resources that RTI Connext DDS Micro can use. | |
| ENTITY_NAME | |
| <<eXtension>> Name of the entity. | |
| PUBLISH_MODE | |
| <<eXtension>> Specifies how RTI Connext DDS Micro sends application data on the network. This QoS policy can be used to tell RTI Connext DDS Micro to use its own thread to send data, instead of the user thread. | |
| PARTITION | |
| The PARTITION QoS policy provides a method to prevent Entities that have otherwise compatible QoS policies from matching with each other and thus communicating with each other. | |
| PROPERTY | |
| <<eXtension>> Stores (name, value) pairs that can be used to configure certain parameters of RTI Connext DDS Micro that are not exposed through formal QoS policies. | |
| TRANSPORT_PRIORITY | |
| This QoS policy allows the application to take advantage of transports that are capable of sending messages with different priorities. | |
| USER_DATA | |
| The USER_DATA QoS policy allows the user to attach a buffer of opaque data to a DDS_DomainParticipant, DDS_DataWriter, or DDS_DataReader. How this information is used will be up to the user code; RTI Connext DDS Micro distributes this information to other applications as part of the discovery process, but RTI Connext DDS Micro does not interpret the information. | |
| GROUP_DATA | |
| The GROUP_DATA QoS policy allows you to attach a buffer of opaque data to a DDS_Publisher or DDS_Subscriber. The use of this information is up to user code; RTI Connext DDS Micro distributes this information to other applications as part of the discovery process, but RTI Connext DDS Micro does not interpret the information. | |
| TOPIC_DATA | |
| The TOPIC_DATA QoS policy allows the user to attach a buffer of opaque data to a DDS_Topic. How this information is used will be up to the user code; RTI Connext DDS Micro distributes this information to other applications as part of the discovery process, but RTI Connext DDS Micro does not interpret the information. | |
| DATA_WRITER_TRANSFER_MODE | |
| <<eXtension>> Specifies the DDS_DataWriter transfer mode QoS. | |
Data Structures | |
| struct | DDS_QosPolicyCount |
| <<cert>> Type to hold a counter for a DDS_QosPolicyId_t More... | |
Enumerations | |
| enum | DDS_QosPolicyId_t { DDS_INVALID_QOS_POLICY_ID , DDS_USERDATA_QOS_POLICY_ID = 1 , DDS_DURABILITY_QOS_POLICY_ID = 2 , DDS_PRESENTATION_QOS_POLICY_ID = 3 , DDS_DEADLINE_QOS_POLICY_ID , DDS_LATENCYBUDGET_QOS_POLICY_ID = 5 , DDS_OWNERSHIP_QOS_POLICY_ID , DDS_OWNERSHIPSTRENGTH_QOS_POLICY_ID , DDS_LIVELINESS_QOS_POLICY_ID , DDS_TIMEBASEDFILTER_QOS_POLICY_ID = 9 , DDS_PARTITION_QOS_POLICY_ID = 10 , DDS_RELIABILITY_QOS_POLICY_ID , DDS_DESTINATIONORDER_QOS_POLICY_ID = 12 , DDS_HISTORY_QOS_POLICY_ID , DDS_RESOURCELIMITS_QOS_POLICY_ID = 14 , DDS_ENTITYFACTORY_QOS_POLICY_ID , DDS_WRITERDATALIFECYCLE_QOS_POLICY_ID = 16 , DDS_READERDATALIFECYCLE_QOS_POLICY_ID = 17 , DDS_TOPICDATA_QOS_POLICY_ID = 18 , DDS_GROUPDATA_QOS_POLICY_ID = 19 , DDS_TRANSPORTPRIORITY_QOS_POLICY_ID = 20 , DDS_LIFESPAN_QOS_POLICY_ID = 21 , DDS_DURABILITYSERVICE_QOS_POLICY_ID = 22 , DDS_DATA_REPRESENTATION_QOS_POLICY_ID = 23 , DDS_PROPERTY_QOS_POLICY_ID = 24 } |
Type to identify QosPolicies. More... | |
Detailed Description
Quality of Service (QoS) policies.
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).
RTI Connext DDS Micro supports a subset of these QoS.
The QosPolicy provides the basic mechanism for an application to specify quality of service parameters. A QosPolicy may have additional properties associated with it:
-
RxO property
The QosPolicy objects that need to be set in a compatible manner between the publisher and subscriber end are indicated by the setting of the RxO property:- RxO = YES indicates that the policy can be set both at the publishing and subscribing ends and the values must be set in a compatible manner. In this case the compatible values are explicitly defined.
- RxO = NO indicates that the policy can be set both at the publishing and subscribing ends but the two settings are independent. That is, all combinations of values are compatible.
- RxO = N/A indicates that the policy can only be specified at either the publishing or the subscribing end, but not at both ends. So compatibility does not apply.
-
Changeable property
Determines whether a QosPolicy can be changed.
NO -- policy can only be specified at DDS_Entity creation time.
UNTIL ENABLE -- policy can only be changed before the DDS_Entity is enabled.
YES -- policy can be changed at any time.
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 structures. Compound types are used whenever multiple parameters must be set coherently to define a consistent value for a QosPolicy.
QoS, which is 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.
Specifying QoS on entities
QosPolicies can be set programmatically when an DDS_Entity is created, or modified with the DDS_Entity's set_qos (abstract) function.
To customize a DDS_Entity's QoS before creating the entity, the correct pattern is:
- First, initialize a QoS object with the appropriate INITIALIZER constant.
- Call the relevant get_<entity>_default_qos() function.
- Modify the QoS values as desired.
- Finally, create the entity.
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 set_qos (abstract) 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 DDS Micro 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.
QoS compatibility
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 specifies an "offered" value for that QosPolicy. RTI Connext DDS Micro 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 DDS Micro 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.
Enumeration Type Documentation
◆ DDS_QosPolicyId_t
| enum DDS_QosPolicyId_t |
Type to identify QosPolicies.
| Enumerator | |
|---|---|
| DDS_INVALID_QOS_POLICY_ID | Identifier for an invalid QoS policy. |
| DDS_DEADLINE_QOS_POLICY_ID | Identifier for DDS_DeadlineQosPolicy. |
| DDS_OWNERSHIP_QOS_POLICY_ID | Identifier for DDS_OwnershipQosPolicy. |
| DDS_OWNERSHIPSTRENGTH_QOS_POLICY_ID | Identifier for DDS_OwnershipStrengthQosPolicy. |
| DDS_LIVELINESS_QOS_POLICY_ID | Identifier for DDS_LivelinessQosPolicy. |
| DDS_RELIABILITY_QOS_POLICY_ID | Identifier for DDS_ReliabilityQosPolicy. |
| DDS_HISTORY_QOS_POLICY_ID | Identifier for DDS_HistoryQosPolicy. |
| DDS_ENTITYFACTORY_QOS_POLICY_ID | Identifier for DDS_EntityFactoryQosPolicy. |
