State
A named condition where a protocol waits for a legal event, such as "awaiting CONNACK" or "waiting for ACK".
Protocol State Machine Reference Workbench
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
TryChoose CoAP, select Timeout / retry, and Step from the initial state through one retransmission.
ObserveHighlighted state, event, timer, and error response move together; Invalid event shows rejection without inventing a transition. Step confirms this readout.
ExplainA state machine accepts an event only when current state and guard permit its action, with timers supplying recovery events. Step exposes this mechanism.
Technical boundariesThe reference omits normative transitions, concurrent exchanges, transport detail, persistence, implementation races, and complete protocol versions.
Colour keyreference architectures identitycurrent / primaryreference / datasuccesscautionerror / failure
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.
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.