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

Never Block in a Listener Callback

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

rose

Tue, 05/07/2013 - 14:41

17284 reads — 0 comments

Create as Few Publishers and Subscribers as Possible

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

rose

Tue, 05/07/2013 - 14:38

12667 reads — 0 comments

Use StatusConditions Instead of ReadConditions with DDS_ANY_READ_STATE | DDS_ANY_VIEW_STATE | DDS_ANY_INSTANCE_STATE

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

rose

Tue, 05/07/2013 - 14:31

7176 reads — 0 comments

Use WaitSets, Except When You Need Extreme Latency

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.

rose

Tue, 05/07/2013 - 13:23

23530 reads — 2 comments

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.

rose

Fri, 05/03/2013 - 18:42

15327 reads — 1 comment

Create and Delete DDS entities outside of the write() or read() loop

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

rose

Fri, 05/03/2013 - 18:23

5227 reads — 0 comments

Secondary menu

Navigation

DDS Best Practices

Never Block in a Listener Callback

Create as Few Publishers and Subscribers as Possible

Use StatusConditions Instead of ReadConditions with DDS_ANY_READ_STATE | DDS_ANY_VIEW_STATE | DDS_ANY_INSTANCE_STATE

Use WaitSets, Except When You Need Extreme Latency

Create as Few DomainParticipants as Possible

Create and Delete DDS entities outside of the write() or read() loop

Pages

RTI Community Portal Terms of Use

Search

Secondary menu

You are here

Navigation

User login

DDS Best Practices

Never Block in a Listener Callback

Create as Few Publishers and Subscribers as Possible

Use StatusConditions Instead of ReadConditions with DDS_ANY_READ_STATE | DDS_ANY_VIEW_STATE | DDS_ANY_INSTANCE_STATE

Use WaitSets, Except When You Need Extreme Latency

Create as Few DomainParticipants as Possible

Create and Delete DDS entities outside of the write() or read() loop

Pages

RTI Community Portal Terms of Use