CoAP · Study deck

CoAP Exchange Reliability Contracts

A battery valve sends a CoAP request over a lossy radio and waits for an acknowledgement that may never arrive.

Broker Bex is your guide for this deck.

messagereliability

Broker Bex, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Separate CoAP message-layer type from request/response Code and Token semantics in a packet trace.
Set CON/NON policy and document ACK timeout, randomization, backoff, and retransmission evidence.
Distinguish piggybacked ACK-plus-response exchanges from separate responses that use a new Message ID.
Diagnose duplicate suppression, Message ID reuse, Token correlation, and RST paths after context loss.

Major section

Separate the Exchange From the Valve Action

A non-confirmable message does not create that acknowledgement duty.

The message ID supports duplicate detection for the message exchange.
The token lets a client match a response to its request.
Neither identifier alone proves that a physical command is safe to repeat.

CoAP reliable, fire-and-forget, piggybacked, and separate exchange patterns.

Major section

Separate the Exchange From the Valve Action (continued)

The valve applies the target and sends an acknowledgement, but that packet is lost.

Duplicate handling should return the prior exchange result without applying a second non-idempotent action.
A command identifier in the application payload gives longer-lived protection when protocol duplicate state expires.
If the first wait is 2 s and each retry doubles it, waits before three retries are 2 s, 4 s, and 8 s, totalling 14 s.

Major section

Start With the Lost ACK

A protocol means agreed rules and message order for communication.

Constrained Application Protocol (CoAP) is a web-style method made for small devices and limited networks.
A Confirmable command can be delivered, executed, and still look failed if the ACK disappears on the way back.
The client retries; the server must recognize the duplicate; the response still needs to match the original request instead of running the command twice.

Major section

Overview: Four Message Types Living in Two Layers

The messaging layer handles the datagram itself and uses four message types plus a 16-bit Message ID.

The message type is orthogonal to whether a datagram carries a request or a response: a single message is both a type (CON/NON/ACK/RST) and, usually, a request or response.

Major section

Overview: Four Message Types Living in Two Layers (continued)

Confirmable (CON)Elicits an ACK and is retransmitted on timeout.

Confirmable (CON) asks for reliability: the sender expects an acknowledgment and will retransmit if none arrives.
A useful packet-trace habit is to name both layers for every datagram.
It may be empty, or it may piggyback the response.

Major section

Practitioner: Reliability Is a Per-Message Decision With Named Timers

By default NSTART = 1, meaning an endpoint keeps only one CON exchange outstanding to a given destination at a time.

When you mark a message CON, you inherit RFC 7252's retransmission machinery, and its constants are worth knowing by name.
The first retransmission timeout is a random value between ACK_TIMEOUT (default 2 s) and ACK_TIMEOUT × ACK_RANDOM_FACTOR (default 1.5, so up to 3 s).
Approx. Wait before retry.

Major section

Practitioner: Reliability Is a Per-Message Decision With Named Timers (continued)

With default parameters, MAX_TRANSMIT_SPAN is 45 seconds from first to last transmission; MAX_TRANSMIT_WAIT is 93 seconds until the sender gives up waiting for ACK or RST.

If you need concurrency, you either raise NSTART carefully or use NON for the bulk traffic.
If the valve ACK is lost, the timeline below plays out; the temperature NON simply relies on the next sample.
Account for NSTART = 1 as well; confirmable writes to one peer serialize, so the latency budget must cover the queue.

Major section

Under the Hood: Piggybacked vs Separate Responses, and Duplicate Suppression

A server has two ways to answer a Confirmable request.

The ACK reuses the request's Message ID, and the Token matches the request's Token.
If that later message is CON, the client ACKs it in turn.
Because a CON can be retransmitted, a server may receive the same message twice.

CoAP client-server message flow compares confirmable request and acknowledgment, non-confirmable request without acknowledgment, and a separate response where a slow request first receives an empty acknowledgment and later a result.

Major section

Under the Hood: Piggybacked vs Separate Responses, and Duplicate Suppression (continued)

A ready response can ride inside the ACK; a delayed response uses a new message exchange but retains the Token.

This separation also explains why duplicate suppression is keyed at the message layer while application correlation survives across exchanges.
PiggybackedACK carries the response.
Used when the answer is immediate.

Major section

Under the Hood: Piggybacked vs Separate Responses, and Duplicate Suppression (continued)

A duplicate CON must not be acted on twice; instead the server resends the cached ACK.

This matters most for non-idempotent operations — a duplicated POST that appended a log entry, or a relative counter increment, would be wrong if processed twice.
Same Message ID as the request, Token matches.
SeparateEmpty ACK stops retransmission, then a new CON/NON carries the response, correlated only by Token.

