2.1.1. An Introduction to Connext DDS

2.1.1.1. DDS Concepts

Connext DDS is a connectivity software framework for real-time distributed applications. It provides the communications service that programmers need to distribute time-critical data between embedded and/or enterprise devices or nodes. Connext DDS uses a publish-subscribe communications model to make data-distribution efficient and robust.

Connext DDS implements the Data-Centric Publish-Subscribe (DCPS) API of the OMG’s specification, Data Distribution Service (DDS) for Real-Time Systems. DDS is the first standard developed for the needs of real-time systems, providing an efficient way to transfer data in a distributed system. With Connext DDS, you begin your development with a fault-tolerant and flexible communications infrastructure that will work over a wide variety of computer hardware, operating systems, languages, and networking transport protocols. Connext DDS is highly configurable, so programmers can adapt it to meet an application’s specific communication requirements.

2.1.1.2. An Overview of Connext DDS Objects

The primary objects in Connext DDS are:

  • DomainParticipants

  • Publishers and DataWriters

  • Subscribers and DataReaders

  • Topics

  • Keys and DDS Samples

  • Requesters and Repliers

Small Dds system

2.1.1.3. DomainParticipants

A DDS domain, (represented in Admin Console by this icon IMAGE_PARTICIPANT ) is a concept used to bind individual applications (represented by this icon IMAGE_PROCESS) together for communication. To communicate with each other, DataWriters (represented by this icon IMAGE_DATA_WRITER ) and DataReaders (represented by this icon IMAGE_DATA_READER) must have the same Topic (represented by this icon IMAGE_DOMAIN_TOPIC) of the same DDS data type and be members of the same DDS domain. Each DDS domain has a unique integer domain ID.

Applications in one DDS domain cannot subscribe to data published in a different DDS domain. Multiple DDS domains allow you to have multiple virtual distributed systems on the same physical network. This can be very useful if you want to run multiple independent tests of the same applications. You can run them at the same time on the same network as long as each test runs in a different DDS domain. Another typical configuration is to isolate your development team from your test and production teams: you can assign each team or even each developer a unique DDS domain.

DomainParticipants enable an application to exchange messages within DDS domains. An application must have a DomainParticipant for every DDS domain in which the application will communicate. (Unless your application is a bridging application, it will typically participate in only one DDS domain and have only one DomainParticipant).

DomainParticipants are used to create Topics, Publishers, DataWriters, Subscribers, and DataReaders in the corresponding DDS domain.

Application scheme with domains

When creating a new DomainParticipant, its quality of service (QoS) is specified. The discussion below on What is QoS? is a brief introduction to the concept of QoS. You can learn more in the Basic QoS chapter of the RTI Connext DDS Getting Started Guide.

2.1.1.4. Finding and Selecting DDS Entities in Admin Console

DomainParticipants can be found in the Process View. To get to that view, first find the process of interest in the Physical View. Clicking on the process will then bring up a Process View. The DDS Entities tab breaks down DDS Entities in a hierarchy. The first level shows the process and the second shows DomainParticipants.

In the aforementioned Process View, Publishers and Subscribers can be found at the third level of the DDS Entities tree. Below them you will find DataWriters and DataReaders.

DataWriters and DataReaders can also be selected in the Topic View and in the Process view.

2.1.1.5. What is QoS?

Fine control over Quality of Service (QoS) is perhaps the most important feature of Connext DDS. Each data producer-consumer pair can establish independent quality of service agreements, even in many-to-many topologies. This allows applications to support extremely complex and flexible data-flow requirements.

QoS policies control virtually every aspect of Connext DDS and the underlying communications mechanisms. Many QoS policies are implemented as ‘contracts’ between data producers (DataWriters) and consumers (DataReaders); producers offer and consumers request levels of service. Connext DDS 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. For example:

  • Periodic producers can indicate the speed at which they can publish by offering guaranteed update deadlines. By setting a deadline, a producer promises to send updates at a minimum rate. Consumers may then request data at that or any slower rate. If a consumer requests a higher data rate than the producer offers, Connext DDS will flag that pair as incompatible and notify both the publishing and subscribing applications.

  • Producers may offer different levels of reliability, characterized in part by the number of past DDS data samples they store for retransmission. Consumers may then request differing levels of reliable delivery, ranging from fast-but-unreliable ‘best effort’ to highly reliable in-order delivery. This provides per-data-stream reliability control. A single producer can support consumers with different levels of reliability simultaneously.

Other QoS policies control when Connext DDS detects nodes that have failed, set delivery order, attach user data, prioritize messages, set resource utilization limits, partition the system into namespaces, control durability (for fault tolerance) and much more. The Connext DDS QoS policies offer unprecedented flexible communications control. The RTI Connext DDS Core Libraries User’s Manual contains details about all available QoS policies.

2.1.1.6. Inspecting QoS Values in Admin Console

