Characterize DDS's discovery system

[wjwwood]

Previously we appraised mDNSResponder (bonjour) and avahi for their use as a discovery system for ROS. We found the system easily got into inconsistent states and could sometimes be very unresponsive. We have similar concerns about DDS's discovery system.

Things we would like to know more about DDS's discovery system:

• What startup times are associated with DDS participants?
  • For participant discovery
  • For end point discovery and connection
• What options are there for bridging connections across networks?
• What options are there for static configuration?
• Is the discovery system consistent and responsive?

[esteve]

References:

• Chapter 14 (page 518) of the RTI Connext Core Libraries and Utilities User's Manual (http://community.rti.com/rti-doc/500/ndds.5.0.0/doc/pdf/RTI_CoreLibrariesAndUtilities_UsersManual.pdf)
• Section 8.5 (page 123) of The Real-Time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol Specification (DDSI), V2.1 (http://www.omg.org/spec/DDSI/2.1/PDF/)

Troubleshooting:

• http://community.rti.com/content/forum-topic/dds-discovery-very-slow

Improvements:

• Bloom filter-based discovery protocol for DDS middleware http://www.sciencedirect.com/science/article/pii/S0743731511000876

[esteve]

Link to PDF for the Bloom filter-based protocol: http://dtstc.ugr.es/tl/pdf/pf/PFM_jsanchez_electronic-EN.pdf

[esteve]

Static discovery plug-in for RTI's implementation (page 7): http://www.rti.com/docs/DDS_Over_Low_Bandwidth.pdf

[esteve]

More info about firewalls, DDS and discovery (especially the ports being used):

http://community.rti.com/content/forum-topic/statically-configure-firewall-let-omg-dds-traffic-through

[esteve]

Participants can be either discovered asynchronously (subscribing to the builtin DCPSParticipant datareader) or synchronously via DDSDomainParticipant::get_discovered_participants. I wrote a program that exemplifies the asynchronous API in example/cpp/src/Discovery.cpp

The standard DDS API provides other builtin mechanisms for discovering datareaders and datawriters (via the DCPSSubscription and DCPSPublication datareaders respectively). RTI's implementation provides the Subscriber::get_datareaders and Publisher::get_datawriters synchronous methods, but it's a custom extension.

DDS uses multicast for discovery by default, but it can be configured to a pre-defined topology. OpenDDS has two methods for achieving this, both via the XML configuration file. The first one is by defining a <Discovery> section in <DDSI2Service>:

` ...

... `

the other method is by defining a new networking service, first in the <Domain> section:

`

networking

`

and then in the <OpenSplice> section:

`

53340 53350

  <Discovery enabled="true">
     <PortNr>53360</PortNr>
  </Discovery>

`

RTI's implementation provides more options for configuring discovery programmatically, but they work with OpenDDS:

http://community.rti.com/content/forum-topic/configure-rti-connext-dds-not-use-multicast

In my tests, discovery is very responsive, participants are notified of other participants joining and leaving the domain almost immediately, but more testing should be done.