Why two applications cannot communicate using shared memory when their network interface cards are different

Submitted by acasado on Wed, 12/20/2017 - 07:43

RTI Connext DDS assigns a number, called a GUID, to each entity in order to uniquely identify it for the discovery process to work correctly. You can control how to set the GUID using the value assigned to rtps_auto_id_kind. For more information, see Controlling How the GUID is Set (rtps_auto_id_kind) in the RTI Connext DDS Core Libraries User’s Manual, here for the current release or here for release 5.3.0.

The GUID is composed of three parts:

  1. rtps_host_id: the 32-bit value of the IPv4 of the first up and running interface of the host machine is assigned to this field. The value is based on the identity of the machine on which the participant is executing. This is the default behavior, but it is possible to change this behavior using the QoS rtps_auto_id_kind, as mentioned.
  2. rtps_app_id: the process (or task) ID is assigned to this field.
  3. rtps_instance_id: a counter is assigned to this field that is incremented for each new participant and identifies the participant itself.

Check out how to access the GUID from the RTI DDS entities through the code in this article.

By default, RTI Connext DDS queries the operating system for the interfaces to set the rtps_host_id. The value is based on the identity of the machine where the entity is being executed. To have two entities communicating through shared memory, both must be on the same machine. In other words, they must have the same IP address. If the IP address changes and a new entity is created or an old one rebooted, rtps_host_id---which is based on the IP address---will be different. So the application will understand that the entities are on different machines.

If we are running our applications on a machine with multiple network interfaces, the following scenario could happen:

  1. A network interface is enabled. We run one application.

  2. For some reason, the network interface gets disabled.

  3. Another network interface is used since the other one is down. So, we run a second application.

  4. Now, we have two applications running on the same machine, each with a different host_id. In this scenario, the middleware concludes that the applications are on different machines and communication using shared memory fails.

To allow these applications to communicate using shared memory,  manually set the  host_id of the applications. This forces the applications to have the same  rtps_host_id value, despite having different IP addresses, and they will be able to communicate using shared memory.

An easy way to manually set the  host_id is to add  this snippet to your QoS profile:

<participant_qos>
    <wire_protocol>
        <rtps_host_id>my_host_id_value</rtps_host_id>
    </wire_protocol>
</participant_qos>
Product:
Keywords: