CoAP · Study deck

CoAP Stack and Trace Contracts

A valve controller takes time to read its position, so it acknowledges a request before returning the value.

Broker Bex is your guide for this deck.

implementationstacktrace

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

After studying this chapter

Learning objectives

You will be able to:

Select an appropriate CoAP stack for a host, gateway, or constrained embedded node.
Map each URI and method to a resource handler, response code, payload, and trace artifact.
Verify client behavior by checking response codes, payloads, Tokens, Message IDs, options, and retransmissions.
Diagnose classic implementation failures: Message ID correlation, overuse of Confirmable messages, stale proxy caches, and repeated DTLS handshakes.

Major section

Start With the Trace That Must Prove It

The packet record reveals that replies are being matched to the wrong request after a restart.

A convincing screen can hide a message contract that is already unsafe.
A protocol is a shared set of rules for exchanging messages.
Constrained Application Protocol (CoAP) is a compact web-style protocol for small devices.

Major section

Start With the Trace That Must Prove It (continued)

A payload is the useful data in a message.

Transport Layer Security is a way to protect message traffic.
Datagram Transport Layer Security (DTLS) adapts that protection to a datagram link.
A gateway is the device that joins unlike networks.
The implementation is not accepted until the trace explains the behavior.

Major section

Overview: You Rarely Write CoAP Bytes by Hand — You Use a Stack

On general-purpose hosts and gateways the common stacks are aiocoap (Python, asyncio — the library these labs use), libcoap (C, which also ships the handy coap-client CLI), and Eclipse Californium (Java).

The labs below use that chain as their debugging order.
They implement the same RFC 7252 on the wire, so an aiocoap client can talk to an ESP32 server — interoperability is the whole point of the standard.

CoAP implementation lab diagram showing sensor, mobile app, and gateway clients sending GET, PUT, and Observe requests to a CoAP server with resource handlers.

Major section

Practitioner: A Server Is Handlers by URI+Method; A Client Reads Code and Payload

A small toolkit proves the exchange is doing what you think.

If an ESP32 version and a Python version expose the same resource contract, use the same client checklist for both; only the build and deployment step changes.
coaps traffic is encrypted ApplicationData.
Proving DTLS actually protects the payload.

Major section

Under the Hood: The Token Bug and Three Classic Pitfalls

A common implementation bug in hand-rolled correlation is matching responses by Message ID instead of Token.

The rule is simple: correlate application responses by Token; the Message ID is only for message-layer ACK and duplicate handling.
Good libraries already do this, which is a strong reason to use one.
You will see one Token repeated across notifications while the Message ID changes each time.

Major section

Under the Hood: The Token Bug and Three Classic Pitfalls (continued)

Correlate by TokenNotifications and separate responses share the Token, not the Message ID; key your dispatch on the Token.

If your handler only fires on the first notification, you are matching on the Message ID.
Three deployment pitfalls recur, and each is visible in a capture.
NON for telemetryReserve CON for messages whose loss is unsafe; frequent readings as NON save radio-on energy.

Major section

Follow a Separate Response through a Restart

The server sends an empty acknowledgement for Message ID 100.

That packet stops the request's message-level retry cycle; it contains no valve-position result.
Later, a separate Confirmable response arrives with Message ID 700 and the same Token A1.
The trace shows a 40 ms acknowledgement delay and a 240 ms response delay.

Major section

Follow a Separate Response through a Restart (continued)

Reporting only the smaller number would hide the time the application waited for data.

Neither figure measures the valve's physical travel unless the handler contract explicitly waits for that outcome.
Its old request state may have vanished.
An empty acknowledgement already proved receipt of the request, but the application still has no result.

Major section

Reference: CoAP Quick Reference Card

Constrained Application Protocol (CoAP) means a compact request method for small devices.

User Datagram Protocol (UDP) means sending separate messages without a lasting connection.
Hypertext Transfer Protocol (HTTP) means a request-and-response format used by web systems.
A payload means the useful data inside one message.
Transport layer security means protection for a network exchange.

Deck summary

Key takeaways

The packet record reveals that replies are being matched to the wrong request after a restart.

A payload is the useful data in a message.
On general-purpose hosts and gateways the common stacks are aiocoap (Python, asyncio — the library these labs use), libcoap (C, which also ships the handy coap-client CLI), and Eclipse Californium (Java).
A small toolkit proves the exchange is doing what you think.
A common implementation bug in hand-rolled correlation is matching responses by Message ID instead of Token.