Major section

Release Checklist

ACK timeout, ACK random factor, maximum retransmits, and any NSTART change are recorded with their rationale.

Piggybacked and separate response cases are distinguished, including when an empty ACK is sent.
Duplicate cache lifetime, Message ID reuse policy, and non-idempotent operation handling are explicit.
RST behavior is defined for unknown tokens, lost Observe state, rebooted endpoints, and malformed messages.

Deck summary

Key takeaways

A non-confirmable message does not create that acknowledgement duty.

The valve applies the target and sends an acknowledgement, but that packet is lost.
A protocol means agreed rules and message order for communication.
The messaging layer handles the datagram itself and uses four message types plus a 16-bit Message ID.
Confirmable (CON)Elicits an ACK and is retransmitted on timeout.

Retrieval practice

Recall check 1 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q1A constrained node reboots and then receives a Confirmable notification for an Observe registration it no longer remembers. Which message type should it send back?

ARST, because it received the message but has lost the context needed to process it.

BACK, because the notification arrived intact and the sender needs confirmation of delivery.

CA new CON request, because the node should re-register the resource first.

DNON, because the node wants to avoid retry traffic while it recovers from reboot.

Show answer

Answer: A RST means 'received but not processable here'; it is exactly how a node cancels an exchange whose context it lost, such as after a reboot.

Retrieval practice

Recall check 2 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q2Which CoAP fields distinguish message-layer acknowledgement matching and duplicate detection from request/response semantics?

AType and MID match ACKs and duplicates; Token matches responses; Code states result.

BMID alone proves both ACK delivery and result without Type, Token, or Code.

CToken names the method while Code detects duplicate messages.

DIP address alone identifies response semantics and proves success.

Show answer

Answer: A Message Type and Message ID support ACK/RST matching and duplicate detection; Token correlates requests and responses; Code identifies the method or result.

Retrieval practice

Recall check 3 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q3A device sends a Confirmable PUT and receives no ACK. Roughly how does CoAP's default retransmission behave before it declares failure?

AIt retries up to MAX_RETRANSMIT with backoff, then reports failure.

BIt retries forever at a fixed one-second interval until ACK arrives.

CIt converts the command to NON immediately and stops delivery checks.

DIt sends all retransmissions in parallel to shorten the wait.

Show answer

Answer: A see answers page

Retrieval practice

Recall check 4 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q4A CoAP server needs several seconds to sample a slow sensor before it can answer a Confirmable GET. What is the correct exchange pattern?

AWait until sampling ends, then put the delayed result into the original ACK.

BSend RST to the client and require a new GET after sampling completes.

CReuse the request MID for a delayed result rather than a separate response.

DSend empty ACK promptly, then a separate response when sampling ends.

Show answer

Answer: D The empty ACK confirms receipt so the client stops retransmitting.

Retrieval practice

Recall check 5 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q5A client retries a command after losing the reply. What prevents the server from applying the same non-idempotent operation twice?

ATrack duplicate exchanges using an application command ID across retries.

BApply repeated packets as new commands after a lost non-idempotent reply.

CMatch response Token alone without identifying repeated side effects.

DDisable ACKs so a command can never be duplicated by a retry.

Show answer

Answer: A Message-level suppression has a bounded lifetime, so the application needs a repeat-safe command rule.

Print reference

Answers

Answer key.

A · RST means 'received but not processable here'; it is exactly how a node cancels an exchange whose context it lost, such as after a reboot.
A · Message Type and Message ID support ACK/RST matching and duplicate detection; Token correlates requests and responses; Code identifies the method or result.
A · ACK_TIMEOUT (2 s) and ACK_RANDOM_FACTOR (1.5) set the first 2–3 s random window, then binary exponential backoff runs for up to MAX_RETRANSMIT (default 4) retransmissions. MAX_TRANSMIT_SPAN is 45 s from first to last send; MAX_TRANSMIT_WAIT is 93 s until the sender gives up waiting.
D · The empty ACK confirms receipt so the client stops retransmitting.
A · Message-level suppression has a bounded lifetime, so the application needs a repeat-safe command rule.

Q1: Reset rejects a notification whose old context is gone. Q2: Type and Message ID identify exchange handling; token matches a response to its request. Q3: Use the timer and retransmission rules for confirmable messages. Q4: Piggybacked responses share the acknowledgement; separate responses follow an empty acknowledgement. Q5: Keep protocol receipt evidence separate from the physical valve action. Reveal each answer after five seconds; retain the complete print key.