Create as Few DomainParticipants as Possible

To send or receive samples from the DDS dataspace or domain, you must create a domain participant in that domain. Within a DomainParticipant you then create Publishers and Subscribers, and within those you create DataWriters and DataReaders respectively. While you can theoretically create a DomainParticipant for every reader or writer, this is strongly discouraged because multiple DomainParticipants within an application impact the system resources (threads, memory, sockets, CPU).  

In addition to local resources, each DomainParticipant will discover other DomainParticipants in the same domain. This discovery process uses network bandwidth at startup and at runtime.  This will also use CPU and memory in the other applications that discover this DomainParticpant.

By default, all DomainParticipants are created with:

• multiple (7)  threads: one event thread, one database thread, one unicast and one multicast receive thread to handle UDPv4 meta data (e.g., discovery) and one unicast receive thread to handle UDPv4 user data. Finally two threads are created to handle metadata and user data over the built-in shared memory transport. Additional threads will be created if you install additional transports, or have data larger than 64k.
• various internal "in-memory databases" to keep track of other domain participants and DDS entities

If the application only needs to be in one domain, we recommend using just one DomainParticipant (to avoid using the extra resources). Of course, if the application needs to belong to different domains, you must use multiple DomainParticipants. We recommend using one DomainParticipant for each domain the application belongs to.

There are some rare scenarios where why you might want to have multiple DomainParticipants in the same domain:

• The participant threads need to run at different priorities.
• The participants have different transport properties such as different NIC addresses.
• The participants have different resource limits. Although, if they're running in the same application, they're likely bound by the same resource limits.

Domain Participants are a very heavyweight way to separate data traffic. Use them when you are separating whole subsystems, not when you are separating a subset of data traffic within the same applications. RTI Connext DDS supports various concepts and Quality of Service policies to manage the data: e.g., PartitionQoS, MultiChannel DataWriters, Prioritized Samples, Content Filtering, the ability to create additional receive threads per DataReader, etc.