Chapter 26 Discovered RTPS Locators and Changes with IP Mobility

DDS endpoints (DataWriters and DataReaders) can be reached at specific transport addresses called RTPS locators. An RTPS locator is an n-tuple (transport, address, port). For example (UDPv4, 192.168.1.1, 7400) is a locator for the UDPv4 transport. Locator information is sent as part of the Participant and Endpoint DATA messages (see Chapter 22 Discovery Overview).

The initial set of locators that a DomainParticipant will use to communicate with other DomainParticipants is provided using a peer descriptor (see Chapter 24 Configuring the Peers List Used in Discovery).

26.1 Locator Changes at Run Time

In Connext 5.2.3 and earlier, the set of locators associated with a DDS endpoint could not be changed after the DomainParticipant containing the endpoints was enabled. Therefore, Connext was not prepared to deal with, for example, IP address changes in IP-based transports.

Starting with Connext 5.3.0, locator changes are propagated as part of new Participant and Endpoint DATA messages.

26.1.1 Locator Changes in IP-Based Transports

For IP-based transports, including UDPv4 and UDPv6, the following IP mobility use cases (i.e., the need for IP-address changes at runtime) are supported in Connext 5.3.0 and higher:

  • Starting a DomainParticipant without network connectivity and connecting to the network at runtime.
  • Switching network interfaces (for example, going from wired to Wi-Fi).
  • Acquiring a new IP address after DHCP lease expiration.
  • Having mobile devices roaming across network segments.

Connext supports IP mobility in all IP-based transports.

The functionality is enabled out-of-the-box.

When possible, the detection of IP address changes is done asynchronously using the APIs offered by the underlying OS. If there is no mechanism to do that, the detection will use a polling strategy.

The polling period can be configured using the following transport property in the DomainParticipant's PropertyQosPolicy: <<transport prefix>>.interface_poll_period. For example, for UDPv4 the property name is dds.transport.UDPv4.builtin.interface_poll_period.

26.1.1.1 Starting a DomainParticipant without Enabled Network Interfaces

For this use case, the GUID prefix generation algorithm must not be based on the IPv4/MAC address of the first enabled interface, but must use a UUID algorithm instead. This is necessary to avoid collisions on the GUID, which needs to be unique on the network.

In Connext 5.3.x, to enable the use of a UUID algorithm to generate the GUID, you had to modify the rtps_auto_id_kind field in the DomainParticipant's 44.10 WIRE_PROTOCOL QosPolicy (DDS Extension) to DDS_RTPS_AUTO_ID_FROM_UUID. Starting with Connext 6.0.0, the default value of this field changed to DDS_RTPS_AUTO_ID_FROM_UUID, and you do not need to modify it.

26.1.1.2 Disabling IP Locator Change Propagation

Connext 5.2.3 and earlier will report errors if it detects locator changes in a DDS endpoint. You can disable the notification and propagation of these changes for a DomainParticipant. This way, an interface change in a 5.3.0 or higher application will not trigger errors in an application running 5.2.3 or earlier. Setting this property to true will prevent a 5.3.0 application from being able to detect network interface changes.

To disable the notification of IP locator changes, set the following transport property in the DomainParticipant's PropertyQosPolicy: <<transport prefix>>.disable_interface_tracking. For example, for UDPv4 the property name is dds.transport.UDPv4.builtin.disable_interface_tracking. To disable the property in XML, for example:

<domain_participant_qos>
    <property>
        <value>
            <element>
                <name>dds.transport.UDPv4.builtin.disable_interface_tracking</name>
                <value>true</value>
            </element>
        </value>
    </property>
</domain_participant_qos>

26.2 Detection of Unreachable Locators

It is possible for a DomainParticipant to announce locators for endpoints that are temporarily or permanently unreachable from a different DomainParticipant.

For example, DomainParticipant 'A' may send to a different DomainParticipant 'B' one locator where the IP address corresponds to a subnet that is not reachable from DomainParticipant 'B'. In such case, the DomainParticipant 'B' running in a different subnet should not use this address to send information to the endpoints of DomainParticipant 'A'.

