Incompatibility between DDS5.2 and DDS5.0

5 posts / 0 new
Last post
Last seen: 1 year 4 months ago
Joined: 03/25/2015
Posts: 33
Incompatibility between DDS5.2 and DDS5.0


I have moved all applications, whichever I am aware of, from DDS5.0 to DDS5.2. Finally after deploying all my applications onto the target I get the following error for some of my DDS topics:

COMMENDBeWriterService_assertRemoteReader:Discovered remote reader using a non-addressable locator for a transport with class ID 16777216.
This can occur if the transport is not installed and/or enabled in the local participant.
See for additional info.
can't reach:
transport: 16777216
address: 0000:0004:0001:0000:0000:0000:0000:0000
port: 7470
transport_priority: 0
aliasList: ""

Looks like there are still some application(s) which are not moved to DDS5.2. If I understand correctly, the above error occurs for a topic where the listener and writer are incompatible.

What are the approaches I can take to detect that listener which is still in DDS5.0. BTW, my target has DDS5.2 libraries deployed. Just that some applications are statically linked.



Last seen: 4 years 10 months ago
Joined: 01/18/2016
Posts: 1

Similarly my organization just moved from DDS5.0 to DDS5.2 and we are seeing the same errors.  We would like to know how to resolve this issue.

Last seen: 3 years 3 months ago
Joined: 12/02/2015
Posts: 3

One way to check which app is running 5.0.0 is to use Admin Console. I attached a screenshot showing how to check the version number.

Fernando Garcia's picture
Last seen: 3 weeks 1 day ago
Joined: 05/18/2011
Posts: 199

In Connext DDS 5.2.0, the UDPv6 and SHMEM transport kinds changed to address an RTPS-compliance issue (RTI Issue ID CORE-5788). You can configure your 5.2.0 to be backwards compatible with 5.1.0 and earlier either by using the Generic.510TransportCompatibility QoS profile or the alternative solution described in this Knowledge Base article. Also, this section of the User's Manual includes further information on how to tackle this issue.

I agree with Vlad, the easiest way to detect whether an application is running RTI Connext DDS 5.0.0 is to use Admin Console. As a side note, RTI Connext DDS 5.2.0 libraries introduced a "build id" that you can query using the strings command. For instance if you want to know the build ID of libnddsc.dylib you can run:

$ strings lib/x64Darwin14clang6.0/libnddsc.dylib | grep BUILD

You can do the same with applications that are statically linked against 5.2.0. For instance, rtiddsping is a C++ application statically linked against libnddscorez.a, libnddscz.a, and libnddscppz.a:

$ strings resource/app/bin/x64Darwin12clang4.1/rtiddsping | grep BUILD

Please, let us know if there is anything else we can help you with.


Last seen: 1 year 4 months ago
Joined: 03/25/2015
Posts: 33

Hi Fernando and Vlad,

Thanks for your inputs. Actual problem is kind of root caused now. There were infact 2 problems. In one case it is resolved through makinf QoS uniform - especially with message_max_size.

The other problem is persistent. It is because one of the subsystems is on a different machine, and shared memory is not enabled on this machine. That is the reason of seeing the message "Discovered remote reader using a non-addressable locator...", which is a bit nagging. My machines are set up in the same manner even with DDS5.0. It is just that these messages are being thrown to stdout now with DDS5.2.

I have opened a different topic where I need some help - Wanted to take advantage of this post, as you guys will definitely look into this post :-).