What causes this error: "PRESParticipant_checkTransportInfoMatching:Warning: discovered remote participant 'yyyyy' using the 'shmem' transport with class ID 2"

Submitted by belen on Wed, 03/25/2015 - 10:05

 

Note: Applies to RTI Connext 5.2.0 and above.

The following error:

PRESParticipant_checkTransportInfoMatching:Warning: discovered remote participant 'yyyyy' using the 'shmem' transport with class ID 2. 
This class ID does not match the class ID 16777216 of the same transport in the local participant 'xxxxx'. 
These two participants will not communicate over the 'shmem' transport.

is caused when two applications, one using RTI Connext 5.2.0 or later, and one using a previous release of RTI Connext, run on the same node and have the shared memory and UDPv6 transports enabled.

The application running RTI Connext 5.1.0 or earlier will show the following error:

can't reach: 
locator: 
   transport: 16777216 
   address: 0000:0000:0100:0000:0000:0000:0000:0000 
   port: 21410 
   encapsulation: 
transport_priority: 0 
aliasList: ""

These applications will not communicate over UDPv6 and shared memory. If you need communication between RTI Connext 5.2.0 and previous releases, there are two options:

  • Set the DomainParticipant's property dds.transport.use_510_compatible_locator_kinds to 1 in the RTI COnnext 5.2.0 applications.
    For example:
<participant_qos>
    <property>
	<value>
	    <element>
		<name>dds.transport.use_510_compatible_locator_kinds</name>
		<value>1</value>
	    </element>
	</value>
    </property>
</participant_qos>
  • Use the new built-in Generic.510TransportCompatibility QoS profile. The following example shows how to inherit from this profile when configuring QoS settings:
<qos_profile name="MyProfile" base_name="BuiltinQosLib::Generic.510TransportCompatibility">
...
</qos_profile>

 

Product:
Platform:
Keywords:

Comments

MathieuMathieu

Thu, 11/10/2016 - 09:21

I'm struggling through this but none of these 2 solutions solve my problem. I'm still getting "can't reach locator: transport: 5" while using both of the methods.

Moreover, to use the "

<qos_profile name="MyProfile" base_name="Generic.510TransportCompatibility">" method, you need to change
base_name="Generic.510TransportCompatibility" with
base_name="BuiltinQosLib::Generic.510TransportCompatibility"

otherwise an error will occur.
 
Cheers,
 
Mathieu

renu555

Mon, 09/11/2017 - 23:36

My machine has 5.2.3 connext dds and my application is built in 5.2.3 connext dds.but when i m opening rti admin console on the same machine i unfortunately get this error.

Benito Palacios

Wed, 09/13/2017 - 03:37

Can you provide us with the full error message you get? I recommend you to take a look into the following KB solution, it may be related: https://community.rti.com/kb/what-does-cant-reach-locator-error-message-mean

renu555

Thu, 09/14/2017 - 02:44

Error message

renu555

Thu, 09/14/2017 - 02:46

I m using rti connext 5.2.3 in both participant....if transport is not enabled kindly help me out in enabling it

bobby

Fri, 09/15/2017 - 08:55

Hi renu555,

From your screenshot it looks like you are running an RTI Admin Console that is not 5.2.3. The error message is pretty clear in your screenshot, the RTI Admin Console is using 2 as the transport ID for the shared memory transport. To be complient with the RTPS specification, in 5.2.0 we changed the transport ID (class ID) for shared memory to 16777216.

So double check which version of RTI Administration Console you are running. You can do that by going into the About Dialog window once you are in the application. You will want to also double check that you are launching Admin Console from the correct RTI Launcher. If you have multiple versions of RTI Connext installed you might be accidently running RTI Launcher 5.1.0 and launching Admin Console from there.

Regards,

Bobby

actinium226

Wed, 07/10/2019 - 10:40

I'm getting this issue when trying to publish from a ROS2 node and listen with a DDS node that I created with rtiddsgen from Connext 5.3.1. I get the same issue the other way around, i.e. when publishing from a DDS node and listening with a ROS2 node.

If I build with Connext 6.0.0 I can publish from a DDS node and listen with a ROS2 node, but not the other way around.

Interestingly, with Docker, I'm able to pub/sub both ways (in my Docker I only have Connext 5.3.1)

I had tried the suggested solution here, but it didn't fix the issue. Any other suggestions?