|Contains the DDSDomainParticipant class that acts as an entrypoint of RTI Connext and acts as a factory for many of the classes. The DDSDomainParticipant also acts as a container for the other objects that make up RTI Connext. |
|Contains the DDSTopic, DDSContentFilteredTopic, and DDSMultiTopic classes, the DDSTopicListener interface, and more generally, all that is needed by an application to define DDSTopic objects and attach QoS policies to them. |
|Contains the DDSFlowController, DDSPublisher, and DDSDataWriter classes as well as the DDSPublisherListener and DDSDataWriterListener interfaces, and more generally, all that is needed on the publication side. |
|Contains the DDSSubscriber, DDSDataReader, DDSReadCondition, and DDSQueryCondition classes, as well as the DDSSubscriberListener and DDSDataReaderListener interfaces, and more generally, all that is needed on the subscription side. |
|Defines the abstract classes and the interfaces that are refined by the other modules. Contains common definitions such as return codes, status values, and QoS policies. |
|Queries and Filters Syntax|
DDS Dissemination Overview
DDSTopic objects conceptually fit between publications and subscriptions. Publications must be known in such a way that subscriptions can refer to them unambiguously. A DDSTopic is meant to fulfill that purpose: it associates a name (unique in the domain i.e. the set of applications that are communicating with each other), a data type, and QoS related to the data itself. In addition to the topic QoS, the QoS of the DDSDataWriter associated with that Topic and the QoS of the DDSPublisher associated to the DDSDataWriter control the behavior on the publisher's side, while the corresponding DDSTopic, DDSDataReader and DDSSubscriber QoS control the behavior on the subscriber's side.
When an application wishes to publish data of a given type, it must create a DDSPublisher (or reuse an already created one) and a DDSDataWriter with all the characteristics of the desired publication. Similarly, when an application wishes to receive data, it must create a DDSSubscriber (or reuse an already created one) and a DDSDataReader to define the subscription.
DCPS conceptual model
All DCPS entities are attached to a DDSDomainParticipant. A domain participant represents the local membership of the application in a domain. A domain is a distributed concept that links all the applications able to communicate with each other. It represents a communication plane: only the publishers and the subscribers attached to the same domain may interact.
DDSDomainEntity is an intermediate object whose only purpose is to state that a DomainParticipant cannot contain other domain participants.
At the DCPS level, data types represent information that is sent atomically. For performance reasons, only plain data structures are handled by this level.
By default, each data modification is propagated individually, independently, and uncorrelated with other modifications. However, an application may request that several modifications be sent as a whole and interpreted as such at the recipient side. This functionality is offered on a Publisher/Subscriber basis. That is, these relationships can only be specified among DDSDataWriter objects attached to the same DDSPublisher and retrieved among DDSDataReader objects attached to the same DDSSubscriber.
By definition, a DDSTopic corresponds to a single data type. However, several topics may refer to the same data type. Therefore, a DDSTopic identifies data of a single type, ranging from one single instance to a whole collection of instances of that given type. This is shown below for the hypothetical data type
A collection of object instances, identified by their
keys, can be disseminated on a topic.
Topics need to be known by the middleware and potentially propagated. Topic objects are created using the create operations provided by DDSDomainParticipant.
The interaction style is straightforward on the publisher's side: when the application decides that it wants to make data available for publication, it calls the appropriate operation on the related DDSDataWriter (this, in turn, will trigger its DDSPublisher).
On the subscriber's side however, there are more choices: relevant information may arrive when the application is busy doing something else or when the application is just waiting for that information. Therefore, depending on the way the application is designed, asynchronous notifications or synchronous access may be more appropriate. Both interaction modes are allowed, a DDSListener is used to provide a callback for synchronous access and a DDSWaitSet associated with one or several DDSCondition objects provides asynchronous data access.
The same synchronous and asynchronous interaction modes can also be used to access changes that affect the middleware communication status (see Status Kinds). For instance, this may occur when the middleware asynchronously detects an inconsistency. In addition, other middleware information that may be relevant to the application (such as the list of the existing topics) is made available by means of built-in topics that the application can access as plain application data, using built-in data-readers.
DCPS modules and their dependencies