Discovery of DDS Domains

Hi Mike,

   Thanks so much for your kind words about the Admin Console. I'm the team lead for this product and have spent many, many hours on it. :-) Would you mind telling me more about your monitoring application? Were you aware that we also have the RTI Monitor which has quite a bit of monitoring capability for DDS products as well as the Distributed Logger which can be used to help you monitor your system. With Distributed Logger, you could log warning or error messages and those would change the status of your process in both Monitor and Admin Console to warning or error if you're looking for a quick solution to the problem.

   So, there's a mix of QoS and code that you'll want to use to automatically discover the active DDS domains in your system. What happens is that DDS Domain Participants will announce their presence on their assigned domain but they will also announce it to domain zero. This is how Monitor and Admin Console discover the active domains. The default QoS, however, disables these announcements from arriving in the Participant builtin topic. So, let's address that first. I would recommend that you first create your DomainParticipant disabled. This is because you don't want to miss any of the announcements that can arrive on the Participant builtin topic before you've added your listener. You can do this by adjusting the DomainParticipantFactory's entity_factory.autoenable_created_entities QoS to be false. Once you've done this, create a DomainParticipant in domain zero with the QoS below and then attach a listener to the Participant topic.

   Here's most of the QoS that Admin Console uses for the Domain Participant (I omitted the participant name which you probably won't want to use anyway):

<participant_qos>
 
 <discovery_config>
  <ignore_default_domain_announcements>false</ignore_default_domain_announcements>
 
  <participant_liveliness_assert_period>
   <sec>1</sec>
   <nanosec>0</nanosec>
  </participant_liveliness_assert_period>
  <participant_liveliness_lease_duration>
   <sec>10</sec>
   <nanosec>0</nanosec>
  </participant_liveliness_lease_duration>
 
  <!-- quickly detect the loss of liveness of remote participants -->
  <max_liveliness_loss_detection_period>
   <sec>5</sec>
   <nanosec>0</nanosec>
  </max_liveliness_loss_detection_period>
 
  <asynchronous_publisher>
   <disable_asynchronous_write>false</disable_asynchronous_write>
  </asynchronous_publisher>
 
  <publication_writer_publish_mode>
   <kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind>
  </publication_writer_publish_mode>
 
  <subscription_writer_publish_mode>
   <kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind>
  </subscription_writer_publish_mode>
 
 </discovery_config>
 
 <resource_limits>
  <type_code_max_serialized_length>65535</type_code_max_serialized_length>
  <deserialized_type_object_dynamic_allocation_threshold>1024</deserialized_type_object_dynamic_allocation_threshold>
  <type_object_max_deserialized_length>LENGTH_UNLIMITED</type_object_max_deserialized_length>
  <type_object_max_serialized_length>12288</type_object_max_serialized_length>
  <participant_property_list_max_length>1024</participant_property_list_max_length>
  <participant_property_string_max_length>32768</participant_property_string_max_length>
 </resource_limits>
 
 <property>
 <value>
  <!-- Don't ignore the local loopback. -->
  <element>
   <name>dds.transport.UDPv4.builtin.ignore_loopback_interface</name>
   <value>0</value>
  </element>
  <element>
   <name>dds.transport.UDPv4.builtin.recv_socket_buffer_size</name>
   <value>1048576</value>
  </element>
 </value>
 </property>
</participant_qos>

(Note: the full version of the above QoS can be found in <Admin Console install directory>/example/QoS folder.)

   The QoS that allows the announcements to arrive is discovery_config.ignore_default_domain_announcements being set to false; it's true by default. While you don't have to use all of this QoS, there are some best practices displayed here. For example, this QoS allows much more space for type information as well as increasing the UDP buffer size which can help discovery complete more quickly. The QoS also allows for data to flow from the local loopback which is helpful if the applications are on the same machine as the tool but they've disabled shared memory.

   Ok, so now you should be getting announcements from DomainParticipants on all of the active domains in your system. But, there are still a couple of things that you probably want to do before using that data. First, you might want to filter out announcement from domain zero. After all, you've already joined that domain and probably don't care to join it again. Secondly, and less obvious, is to keep in mind that you're listener is being called from the middleware thread. This means that you should not attempt to, for example, create a new DomainParticipant in this thread. Instead, push the data to a queue for another thread to process. This is exactly how the Admin Console and Monitor do it.

   Please let me know if you have any follow-up questions.

Thanks,
Ken

Mike,

   You're welcome, glad to be of service. The domain_announcement QoS is new in 5.1 and is not yet publicly documented. Please keep this in mind as you're coding your application. In particular, the API could change if/when we expose this as an officialy-supported feature in the future.

   Thanks again for the kind words regarding Admin Console. We have talked about an RAP version but have not yet seriously considered it. We're in the process of moving our code to the Luna release and adding data visualization features to it. I think that the data visualization features could be a challenge for the RAP framework as we are aiming to support very high data update rates. I don't know how well optimized the RAP logic is for handling such situations.

Thank you,
Ken

Mike,

   Actually, this QoS is public. I was looking in the wrong place, DiscoveryQoSPolicy, but it is part of DiscoveryConfigQosPolicy. Sorry for the confusion.

Thanks,
Ken