Publisher's deadline is slower than the subscriber demands

Rule 24 · applies to publisher and subscriber matching · Back to all rules

Won't connect. An offered deadline longer than requested is incompatible, so the pair never matches.

If you set Writer Deadline period P together with Reader Deadline period smaller than P

Won't connect

• Settings involved: Deadline and Deadline
• What QoS Guard checks: [Writer.DEADLN.period > Reader.DEADLN.period]

Example

The writer promises a sample every 200 ms, but the reader demands every 100 ms. They are incompatible and do not connect.

How to fix it

Make the writer's Deadline period at most the reader's requested period.

Why this rule is flagged

What the DDS specification says

OMG DDS §	QoS policy	Standard statement
§2.2.3.7	DEADLINE	The value offered is considered compatible with the value requested if and only if the inequality "offered deadline period <= requested deadline period" evaluates to 'TRUE.'

---

What the engine source code shows

Both engines reject endpoint matching when the writer offers a deadline period longer than the reader requests.

Fast DDS implementation evidence

// EDP::valid_matching: offered deadline period must not exceed requested period.
if (wdata->m_qos.m_deadline.period > rdata->m_qos.m_deadline.period)
{
    incompatible_qos.set(fastdds::dds::DEADLINE_QOS_POLICY_ID);
}

Cyclone DDS implementation evidence

// q_qosmatch.c: writer deadline period must not exceed reader deadline period.
if ((mask & QP_DEADLINE) &&
        rd_qos->deadline.deadline < wr_qos->deadline.deadline)
{
    *reason = DDS_DEADLINE_QOS_POLICY_ID;
    return false;
}

Item	Value
Dataset	Download CSV
Fixed QoS setting	None
Tested variable	writer_deadline_ms, reader_deadline_ms
Tested values	writer_deadline_ms ∈ {50, 100, 200}, reader_deadline_ms ∈ {50, 100, 200}
Valid / boundary cases	writer_deadline_ms <= reader_deadline_ms, including 50 ≤ 50, 50 ≤ 100, 50 ≤ 200, 100 ≤ 100, 100 ≤ 200, 200 ≤ 200
Violating cases	writer_deadline_ms > reader_deadline_ms, including 100 > 50, 200 > 50, 200 > 100
Tested engines / versions	Fast DDS 2.6.11 (Humble), Fast DDS 2.14.6 (Jazzy), Cyclone DDS 0.10.5
Network setting	RTT = 1 ms, loss = 0%, PP = 50 ms, message size = 1024 B

Engine	Tested setting	Observed behavior
Fast DDS 2.6.11 (Humble)	writer_deadline_ms, reader_deadline_ms ∈ {50, 100, 200}	Matched when writer_deadline_ms <= reader_deadline_ms; match rejected when writer_deadline_ms > reader_deadline_ms
Fast DDS 2.14.6 (Jazzy)	writer_deadline_ms, reader_deadline_ms ∈ {50, 100, 200}	Matched when writer_deadline_ms <= reader_deadline_ms; match rejected when writer_deadline_ms > reader_deadline_ms
Cyclone DDS 0.10.5	writer_deadline_ms, reader_deadline_ms ∈ {50, 100, 200}	Matched when writer_deadline_ms <= reader_deadline_ms; match rejected when writer_deadline_ms > reader_deadline_ms

---

What you'll see when you run it

QoS Guard reports this mismatch as a structural conflict:

[STRUCTURAL] [pose_pub] Writer.DEADLN.period <-> Reader.DEADLN.period (Writer>Reader)

At runtime the two endpoints never connect. DDS matches a publisher and subscriber only when the offered QoS satisfies the requested QoS (the Requested-Offered, or RxO, rule). A deadline is compatible only when the offered period is at most the requested period, but here the writer offers a 2 s period against the reader's 1 s request, so discovery refuses the match. No connection forms and no samples flow, with no error printed.