QoS configurations for transport when starting applications with network interfaces disabled for IP mobility use case.

QoS configurations for transport when starting applications with network interfaces disabled for IP mobility use case

With the introduction of version 5.3.0, Connext DDS supports Locator change at runtime. The IP mobility feature allows DDS applications to start without enabled network interfaces. This article describes the configurations required for the QoS profile to use UDP, TCP LAN and TCP WAN transports to make use of the IP mobility feature.

(Note that in each of the following transport descriptions, the corresponding transport is the only one enabled i.e. the same transport is used for discovery and user data.)

On trying to start the application with network interfaces disabled and not using the SHMEM transport, the following error message would be seen:

[D0205|ENABLE]DDS_DomainParticipant_enableI:Automatic participant index failed to initialize. PLEASE VERIFY CONSISTENT TRANSPORT / DISCOVERY CONFIGURATION.

[NOTE: If the participant is running on a machine where the network interfaces can change, you should manually set wire protocol's participant id]
DDSDomainParticipant_impl::createI:ERROR: Failed to auto-enable entity
DomainParticipantFactory_impl::create_participant():!create failure creating participant
DomainParticipantFactory_impl::create_participant_with_profile():ERROR: Failed to create participant from a profile

The error implies that the creation of participant failed. Every participant has a unique ID associated with it. Before a participant is assigned an ID, it is checked for collision. However, when network interfaces are down, Connext DDS is unable to check for collision. In this scenario, a configuration is required to the QoS profile of the DDS application.

IP Mobility with TCP LAN:

In this scenario, participant ID needs to be manually configured in the QoS profile in the following way:

<participant_qos>
    <wire_protocol>
        <rtps_auto_id_kind>RTPS_AUTO_ID_FROM_UUID</rtps_auto_id_kind>
        <participant_id>participant_id_value</participant_id>
    </wire_protocol>
</participant_qos>

The participant_id_value can be any value from 0 to 120 (and will be less for domain IDs other than 0). By default, the discovery is made for DomainParticipants with IDs from 0 to 4. For more information on participant id and its use in discovery, read the section 8.5.9.1 and 14.2.1 from the RTI Connext DDS Core Libraries User's Manual.

Note that the participant ID is also used for calculating the port number for the socket used for communication. For TCP transport any DomainParticipant is manually bound to a port using, dds.transport.TCPv4.tcp1.server_bind_port the property, so it is fine to set the wire protocol's participant_id value to same value for all the DomainParticipants as part of the QoS configuration.

IP Mobility with TCP WAN: 

In case of TCP WAN transport, Connext DDS does rely on the system interfaces to determine locator for the DomainParticipant. In particular, in the case of TCP WAN, the locators are generated from the configured public_address parameter, that will determine what locators are announced to other peers. 

In this case, there is no need to manually set the participant ID.

The configuration required in the QoS profile is as follows:

<participant_qos>
    <property>
        <value>
            <element>
                 <name>dds.transport.TCPv4.tcp1.public_address</name>
                <value>public_address_value</value>
            </element>
        </value>
    </property>
</participant_qos>

IP Mobility with UDP transport

For the UDP transport, similar to TCP transport, the participant_id needs to be manually specified. But in this case, make sure that each DomainParticipant has a different participant_id. Else, the participant_id collision occurs and as participant_id is used to assign port numbers for the socket used for communication, two DomainParticpants cannot be assigned the same socket. This results in an error.

IP Mobility with SHMEM transport 

While using Shared Memory transport, Connext DDS does not rely on system interfaces to determine the locators for the DomainParticipant. No special configuration is needed in case of shared memory transport.