In Connext 5.2.3 and earlier, the middleware did not have the ability to detect unreachable locators. This had two main consequences:

  1. The middleware could waste CPU cycles and bandwidth sending messages to unreachable locators.
  2. If the unreachable locator was a multicast locator, the destination endpoint would never receive live samples from the sender's endpoints. For best-effort communication, this would have resulted in never receiving samples. For reliable communication, this would have resulted in sending samples as repair traffic.

Connext 5.3.0 introduces a new locator REACHABILITY PING mechanism, which the middleware can use to detect when an endpoint is not reachable at a locator; then it can stop using the locator to send data to the endpoint. For temporary disconnections, the middleware will be able to detect and use an endpoint’s locator that becomes reachable again. While data is not being sent to an unreachable locator, the middleware still sends periodic REACHABILITY PING messages to see if it is still unreachable. REACHABILITY PING messages are sent over an anonymous channel and the responses (Locator Reachability Messages) are sent over the ServiceRequest channel.

The configuration of the REACHABILITY mechanism is done using the following DomainParticipant's QosPolicy values:

  • participant_qos.discovery_config.locator_reachability_assert_period
  • participant_qos.discovery_config.reachability_lease_duration
  • participant_qos.discovery_config.locator_reachability_change_detection_period

For more information on these QoS values, see Table 44.3 DDS_DiscoveryConfigQosPolicy.

26.3 Using DNS Tracker to Keep Peer List Updated

Connext allows the use of hostnames instead of IP addresses when configuring peers for specific transports (e.g., UDPv4 and UDPv6). By default, Connext resolves hostnames into IP addresses only when the DomainParticipant is created. But you can use the DNS tracker to keep the IP addresses of these hostnames updated. The DNS tracker does this by creating a thread that regularly polls the DNS service. This thread detects changes in the IP address that a hostname is resolved to and updates the related peers accordingly.

Use the dns_tracker_polling_period field in the 44.3 DISCOVERY_CONFIG QosPolicy (DDS Extension) to define how often the DNS tracker thread will query the DNS service for updates (e.g., every 30 seconds). When the period is set to DDS_DURATION_INFINITE (the default value), the tracker is disabled and changes in hostnames will not be tracked. You can also configure the polling period after the creation of the DomainParticipant using the DomainParticipant’s set_dns_tracker_polling_period() operation. This operation can enable or disable the DNS tracker depending on the value of the DDS_Duration_t provided as parameter.

Connext keeps information regarding the hostnames of peers, whether the hostnames are part of the initial_peers field in the 44.2 DISCOVERY QosPolicy (DDS Extension) or the peers were added through the DomainParticipant’s add_peer() API. When the DNS tracker is enabled, it builds the list of names to track from the DomainParticipant’s current peers. Removing peers from the DomainParticipant (using the remove_peer() API) will also affect the DNS tracker. If all the peers with a specific name are removed, the DNS tracker will stop tracking that name.

Enabling the DNS tracker changes the behavior of the DomainParticipant’s add_peer() API. If the DNS tracker has not been enabled, the API will fail to add a peer with a hostname that cannot be resolved into an IP address. If the DNS tracker has been enabled, the DomainParticipant’s add_peer() API will successfully add a peer with a hostname that cannot be resolved into an IP address. Although the hostname or the DNS service may not be available when the add_peer() API is called, the enabled DNS tracker will be able to resolve the name and update the locator once the hostname can be resolved.

Once the DNS tracker has been enabled, the change in the behavior of the DomainParticipant’s add_peer() API remains until the DomainParticipant is destroyed. Adding a peer with a hostname that cannot be resolved will not produce an error even if the DNS tracker is disabled. Connext assumes that if the DNS tracker has been enabled once, all hostnames should be considered as valid peers independently of the status of the DNS tracker at the moment of adding the peer.