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.
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.
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
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).
- That yields a worst-case window of roughly 45 seconds ( MAX_TRANSMIT_SPAN ) before the sender gives up on that Message ID.
- Approx. Wait before retry.
Major section
Practitioner: Reliability Is a Per-Message Decision With Named Timers (continued)
By default NSTART = 1, meaning an endpoint keeps only one CON exchange outstanding to a given destination at a time.
- 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.
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.
- Piggybacked ACK 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.
- Separate Empty 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 3
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?
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 3
Broker Bex says: answer from memory, then check your reasoning.
Q2A device sends a Confirmable PUT and receives no ACK. Roughly how does CoAP's default retransmission behave before it declares failure?
Show answer
Answer: A ACK_TIMEOUT (2 s) times ACK_RANDOM_FACTOR (1.5) sets the first random window, then binary exponential backoff runs for up to MAX_RETRANSMIT (default 4) retransmissions. With default constants, MAX_TRANSMIT_SPAN is about 45 seconds before failure is reported.
Retrieval practice
Recall check 3 of 3
Broker Bex says: answer from memory, then check your reasoning.
Q3A CoAP server needs several seconds to sample a slow sensor before it can answer a Confirmable GET. What is the correct exchange pattern?
Show answer
Answer: D The empty ACK confirms receipt so the client stops retransmitting.
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 · ACK_TIMEOUT (2 s) times ACK_RANDOM_FACTOR (1.5) sets the first random window, then binary exponential backoff runs for up to MAX_RETRANSMIT (default 4) retransmissions. With default constants, MAX_TRANSMIT_SPAN is about 45 seconds before failure is reported.
- D · The empty ACK confirms receipt so the client stops retransmitting.