SHM transport is not used when network interfaces list changes due to creating a new docker container

[ksuszka]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

Running a new, unrelated docker container on a machine should not change the ability to use shared memory transport between processes running on the host or in a separate container sharing a network with the host.

Current behavior

Running a new, unrelated docker container on a machine changes the list of network interfaces on that machine so processes started on that machine before and after the mentioned container was created most likely have different host id and don't use the shared memory transport.

Steps to reproduce

1. Run some message publisher on the host.
2. Run subscriber on the host (SHM transport is used)
3. Start a new unrelated docker container on the host with a default network mode
4. Run subscriber on the host (SHM tranposrt is not used)

Fast DDS version/commit

ros-humble-fastcdr/jammy,now 1.0.24-2jammy.20221108.143821 amd64 [installed,automatic]
ros-humble-fastrtps-cmake-module/jammy,now 2.2.0-2jammy.20230112.142430 amd64 [installed,automatic]
ros-humble-fastrtps/jammy,now 2.6.4-1jammy.20230117.223829 amd64 [installed,automatic]
ros-humble-rmw-fastrtps-cpp/jammy,now 6.2.2-1jammy.20230117.225910 amd64 [installed,automatic]
ros-humble-rmw-fastrtps-shared-cpp/jammy,now 6.2.2-1jammy.20230117.225455 amd64 [installed,automatic]
ros-humble-rosidl-typesupport-fastrtps-c/jammy,now 2.2.0-2jammy.20230112.145514 amd64 [installed,automatic]
ros-humble-rosidl-typesupport-fastrtps-cpp/jammy,now 2.2.0-2jammy.20230112.145146 amd64 [installed,automatic]

Platform/Architecture

Other. Please specify in Additional context section.

Transport layer

Default configuration, UDPv4 & SHM

Additional context

Tested on ros:humble docker images based on Ubuntu 22.04.

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[JLBuenoLopez]

Thanks, @ksuszka, for your contribution!

I have clarified this point in eProsima/Fast-DDS-docs#487. If SHM transport is exclusively in use, you shall ensure that network interfaces does not change. Otherwise, Fast DDS will consider the new DomainParticipants to be running in a different Host and therefore inaccessible using SHM (even though both are in fact running in the same machine). This could be improved and I have labeled as enhancement. According to Fast DDS contributing guidelines I am moving this ticket to the Ideas discussion forum.