CoAP Message Types Workbench

Animate RFC 7252 CON, NON, ACK, RST, Message ID matching, tokens, piggybacked responses, and separate responses.

animation
coap
protocols
reliability
request-response
interactive
Interactive CoAP message types workbench for learning RFC 7252 CON, NON, ACK, RST, Message ID, Token, piggybacked responses, separate responses, duplicate detection, and compact header fields.
CoAP RFC 7252 Message Layer Request Matching

CoAP Message Types Workbench

Step through the four CoAP message types and watch how Message IDs handle message-layer reliability while Tokens match responses to requests. The key lesson is that ACK/RST are not the same thing as an application response.

Scenario Piggybacked CON GET
Active Type CON
MID Rule ACK uses same MID
Token Rule Response echoes token

Message Exchange

Use Play or Step to move packet by packet. The active packet also drives the header inspector below.

Reliable request
Endpoint Client
Step 1 of 2
Endpoint Server
CON asks the receiver to acknowledge the message.

The response is ready immediately, so the server can acknowledge the CON and carry the 2.05 Content response in the same ACK packet.

Current Packet Format

The first four bytes are always the compact CoAP header; token, options, marker, and payload follow only when present.

17 bytes
Version 1 2 bits, binary 01
Type CON (0) Confirmable
TKL 1 Token bytes
Code 0.01 GET Request method
Message ID 0xbc90 Duplicate and ACK matching
Header 4 bytes
Token 1 byte
Options 6 bytes
Payload 0 bytes
Message ID matches ACK/RST The ACK for a CON repeats the same 16-bit Message ID. Duplicate CON packets also reuse the same Message ID.
Token matches response to request The response echoes the request Token, even when a separate response uses a different Message ID.

Event Trace

Each trace entry states what changed and what the learner should notice.

Two layers share one packet

CON, NON, ACK, and RST belong to the message layer. GET, POST, 2.05 Content, and 4.04 Not Found belong to the request/response layer.

ACK is not success

An ACK confirms a confirmable message was received. Application success or failure is carried by the Code field, sometimes inside the ACK.

MID is not Token

Message ID finds duplicates and matches ACK/RST. Token connects the request with the response across one or more messages.

NON can still have a response

A NON request is not acknowledged at the message layer. If a response is sent, it uses a new message and the same Token.

CoAP Message Quick Reference

Use the cards as a compact lookup while reading packet traces or debugging constrained devices.

Message Types

Type Value Main use
CON 0 Reliable transfer
NON 1 Best effort transfer
ACK 2 Acknowledge CON
RST 3 Reset message state

Exchange Patterns

  • CON + ACK response: fastest reliable request when the server has the answer now.
  • CON + empty ACK + CON response: separate response when processing takes longer.
  • NON + NON response: lighter exchange with no message-layer ACK.
  • RST: message cannot be handled at this endpoint or context.

Header Fields

  • Ver is 1 for RFC 7252 CoAP.
  • T encodes CON, NON, ACK, or RST.
  • TKL is 0 to 8 token bytes.
  • Code is method, response, or 0.00 Empty.
  • MID is 16-bit duplicate and ACK/RST matching state.

Common Codes

Code Meaning
0.00 Empty message
0.01 GET
0.02 POST
2.04 Changed
2.05 Content
4.04 Not Found

Learning Support

These notes target common misconceptions that block students from reading CoAP traces independently.

Piggybacked Response

The ACK can carry the response code and payload when the answer is ready quickly. One packet both acknowledges the CON and answers the request.

Separate Response

The empty ACK stops client retransmission. The final response later uses a new Message ID and the original Token.

Duplicate Detection

If a CON is retransmitted with the same Message ID, the server should avoid repeating the side effect and can resend the cached response.

Reset Is Not 4.xx

RST is a message-layer signal. A 4.xx response is an application-layer response to a valid request context.

Technical Notes And Source Links

This workbench follows RFC 7252 message semantics. The byte sizing display is a teaching estimate for the visible packets and simple options; real datagrams also depend on exact option values, payload length, security layer, and lower-layer headers.

Technical accuracy check

CON reliability is message-layer reliability. A successful ACK does not prove the application operation succeeded unless a response code is piggybacked in that ACK.

Trace-reading check

When a separate response appears, compare both fields: the response Message ID is new, but the Token remains the one from the original request.

Next learning link

Pair this page with the CoAP congestion and block-wise workbenches to see retransmission timing, NSTART, and large payload behavior.