.. include:: ../../vars.rst .. _section-dds-introduction: An Introduction to |CONNEXT_HEADING| ------------------------------------ DDS Concepts ^^^^^^^^^^^^ |CONNEXT| 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| uses a *publish-subscribe* communications model to make data-distribution efficient and robust. |CONNEXT| 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|, 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| is highly configurable, so programmers can adapt it to meet an application's specific communication requirements. An Overview of |CONNEXT_HEADING| Objects ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The primary objects in |CONNEXT| are: * DomainParticipants * Publishers and DataWriters * Subscribers and DataReaders * Topics * Keys and DDS Samples * Requesters and Repliers .. figure:: ../../_static/administration/dds_intro/small_dds_system.png :alt: Small Dds system :name: Small Dds system :align: center :figWidth: 100% DomainParticipants ^^^^^^^^^^^^^^^^^^ .. |IMAGE_PARTICIPANT| image:: ../../_static/administration/branding/icons/participant.png .. |IMAGE_PROCESS| image:: ../../_static/administration/branding/icons/process.png .. |IMAGE_DATA_WRITER| image:: ../../_static/administration/branding/icons/datawriter.png .. |IMAGE_DATA_READER| image:: ../../_static/administration/branding/icons/datareader.png .. |IMAGE_DOMAIN_TOPIC| image:: ../../_static/administration/branding/icons/domaintopic.png A DDS domain, (represented in |AC| 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. .. figure:: ../../_static/administration/dds_intro/seg_app_with_domains.png :alt: Application scheme with domains :name: Application scheme with domains :align: center :figWidth: 100% 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*. Finding and Selecting DDS Entities in |AC_HEADING| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ *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. What is QoS? ^^^^^^^^^^^^ Fine control over Quality of Service (QoS) is perhaps the most important feature of |CONNEXT|. 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| 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| 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| 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| 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| QoS policies offer unprecedented flexible communications control. The *RTI Connext DDS Core Libraries User's Manual* contains details about all available QoS policies. Inspecting QoS Values in |AC_HEADING| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |AC| 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*). 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. .. figure:: ../../_static/administration/dds_intro/pub_entities.png :alt: Entities associated with publication :name: Entities associated with publication :align: center :figWidth: 100% 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*. 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. .. figure:: ../../_static/administration/dds_intro/sub_entities.png :alt: Entities associated with subscription :name: Entities associated with subscription :align: center :figWidth: 100% Each *DataReader* is tied to a single *Topic*. A *DataReader* will only receive data that was published on its *Topic*. Not only can |CONNEXT| 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. 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. 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*. 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| 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. Discovery ^^^^^^^^^ Discovery is the behind-the-scenes way in which |CONNEXT| 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. |AC| 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*.