Chapter 5 Type Representation
The type representation specifies the ways in which a type can be externalized so that it can be stored in a file or sent over the network.
The OMG 'Extensible and Dynamic Topic Types for DDS' specification, version 1.3 describes four different type representations: IDL, TypeObject, XML, and XSD.
5.1 TypeObject and TypeCode Type Representation
Earlier versions of Connext (4.5f and lower) used TypeCodes as the wire representation to communicate types over the network and the TypeCode API to introspect and manipulate the types at run time.
The Extensible Types specification uses TypeObjects as the wire representation and the DynamicType API to introspect and manipulate the types. Types are propagated by serializing the associated TypeObject representation.
This release does not enable TypeCode propagation by default, but to maintain backward compatibility with previous releases it can be enabled; see the section, "TypeCode information is not sent by default" in the Migration Guide on the RTI Community Portal (https://community.rti.com/documentation). Support for the TypeCodes feature may be discontinued in future releases.
Connext 5.x and higher supports TypeObjects v1 as the wire representation. (TypeObjects v2, which were introduced in Extensible and Dynamic Topic Types for DDS 1.2, are not supported.)
In this release, only Modern C++ supports the DynamicType API to introspect the types at runtime. Other language bindings must use the TypeCode API.
You can introspect the discovered type independently of the wire format by using the type_code member in the PublicationBuiltinTopicData and SubscriptionBuiltinTopicData structures for all language bindings but Modern C++. In Modern C++, the type information can be accessed using the type() or get_type_no_copy() accessors.
One important limitation of using TypeCodes as the wire representation is that their serialized size is limited to 65 KB. This is a problem for services and tools that depend on the discovered types, such as RTI Routing Service . With the introduction of TypeObjects, this limitation is removed since the size of the serialized representation is not bounded.
To summarize:
|
Connext 5.x and Higher |
Connext 4.5f and Earlier |
Wire Representation |
TypeObjects or TypeCodes (for backwards compatibility) |
TypeCodes |
For Introspection at Run Time |
TypeCode API (DynamicType API for Modern C++) |
TypeCode API |
Maximum Size of Serialized Representation |
When using TypeObjects: Unbounded When using TypeCodes: 65 KB |
65 KB |
5.1.1 TypeObject Resource Limits
Table 5.1 TypeObject Fields in DomainParticipantResourceLimitsQosPolicy lists fields in the DomainParticipantResourceLimitsQosPolicy that control resource utilization when the TypeObjects in a DomainParticipant are stored and propagated.
Note that memory usage is optimized; only one instance of a TypeObject will be stored, even if multiple local or remote DataReaders or DataWriters use it.
The TypeObject is needed for type-assignability enforcement.
Since TypeObjects contain all of the information of a data structure, including the strings that define the names of the members of a structure, complex data structures can result in large TypeObjects that frequently require enabling asynchronous publication for discovery data.
To reduce bandwidth usage during discovery for large TypeObjects, Connext allows compressing the TypeObject information. Compression is enabled by default, and it can be configured using the QoS value DDS_DiscoveryConfigQosPolicy::endpoint_type_object_lb_serialization_threshold. For additional information, see the section “DISCOVERY_CONFIG QosPolicy” in the RTI Connext Core Libraries User's Manual.
By default, Connext 5.3.1 and lower propagated both the pre-standard TypeCode and the TypeObject. Connext 6.0.0 and higher only propagates TypeObjects by default. You can change this behavior:
To propagate TypeObject only (default): |
Set type_code_max_serialized_length = 0 |
To propagate TypeCode only: |
Set type_object_max_serialized_length = 0 |
To propagate none: |
Set type_code_max_serialized_length = 0 and type_object_max_serialized_length = 0 |
To propagate both: |
Use the default value of type_object_max_serialized_length, and change type_code_max_serialized_length from 0 to the desired length. Modify these values if the type size requires. |
5.2 XML and XSD Type Representations
The XML and XSD type-representation formats available in Connext formed the basis for the DDS-XTypes specification of these features.
The XML format is compatible with the format described in the XTypes specification.
The XSD format, however, has not been completely updated to the new standard format. For example, in Connext, built-in annotations are applied using comments, whereas in the XTypes specification they are applied using <xsd:annotation>.
For additional information on how to apply built-in annotations using XSD Type Representation in Connext see the section "Creating User Data Types with XML Schemas (XSD)" in the RTI Connext Core Libraries User's Manual.
For additional information on how to apply built-in annotations using XSD Type Representation in the XTypes specification, see the section “XSD Type Representation” in the OMG 'Extensible and Dynamic Topic Types for DDS' specification, version 1.3.