Questions about network matching algorithms

[p-zzg]

Is there an already existing issue for this?

• [X] I have searched the existing issues

Expected behavior

Multi-host communication does not depend on whitelists Is there a strategy to prevent UDP sendto from blocking?

Current behavior

udp_transport->interface_allowlist.emplace_back("eth2eth", NetmaskFilterKind::OFF); udp_transport->interface_allowlist.emplace_back("lo", NetmaskFilterKind::OFF); qos.transport().user_transports.push_back(udp_transport); qos.transport().use_builtin_transports = false;

The network port on network segment 1.x is set in my whitelist, excluding network segment 2.x

This issue was fixed after I set the whitelist of the Nic name But I don't want this whitelist to restrict my network communications

Steps to reproduce

The structure of my network is shown below：

I tried using host3 to publish data, host1 and host2 subscribe, but it blocked unexpectedly I used strace to look at the system function execution of the process and found that it was blocking in UDP sendto host3 attempts to send data to the IP address of 192.168.2.x, but the IP address is unreachable Is this a BUG in the DDS internal network matching mechanism?

Fast DDS version/commit

2.14.0

Platform/Architecture

Ubuntu Focal 20.04 amd64

Transport layer

Default configuration, UDPv4 & SHM

Additional context

No response

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[elianalf]

Hi @Heyangq, thanks for using Fast DDS.

Since 192.168.2.x is unreachable for host3, you can try to set NetmaskFilterKind to ON at participant level (so that it is applied to all the interfaces) as shown here:

qos.transport().netmask_filter = NetmaskFilterKind::AUTO;
qos.wire_protocol().ignore_non_matching_locators = true; // Required if not defining an allowlist or blocklist

this way host3 will filter-out that IP address before trying to send the data. For more information about it have a look to the docs.

[p-zzg]

Hi @Heyangq, thanks for using Fast DDS.

Since 192.168.2.x is unreachable for host3, you can try to set NetmaskFilterKind to ON at participant level (so that it is applied to all the interfaces) as shown here:

qos.transport().netmask_filter = NetmaskFilterKind::AUTO;
qos.wire_protocol().ignore_non_matching_locators = true; // Required if not defining an allowlist or blocklist

this way host3 will filter-out that IP address before trying to send the data. For more information about it have a look to the docs.

I also tried the above solution, but there was still blocking, still caught the sendto function blocking from 1.x to 2.x

[p-zzg]

Hi @Heyangq, thanks for using Fast DDS.

Since 192.168.2.x is unreachable for host3, you can try to set NetmaskFilterKind to ON at participant level (so that it is applied to all the interfaces) as shown here:

qos.transport().netmask_filter = NetmaskFilterKind::AUTO;
qos.wire_protocol().ignore_non_matching_locators = true; // Required if not defining an allowlist or blocklist

this way host3 will filter-out that IP address before trying to send the data. For more information about it have a look to the docs.

// qos.setup_transports(eprosima::fastdds::rtps::BuiltinTransports::LARGE_DATA);

auto udp_transport = std::make_shared<UDPv4TransportDescriptor>();
udp_transport->interface_allowlist.emplace_back("eth2eth", NetmaskFilterKind::OFF);
udp_transport->interface_allowlist.emplace_back("lo", NetmaskFilterKind::OFF);
qos.transport().user_transports.push_back(udp_transport);
qos.transport().use_builtin_transports = false;

// qos.transport().netmask_filter = NetmaskFilterKind::AUTO;
// qos.wire_protocol().ignore_non_matching_locators =true;

LARGE_DATA is also non-blocking because it is a TCP connection, but using LARGE_DATA prevents me from communicating with other modules that don't use LARGE_DATA
I tried to communicate with ROS2 foxy in Ubuntu20.04, foxy's FastDDS version is 2.1.x, so I could not use LARGE_DATA to implement my communication
The 2.1.x version of FastDDS does not support the setting of network card names. When I receive point cloud data across hosts, I often get blocked for a long time because of the IP unreachable problem. In fact, my host bandwidth is satisfied
My point cloud data is published through FastDDS, but it needs rviz of ROS2 to realize visualization. If the bandwidth is sufficient, what other solutions can achieve this requirement?

[elianalf]

Unfortunately, 2.1.x of Fast DDS is End-Of-Life, consequently we don't support it anymore. The only possibility is to use allowist or you could try to set NetmaskFilter directly to ON: qos.transport().netmask_filter = NetmaskFilterKind::ON;

[Javgilavi]

According to our CONTRIBUTING.md guidelines, I am closing this issue due to seaming to be resolved. Please feel free to reopen it if necessary.