I am trying to interoperate with other DDS implementations. I can successfully publish and subscribe between domain participants that both have the type information. However, I can’t subscribe to any topic published by another DDS implementation (cyclone) with either the rtirecordingservice or the rtiadminconsole. (ie tools that acquire the type dynamically)
Looking at the documentation, it seems rti does not support the TypeLookup service or the ‘type’ member in PublicationBuiltinTopicData and SubscriptionBuiltinTopicData [1] . How does rti support dynamically acquiring the type information if it doesn't support either of those methods?
It seems to be able to send TypeObject’s [3] but I am not sure what discovery topic or message this TypeObject is sent. Perhaps it is also in a proprietary field like the compressed TypeObjectLb which is noted as being in proprietary field in a community forum? [2]
[2] https://community.rti.com/forum-topic/rtps-typeobject-proprietary-field
DataTypes of DataWriters and DataReaders are propagated as TypeObject in Connext DDS (and per the DDS Standard).
In Publication/SubscriptionBuiltinTopicData, unfortunately, the DDS Standard does specify how to access a datatype found during discovery via those structures. There is no "type" member defined by the DDS standard for those structures.
Thus, different vendors must decide on their own how/if to expose that functionality in their API. RTI does this by adding a type field (Modern C++) or type_code field (Traditional C++/C) to those structures and documented as <<extensions>>.
However, even without exposing the type object to user code through an API, internally, type objects are propogated as a part of the DATA(r) or DATA(w) samples for the builtin discovery topics that are exchanged during discovery.
RTI's type object implementation complies with the DDS standard and is interoperable.
HOWEVER, RTI did make an extension in which we compress the type object in the DATA(r) and DATA(w)...since those objects can be quite big and are very compressible (lots of strings).
AND by default, RTI Connext will send type objects in compressed mode so that our discovery is more efficient. But what this means is that if you want to interoperate with other DDS versions, you have to disable the type code compresssion via QoS settings.
To disable type object compression, you should set
ParticipantQos.discovery_config.endpoint_type_object_lb_serialization_threshold = -1
https://community.rti.com/static/documentation/connext-dds/current/doc/api/connext_dds/api_cpp/structDDS__DiscoveryConfigQosPolicy.html#a263882fe07ecff867beebf0c1fe80c6b
That would have to be done in the ParticipantQos configuration for the participants created by the Recording Service or Admin Console.
HOWEVER, if a Connext DDS participant should be able to receive and process standard type objects that are sent in discovery messages by other vendors, even if the participant isn't configured to send uncompressed type objects.
So, can RTI Admin Console "see" the CycloneDDS participant? And DataWriters/DataReaders created by that participant? If so, if you select the DataWriter/DataReader, can Admin Console display the Type information for that Entity? If so, then Admin Console know what the data type is.
I assume when you use Admin Console to subscribe to the Topic sent by Cyclone, it allows you to do so? If true, then that's another indication that Admin Console knows what the data type is (otherwise it wouldn't be able to create a subscriber/datareader).
If the problem is that you're just not seeing the data being received, that it's possibly the typ eobject compression problem, and you have to configure the Admin Console Visualization participant to not compress type objects.
If you cannot see what the data type is in Admin Console (of the CycloneDDS created datawriter), then CycloneDDS is not propagating the type object.
You can use wireshark to check. With wireshark, you can check the DATA(w) packets sent by the Cyclone application, and see if it has a typeobject included in the data packet...
Another thing you can try is set the environment variable:
NDDS_XTYPES_COMPLIANCE_MASK = 0x000000a9
before starting Admin Console or Recording Service. You can read why here:
https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/extensible_types_guide/extensible_types/Data_Representation.htm
However, if you were able to get your own RTI Connext DDS application to pub/sub with a CycloneDDS application without using the environment variable, then it's not likely to be the problem (assuming you are using the same data types in both tests).
And finally, if CycloneDDS setting "force_type_validation" is used, then the application may report a type mismatch when interoperating with Connext. The only workaround is to not set force_type_validation.
As you mentioned, RTI Connext Pro doesn't yet support TypeLookup Service (or TypeObjectV2) as defined by the XTypes v1.3 specification. Our next LTS release will support TypeLookup Service (and integration with RTI Tools and Infrastructure Services).
Until then, if the remote applications are using TypeLookup Service to propagate types, you will need to either provide the types via XML, or modify the remote application to use TypeObjectV1.
Oh yes, as Sam stated, if you use "rtiddsgen", you can generate the XML version of the IDLs (the type definition files) that define the data types used in the CycloneDDS application, and then use those XML files to define the data type when using Admin Console (via the Subscribe dialog box and the "Load datatypes from XML file" link)
or in Recording Service, see this doc: https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/services/recording_service/replay/replay_configuration.html#xml-tags-for-configuring-replay-service, specifically the <types> tag. Here is an example: https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/services/recording_service/recorder/record_configuration.html#example-configuration-to-enable-both-flatdata-and-zero-copy-transfer-over-shared-memory)