State
A remembered protocol condition, such as an open MQTT session or a CoAP request waiting for an ACK.
Protocol State Machine Simulation Workbench
Run event-by-event IoT protocol scenarios and test which transitions are valid
animation
networking
protocols
state-machines
simulation
mqtt
coap
amqp
Learner-ready protocol state machine simulation for MQTT, CoAP, and AMQP, with scenario playback, manual event triggering, guard feedback, transition history, and source-backed reference notes.
Animation
State machine
MQTT, CoAP, AMQP
Protocol State Machine Simulation Workbench
Run protocol events one at a time, then try your own events. The workbench shows whether the current state accepts the event, which guard fired, what action was taken, and how the protocol should recover from timeouts or invalid input.
3 protocols
Connection, message, and delivery state are separated.
12 scenarios
Normal, timeout, retry, reject, close, and error paths.
Manual guards
Try invalid events and see why they are blocked.
Source backed
Labels match MQTT 5.0, RFC 7252 CoAP, and AMQP 1.0 transport.
Event
A packet, timer, application action, or peer action that asks the state machine to move.
Guard
The rule that decides if the event is valid now, such as matching a Token or being inside an open connection.
Action
The side effect: send a frame, start a timer, store delivery state, retransmit, or close safely.
Protocol
MQTT
Current State
Initial
Valid Next Events
0
History
0 transitions
Live protocol state
State machine description appears here.
Ready
Client
Application, socket, timers, and stored protocol context.
Network
Loss, delay, duplicated messages, and peer close events become state events.
Peer
Broker, CoAP server, or AMQP peer validates the frame and responds.
Choose Run or Step, then try manual events to test the guards.
No event has fired yet.
Transition History
Use this like a debugging trace: read the previous state, event, guard result, new state, and side effect.
Quick Reference
MQTT
MQTT state begins with a network connection, then a CONNECT packet and CONNACK acceptance create the MQTT connection.
- CONNECT is the first MQTT packet sent by the client.
- CONNACK success opens the MQTT connection.
- Keep Alive is measured in seconds; PINGREQ/PINGRESP detects silence.
CoAP
CoAP combines a message layer with request/response matching. The Message ID and Token do different jobs.
- CON messages need ACK or RST at the message layer.
- Responses match requests by Token at the request/response layer.
- Default ACK_TIMEOUT is 2 seconds and MAX_RETRANSMIT is 4.
AMQP
AMQP 1.0 has nested state. A connection can be open while sessions, links, and deliveries have their own state.
- Peers exchange protocol headers before Open frames complete the connection.
- Begin opens a session; Attach opens a link.
- Transfers and dispositions handle delivery settlement.
Technical Accuracy Notes
Do not flatten state
MQTT connection state, CoAP message exchanges, and AMQP connection/session/link/delivery state are intentionally modeled separately. A real implementation stores more than one state variable.
Timers are guarded events
A timer expiry is not just a visual delay. It triggers a rule: retransmit, close, mark failed, or wait for a later response depending on protocol and current state.
Invalid events teach boundaries
Clicking a muted event records a blocked transition. This is useful because protocol bugs often come from accepting packets in the wrong state.
Self Check
Check 1
In MQTT, which event opens the MQTT connection: TCP open or CONNACK success?
Check 2
In CoAP, what should happen when a confirmable request times out but MAX_RETRANSMIT has not been reached?
Check 3
In AMQP, why is it misleading to call a delivery complete just because the TCP connection is open?
Primary Sources
These are the sources used for terminology, timers, and protocol state boundaries in this simulation.