# 14.5. Dynamic Types Discovery and Endpoint Matching¶

When using DynamicType support, Fast DDS checks the optional TypeObject and TypeIdentifier values during endpoint matching. Currently, the matching only verifies that both endpoints are using the same topic data type, but will not negotiate about it.

The process of checking the types is as follows:

• It checks CompleteTypeObject on TypeObject first.

• If one or both endpoints do not define the CompleteTypeObject, it tries with MinimalTypeObject.

• If one or both endpoints do not define MinimalTypeObject either, it compares the TypeIdentifier.

• If none is defined, then just the type name is checked.

If one of the endpoints transmits a CompleteTypeObject, Discovery-Time Data Typing can be performed.

## 14.5.1. TypeObject¶

TypeObject fully describes a data type, the same way as the IDL representation does. There are two kinds of TypeObjects: CompleteTypeObject and MinimalTypeObject .

• CompleteTypeObject fully describes the type, the same way as the IDL representation does.

• MinimalTypeObject is a compact representation of the data type, that contains only the information relevant for the remote Endpoint to be able to interpret the data.

TypeObject is an IDL union with both Minimal and Complete representation. Both are described in the annexes of DDS-XTypes V1.2 document, please refer to this document for details.

## 14.5.2. TypeInformation¶

TypeInformation is an extension of XTypes 1.2 that allow Endpoints to share information about data types without sending the TypeObject. Endpoints instead share a TypeInformation containing the TypeIdentifier of the data type. Then each Endpoint can request the complete TypeObject for the data types it is interested in. This avoids sending the complete data type to Endpoints that may not be interested.

TypeInformation is described in the annexes of DDS-XTypes V1.2 document, please refer to this document for details.

## 14.5.3. TypeIdentifier¶

TypeIdentifier provides a unique way to identify each type. For basic types, the information contained in the TypeIdentifier completely describes the type, while for complex ones, it serves as a search key to retrieve the complete TypeObject.

TypeIdentifier is described in the annexes of DDS-XTypes V1.2 document, please refer to this document for details.

## 14.5.4. TypeObjectFactory¶

Singleton class that manages the creation and access for every registered TypeObject and TypeIdentifier. It can generate a full DynamicType from a basic TypeIdentifier (i.e., one whose discriminator is not EK_MINIMAL or EK_COMPLETE).

## 14.5.5. Fast DDS-Gen¶

Fast DDS-Gen supports the generation of XXXTypeObject.h and XXXTypeObject.cxx files, taking XXX as our IDL type. These files provide a small Type Factory for the type XXX. Generally, these files are not used directly, as now the type XXX will register itself through its factory to TypeObjectFactory in its constructor, making it very easy to use static types with dynamic types.

## 14.5.6. Discovery-Time Data Typing¶

Using the Fast DDS API, when a participant discovers a remote endpoint that sends a complete TypeObject or a simple TypeIdentifier describing a type that the participant does not know, the participant listener’s function on_type_discovery is called with the received TypeObject or TypeIdentifier, and, when possible, a pointer to a DynamicType ready to be used.

Discovery-Time Data Typing allows the discovering of simple DynamicTypes. A TypeObject that depends on other TypeObjects, cannot be built locally using Discovery-Time Data Typing and should use TypeLookup Service instead.

To ease the sharing of the TypeObject and TypeIdentifier used by Discovery-Time Data Typing, TopicDataType contains a function member named auto_fill_type_object. If set to true, the local participant will send the TypeObject and TypeIdentifier to the remote endpoint during discovery.

## 14.5.7. TypeLookup Service¶

Using the Fast DDS API, when a participant discovers an endpoint that sends a type information describing a type that the participant doesn’t know, the participant listener’s function on_type_information_received() is called with the received TypeInformation. The user can then try to retrieve the full TypeObject hierarchy to build the remote type locally, using the TypeLookup Service.

To enable this builtin TypeLookup Service, the user must enable it in the QoS of the DomainParticipant:

DomainParticipantQos qos;
qos.wire_protocol().builtin.typelookup_config.use_client = true;
qos.wire_protocol().builtin.typelookup_config.use_server = true;


A participant can be enabled to act as a TypeLookup server, client, or both.

The process of retrieving the remote type from its TypeInformation, and then registering it, can be simplified using the register_remote_type function on the DomainParticipant. This function takes the name of the type, the type information, and a callback function. Internally it uses the TypeLookup Service to retrieve the full TypeObject, and, if successful, it will call the callback.

This callback has the following signature:

void(std::string& type_name, const DynamicType_ptr type)

• type_name: Is the name given to the type when calling register_remote_type, to allow the same callback to be used across different calls.

• type: If the register_remote_type was able to build and register a DynamicType, this parameter contains a pointer to the type. Otherwise it contains nullptr. In the latter case, the user can still try to build the type manually using the factories, but it is very likely that the build process will fail.

TopicDataType contains a data member named auto_fill_type_information. If set to true, the local participant will send the type information to the remote endpoint during discovery.