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 withMinimalTypeObject
.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;
<participant profile_name="participant_typelookup_service_enabled">
<rtps>
<builtin>
<typelookup_config>
<use_client>true</use_client>
<use_server>true</use_server>
</typelookup_config>
</builtin>
</rtps>
</participant>
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 containsnullptr
. 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.