Feature [Request / Discussion] Decentralized discovery and communication between networks

[andreclerigo]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

The possibility of having decentralized processes of discovery and communication between networks and within the network itself.

Solution 1 - The possibility of having a Discovery Process that uses both a look-up service (Discovery Server) and multicast discovery on the same participant, this ensures the discoverability between networks that have L3 connectivity but not L2 connectivity, while maintaining multicast discovery within the network. (Exemplified by Figure 1).

<?xml version="1.0" encoding="utf-8"  ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
    <participant profile_name="custom_profile" is_default_profile="true">
        <rtps>
            <builtin>
                <!-- Discovery Server -->
                <discovery_config>
                    <discoveryProtocol>CLIENT</discoveryProtocol>
                    <discoveryServersList>
                        <RemoteServer prefix="72.61.73.70.66.61.72.6d.74.65.73.74">
                            <metatrafficUnicastLocatorList>
                                <locator>
                                    <udpv4>
                                        <address>10.0.22.140</address>
                                        <port>11811</port>
                                    </udpv4>
                                </locator>
                            </metatrafficUnicastLocatorList>
                        </RemoteServer>
                    </discoveryServersList>
                </discovery_config>
                <!-- Additional reference to also use multicast -->
                <!-- Similarly to avoid_builtin_multicast but the opposite -->
            </builtin>
        </rtps>
    </participant>
</profiles>

An alternative solution could be creating a new participant type instead of changing current discovery behaviours when using a Discovery Server.
Solution 2 - Create special participants that act as relay points, these participants could collect a peer list from the multicast discovery process and then share these lists with other relay points (through static connections in the L3 layer). The relay point would then disseminate the received list on its local network, assuming that all participants have L3 connectivity (not only the relay points), peer-to-peer communication could still be used between networks. (Exemplified by Figure 2).

Current behavior

I will first explain why it is not clear to me if current solutions by eProsima address this feature. When communicating between two networks that have L3 connectivity but not L2 connectivity, the use of a Discovery Server (DS) can offer a valid solution. One of the networks might have a DS, and since there is L3 connectivity, the participants from the other network can be clients of that DS. The problem here lies in the limitation (as far as I know), that creating a participant who is a client of a DS, inherently disables multicast discovery. Additionally, it forces all participants to be connected and dependent on the DS during the Discovery Process (DP), even if they are all.
Another solution could be the use of a DDSRouter, which enables multicast discovery within a network but also enables the discovery of other participants through the L3 layer, however, the data transfer between the networks is dependent on the router itself, even though there is L3 connectivity between the participants, all traffic goes through the Router.

Steps to reproduce

Below are the images referenced previously that showcase the interaction described.

Figure 1

Figure 2

Fast DDS version/commit

Latest version on the master branch

Platform/Architecture

Ubuntu Focal 20.04 amd64

Transport layer

Default configuration, UDPv4 & SHM

Additional context

Firstly, I would like to know if the detailed "features" are possible. If so, how could I achieve the desired result?
I would like to know your thoughts on these potential features and any insight on why this scenario was not considered or possible.

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[Mario-DL]

Hi @andreclerigo

Thanks for using Fast DDS. In the scenario you depict, if one LAN is reachable from the other one a thing that could work would be increasing the ttl hops number in the transport descriptor configuration. In any case, for further support you can reach us by mail at [email protected]

I am moving this thread to the proper forum.

[andreclerigo]

@Mario-DL Using the following XML doesn't work for the proposed scenario.
It is my understanding that even though UDP transport is being used, the RTPS Simple discovery mechanism still uses L2 multicast for the matching of subscribers/publishers.

<?xml version="1.0" encoding="utf-8"  ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
    <!-- Create a descriptor for the new transport -->
    <transport_descriptors>
        <transport_descriptor>
            <transport_id>udp_transport</transport_id>
            <type>UDPv4</type>
            <TTL>250</TTL>
        </transport_descriptor>
    </transport_descriptors>

    <participant profile_name="UDPParticipant">
        <rtps>
            <userTransports>
                <transport_id>udp_transport</transport_id>
            </userTransports>
            <!-- With ou without <useBuiltinTransports>false</useBuiltinTransports> -->
        </rtps>
    </participant> 
</profiles>