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:
CompleteTypeObjecton TypeObject first.
If one or both endpoints do not define the
CompleteTypeObject, it tries with
If one or both endpoints do not define
MinimalTypeObjecteither, 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.
TypeObject fully describes a data type, the same way as the IDL representation does.
There are two kinds of TypeObjects:
CompleteTypeObjectfully describes the type, the same way as the IDL representation does.
MinimalTypeObjectis 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.
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.
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.
Singleton class that manages the creation and access for every registered TypeObject
It can generate a full DynamicType from a basic
TypeIdentifier (i.e., one whose discriminator is not
14.5.5. Fast DDS-Gen¶
Fast DDS-Gen supports the generation of XXXTypeObject.h and XXXTypeObject.cxx files,
XXX as our IDL type.
These files provide a small Type Factory for the type
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
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
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
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
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
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_typewas 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.