Channels ▼


OMG's Data Distribution Service Standard

The DDS Communication Model

Data Centric Publish-Subscribe

The DDS publish-subscribe model connects anonymous information producers (publishers) with information consumers (subscribers). A distributed application is composed of processes called "participants", each running in a separate address space, possibly on different computers. A participant may simultaneously publish and subscribe to typed data-flows identified by names called "Topics". The interface allows publishers and subscribers to present type-safe API interfaces to the application.

The typical DDS application architecture can be represented as a "data-flow bus" as in Figure 1. The data model means you can essentially ignore the complexity of the data flow; each node gets the data it needs from the bus. The communications are decoupled in space (nodes can be anywhere), time (delivery may be immediately after publication or later), and flow (delivery may be reliably made at controlled bandwidth).

Strongly Typed Global Data Space

Participants using DDS can read/write data efficiently and naturally with a typed interface. Underneath, the DDS middleware will distribute the data so that each reading participant can access the "most-current" values. In effect, the service creates a global "data space" that any participant can read and write. It also creates a namespace to let participants find and share objects.

Figure 1: DDS may be regarded as a data-bus for distributed applications.

To increase scalability, topics may contain multiple independent data channels identified by "keys". This allows nodes to subscribe to many, possibly thousands, of similar data streams with a single subscription. When the data arrives, the middleware can sort it by the key and deliver it for efficient processing.

DDS also provides a "state propagation" model. This model allows nodes to treat DDS-provided data structures like distributed shared-memory structures, with values efficiently updated only when they change. There are facilities to ensure coherent and ordered state updates. An optional part of the specification called the Data Local Reconstruction Layer (DLRL) abstracts most of the underlying publish-subscribe semantics and presents a very-near analog to distributed shared memory.

Quality of Service Per Data Flow

DDS allows for fine control over Quality of Service (QoS) on a "per data flow basis". Each publisher-subscriber pair can establish independent quality of service (QoS) agreements. This aspect, unique to DDS, enables application designs that easily support extremely complex, flexible data flow requirements.

QoS parameters control virtually every aspect of the DDS model and the underlying communications mechanisms. Many QoS parameters are implemented as "contracts" between publishers and subscribers; publishers offer and subscribers request levels of service. The middleware is responsible for determining if the offer can satisfy the request, thereby establishing the communication or indicating an incompatibility error. Ensuring that participants meet the level-of-service contracts guarantees predictable operation necessary for real-time systems.

Automatic Discovery and Management of Data Flows

DDS is designed to automatically discover publishers and subscribers for each topic, and autonomously establish data flows between them as permitted by the settings of the quality of service parameters.

The DDS model provides fast location transparency. That makes it well suited for systems with dynamic configuration changes. It quickly discovers new nodes, new participants on those nodes, and new data topics between participants. The system cleanly flushes old or failed nodes and data flows as well.

Unreliable Connectionless Transports

DDS is fundamentally designed to work over unreliable transports, such as UDP or wireless networks. No facilities require central servers or special nodes. Efficient, direct, peer-to-peer communications, or even multicasting, can implement every part of the model.

Figure 2 summarizes the above five key aspects of the DDS communication model.

Figure 2: Fundamental aspects of the DDS communication model.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.

Design Recent Articles


Upcoming Events

Most Recent Premium Content