15.12. IP mobility Pro

DDS Simple Discovery relies on well-known multicast addresses and ports to relay the Participant announcement messages (see Discovery phases). Such Participant announcement includes information about the unicast address-port pairs (a.k.a. locators) where the Participant is expecting to receive incoming metatraffic data. The list with these unicast locators is automatically initialized taking into account the network interfaces that are available when the Fast DDS DomainParticipant is enabled.

Fast DDS Pro detects changes in the system’s IP addresses, and automatically updates them through the discovery protocol, so other participants start sending data to the new addresses.

Important

This feature is still under development and is only officially supported for UDPv4 Transport without whitelisting.

This feature is only available in Windows and Linux. MacOS will be supported in future releases.

15.12.1. Prerequisites

This feature is intended to be used when Fast DDS automatically sets the listening unicast locators. Consequently, all the locator lists in wire_protocol() must be empty when the participant is created. If any of them is not empty, no updates will be transmitted to other participants, and communication with them will stop.

These locator lists are:

  • metatrafficUnicastLocatorList

  • metatrafficMulticastLocatorList

  • default_unicast_locator_list

  • default_multicast_locator_list

Please refer to DomainParticipantQos for more information about these attributes.

Note

Be aware of the remote locators’ collections limits set within the DomainParticipantQos (please refer to RemoteLocatorsAllocationAttributes). It is recommended to use the highest number of local addresses found on all the systems belonging to the same domain.

15.12.2. TCP Keep Alive Pro

Fast DDS Pro additionally provides a TCP keep-alive mechanism to detect stalled TCP connections and recover from link failures more reliably. When enabled, the TCP transport periodically sends keep-alive requests on established TCP channels, and monitors activity to determine whether a connection is still responsive. Keep alive requests are sent only when no incoming data has been received for a specified interval.

If the configured timeout is reached without observing activity after a keep-alive request, the channel is considered broken and is closed, allowing Fast DDS to reconnect and restore communication.

Note that this feature operates at the application level, independently of any TCP keep-alive settings at the OS level. This allows for more fine-grained control over connection monitoring and recovery within Fast DDS. It also ensures consistent behavior across different operating systems and increases portability.

Keep alive is disabled by default and can be configured through the following parameters in TCPTransportDescriptor:

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com">
        <transport_descriptor>
            <transport_id>keep_alive_transport</transport_id>
            <type>TCPv4</type>
            <keep_alive_frequency_ms>5000</keep_alive_frequency_ms>
            <keep_alive_timeout_ms>25000</keep_alive_timeout_ms>
        </transport_descriptor>
    </transport_descriptors>
</profiles>

DomainParticipantQos qos;

// Create a descriptor for the new transport.
auto tcp_transport = std::make_shared<TCPv4TransportDescriptor>();

// Configure keep alive options
tcp_transport->keep_alive_frequency_ms = 5000;  // Send a keep-alive message every 5 seconds when connection is idle
tcp_transport->keep_alive_timeout_ms = 2000;  // Consider connection lost if no response is received within 2 seconds
tcp_transport->keep_alive_thread = eprosima::fastdds::rtps::ThreadSettings{-1, 0, 0, -1};  // Configure thread settings

// Link the Transport Layer to the Participant.
qos.transport().user_transports.push_back(tcp_transport);

Note

This feature is intended for TCP transports and only applies to connected TCP channels.