You may have several independent DCPS applications all running on the same set of computers. You may want to isolate one (or more) of those applications so that it isn’t affected by the others. To address this issue, DCPS has a concept called DDS domains.
DDS domains represent logical, isolated, communication networks. Multiple applications running on the same set of hosts on different DDS domains are completely isolated from each other (even if they are on the same machine). DataWriters and DataReaders belonging to different DDS domains will never exchange data.
Applications that want to exchange data using DCPS must belong to the same DDS domain. To belong to a DDS domain, DCPS APIs are used to configure and create a DomainParticipant with a specific Domain Index. DDS domains are differentiated by the domain index (an integer value). Applications that have created DomainParticipants with the same domain index belong to the same DDS domain. DomainParticipants own Topics, Publishers, and Subscribers, which in turn owns DataWriters and DataReaders. Thus all DCPS Entities belong to a specific DDS domain.
An application may belong to multiple DDS domains simultaneously by creating multiple DomainParticipants with different domain indices. However, Publishers/DataWriters and Subscribers/DataReaders only belong to the DDS domain in which they were created.
As mentioned before, multiple DDS domains may be used for application isolation, which is useful when you are testing applications using computers on the same network or even the same computers. By assigning each user different domains, one can guarantee that the data produced by one user’s application won’t accidentally be received by another. In addition, DDS domains may be a way to scale and construct larger systems that are composed of multi-node subsystems. Each subsystem would use an internal DDS domain for intra-system communications and an external DDS domain to connect to other subsystems.
For more information, see Working with DDS Domains.
© 2016 RTI