CoAP · Study deck
CoAP Observe Freshness Contracts
A wall display receives a room temperature and then loses its connection.
Broker Bex is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Trace a CoAP Observe registration from GET with Observe: 0 through token-bound notifications and cancellation.
- Design Max-Age, Confirmable notification, and re-registration policies for best-effort notification streams.
- Apply the RFC 7641 Observe-value comparison rule to reordered, skipped, and wrapped 24-bit sequence values.
- Capture the lifecycle, freshness, pacing, and stale-update evidence needed to review an Observe deployment.
Major section
Start With the Stale Alarm
A wall screen loses contact for ten minutes, then shows its last update beside a current time.
- The nurse may act on an old fact unless the client can tell its age and source.
- CoAP is a web-style exchange method for small devices.
- Observe is its way for a client to ask for later updates.
Major section
Start With the Stale Alarm (continued)
Delay one update, change their order, drop several, restart each side, let the age limit expire, and wrap the order value.
- The screen must show age and uncertainty clearly enough for the nurse to choose a safe next step.
- Under the Hood explains tokens, age fields, confirmation, order comparison, wrap rules, pacing, and the limits of best-effort updates.
- An alarm notification that arrives late can be worse than no notification if the client treats it as current.
- This page follows the subscription through token binding, Max-Age, liveness checks, sequence comparison, cancellation, and stale-update rejection so the pushed value can be trusted.
Major section
Overview: Register Once, Then Receive Pushes
Observe (RFC 7641) adds a lightweight publish/subscribe relationship on top of plain CoAP request/response, using a single option numbered 6.
- The server records the client — keyed by its source endpoint, its Token, and the requested resource — and answers 2.05 Content that itself carries an Observe option holding a sequence number.
Major section
Overview: Register Once, Then Receive Pushes (continued)
To stop, the client either sends a GET with Observe set to 1 (explicit cancel) or rejects a Confirmable notification with an RST.
- From that moment the client is an observer.
- That Token is how the client knows an unsolicited notification belongs to a subscription it opened.
- A concrete trace shows the contract.
Major section
Overview: Register Once, Then Receive Pushes (continued)
Whenever the resource's representation changes, the server sends a fresh 2.05 Content notification carrying an incremented Observe value and, crucially, the same Token as the original registration.
- If a dashboard registers GET /sensors/temp with Token 0x4a01, the server might answer 2.05 Content, Observe 12, and Max-Age: 60.
- Fourteen seconds later the pushed update uses a new Message ID but the same Token 0x4a01 and Observe 13.
- The client must keep that Token reserved while the observation is active; reusing it for another outstanding exchange would make later pushes ambiguous.
Major section
Overview: Register Once, Then Receive Pushes (continued)
The server keys an observer entry by endpoint, Token, and resource URI, then emits 2.05 Content notifications with advancing Observe values when that resource changes.
- The Token preserves relationship identity while freshness rules order updates.
- Cancel GET with Observe = 1, or reject a CON notification with RST, to end the relationship.
- Token binding The Token ties every later notification to the subscription; without it the client cannot match a push.
Major section
Practitioner: Notifications Are Best-Effort, So Max-Age and CON Checks Matter
Notifications are usually Non-confirmable, so any single one may be lost; the model only guarantees that the client eventually converges on the current state through later notifications.
- Freshness is governed by Max-Age.
- Each notification says how long its value can be considered current.
- Confirms observer is still reachable.
Major section
Practitioner: Notifications Are Best-Effort, So Max-Age and CON Checks Matter (continued)
For example, a battery gateway observing /tank/level might send ordinary NON notifications only when the level changes by at least 2% or every 60 seconds, whichever comes first, with Max-Age: 120.
- The client treats silence for 120 seconds as stale and re-registers instead of assuming the last level is still safe.
- The server might make every tenth notification Confirmable, or use a five-minute CON probe, so closed NAT bindings and rebooted clients are detected without turning every update into an ACK exchange.
- Bounds how long a value is fresh.
Major section
Under the Hood: The Observe Value Orders Notifications Despite UDP Reordering
Near wraparound, a server can move from 16777214 to 1; the large reverse numeric difference tells the client that 1 is actually newer, not older.
- If it simply trusted arrival order it would display stale data.
- Anything that fails all three tests is a reordered straggler and is discarded.
- If 122 arrives two seconds later, it is discarded as a late datagram.
Major section
Under the Hood: The Observe Value Orders Notifications Despite UDP Reordering (continued)
Observe value Up to 24 bits, incremented per notification, used purely to decide which of two notifications is newer.
- The Observe option value — a number up to 24 bits wide that the server increments per notification — exists to solve exactly this, and RFC 7641 defines a precise comparison so wraparound does not fool the client.
- After a long quiet period above 128 seconds, the client accepts the later arrival as a new baseline because old ordering evidence has expired.
- 128-second rule After 128 s, the later arrival is accepted regardless of the numeric comparison.
Major section
Let the Temperature Tile Become Unknown
An Observe application that requires every transition needs a separate durable event-history contract.
- At 125 s, 5 s remain.
- At 131 s, the display should follow its stale-data policy instead of presenting the temperature as current.
- Ordering asks which representation is newer within the registration.
Major section
Let the Temperature Tile Become Unknown (continued)
Skipping a sequence value does not by itself prove a lost critical event: notifications may represent changing resource state rather than a complete event history.
- Max-Age asks how long the accepted representation may be treated as fresh.
- A higher Observe value does not grant indefinite freshness, and an old packet arriving late must not silently renew confidence in an obsolete state.
- A separate warning can indicate that the monitoring path needs attention.
Major section
Let the Temperature Tile Become Unknown (continued)
The tile still becomes unknown when its freshness allowance expires; unchanged physical conditions cannot be inferred from silence.
- A renewed Observe registration must not accept an arbitrary old notification as its own continuation.
- A display can keep the last temperature for context while marking its age and loss of freshness clearly.
- They do not turn best-effort updates into a guarantee that every physical event was observed.
Major section
Release Checklist
Registration state is keyed by client endpoint, request Token, and resource URI, and the Token stays reserved while the observation is active.
- Notification policy names which updates are Non-confirmable, which are occasional Confirmable liveness probes, and when failed probes remove the observer.
- Freshness policy sets Max-Age for each observed resource and says what the client does when no notification arrives before that value expires.
- Pacing policy documents change thresholds, coalescing, maximum notification rate, and evidence that Observe reduces traffic instead of creating a push flood.
Deck summary
Key takeaways
A wall screen loses contact for ten minutes, then shows its last update beside a current time.
- Delay one update, change their order, drop several, restart each side, let the age limit expire, and wrap the order value.
- Observe (RFC 7641) adds a lightweight publish/subscribe relationship on top of plain CoAP request/response, using a single option numbered 6.
- To stop, the client either sends a GET with Observe set to 1 (explicit cancel) or rejects a Confirmable notification with an RST.
- Near wraparound, a server can move from 16777214 to 1; the large reverse numeric difference tells the client that 1 is actually newer, not older.
Retrieval practice
Recall check 1 of 3
Broker Bex says: answer from memory, then check your reasoning.
Q1In CoAP Observe, how does a client know that an unsolicited 2.05 Content notification belongs to a subscription it opened?
Show answer
Answer: A The registration Token is echoed on every notification, which is how the client correlates pushes to a specific observed resource.
Retrieval practice
Recall check 2 of 3
Broker Bex says: answer from memory, then check your reasoning.
Q2A CoAP observer stops receiving notifications and the Max-Age of the last one has expired. What is the correct client behavior?
Show answer
Answer: A Observe is best-effort; once Max-Age lapses with no new notification the client must not trust the old value and should re-register to recover.
Retrieval practice
Recall check 3 of 3
Broker Bex says: answer from memory, then check your reasoning.
Q3Why does a CoAP Observe client compare the Observe option value with a windowed rule instead of trusting the order in which notifications arrive?
Show answer
Answer: D RFC 7641's comparison uses the Observe value, its 2^23 wraparound window, and the 128-second fallback to accept newer notifications and discard reordered stragglers.
Print reference
Answers
Answer key.
- A · The registration Token is echoed on every notification, which is how the client correlates pushes to a specific observed resource.
- A · Observe is best-effort; once Max-Age lapses with no new notification the client must not trust the old value and should re-register to recover.
- D · RFC 7641's comparison uses the Observe value, its 2^23 wraparound window, and the 128-second fallback to accept newer notifications and discard reordered stragglers.