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

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

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

13684 reads — 0 comments

Most operating systems are not configured for high-performance networking out of the box.

9794 reads — 0 comments

Defining Topic names in source code in each application is readable in example code, but is not ideal for a real system.

9346 reads — 0 comments

For each data type, indicate to RTI Connext DDS the fields that uniquely identify the data object.

17069 reads — 0 comments

Mapping all of your data model to opaque bytes or strings (even XML strings) is a bad practice for several reasons, some obvious and some subtle:

8244 reads — 0 comments

When you write keyed data, the RTI Connext DDS has to send the unique identifier of each instance along with the data.

9769 reads — 0 comments