Discovery of DDS Domains

5 posts / 0 new
Last post
Offline
Last seen: 6 years 2 months ago
Joined: 10/03/2013
Posts: 5
Discovery of DDS Domains

Hi All!

The new RTI Connext 5.1.0 Admin Console is awesome!  We are building a small monitoring application and are wondering how the Admin Console automatically discovers and joins domains.  Once I do this, then it is straightforward to use the built-in topics to get the rest of the info I require.

Am I missing something obvious?  Is there an API that is available?

Thanks,

 - Mike

Keywords:
ken
ken's picture
Offline
Last seen: 2 months 2 weeks ago
Joined: 04/13/2011
Posts: 55

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

Offline
Last seen: 6 years 2 months ago
Joined: 10/03/2013
Posts: 5

Thank you Ken.

Our application is supposed to be a simple status monitor/dashboard embedded in a web portal.  It will show us what Participants (and their readers and writers) are active.  (Nothing as complex as the Admin Console.)  So I am basically monitoring the discovery traffic and pushing info through a web socket to the web app.  I guess the domain_announcement QoS is new - I missed it in the docs.  This makes it a lot easier to automate things if I don't have to set the domain.

(BTW - Your admin console is a nice RCP app.  Have you ever looked at single sourcing it using eclipse RAP/RWT to make it available in a browser?)

 - Mike

ken
ken's picture
Offline
Last seen: 2 months 2 weeks ago
Joined: 04/13/2011
Posts: 55

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

ken
ken's picture
Offline
Last seen: 2 months 2 weeks ago
Joined: 04/13/2011
Posts: 55

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