How can I reduce the discovery time?

For complex systems with hundreds of participants and endpoints, discovery may cause long startup times and high network utilization. There are several options that help increase discovery performance:

1) Reduce the size of discovery packets

1.1. You can configure the middleware to not send the TypeCode/TypeObject in the following cases: 

1.2. You can suppress the system properties that are normally propagated. System properties are architecture dependant but may include information such as:

  • dds.sys_info.creation_timestamp
  • dds.sys_info.executable_filepath
  • dds.sys_info.execution_timestamp
  • dds.sys_info.hostname
  • dds.sys_info.target
  • dds.sys_info.process_id
  • dds.sys_info.username

The number of system properties that are initialized for a DomainParticipant is platform-specific: only process_id and os_arch are supported on all platforms

You can disable propagation of individual properties by setting the property’s propagate flag to FALSE or by removing the property using the PropertyQosPolicyHelper operation, remove_property() (see Table 7.63 PropertyQoSPolicyHelper Operations).
 
In the following XML snippet,  both the system property 'hostname' and 'process_id' are configured to not be propagated as part of discovery.
 
            <participant_qos>
               <property>
                  <value>
                        <element>
                            <name>dds.sys_info.hostname</name>
                            <value>"hostname will not be propagate"</value>
                            <propagate>false</propagate>
                        </element>
                        <element>
                            <name>dds.sys_info.process_id</name>
                            <value>1234</value>
                            <propagate>false</propagate>
                        </element>   
                    </value>
                </property>
            </participant_qos>

 

2) Reduce the number of interfaces that participants announce

By default, Connext announces the locators for all enabled interfaces. You can restrict the interfaces used by using allow_interfaces_list and deny_interfaces_list. For more information, check the KB: How do I restrict RTI Connext to use only a subset of interfaces.

3) Disable preemptive Heartbeats and ACKNACKs

When the Liveliness QoS policy's lease_duration is set to a finite value, DomainParticipants manages one channel with each of the other participants; this channel is used to keep the participant’s liveliness. By default this channel is Best Effort, but if the channel is made Reliable, it uses preemptive heartbeats and ACKNACKs. In this case, you can reduce the network usage by disabling preemptive heartbeats and NACKs in this channel. For example, use the following settings in the participant_qos.property QoS: 

<element> 
    <name> dds.participant.inter_participant_data_reader.protocol.disable_preemptive_nack </name> 
    <value> 1 </value> 
</element> 
<element> 
    <name> dds.participant.inter_participant_data_writer.protocol.disable_preemptive_heartbeat </name> 
    <value> 1 </value> 
</element>

Note: Please take into account these properties only affect the liveliness channel. There are other channels that also send preemptive heartbeats and ACKNACKs that will continue sending them. 

4) Reduce the number of initial announcements

When a participant is enabled, by default it sends five announcements. You can reduce the number of initial announcements and the period between them with the following properties from the Discovery_config QoS: 

  1. initial_participant_announcements
  2. min_initial_participant_announcement_period
  3. max_initial_participant_announcement_period 


You can find further explanations about those QoS settings in the documentation.

5) Modify Participant's Liveliness configuration

The participant liveliness period can be increased with the property participant_liveliness_assert_period. If this property is increased, the property participant_liveliness_lease_duration must also be increased accordingly. 

6) Use Multicast discovery when possible

The usage of Unicast discovery with a large Max Participant Id can have a huge effect on bandwidth. If Multicast is available in the network, it is recommended to use it.

Comments

This solution should be updated with instructions on how to do

1.2. You can remove the system properties being sent:

  • dds.sys_info.hostname
  • dds.sys_info.process_id
  • dds.sys_info.executable_filepath

 

I'd point them to

https://community.rti.com/static/documentation/connext-dds/6.0.1/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/index.htm#UsersManual/System_Properties.htm


Example for XML qos:

<participant_qos>
     <property inherit="false">
     </property>
</participant_qos>