Chapter 9 DataWriters/Publishers and DataReaders/Subscribers

In the Connext communication model, applications must use APIs to create entities (objects) in order to establish publish-subscribe communications between each other. The entities and terminology associated with the data itself have been discussed already—Topics, keys, instances, DDS samples. This section will introduce the entities that user code must create to send and receive the data. Note that Entity is actually a basic concept. In object-oriented terms, Entity is the base class from which other DCPS classes—Topic, DataWriter, DataReader, Publisher, Subscriber, DomainParticipants—derive. For general information on Entities, see Chapter 18 Working with DDS Entities.

The sending side uses objects called Publishers and DataWriters. The receiving side uses objects called Subscribers and DataReaders. Figure 9.1: Overview illustrates the relationship of these objects.

Figure 9.1: Overview

For Publishers/DataWriters:

  • An application uses DataWriters to send data. A DataWriter is associated with a single Topic, which is associated with a specific type of data. You can have multiple DataWriters and Topics in a single application. In addition, you can have more than one DataWriter for a particular Topic in a single application.
  • Publishers act as containers for DataWriters. They own and manage DataWriters. A DataWriter can only be owned by a single Publisher while a Publisher can own many DataWriters. For more information, see Part 5: Sending Data.

For Subscribers/DataReaders:

  • An application uses DataReaders to access data received over the Connext databus. A DataReader is associated with a single Topic, which is responsible for subscribing to a specific type of data. You can have multiple DataReaders and Topics in a single application. In addition, you can have more than one DataReader for a particular Topic in a single application.
  • Subscribers act as containers for DataReaders. They own and manage DataReaders. A DataReader can only be owned by a single Subscriber while a Subscriber can own many DataReaders. Thus the same Subscriber may receive data for many different Topics of different data types. User code can either register a listener to be called when new data arrives or actively poll the DataReader for new data using its read() and take() methods. For more information, see Chapter 41 Overview of Receiving Data.

Some functional QoS policies, such as the Partition and Presentation QoS policy, are set at the Publisher/Subscriber level.

Example:

The publish-subscribe communications model is analogous to that of magazine publications and subscriptions. Think of a publication as a weekly periodical such as Newsweek®. The Topic is the name of the periodical (in this case the string "Newsweek"). The type specifies the format of the information, e.g., a printed magazine. The user data is the contents (text and graphics) of each DDS sample (weekly issue). The middleware is the distribution service (usually the US Postal service) that delivers the magazine from where it is created (a printing house) to the individual subscribers (people’s homes). This analogy is illustrated in Figure 9.2: An Example of Publish-Subscribe. Note that by subscribing to a publication, subscribers are requesting current and future DDS samples of that publication (such as once a week in the case of Newsweek), so that as new DDS samples are published, they are delivered without having to submit another request for data.

Figure 9.2: An Example of Publish-Subscribe

The publish-subscribe model is analogous to publishing magazines. The Publisher sends DDS samples of a particular Topic to all Subscribers of that Topic. With Newsweek® magazine, the Topic would be "Newsweek." The DDS sample consists of the data (articles and pictures) sent to all Subscribers every week. The middleware (Connext) is the distribution channel: all of the planes, trucks, and people who distribute the weekly issues to the Subscribers.

By default, each DDS sample is propagated individually, independently, and uncorrelated with other DDS samples. However, an application may request that several DDS samples be sent as a coherent set, so that they may be interpreted as such on the receiving side.