How to use RTI Connext DDS to Communicate Across Docker Containers Using the Host Driver

When using the “host” Docker driver, all network interfaces of the host machine are accessible from the Docker container. Furthermore, there is no networking namespace separation between the Docker containers and the host machine.

To run a container in host mode, run the following command:

$ docker run --network="host" -ti <Docker image> <Program>  

Possible scenarios

Communication within a host machine (Docker container to Docker container, or Docker container to host machine):

The configuration of the Docker container can affect the ability of RTI Connext DDS to communicate using the Docker "host" driver if shared memory is enabled. This is due to how the GUID that identifies every DDS Entity is generated.

By default, RTI Connext DDS generates the GUID as follows (for more information, see section “8.5.9.4 Controlling How the GUID is Set” of the RTI Connext DDS User’s Manual):

  • 32 bits for the Host ID (rtps_host_id). The Host ID is currently based upon the IP address by default (although this might change in future versions). This will allow you to determine the node having the GUID problem.

  • 16 low bits for the Application ID ( rtps_app_id).
    • If the originating node is a Windows system, the relevant Process ID will be the value of GetCurrentProcessId().

    • On a VxWorks system, it will be the Task ID of a specific task.

    • On a Linux system, it will be the Process ID that you can see as the output of the command ps -ef.
  • 8 bits for an Internal Counter. This counter allows an application to create multiple DomainParticipants in the same domain.

  • 8 bits containing a Constant Value (0x01).

As we mentioned before, the host Docker driver mode could affect this generation process as follows:

  1. All the containers in host driver mode will have the same IP address; therefore, they will have the same Host ID.

  2. Due to the way process IDs are generated, two applications in two containers could have the same Process ID; therefore, they could have the same Application ID.

In this case, RTI Connext DDS will interpret that both applications are in the same machine and will try to communicate using shared memory. This is an optimization done by our Shared Memory transport. To resolve this, there are three possible solutions:

  1. Disabling the Shared Memory transport, as explained in Section "8.5.7 TRANSPORT_BUILTIN QosPolicy (DDS Extension)" of the RTI Connext DDS Core Libraries User’s Manual.

  2. Configuring your RTI Connext DDS applications and Docker containers to enable communication using shared memory, as explained in this Knowledge Base article.

  3. Changing how the GUID is set, as explained in Section “8.5.9.4 Controlling How the GUID is Set” of the RTI Connext DDS Core Libraries User’s Manual.

Communication across machines (Docker to Docker, or Docker to a remote host)

In this case, you should get out-of-the-box communication. That is, you should be able to communicate with RTI Connext DDS applications running on other machines (whether they are running on Docker containers or not).

This happens because a Docker container behaves just like any other regular process, despite having some resource isolation. With the host driver, the container will use the same network stack that any other process would use.

Platform:
Keywords: