DDS Best Practices

RTI Connext DDS is a powerful platform that abstracts many difficult parts of distributed system design. However, like any powerful technology, it must be used in optimal ways to get the most out of it. There may be multiple ways to accomplish the same goal, but the approaches can differ in performance or resource utilization. These best practices provide rules on designing your distributed system and architecting applications that use RTI Connext DDS.

You can contribute by commenting on existing best practice articles, or by creating new best practices here (requires logging in).

QoS Profile composition is a new feature added to Connext DDS 6. This feature allows QoS Profiles to be constructed from other profil

413 reads — 0 comments

The following references summarize key best practices when using DDS to integrate distributed systems:

3783 reads — 0 comments
Use the bind_and_manage_listener call to avoid managing Entity and listener deletion in your application.
4406 reads — 0 comments
Entities, such as the DomainParticipant or the DataReader should never be created as pointers (i.e. using new). They implement reference semantics, and should be declared as regular variables.
5525 reads — 0 comments

For better reusability and maintenance of your code, design your QoS as sets of reusable profiles instead of tuning each data flow separately.

7699 reads — 0 comments

Your Topic names should represent the meaning of the data you are sending, not the structure of the data.

18490 reads — 0 comments

If you have one DataWriter that is sending data to more than one or two DataReaders, you can get better overall throughput performance by enabling multicast.

8498 reads — 0 comments