Protocol State Machine Reference Workbench

Compare MQTT, CoAP, and AMQP state machine patterns, timers, errors, and implementation state

animation
networking
protocols
state-machines
mqtt
coap
amqp
implementation
Learner-ready protocol state machine reference workbench for comparing states, events, guards, actions, timers, retries, and recovery behavior in MQTT, CoAP, and AMQP.

Protocol State Machine Reference Workbench

Animation Protocol reference MQTT / CoAP / AMQP

Protocol State Machine Reference Workbench

Select a protocol, choose a failure lens, and step through the reference path. The workbench separates the visible state, the triggering event, the guard condition, the action, and the implementation state that must be retained.

MQTTSelected protocol
Connection + sessionState scope
Keep AliveMain timer
MediumImplementation complexity

State

A named condition where a protocol waits for a legal event, such as "awaiting CONNACK" or "waiting for ACK".

Event

A packet, timer, API call, or link failure that asks the state machine to move or reject the request.

Guard + Action

A guard checks whether a transition is allowed. An action sends a packet, starts a timer, records state, or closes safely.

Stored Context

Robust clients keep identifiers, timers, sessions, and in-flight exchanges so retries and recovery are not guesses.

Reference Controls

Use the protocol buttons first, then compare the normal path with timeout and invalid-event behavior.

Protocol
Failure lens

Guided Task

  1. Step through MQTT normal path and find where MQTT becomes usable.
  2. Switch to CoAP timeout and locate the retransmission counter.
  3. Switch to AMQP invalid event and notice why nested state matters.

MQTT connection and in-flight exchange reference

MQTT has a connection/session state plus separate in-flight packet exchanges for QoS 1 and QoS 2.

1 / 5 Current state

Transition Ledger

Protocol State scope Timer / reliability rule Implementation state to keep

MQTT Quick Reference

  • First MQTT packet on a network connection is CONNECT.
  • CONNACK success opens the MQTT session.
  • Keep Alive is maintained with traffic or PINGREQ/PINGRESP.
  • QoS 1 and QoS 2 keep in-flight packet state until their acknowledgments complete.

CoAP Quick Reference

  • CON messages are acknowledged or reset by matching Message ID.
  • Retransmission uses randomized timeout and binary exponential backoff.
  • NON messages are not acknowledged at the CoAP message layer.
  • Tokens correlate requests and responses; Message IDs support message matching and deduplication.

AMQP Quick Reference

  • AMQP 1.0 has nested connection, session, link, and delivery state.
  • Peers exchange headers and open frames before the connection is fully opened.
  • Sessions multiplex links; links carry delivery and settlement state.
  • Idle timeout is negotiated and enforced per connection endpoint.

Common Debug Pattern

  • Name the current state before naming the fault.
  • Identify the event that arrived or expired.
  • Check whether the transition is legal for this state.
  • Inspect persisted identifiers, timers, and in-flight records.

Protocol Comparison

MQTTBest mental model: a connected client session with in-flight publish/subscribe exchanges. It is simple at the connection level but needs careful in-flight tracking for QoS.
CoAPBest mental model: small per-message exchanges. Reliability is optional and message-oriented, so a client may have many compact message state machines.
AMQP 1.0Best mental model: nested transport machinery. Connection, session, link, and delivery state all matter, especially under errors and flow control.

Self Check 1

If an MQTT client is connected but waiting for PUBACK, is the whole client disconnected? No. The connection can be healthy while one in-flight QoS 1 exchange waits.

Self Check 2

If a CoAP CON retransmits, should the Message ID change? No. Retransmissions of the same CoAP message keep the same Message ID for matching and deduplication.

Self Check 3

If an AMQP link has an error, can the TCP connection still exist? Often yes. AMQP has nested state, so a link or session problem is not automatically the same as a closed connection.

Technical Accuracy Notes
  • MQTT state in this page is a teaching abstraction over MQTT control packet order and session behavior. The specification defines packets and operational behavior; it does not require a single client class named exactly like these cards.
  • CoAP default transmission parameters from RFC 7252 include ACK_TIMEOUT = 2 seconds, ACK_RANDOM_FACTOR = 1.5, and MAX_RETRANSMIT = 4. The simplified timer card shows the common teaching sequence, while real implementations randomize the initial timeout and must stay inside the transmit-span limits.
  • AMQP 1.0 explicitly specifies connection states and also defines session, link, and delivery state. A robust implementation should avoid flattening those into one global state variable.
  • Invalid-event handling differs by protocol and layer. Some inputs cause a protocol error and close; some are ignored; some are scoped to a per-message or per-delivery exchange.
Primary Source Links