CoAP · Study deck
CoAP Messages: Format Foundations
A constrained sensor has little memory, power, or network capacity, so it cannot waste bytes on each request.
Broker Bex is your guide for this deck.
After studying this chapter
Learning objectives
Read the fixed header before interpreting the rest of a CoAP message.
- The fixed header has five fields in four bytes.Version, type, token length, code, and Message ID give the receiver its starting information without a long text header.
- Type and Code have different message-handling jobs.Type selects acknowledgement behaviour, while Code identifies the request method or response status carried by the datagram.
- Tokens can pair responses with concurrent requests.The controller needs the reply’s token to match an outstanding leak-sensor request rather than assuming the newest arrival answers the newest question.
- Compact binary fields can leave more space for useful data.The chapter’s 83-byte application budget leaves 79 bytes for tokens, options, and payload after the four-byte fixed header.
Major section
Start With the Decision
A constrained sensor has little memory, power, or network capacity, so it cannot waste bytes on each request.
- CoAP is the compact request-and-response method used here.
- Its four-byte header records the version, type, token length, code, and message ID.
- A token follows that header; checking it helps match a reply to the right request.
Major section
In 60 Seconds (1/2)
A well-formed header still needs checks before its reply can change application state.
- A delayed leak-sensor reply can answer an earlier request.Several exchanges can overlap, so four valid header bytes alone do not establish that the response belongs to the current question.
- The reply token must match an outstanding request.A mismatched response needs rejection rather than a guess about which sensor state the controller should accept.
Major section
In 60 Seconds (2/2)
- Message identity alone cannot establish the payload’s meaning.Code, source, time, unit, and content type belong in the record alongside the token and accepted application state.
- Repeated requests and receiver restarts can expose incorrect matching.The chapter also delays a reply and changes content type to test whether the controller accepts only the expected response.
Major section
Start With the First Four Bytes (1/2)
Follow the packet from its fixed header through token and options to any payload.
- Type and Code determine the receiver’s initial handling.The gateway needs the Confirmable or Non-confirmable choice and the request or response code before interpreting the rest of the packet.
- Token length tells the parser how much matching data follows.The token comes immediately after the fixed header, before compressed options and any message body.
Major section
Start With the First Four Bytes (2/2)
- Message ID supports acknowledgements and duplicate detection.Request-response pairing belongs to the Token instead, which matters when the controller has several sensor requests in flight.
- The payload marker appears only when a body follows.The chapter’s packet order separates fixed header, token, and options from the optional useful content.
Major section
Key Concepts
Separate request matching from the choice of acknowledgement behavior.
- A Confirmable message requires an acknowledgement from its recipient.This per-message choice provides acknowledgement behaviour over UDP instead of relying on a permanent TCP connection.
- A Non-confirmable message has no delivery guarantee.The chapter describes this fire-and-forget datagram as the lower-latency choice without a required acknowledgement from its recipient.
- The client’s Token can distinguish several outstanding requests.Concurrent replies need request-response pairing even when Message IDs already support acknowledgement handling and duplicate detection.
- Observe lets a client request resource-change notifications.The client registers for changes rather than treating every later notification as an unrelated response to a new question.
Activity 1 · Match
✎ Match each CoAP job
I want you to separate reply matching from message delivery.
On paper, match Token, Message ID, CON, NON, and Observe to these jobs: duplicate detection; resource-change notifications; request-response pairing; acknowledgement required; no delivery guarantee.
3 minutes · Pen and paper · Answer: Activity 1
Pause for eight seconds · Match five jobs · Compare with Activity 1 answer.
Major section
For Beginners: CoAP Message Format (1/2)
A compact fixed beginning makes the optional parts easier to locate.
- The header is the postcard’s small fixed beginning.Its four bytes are the chapter’s address-and-stamp area, leaving constrained devices room for the rest of the message.
- The following token can link a response to its request.A controller with overlapping sensor requests needs that pairing value before it can accept a delayed reply.
Major section
For Beginners: CoAP Message Format (2/2)
- Binary options can carry metadata without long text header lines.The worked first-option Content-Format example describes JSON in two CoAP bytes compared with a 32-byte HTTP header line.
- An optional payload carries content after its marker.The receiver still needs content metadata and application checks to interpret the useful data after locating its boundary.
Major section
Why CoAP's Format Exists: Design Rationale (1/2)
The application shares a small frame with several lower-layer headers.
- The chapter’s frame budget starts at 127 bytes.Its IEEE 802.15.4 example must fit lower-layer headers and application data inside that small shared space.
- MAC and 6LoWPAN headers need 23 and 13 bytes respectively.Those deductions occur before the UDP header or any CoAP header, token, option, or payload enters the budget.
Major section
Why CoAP's Format Exists: Design Rationale (2/2)
- The eight-byte UDP header leaves 83 bytes for the application.Subtracting 23, 13, and 8 from the 127-byte frame shows why long text headers compete directly with useful content.
- CoAP’s fixed header needs four bytes of the application budget.The remaining 79 bytes must accommodate the token, compressed options, and payload rather than carrying payload alone.
Major section
Tokens and binary metadata save space (1/2)
32-byte HTTP line versus 2-byte first CoAP option: 30 metadata bytes saved; whole-message size not implied.
- Tokens, options, and payload share the space after the fixed header.The chapter’s 83-byte application allowance becomes 79 bytes after the four-byte CoAP header, before any variable fields are included.
- The token can accompany the message without TCP connection setup.The gateway can use this pairing field instead of maintaining a TCP socket for every sensor connection in the chapter’s comparison.
Major section
Tokens and binary metadata save space (2/2)
- The first JSON Content-Format option uses two CoAP bytes.One byte marks the option and one carries the JSON format value, leaving 30 metadata bytes saved against the 32-byte HTTP line.
- Compact encoding can reduce transmitted bytes and their energy cost.The sensor’s binary header and metadata use less of the small frame, where every transmitted byte consumes airtime and battery energy.
Deck summary
Key takeaways
Decode structure and verify meaning before accepting a CoAP reply.
- The fixed header tells the receiver where parsing begins.Its version, type, token length, code, and Message ID fit in four bytes before the token and compressed options.
- Tokens and Message IDs have different matching responsibilities.The Token pairs request and response; Message ID supports message-layer acknowledgements and duplicate detection during the exchange.
- Confirmable and Non-confirmable messages have different acknowledgement rules.The first requires an acknowledgement, while the second avoids that requirement and provides no delivery guarantee.
- Payload acceptance needs metadata and application checks.A well-formed reply can still have the wrong content type, source, time, or unit for the controller’s current question.
Retrieval practice
Recall check 1 of 2
Broker Bex says: answer from memory, then check your reasoning.
Q1A CoAP client has several requests in flight and uses Message ID alone to match responses. What should the reviewer correct?
Show answer
Answer: A CoAP message-format review should distinguish header fields, options, tokens, and payload interpretation.
Retrieval practice
Recall check 2 of 2
Broker Bex says: answer from memory, then check your reasoning.
Q2A 32-byte HTTP Content-Type line is compared with a two-byte CoAP Content-Format JSON option encoded as the first option. How many bytes are saved?
Show answer
Answer: A The first CoAP option uses one header byte and one value byte, so 32 minus 2 equals 30 bytes saved; this example has a 16× metadata-size difference.
Print reference
Answers
Answer key.
- A · CoAP message-format review should distinguish header fields, options, tokens, and payload interpretation.
- A · The first CoAP option uses one header byte and one value byte, so 32 minus 2 equals 30 bytes saved; this example has a 16× metadata-size difference.
Print reference
Activity 1 answer
Model answer.
Match: Token: request-response pairing. Message ID: duplicate detection. CON: acknowledgement required. NON: no delivery guarantee. Observe: resource-change notifications.