CoAP Observe Workbench
Animate RFC 7641 Observe registration, notifications, sequence ordering, Max-Age freshness, CON/NON delivery, and cancellation.
CoAP Observe Workbench
Step through an Observe relationship and watch the same extended GET become a stream of server notifications. The important details are the Token that binds the stream, the Observe option that changes meaning by direction, and Max-Age as representation freshness.
Observe Exchange
Use Play or Step to inspect each packet. The moving packet, event trace, registry, cache, and option inspector update together.
The client asks to observe a resource by sending a GET with Observe=0. The Token becomes the stream handle for later notifications.
Server has a current representation of /sensors/temp.
Endpoint, token, resource, and request options are stored on the server.
The value is fresh while its age is within Max-Age.
Current Packet Inspector
Observe is a CoAP option. In the request, value 0 registers and value 1 cancels. In responses and notifications, the value is a sequence number.
Event Trace
Read this trace like a packet capture: each row states the protocol action and the learner decision.
The client begins with a normal GET. The Observe option asks the server to keep sending updated responses later.
Later notifications are matched to the original request by Token, not by Message ID.
Client request values are control signals. Server response values are sequence numbers.
Expiry means the cached representation may be stale. It is not the same thing as automatic cancellation.
CoAP Observe Quick Reference
These cards organize the protocol details students need when reading traces or implementing an observer.
Request Values
| Observe | Meaning | Direction |
|---|---|---|
| 0 | Register | Client -> Server |
| 1 | Deregister | Client -> Server |
| Absent | Normal GET or final response | Either |
Notification Values
- Server responses include an Observe sequence value when the observation is active.
- The value is up to 24 bits and is used for freshness ordering.
- Notifications keep the same Token as the registration.
Ordering Checks
- Accept a newer sequence value and update the cached representation.
- Discard late older values that arrive after a newer notification.
- Handle wraparound with RFC 7641 serial-number logic, not plain integer sorting.
Freshness Checks
Max-Agetells how long the response is fresh.- Refresh notifications can repeat unchanged content before expiry.
- After expiry, the client should not trust the cache as current.
CON Notifications
- Use when the update is important enough to confirm receipt.
- The client sends an empty ACK with the same Message ID.
- Repeated failed CON delivery lets the server remove an unreachable observer.
NON Notifications
- Use for frequent readings where losing one update is acceptable.
- No ACK is expected, so delivery failure is less visible.
- The next newer notification replaces missed or older data.
Cancellation
- Send GET with Observe=1 using the same Token and request context.
- Send RST if a notification arrives for an observation the client no longer wants.
- The server can also end observation by omitting Observe from a response.
Design Tradeoff
- Observe saves polling traffic when resources change less often than clients poll.
- The server must keep observer state and fan out notifications.
- Use polling when state is highly volatile or server memory is too constrained.
Learning Support
Use these checks to help learners with different backgrounds read the animation independently.
How To Read A Trace
First check Token continuity, then Observe value direction, then Message Type. Message ID only matches ACK/RST for a specific message.
Choose CON Or NON
Use CON when missing the update matters. Use NON when readings are frequent and a later value naturally repairs a lost update.
Handle Stale Data
When Max-Age expires, mark the cache stale and revalidate or fall back to a fresh GET if the application needs current state.
Avoid Ghost Observers
Persist or regenerate Tokens carefully. If a rebooted client receives a notification it cannot map, RST tells the server to clean up.
Technical Notes And Source Links
This workbench follows RFC 7641 Observe semantics and RFC 7252 message-layer behavior. It intentionally separates representation freshness from observer lifetime, and separates Token-based observation matching from Message ID based ACK/RST matching.
Observe=1 is shown as explicit cancellation only in the client-to-server direction. Server-to-client Observe values are notification sequence numbers, not deregistration commands.
For a CON notification, the ACK repeats the notification Message ID and normally has no payload. The Token still belongs to the response stream.
If a representation exceeds Max-Age, the cache is stale. The server may still keep the observer until explicit cancellation, RST, failed delivery, resource removal, or local policy cleanup.