The DCPS model provides anonymous, transparent, many-to-many communications. Each time an application sends a DDS sample of a particular Topic, the middleware distributes the DDS sample to all the applications that want that Topic. The publishing application does not need to specify how many applications receive the Topic, nor where those applications are located. Similarly, subscribing applications do not specify the location of the publications. In addition, new publications and subscriptions of the Topic can appear at any time, and the middleware will automatically interconnect them.
So how is this all done? Ultimately, in each application for each publication, Connext DDS must keep a list of applications that have subscribed to the same Topic, nodes on which they are located, and some additional QoS parameters that control how the data is sent. Also, Connext DDS must keep a list of applications and publications for each of the Topics to which the application has subscribed.
This propagation of this information (the existence of publications and subscriptions and associated QoS) between applications by Connext DDS is known as the discovery process. While the DDS (DCPS) standard does not specify how discovery occurs, Connext DDS uses a standard protocol RTPS for both discovery and formatting on-the-wire packets.
When a DomainParticipant is created, Connext DDS sends out packets on the network to announce its existence. When an application finds out that another application belongs to the same DDS domain, then it will exchange information about its existing publications and subscriptions and associated QoS with the other application. As new DataWriters and DataReaders are created, this information is sent to known applications.
The Discovery process is entirely configurable by the user and is discussed extensively in Discovery.
© 2016 RTI