CoAP · Study deck

CoAP Lab: Message Construction

CoAP is a compact request and response protocol.

Broker Bex is your guide for this deck.

implementation
iotclass.org

After studying this chapter

Learning objectives

You will be able to:

  • Encode CoAP header fields and token length into message bytes.
  • Match tokens and message IDs across replies and retries.
  • Explain: CoAP is a compact request and response protocol.
  • Explain: Construct a CoAP message byte-by-byte and see exactly how the 4-byte header is encoded.
iotclass.org

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.
iotclass.org

Major section

Try It: CoAP Message Byte Builder

Construct a CoAP message byte-by-byte and see exactly how the 4-byte header is encoded.

  • This helps you understand what the coap-simple library constructs behind the scenes when you call coap.get() or coap.put().
  • In a Python terminal, send a CON GET for /temperature over UDP to a local CoAP responder; inspect the first four bytes before any option or payload.
  • The real local request was 42 01 12 34 aa bb bb 74 65 6d 70 65 72 61 74 75 72 65: version 1, CON, token length 2, GET, and message ID 0x1234.
CoAP reduces header and transport overhead relative to HTTP/1.1 for constrained request-response exchanges.
CoAP reduces header and transport overhead relative to HTTP/1.1 for constrained request-response exchanges.
iotclass.org

Major section

Visual: CoAP Message Structure

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.

Why it matters

This prevents options or payload bytes from being mistaken for header fields.

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

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.
iotclass.org

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.
iotclass.org

Deck summary

Key takeaways

CoAP is a compact request and response protocol.

  • Construct a CoAP message byte-by-byte and see exactly how the 4-byte header is encoded.
  • 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.
  • 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.
iotclass.org

Retrieval practice

Recall check 1 of 4

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

Q1A CoAP server receives a POST request, creates a new sensor-reading resource at a new URI, and stores it successfully. Which response code should the server return?

A2.05 Content, treating creation as retrieval of existing content.
B2.01 Created, confirming a new resource at its assigned URI.
C2.04 Changed, treating new resource creation as an update.
D4.00 Bad Request, treating successful creation as client error.
Show answer

Answer: B see answers page

iotclass.org

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?

ABecause CON silently truncates every payload longer than 45 bytes.
BBecause CON cannot be used for GET, only for PUT and POST.
CBecause CON automatically switches UDP transport to TCP.
DBecause ACK waits and four retries can leave CON pending about 62–93 seconds.
Show answer

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

iotclass.org

Retrieval practice

Recall check 3 of 4

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

Q3What binds the server address, port and protocol context before CoAP resources receive requests?

ARegistered Resource Tree
BMethod Handler with Response
CBound UDP and CoAP Endpoint
DClient Assertion and Packet Trace
Show answer

Answer: C The server binds an address, port, and protocol context before any URI can receive a request.

iotclass.org

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?

AUse NON for replaceable telemetry; CON for commands, safety, firmware, and config.
BUse CON for routine samples but NON for commands and safety alerts.
CUse NON for every exchange because CON matters only at provisioning.
DUse CON for every exchange because NON can never report a loss.
Show answer

Answer: A see answers page

iotclass.org

Print reference

Answers 1 of 2

Answer key.

  1. B · 2.01 Created identifies the new resource produced by this POST. 2.04 Changed describes a successful change to an existing resource. 2.05 Content delivers a representation and can also answer a POST that does not create a new resource. Client errors (4.xx) indicate request problems.
  2. D · CON waits for an ACK; with four retransmissions, failure detection can take 62–93 seconds under RFC 7252 defaults.
  3. C · The server binds an address, port, and protocol context before any URI can receive a request.
iotclass.org

Print reference

Answers 2 of 2

Answer key.

  1. 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.
iotclass.org