CoAP · Study deck

CoAP Lab: Message Construction

CoAP is a compact request and response protocol.

Broker Bex is your guide for this deck.

implementation

After studying this chapter

Learning objectives

You will be able to:

Explain: TKL then tells the decoder how many token bytes follow; delta-encoded options continue until the optional 0xFF payload marker, after which the remaining bytes are payload.
Explain: The Error:: Developers new to CoAP often confuse Message ID (MID) and Token, attempting to match responses to requests using MID alone.
Explain: A token links a reply to its request; a code names the request or result; and an ID identifies the message.
Explain: In a few bytes, a CoAP packet holds a type that says how to handle delivery.

Major section

Start With the Decision

CoAP is a compact request and response protocol.

A packet is one unit sent across a network.
In a few bytes, a CoAP packet holds a type that says how to handle delivery.
A token links a reply to its request; a code names the request or result; and an ID identifies the message.

Major section

Visual: CoAP Message Structure

The first four bytes always provide version, type, token length, code, and Message ID.

TKL then tells the decoder how many token bytes follow; delta-encoded options continue until the optional 0xFF payload marker, after which the remaining bytes are payload.
That order is the lab's packet-decoding checklist.

CoAP messages combine a fixed header with an optional token, options, payload marker, and payload.

Major section

Common Mistake: Misunderstanding CoAP Token vs Message ID Correlation

The Error:: Developers new to CoAP often confuse Message ID (MID) and Token, attempting to match responses to requests using MID alone.

This causes failures with Observe notifications and separate responses.
Separate Responses:: Server sends empty ACK (MID=12345) immediately, then data CON (MID=12346) later.
Both share the same Token.

Major section

Common Mistake: Misunderstanding CoAP Token vs Message ID Correlation (continued)

Concurrent Requests:: Client sends multiple requests simultaneously.

Responses may arrive out-of-order.
Token uniquely identifies which request each response answers.
Illustrative failure:: A client that discards Observe notifications with new Message IDs can lose readings.
Correlate notifications by the observation Token; use Message ID for ACK and duplicate handling.

Deck summary

Key takeaways

CoAP is a compact request and response protocol.

The first four bytes always provide version, type, token length, code, and Message ID.
The Error:: Developers new to CoAP often confuse Message ID (MID) and Token, attempting to match responses to requests using MID alone.
Concurrent Requests:: Client sends multiple requests simultaneously.

Retrieval practice

Recall check 1 of 4

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

Q1A CoAP server receives a POST request to create a new sensor reading and stores it successfully. Which response code should the server return?

A2.05 Content

B2.01 Created

C2.04 Changed

D4.00 Bad Request

Show answer

Answer: B

Retrieval practice

Recall check 2 of 4

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

Q2Per this chapter's Common Pitfalls, why can using Confirmable (CON) messages for every CoAP request be risky on a lossy network?

ACON needs an ACK exchange; four RFC-default retransmissions can keep an unanswered message pending for 62–93 seconds, depending on timeout randomization

BCON messages are limited to a maximum payload of 45 bytes, so larger sensor readings get silently truncated

CCON messages cannot be used with GET requests, only with PUT and POST

DCON automatically switches the transport from UDP to TCP, adding a handshake delay

Show answer

Answer: A CON waits for an ACK; with four retransmissions, failure detection can take 62–93 seconds under RFC 7252 defaults.

Retrieval practice

Recall check 3 of 4

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

Q3Place each CoAP lab responsibility where it lives so you can prove the client reached the intended resource and received the response your server actually emitted.

ABound UDP and CoAP Endpoint

BRegistered Resource Tree

CMethod Handler with Response

DClient Assertion and Packet Trace

Show answer

Answer: A Place each CoAP lab responsibility where it lives so you can prove the client reached the intended resource and received the response your server actually emitted.

Retrieval practice

Recall check 4 of 4

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

Q4This chapter's Advanced Lab Consolidation Notes recommend a hybrid CON/NON policy for a production-style CoAP deployment. Which message type does it recommend for routine telemetry versus for commands, safety alerts, firmware blocks, or configuration changes?

ANON for routine telemetry (where the next value replaces the previous one), CON for commands, safety alerts, firmware blocks, and configuration changes

BCON for routine telemetry, NON for commands and safety alerts

CNON for everything, since CON is only needed during initial device provisioning

DCON for everything, since NON provides no way to detect message loss

Show answer

Answer: A see answers page

Print reference

Answers 1 of 2

Answer key.

B
A · CON waits for an ACK; with four retransmissions, failure detection can take 62–93 seconds under RFC 7252 defaults.
A · Place each CoAP lab responsibility where it lives so you can prove the client reached the intended resource and received the response your server actually emitted.

Print reference

Answers 2 of 2

Answer key.

A · The chapter's hybrid policy: NON for routine telemetry where the next value replaces the previous one, CON for user actions, safety alerts, firmware blocks, or configuration changes -- preserving UDP's energy benefit while still proving delivery for messages that cannot be silently lost.