Retrieval practice

Recall check 1 of 6

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

Q1When you build a CoAP server with a library like aiocoap, what does the library handle so your code does not have to?

AThe messaging layer — Confirmable retransmission, deduplication, token generation.

BNothing — you must encode the 4-byte header and options manually for each message.

CIt replaces UDP with TCP automatically for reliability.

DIt writes your application's business logic for each resource.

Show answer

Answer: A The stack implements RFC 7252 formatting, option encoding, token handling, retransmission, and duplicate suppression; your code owns resource handlers.

Retrieval practice

Recall check 2 of 6

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

Q2In client code, which two fields of a CoAP response should you inspect to handle the result correctly?

AUse the payload alone because the library returns code 2.05 for this call.

BResponse code for success or error and its associated payload.

CMessage ID and UDP port alone as if they contain the result.

DIP TTL and checksum alone as if they encode the application outcome.

Show answer

Answer: B The code tells you what happened and the payload carries the data; robust clients check the code before trusting the representation.

Retrieval practice

Recall check 3 of 6

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

Q3A packet trace shows later Observe notifications arrive with the registration Token and new Message IDs, but your CoAP client delivers only the first to its handler. Which client correlation bug explains this?

AIt assumes the server intentionally sends only one notification per Observe.

BIt matches later notifications by new Message ID instead of their shared Token.

CIt assumes DTLS rekeying discarded every message after the first.

DIt assumes Max-Age expiry cancels an otherwise active Observe stream.

Show answer

Answer: B Observe notifications share the registration Token but each has a fresh Message ID; correlating by Message ID drops all but the first.

Retrieval practice

Recall check 4 of 6

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

Q4A Python gateway must serve CoAP resources and handle replies. Which stack is the closest fit?

AAn aiocoap gateway stack that serves resources and handles replies.

BAn HTTP-only web server without any CoAP resource handling.

CA bare UDP socket requiring custom CoAP parsing and retry code.

DAn embedded radio driver with no resource or reply layer.

Show answer

Answer: A The chapter names aiocoap as a host and gateway CoAP stack.

Retrieval practice

Recall check 5 of 6

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

Q5Per this CoAP cheat sheet's Message Types list, which message type requires an acknowledgment (ACK) from the receiver?

ACON, the confirmable type that requires receiver acknowledgement.

BNON, a non-confirmable message with no required ACK exchange.

CACK, the acknowledgement sent in response to a CON message.

DRST, the reset type for a message the peer cannot process.

Show answer

Answer: A The cheat sheet's Message Types block distinguishes CON ('Confirmable, needs ACK') from NON ('Non-confirmable'), with ACK and RST as the acknowledgment and error/reset signals respectively.

Retrieval practice

Recall check 6 of 6

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

Q6According to this cheat sheet's 'Key Feature' note, what does CoAP's Observe option provide?

AResource-change notifications to subscribed clients, like pub/sub.

BA UDP packet retry rule independent of resource subscriptions.

CAutomatic DTLS negotiation instead of plain UDP on port 5683.

DA bulk delete method for several resources in one request.

Show answer

Answer: A The cheat sheet's Key Feature callout states the Observe option gives 'pub/sub-like notifications on resource changes,' distinct from the four basic methods (GET/POST/PUT/DELETE) listed above it.

Print reference

Answers 1 of 2

Answer key.

A · The stack implements RFC 7252 formatting, option encoding, token handling, retransmission, and duplicate suppression; your code owns resource handlers.
B · The code tells you what happened and the payload carries the data; robust clients check the code before trusting the representation.
B · Observe notifications share the registration Token but each has a fresh Message ID; correlating by Message ID drops all but the first.
A · The chapter names aiocoap as a host and gateway CoAP stack.

Print reference

Answers 2 of 2

Answer key.

A · The cheat sheet's Message Types block distinguishes CON ('Confirmable, needs ACK') from NON ('Non-confirmable'), with ACK and RST as the acknowledgment and error/reset signals respectively.
A · The cheat sheet's Key Feature callout states the Observe option gives 'pub/sub-like notifications on resource changes,' distinct from the four basic methods (GET/POST/PUT/DELETE) listed above it.