You are here:

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 "Extensible and Dynamic Topic Types for DDS" (DDS-XTypes) specification describes four different type representations: IDL, TypeObject, XML, and XSD.

5.1 TypeObject and TypeCode Type Representation

Earlier versions of Connext DDS (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.

Connext DDS 5.x and higher supports TypeObjects v1 as the wire representation. TypeObjects v2 are not supported. To maintain backward compatibility with previous releases, this release still supports propagation of TypeCodes; however, support for this feature may be discontinued in future releases.

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 and RTI Spreadsheet Add-in for Microsoft Excel. With the introduction of TypeObjects, this limitation is removed since the size of the serialized representation is not bounded.

To summarize:

	Connext DDS 5.x and Higher	Connext DDS 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.

Table 5.1 TypeObject Fields in DomainParticipantResourceLimitsQosPolicy
Type	Field	Description
DDS_Long	type_object_max_serialized_length	The maximum length, in bytes, that the buffer to serialize a TypeObject can consume. This parameter limits the size of the TypeObject that a DomainParticipant is able to propagate. 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 TypeObjects larger than the default maximum of 3072 bytes. This field allows you to specify a larger value. Cannot be UNLIMITED. Default: 8192
DDS_Long	type_object_max_deserialized_length	The maximum number of bytes that a deserialized TypeObject can consume. This parameter limits the size of the TypeObject that a DomainParticipant is able to store. Default: UNLIMITED
DDS_Long	deserialized_type_object_dynamic_allocation_threshold	A threshold, in bytes, for dynamic memory allocation for the deserialized TypeObject. Above it, the memory for a TypeObject is allocated dynamically. Below it, the memory is obtained from a pool of fixed-size buffers. The size of the buffers is equal to this threshold. Default: 4096

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 DDS 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 DDS Core Libraries User's Manual.

By default, Connext DDS 5.3.1 and lower propagated both the pre-standard TypeCode and the TypeObject. Connext DDS 6.0.0 and higher only propagates TypeObjects by default. You can change this behavior:

To propagate TypeObject only:	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 (default):	Use the default values of type_code_max_serialized_length and type_object_max_serialized_length or modify them if the type size requires so.

5.2 XML and XSD Type Representations

The XML and XSD type-representation formats available in Connext DDS 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 DDS, 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 DDS see the section "Creating User Data Types with XML Schemas (XSD)" in the RTI Connext DDS 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 “Extensible and Dynamic Topic Types for DDS” specification.