RTI Connext DDS Micro C++ API
Version 3.0.0
|
Quality of Service (QoS) policies. More...
Modules | |
DISCOVERY | |
<<eXtension>> Specifies the attributes required to discover participants in the domain. | |
TRUST | |
Trust plugins. | |
DEADLINE | |
Expresses the maximum duration (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 DDSDataWriter (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 DDSDataWriter objects that attempt to modify the same instance of a data type (identified by DDSTopic + key). | |
LIVELINESS | |
Determines the mechanism and parameters used by the application to determine whether a DDSEntity is alive. | |
RELIABILITY | |
Indicates the level of reliability offered/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 DDSDataWriter and/or DDSDataReader. | |
DATA_REPRESENTATION | |
A list of data representations supported by a DDSDataWriter or DDSDataReader. | |
RESOURCE_LIMITS | |
Specifies the resources that RTI Connext DDS Micro can consume in order to meet the requested QoS. | |
DESTINATION_ORDER | |
<<eXtension>> Specifies the DestinationOrder policy. | |
ENTITY_FACTORY | |
A QoS policy for all DDSEntity types that can act as factories for one or more other DDSEntity 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 DDSDomainParticipant. | |
DATA_READER_PROTOCOL | |
<<eXtension>> Specifies the DataReader-specific protocol QoS. | |
DATA_WRITER_PROTOCOL | |
<<eXtension>> Specifies the DataWriter-specific protocol QoS. | |
TRANSPORT | |
<<eXtension>> <<cert>> Specify 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. |
Enumerations | |
enum | DDS_QosPolicyId_t { DDS_INVALID_QOS_POLICY_ID , DDS_DEADLINE_QOS_POLICY_ID , DDS_OWNERSHIP_QOS_POLICY_ID, DDS_OWNERSHIPSTRENGTH_QOS_POLICY_ID, DDS_LIVELINESS_QOS_POLICY_ID , DDS_RELIABILITY_QOS_POLICY_ID , DDS_HISTORY_QOS_POLICY_ID , DDS_ENTITYFACTORY_QOS_POLICY_ID } |
Type to identify QosPolicies . More... |
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. 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 DDSEntity objects in the system such as DDSTopic, DDSDataWriter, DDSDataReader, DDSPublisher, DDSSubscriber, and DDSDomainParticipant.
QosPolicies can be set programmatically when an DDSEntity is created, or modified with the DDSEntity's set_qos (abstract) method.
To customize a DDSEntity'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 set_qos (abstract) operation, or when the DDSEntity 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 DDSEntity creation time or else prior to calling the DDSEntity::enable operation on the entity.
Each DDSEntity can be configured with a list of QosPolicy
objects. However, not all QosPolicies are supported by each DDSEntity. For instance, a DDSDomainParticipant supports a different set of QosPolicies than a DDSTopic or a DDSPublisher.
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 DDSSubscriber requests to receive data reliably while the corresponding DDSPublisher 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 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 DDSEntity 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 DDSListener.
The following properties are defined on a QosPolicy.
enum DDS_QosPolicyId_t |
Type to identify QosPolicies
.
Note that the value of these constants disagree with the values of the corresponding parameter IDs in the RTPS protocol. This conflict is unavoidable since these values are given in the DDS specification, which is not tied to RTPS.
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. |