TYPE_CONSISTENCY_ENFORCEMENT QosPolicy
The TypeConsistencyEnforcementQosPolicy defines the rules that determine whether the type used to publish a given topic is consistent with the type used to subscribe to it.
The QosPolicy structure includes the member in DDS_TypeConsistencyEnforcementQosPolicy.
|
Type |
Field Name |
Description |
|
DDS_TypeConsistencyKind |
kind |
Can be either:
See Values for TypeConsistencyKind for details. |
The type-consistency enforcement rules consist of two steps:
- If both the DataWriter and DataReader specify a TypeObject, it is considered first. If the DataReader allows type coercion, then its type must be assignable from the DataWriter’s type. If the DataReader does not allow type coercion, then its type must be structurally identical to the type of the DataWriter.
- If either the DataWriter or the DataReader does not provide a TypeObject definition, then the registered type names are examined. The DataReader’s and DataWriter’s registered type names must match exactly.
If either Step 1 or Step 2 fails, the Topics associated with the DataReader and DataWriter are considered to be inconsistent and the INCONSISTENT_TOPIC Status is updated.
The default enforcement kind is DDS_ALLOW_TYPE_COERCION. However, when the middleware is introspecting the built-in topic data declaration of a remote DataReader in order to determine whether it can match with a local DataWriter, if it observes that no TypeConsistencyEnforcementQosPolicy value is provided (as would be the case when communicating with a Service implementation not in conformance with this specification), it assumes a kind of DDS_DISALLOW_TYPE_COERCION.
Values for TypeConsistencyKind
With this setting, the DataWriter and DataReader must support the same data type in order for them to communicate. (This is the degree of enforcement required by the OMG DDS Specification prior to theOMG ‘Extensible and Dynamic Topic Types for DDS’ Specification.)
When Connext DDS is introspecting the built-in topic data declaration of a remote DataWriter or DataReader, if no TypeConsistencyEnforcementQosPolicy value is provided (as would be the case when communicating with an implementation not in conformance with the Extensible and Dynamic Topic Types for DDS" (DDS-XTypes) specification), Connext DDS shall assume a kind of DISALLOW_TYPE_COERCION.
With this setting, the DataWriter and the DataReader need not support the same data type in order for them to communicate, as long as the DataReader’s type is assignable from the DataWriter’s type.
For example, the following two extensible types will be assignable to each other since MyDerivedType contains all the members of MyBaseType (member_1) plus an additional element (member_2).
struct MyBaseType {
long member_1;
};
struct MyDerivedType: MyBaseType {
long member_2;
};
Even if MyDerivedType was not explicitly inherited from MyBaseType, the types would still be assignable. For example:
struct MyBaseType {
long member_1;
};
struct MyDerivedType {
long member_1;
long member_2;
};
For more information, see the RTI Connext DDS Core Libraries Getting Started Guide Addendum for Extensible Types and the OMG ‘Extensible and Dynamic Topic Types for DDS’ Specification.
Properties
This QosPolicy cannot be modified after the DataReader is enabled.
It only applies to DataReaders, so there is no requirement that the publishing and subscribing sides use compatible values.
Related QoS Policies
- None.
Applicable Entities
System Resource Considerations
None.
© 2018 RTI