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).

You should never block in a listener callback.  There are many negative consequences of blocking in a listener callback:

17917 reads — 0 comments

A DDS Publisher and Subscriber are responsible for sending and receiving the data. A Publisher contains one or multiple DataWriters.

13350 reads — 0 comments

When using a WaitSet, you can be notified of new data arriving two ways:

7602 reads — 0 comments

An application has multiple ways to be notified about data becoming available in a DataReader, depending on the application’s requirements - between these options, WaitSets are the safest.

24771 reads — 2 comments

To send or receive samples from the DDS dataspace or domain, you must create a domain participant in that domain.

16357 reads — 1 comment

Unlike when creating a socket and sending a UDP packet, creating DDS entities is more heavyweight.

5492 reads — 0 comments

Pages