Admin Console receives a subset of QoS values through Discovery (see the Discovery chapter of the RTI Connext DDS Getting Started Guide for more information). The QoS View displays the settings that are available from Discovery. QoS settings can be displayed for DomainParticipants, DataWriters, and DataReaders. QoS settings are displayed when one of these is selected in the Process View or Topic View (see how to do so for DomainParticipants, DataWriters, DataReaders).

2.1.1.7. Publishers and DataWriters

An application uses a DataWriter to publish data into a DDS domain. Once a DataWriter is created and configured with the correct QoS settings, an application only needs to use the DataWriter’s “write” operation to publish data.

A Publisher is used to group individual DataWriters. You can specify default QoS behavior for a Publisher and have it apply to all the DataWriters in that Publisher’s group.

Entities associated with publication

Each DataWriter is tied to a single Topic. All data published by that DataWriter will be directed to that Topic.

Each Topic and therefore all DataWriters for that Topic are associated with a particular concrete DDS data type. You can learn more about this in the RTI Connext DDS Getting Started Guide.

2.1.1.8. Subscribers and DataReaders

A DataReader is the point through which a subscribing application accesses the data that it has received over the network.

Just as Publishers are used to group DataWriters, Subscribers are used to group DataReaders. Again, this allows you to configure a default set of QoS parameters and event handling routines that will apply to all DataReaders in the Subscriber’s group.

Entities associated with subscription

Each DataReader is tied to a single Topic. A DataReader will only receive data that was published on its Topic.

Not only can Connext DDS publish actual data to a Topic, it can also publish meta-data, indicating for example that an object about which the DataReader has been receiving data no longer exists.

2.1.1.9. Topics

Topics provide the basic connection points between DataWriters and DataReaders. To communicate, the Topic of a DataWriter on one node must match the Topic of a DataReader on any other node.

A Topic is comprised of a name and a DDS type. The name is a string that uniquely identifies the Topic within a DDS domain. The DDS type is the structural definition of the data contained in the Topic; this capability is described in the Data Types chapter of the RTI Connext DDS Getting Started Guide.

Besides the new Topic’s name and DDS type, an application specifies three things:

  • A suggested set of QoS for DataReaders and DataWriters for this Topic.

  • A listener and listener mask that indicate which events the application wishes to be notified of, if any.

In this case, the Topic’s DDS type is a simple string, a type that is built into the middleware.

2.1.1.10. Keys and DDS Samples

The data values associated with a Topic can change over time. The different values of the Topic passed between applications are called DDS samples. A DDS sample is analogous to a message in other publish-subscribe middleware.

An application may use a single Topic to carry data about many objects. For example, a stock-trading application may have a single topic, ‘Stock Price’, that it uses to communicate information about Apple, Google, Microsoft, and many other companies. Similarly, a radar track management application may have a single topic, ‘Aircraft Position’, that carries data about many different airplanes and other vehicles. These objects within a Topic are called instances. For a specific DDS data type, you can select one or more fields within the DDS data type to form a key. A key is used to uniquely identify one instance of a Topic from another instance of the same Topic, very much like how the primary key in a database table identifies one record or another. DDS samples of different instances have different values for the key. DDS samples of the same instance of a Topic have the same key. Note that not all Topics have keys. For Topics without keys, there is only a single instance of that Topic.

2.1.1.11. Match Analysis

Some QosPolicies that apply to Entities on the sending and receiving sides must have their values set in a compatible manner. This is known as the policy’s “requested vs. offered” (RxO) property. Entities on the publishing side “offer” to provide a certain behavior. Entities on the subscribing side “request” certain behavior. For Connext DDS to connect the sending entity to the receiving entity, the offered behavior must satisfy the requested behavior.

For some QosPolicies, the allowed values may be graduated in a way that the offered value will satisfy the requested value if the offered value is either greater than or less than the requested value. For example, if a DataWriter’s DEADLINE QosPolicy specifies a duration less than or equal to a DataReader’s DEADLINE QosPolicy, then the DataWriter is promising to publish data at least as fast or faster than the DataReader requires new data to be received. This is a compatible situation.

Other QosPolicies require the values on the sending side and the subscribing side to be exactly equal for compatibility to be met. For example, if a DataWriter’s OWNERSHIP QosPolicy is set to SHARED, and the matching DataReader’s value is set to EXCLUSIVE, then this is an incompatible situation since the DataReader and DataWriter have different expectations of what will happen if more than one DataWriter publishes an instance of the Topic.

The Match Analysis view provides a visual display of the compatibility check for each offered/requested QoS policy.

2.1.1.12. Discovery

Discovery is the behind-the-scenes way in which Connext DDS entities (DomainParticipants, DataWriters, and DataReaders) on different nodes find out about each other. Each DomainParticipant maintains a database of information about all the active DataReaders and DataWriters that are in the same DDS domain. This database is what makes it possible for DataWriters and DataReaders to communicate. To create and refresh the database, each application follows a common discovery process.

As part of this process, QoS values, data types, and other information is exchanged. Admin Console taps into this information to drive many of its views. You can learn more in the Discovery chapter of the RTI Connext DDS Core Libraries User’s Manual.