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.

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 8192 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 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.