Compilibility problems of eProsima FastDDS and RTI Context DDS

6 posts / 0 new
Last post
Offline
Last seen: 1 month 3 days ago
Joined: 06/27/2020
Posts: 11
Compilibility problems of eProsima FastDDS and RTI Context DDS

I used eProsima FastDDS 2.2.0 and RTI Context DDS 6.0.1 for some interoperational demo example (both using out-of-box auto-generator),but the error below occurred on RTI Context side.

COMMENDSrWriterService_assertRemoteReader:Discovered remote reader with GUID 0X10F44B6,0XA8426118,0X1000000,0X200C7 using a non-addressable locator.
This can occur if the transport is not installed and/or enabled in the local participant.
See https://community.rti.com/kb/what-does-cant-reach-locator-error-message-mean for additional info.
can't reach: locator: 16://5544:B600:0000:0000:0000:0000:0000:0000:7412

 

Thanks in advance!

Organization:
Howard's picture
Offline
Last seen: 5 days 18 hours ago
Joined: 11/29/2012
Posts: 177

This means that the eProsima application is sending a "locator" which is an address that the RTI Connext application does not know how to send to.

"locators"...aka addresses...are propagated in the discovery process to let one application know how to contact the other application.  In this case, the locator sent by the eProsima application is one which the Connext application has no idea what to do with...

16://5544:B600:0000:0000:0000:0000:0000:0000:7412

the "16://" part is a transport class id.  For UDPv4 transport, the class id should be "1" and would have been interpreted as "udpv4" in the error message if it was "1".

The address "5544:B600:0000:0000:0000:0000:0000:0000" also looks strange...it's seems to be in little Endian order and not the expected network order which is big Endian.

5544:B600  = 85.68.182.0  if trying to interpret as an IPv4 address.

That doesn't seem right in either little or big Endian order. 

Thus I guess that eProsima is sending a locator for some eProsima-specific transport not supported or defined by the DDS RTPS spec.  Perhaps some custom shared memory transport?

I would suggest looking at the FastDDS docs to only enable the standard UDPv4 transport.

 

Offline
Last seen: 1 month 3 days ago
Joined: 06/27/2020
Posts: 11

That's correct, thank you !

According to eProsima FastDDS docs, "16://" is for LOCATOR_KIND_SHM and "5544:B600:0000:0000:0000:0000:0000:0000" contains a unique ID for the local host, with the port representing the shared ring buffer used to communicate buffer descriptors.

So, the next problem is that, is there any specification to define the locator of each transport?

I found Locator_t in OMG RTPS specification but no LOCATOR_KIND_SHM ,or class id definition of others either.

https://www.omg.org/spec/DDSI-RTPS/2.3/PDF Page 22

In my opinion, it's a big interoperational problem.

Thank you very much.

Howard's picture
Offline
Last seen: 5 days 18 hours ago
Joined: 11/29/2012
Posts: 177

So, this is documented in the spec (v2.3):

pg 22:

Locator_t
Type used to represent the addressing information needed to send a message to an RTPS Endpoint using one of the supported transports.
Should be able to hold a discriminator identifying the kind of transport, an address, and a port number. It must be possible to represent the discriminator and port number using 4 octets each, the address using 16 octets.
The following values are reserved by the protocol: LOCATOR_INVALID LOCATOR_KIND_INVALID LOCATOR_KIND_RESERVED LOCATOR_KIND_UDPv4 LOCATOR_KIND_UDPv6 LOCATOR_ADDRESS_INVALID LOCATOR_PORT_INVALID

pg 145:

const long LOCATOR_KIND_INVALID = -1;
const long LOCATOR_KIND_RESERVED = 0;
const long LOCATOR_KIND_UDPv4 = 1;
const long LOCATOR_KIND_UDPv6 = 2;
const unsigned long LOCATOR_PORT_INVALID = 0;

 

So, the DDS RTPS specification only standardizes the UDPv4 and UDPv6 transports.  The DDS-TCP spec will be adding the locator kind for TCP transport.

There is no standardization of a shared memory transport.  So all shared memory transports offered by DDS implementations are specific to the implementation and not interoperable between different implementations.

Offline
Last seen: 1 month 3 days ago
Joined: 06/27/2020
Posts: 11

Thank you very much.

So before DDS-TCP spec being launched, there is no standardization of DDS TCP transport or TCP-based discovery(etc.) either, correct ? 

Howard's picture
Offline
Last seen: 5 days 18 hours ago
Joined: 11/29/2012
Posts: 177

That is correct.  Many versions of DDS have TCP transports which are currently not compatible/interoperable.  When the DDS TCP spec is finalized, then we would expect all DDS Implementations to change their TCP transport to meet the spec.