[21899] SHM-only tranport (host id) is dependent from the real IPv4 adresses

[lexamor]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

SHM (only) transport should work on the same host independently if network interfaces have assigned IPv4 addresses or not.

Current behavior

All SHM locators are filtered out because Participants are considered to belong to different hosts, but this is not the case.

Steps to reproduce

1. Two DomainParticpinats (with the same QoS values, domain_id, etc) are always instantiated on the same (Linux) host, belong to different processes, and are executed under the same user.
2. No network connection (WiFi or Ethernet) is established
3. Set DomainParticipants QoS to use only shared memory transport. i.e

    DomainParticipantQos pqos = fastdds::PARTICIPANT_QOS_DEFAULT;
    pqos.transport().use_builtin_transports = false;
    auto shm_transport = std::make_shared<eprosima::fastdds::rtps::SharedMemTransportDescriptor>();
    pqos.transport().user_transports.push_back(shm_transport);

4. Run first app
5. Connect host to the network (connect LAN cable, WiFi, etc) -> as a result, a real IPv4 (e.g. 192.168..) addr will be assigned to some network interface
6. Run the second app
7. As a result participants are not discovered because the first Participant calculated host_id value using "fallback" way without knowledge of an IPv4 locator, but the second Participant used IPv4 addr value for host_id calculation. Later, this calculated host_id value is encoded in the Participant discovery meta-packet with offered traffic locators and announced to another remote participant. But since the values of host_id are different, participants are considered to belong to different hosts, and all SHM locators are filtered out. https://github.com/eProsima/Fast-DDS/blob/v2.14.1/src/cpp/rtps/builtin/data/ParticipantProxyData.cpp#L542 https://github.com/eProsima/Fast-DDS/blob/v2.14.1/src/cpp/rtps/builtin/data/ProxyDataFilters.hpp#L50
   And since we have only SHM transport enabled, and do not have any other transport locators, the (Participant) discovery is not finished and no further steps (i.e. EDP, data exchange) happened.

The opposite scenario, when IPv4 addr is available during the first Participant instantiation, and before the second Participant launch interface goes down/disconnects is also reproducible.

Fast DDS version/commit

2.6.9
2.14.1

Platform/Architecture

Ubuntu Focal 20.04 amd64, Other. Please specify in Additional context section.

Transport layer

Shared Memory Transport (SHM)

Additional context

No response

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[Mario-DL]

Hi @lexamor,
Thanks for the detailed report. I could reproduce the issue, we will try to come up with a solution in the upcoming time.

[lexamor]

Thank you @Mario-DL,
One of the ideas for how to deal with this FMPOV, is to use a more "reliable" system identifier for the host ID value calculation, for Linux(systemd) it could be the machine-id, but of course, it is not a portable way for all supported platforms (e.g. Windows, etc).

[MiguelCompany]

@lexamor We recently merged #5382, where we included the kind of mechanism you mention.

[lexamor]

Many thanks! @MiguelCompany @Mario-DL
Are there any plans to backport it into the 2.x branch or will it only be available in the 3.x ?

[Mario-DL]

Hi @lexamor,
We are partially backporting #5382 in #5410. In particular, a fix for TCP, but unfortunately not the new host-id calculation.

[p-zzg]

@lexamor May I ask if the issue of 'only the host depends on the real IP address' has been fixed?