You are here: Part 2: Core Concepts > Sending Data > DataWriter QosPolicies > DEADLINE QosPolicy

DEADLINE QosPolicy

On a DataWriter, this QosPolicy states the maximum period in which the application expects to call write() on the DataWriter, thus publishing a new DDS sample. The application may call write() faster than the rate set by this QosPolicy.

On a DataReader, this QosPolicy states the maximum period in which the application expects to receive new values for the Topic. The application may receive data faster than the rate set by this QosPolicy.

The DEADLINE QosPolicy has a single member, shown in Table 39 . For the default and valid range, please refer to the API Reference HTML documentation.

Table 39 DDS_DeadlineQosPolicy

Type

Field Name

Description

DDS_Duration_t

period

For DataWriters: maximum time between writing a new value of an instance.

For DataReaders: maximum time between receiving new values for an instance.

You can use this QosPolicy during system integration to ensure that applications have been coded to meet design specifications. You can also use it during run time to detect when systems are performing outside of design specifications. Receiving applications can take appropriate actions to prevent total system failure when data is not received in time. For topics on which data is not expected to be periodic, the deadline period should be set to an infinite value.

For keyed topics, the DEADLINE QoS applies on a per-instance basis. An application must call write() for each known instance of the Topic within the period specified by the DEADLINE on the DataWriter or receive a new value for each known instance within the period specified by the DEADLINE on the DataReader. For a DataWriter, the deadline period begins when the instance is first written or registered. For a DataReader, the deadline period begins when the first DDS sample is received.

Connext DDS will modify the OFFERED_DEADLINE_MISSED_STATUS and call the associated method in the DataWriterListener (see OFFERED_DEADLINE_MISSED Status) if the application fails to write() a value for an instance within the period set by the DEADLINE QosPolicy of the DataWriter.

Similarly, Connext DDS will modify the REQUESTED_DEADLINE_MISSED_STATUS and call the associated method in the DataReaderListener (see REQUESTED_DEADLINE_MISSED Status) if the application fails to receive a value for an instance within the period set by the DEADLINE QosPolicy of the DataReader.

For DataReaders, the DEADLINE QosPolicy and the TIME_BASED_FILTER QosPolicy may interact such that even though the DataWriter writes DDS samples fast enough to fulfill its commitment to its own DEADLINE QosPolicy, the DataReader may see violations of its DEADLINE QosPolicy. This happens because Connext DDS will drop any packets received within the minimum_separation set by the TIME_BASED_FILTER—packets that could satisfy the DataReader’s deadline.

To avoid triggering the DataReader’s deadline even though the matched DataWriter is meeting its own deadline, set your QoS parameters to meet the following relationship:

reader deadline period >= reader minimum_separation + writer deadline period

Although you can set the DEADLINE QosPolicy on Topics, its value can only be used to initialize the DEADLINE QosPolicies of either a DataWriter or DataReader. It does not directly affect the operation of Connext DDS, see Setting Topic QosPolicies.

Example

Suppose you have a time-critical piece of data that should be updated at least once every second. You can set the DEADLINE period to 1 second on both the DataWriter and DataReader. If there is no update within that time, the DataWriter will get an on_offered_deadline_missed Listener callback, and the DataReader will get on_requested_deadline_missed, so that both sides can handle the error situation properly.

Note that in practice, there will be latency and jitter in the time between when data is send and when data is received. Thus even if the DataWriter is sending data at exactly 1 second intervals, the DataReader may not receive the data at exactly 1 second intervals. More likely, it will DataReader will receive the data at 1 second plus a small variable quantity of time. Thus you should accommodate this practical reality in choosing the DEADLINE period as well as the actual update period of the DataWriter or your application may receive false indications of failure.

The DEADLINE QosPolicy also interacts with the OWNERSHIP QosPolicy when OWNERSHIP is set to EXCLUSIVE. If a DataReader fails to receive data from the highest strength DataWriter within its requested DEADLINE, then the DataReaders can fail-over to lower strength DataWriters, see the OWNERSHIP QosPolicy.

Properties

This QosPolicy can be changed at any time.

The deadlines on the two sides must be compatible.

DataWriter’s DEADLINE period <= the DataReader’s DEADLINE period.

That is, the DataReader cannot expect to receive DDS samples more often than the DataWriter commits to sending them.

If the DataReader and DataWriter have compatible deadlines, Connext DDS monitors this “contract” and informs the application of any violations. If the deadlines are incompatible, both sides are informed and communication does not occur. The ON_OFFERED_INCOMPATIBLE_QOS and the ON_REQUESTED_INCOMPATIBLE_QOS statuses will be modified and the corresponding Listeners called for the DataWriter and DataReader respectively.

Related QosPolicies

Applicable DDS Entities

System Resource Considerations

A Connext DDS-internal thread will wake up at least by the DEADLINE period to check to see if the deadline was missed. It may wake up faster if the last DDS sample that was published or sent was close to the last time that the deadline was checked. Therefore a short period will use more CPU to wake and execute the thread checking the deadline.

© 2015 RTI