RTI Connext modules following the DDS module definitions. More...

Modules
	Domain Module
	Contains the dds::domain::DomainParticipant class that acts as an entrypoint of RTI Connext and acts as a factory for many of the classes. The dds::domain::DomainParticipant also acts as a container for the other objects that make up RTI Connext.

	Topic Module
	Contains the dds::topic::Topic, dds::topic::ContentFilteredTopic, and MultiTopic classes, the TopicListener interface, and more generally, all that is needed by an application to define dds::topic::Topic objects and attach QoS policies to them.

	Publication Module
	Contains the rti::pub::FlowController, dds::pub::Publisher, and dds::pub::DataWriter classes as well as the PublisherListener and dds::pub::DataWriterListener interfaces, and more generally, all that is needed on the publication side.

	Subscription Module
	Contains the dds::sub::Subscriber, dds::sub::DataReader, dds::sub::cond::ReadCondition, dds::sub::cond::QueryCondition, and rti::sub::TopicQuery classes, as well as the dds::sub::SubscriberListener and dds::sub::DataReaderListener interfaces, and more generally, all that is needed on the subscription side.

	Infrastructure Module
	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.

	Pluggable Transports
	APIs related to RTI Connext pluggable transports.

	Queries and Filters Syntax

	Configuration Utilities
	Utility API's independent of the DDS standard.

	Unsupported Utilities
	Unsupported APIs used by examples in the RTI Connext distribution as well as in rtiddsgen-generated examples.

	Durability and Persistence
	APIs related to RTI Connext Durability and Persistence.

	System Properties
	System Properties.

	Configuring QoS Profiles with XML
	APIs related to XML QoS Profiles.

	RTI Connext Messaging API Reference
	Extensions to the RTI Connext publish-subscribe functionality.

Detailed Description

RTI Connext modules following the DDS module definitions.

Overview

DDS Dissemination Overview

Information flows with the aid of the following constructs: dds::pub::Publisher and dds::pub::DataWriter on the sending side, dds::sub::Subscriber and dds::sub::DataReader on the receiving side.

A dds::pub::Publisher is an object responsible for data distribution. It may publish data of different data types. A TDataWriter acts as a typed (i.e. each dds::pub::DataWriter object is dedicated to one application data type) accessor to a publisher. A dds::pub::DataWriter is the object the application must use to communicate to a publisher the existence and value of data objects of a given type. When data object values have been communicated to the publisher through the appropriate data-writer, it is the publisher's responsibility to perform the distribution (the publisher will do this according to its own QoS, or the QoS attached to the corresponding data-writer). A publication is defined by the association of a data-writer to a publisher. This association expresses the intent of the application to publish the data described by the data-writer in the context provided by the publisher.

A dds::sub::Subscriber is an object responsible for receiving published data and making it available (according to the Subscriber's QoS) to the receiving application. It may receive and dispatch data of different specified types. To access the received data, the application must use a typed TDataReader attached to the subscriber. Thus, a subscription is defined by the association of a data-reader with a subscriber. This association expresses the intent of the application to subscribe to the data described by the data-reader in the context provided by the subscriber.

dds::topic::Topic objects conceptually fit between publications and subscriptions. Publications must be known in such a way that subscriptions can refer to them unambiguously. A dds::topic::Topic 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 dds::pub::DataWriter associated with that Topic and the QoS of the dds::pub::Publisher associated to the dds::pub::DataWriter control the behavior on the publisher's side, while the corresponding dds::topic::Topic, dds::sub::DataReader and dds::sub::Subscriber QoS control the behavior on the subscriber's side.

When an application wishes to publish data of a given type, it must create a dds::pub::Publisher (or reuse an already created one) and a dds::pub::DataWriter with all the characteristics of the desired publication. Similarly, when an application wishes to receive data, it must create a dds::sub::Subscriber (or reuse an already created one) and a dds::sub::DataReader to define the subscription.

Conceptual Model

The overall conceptual model is shown below.

DCPS conceptual model

Notice that all the main communication objects (the specializations of Entity) follow unified patterns of:

Supporting QoS (made up of several QosPolicy); QoS provides a generic mechanism for the application to control the behavior of the Service and tailor it to its needs. Each dds::core::Entity supports its own specialized kind of QoS policies (see QoS Policies).

Accepting a Listener; listeners provide a generic mechanism for the middleware to notify the application of relevant asynchronous events, such as arrival of data corresponding to a subscription, violation of a QoS setting, etc. Each dds::core::Entity supports its own specialized kind of listener. Listeners are related to changes in status conditions (see Status Kinds).

Note that only one Listener per entity is allowed (instead of a list of them). The reason for that choice is that this allows a much simpler (and, thus, more efficient) implementation as far as the middleware is concerned. Moreover, if it were required, the application could easily implement a listener that, when triggered, triggers in return attached 'sub-listeners'.

Accepting a dds::core::cond::StatusCondition (and a set of dds::sub::cond::ReadCondition objects for the dds::sub::DataReader); conditions (in conjunction with dds::core::cond::WaitSet objects) provide support for an alternate communication style between the middleware and the application (i.e., wait-based rather than notification-based).

All DCPS entities are attached to a dds::domain::DomainParticipant. 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.

DomainEntity 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 dds::pub::DataWriter objects attached to the same dds::pub::Publisher and retrieved among dds::sub::DataReader objects attached to the same dds::sub::Subscriber.

By definition, a dds::topic::Topic corresponds to a single data type. However, several topics may refer to the same data type. Therefore, a dds::topic::Topic 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 Foo.

A collection of object instances, identified by their keys, can be disseminated on a topic.

In case a set of instances is gathered under the same topic, different instances must be distinguishable. This is achieved by means of the values of some data fields that form the key to that data set. The key description (i.e., the list of data fields whose value forms the key) has to be indicated to the middleware. The rule is simple: different data samples with the same key value represent successive values for the same instance, while different data samples with different key values represent different instances. If no key is provided, the data set associated with the dds::topic::Topic is restricted to a single instance.

Topics need to be known by the middleware and potentially propagated. Topic objects are created using the create operations provided by dds::domain::DomainParticipant.

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 dds::pub::DataWriter (this, in turn, will trigger its dds::pub::Publisher).

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 Listener is used to provide a callback for synchronous access and a dds::core::cond::WaitSet associated with one or several dds::core::cond::Condition 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.

Modules

DCPS consists of five modules:

DCPS modules and their dependencies

Infrastructure module defines the abstract classes and the interfaces that are refined by the other modules. It also provides support for the two interaction styles (notification-based and wait-based) with the middleware.

Domain module contains the dds::domain::DomainParticipant class that acts as an entrypoint of the Service and acts as a factory for many of the classes. The dds::domain::DomainParticipant also acts as a container for the other objects that make up the Service.

Topic module contains the dds::topic::Topic class, the TopicListener interface, and more generally, all that is needed by the application to define dds::topic::Topic objects and attach QoS policies to them.

Publication module contains the dds::pub::Publisher and dds::pub::DataWriter classes as well as the PublisherListener and dds::pub::DataWriterListener interfaces, and more generally, all that is needed on the publication side.

Subscription module contains the dds::sub::Subscriber, dds::sub::DataReader, dds::sub::cond::ReadCondition, and dds::sub::cond::QueryCondition classes, as well as the dds::sub::SubscriberListener and dds::sub::DataReaderListener interfaces, and more generally, all that is needed on the subscription side.