DDS provides applications policies to control a wide set of non-functional properties, such as data availability, data delivery, data timeliness and resource usage. The figure below shows the full list of QoS policies available.
DDS QoS Policies
The semantics and the behaviour of entities, such as a topic, data reader, and data writer, can be controlled through available QoS policies. The policies that control an end-to-end property are considered as part of the subscription matching.
DDS Request vs. Offer QoS Model
DDS uses a ‘request vs. offer’ QoS-matching approach, as shown in the figure DDS Request vs. Offer QoS Model in which a data reader matches a data writer if and only if the QoS it is requesting for the given topic does not exceed (i.e. it is no more stringent than) the QoS with which the data is produced by the data writer. DDS subscriptions are matched against the topic type and name, as well as against the QoS being offered and requested by data writers and readers.
This DDS matching mechanism ensures that:
- types are preserved end-to-end due to the topic type matching, and
- end-to-end QoS invariants are also preserved.
The remainder of this chapter describes the most important QoS policies in DDS.
DDS provides the following QoS policies that control the availability of data to domain participants:
The DURABILITY policy controls the lifetime of the data written to the global data space in a domain. Supported durability levels include:
Durability is achieved by relying on a durability service whose properties are configured by means of the DURABILITY_SERVICE QoS of non-volatile topics.
The LIFESPAN QoS policy controls the interval of time during which a data sample is valid. The default value is infinite, with alternative values being the time-span for which the data can be considered valid.
The HISTORY QoS policy controls the number of data samples (i.e. subsequent writes of the same topic) that must be stored for readers or writers. Possible values are the last sample, the last n samples, or all samples.
These DDS data availability QoS policies decouple applications in time and space. They also enable these applications to cooperate in highly dynamic environments characterized by continuous joining and leaving of publishers and subscribers. Such properties are particularly relevant in Systems-of-Systems (SoS) since they increase the decoupling of the component parts.
DDS provides the following QoS policies that control how data is delivered and how publishers can claim exclusive rights on data updates:
These DDS data delivery QoS policies control the reliability and availability of data, thereby allowing the delivery of the right data to the right place at the right time. More elaborate ways of selecting the right data are offered by the DDS content-awareness profile, which allows applications to select information of interest based upon their content. These QoS policies are particularly useful in SoS since they can be used to finely tune how and to whom data is delivered, thus limiting not only the amount of resources used, but also minimizing the level of interference by independent data streams.
DDS provides the following QoS policies to control the timeliness properties of distributed data:
These DDS data timeliness QoS policies provide control over the temporal properties of data. Such properties are particularly relevant in SoS since they can be used to define and control the temporal aspects of various subsystem data exchanges, whilst ensuring that bandwidth is exploited optimally.
DDS defines the following QoS policies to control the network and computing resources that are essential to meet data dissemination requirements:
These DDS resource QoS policies provide control over the local and end-to-end resources, such as memory and network bandwidth. Such properties are particularly relevant in SoS since they are characterized by largely heterogeneous subsystems, devices, and network connections that often require down-sampling, as well as overall limits on the amount of resources used.
The QoS policies described above provide control over the most important aspects of data delivery, availability, timeliness, and resource usage. DDS also supports the definition and distribution of user-specified bootstrapping information via the following QoS policies:
These DDS configuration QoS policies provide useful a mechanism for bootstrapping and configuring applications that run in SoS. This mechanism is particularly relevant in SoS since it provides a fully-distributed means of providing configuration information.
All the code examples you have have seen so far did rely on default QoS settings, so that we did not have to be concerned with defining the desired QoS. Setting QoS on DDS entities shows how you can create and set QoS on DDS entities.
// create a Domain Participant, -1 defaults to value defined in configuration file
dds::domain::DomainParticipant dp(-1);
dds::topic::qos::TopicQos topicQos
= dp.default_topic_qos()
<< dds::core::policy::Durability::Transient()
<< dds::core::policy::Reliability::Reliable();
dds::topic::Topic<tutorial::TempSensorType> topic(dp, "TempSensor", topicQos);
dds::pub::qos::PublisherQos pubQos
= dp.default_publisher_qos()
<< dds::core::policy::Partition("building-1:floor-2:room:3");
dds::pub::Publisher pub(dp, pubQos);
dds::pub::qos::DataWriterQos dwqos = topic.qos();
dds::core::policy::TransportPriority transportPriority(10);
dwqos << transportPriority;
dds::pub::DataWriter<tutorial::TempSensorType> dw(pub, topic, dwqos);
Along with an API to explicitly create QoS, DDS also provides the concept of a QoSProvider to make it possible to externalize the definition of the QoS and make it a deployment-time concern. The listing below shows how the QoSProvider can be used to fetch a QoS definition from a file.
dds::core::QosProvider qp("file://defaults.xml", "DDS DefaultQosProfile");
// create a Domain Participant, -1 defaults to value defined in configuration file
dds::domain::DomainParticipant dp(-1);
dds::topic::qos::TopicQos topicQos = qp.topic_qos();
dds::topic::Topic<tutorial::TempSensorType> topic(dp, "TempSensor", topicQos);
dds::pub::qos::PublisherQos pubQos = qp.publisher_qos();
dds::pub::Publisher pub(dp, pubQos);
dds::pub::qos::DataWriterQos dwqos = qp.datawriter_qos();
dds::pub::DataWriter<tutorial::TempSensorType> dw(pub, topic, dwqos);
This chapter has explained the role of QoS in DDS and shown how the various policies can be used to control the most important aspects of communication, data availability and resource usage. The code examples have also illustrated that setting QoS is pretty straightforward and the use of the QoSProvider can be of great help in making the selection of QoS a deployment concern.