Protocol State Machine Fundamentals Workbench

Build and test the state, event, guard, action, timer, and context pattern behind IoT protocol behaviour

animation
networking
protocols
state-machines
mqtt
coap
amqp
implementation
Learner-ready protocol state machine fundamentals workbench showing how IoT protocol implementations move between states, accept or reject events, run guards, trigger actions, and keep timers and context.

Protocol State Machine Fundamentals Workbench

Protocol modelling State machines Implementation debugging

Protocol State Machine Fundamentals Workbench

State machines are not just diagrams. They are the rules an IoT client uses to decide which event is legal, which timer is running, what packet must be sent, and what context must be remembered before the next step.

MQTT connectionCurrent protocol lens
DisconnectedCurrent state
Application connectEvent under test
Guard readyTransition result

State

The remembered condition of the protocol endpoint right now. A client in the wrong state must reject some events.

Event

A packet, timer, API call, or link failure that asks the model to move. The same event can be valid in one state and invalid in another.

Guard and Action

The guard checks whether the transition is allowed. The action updates context, sends packets, starts timers, or reports an error.

Context

Real implementations keep IDs, retry counts, credit, timers, and pending acknowledgements. Without context, the diagram is incomplete.

Workbench Controls

Choose a protocol lens, run a guided event path, then test what happens when an invalid or timeout event arrives.

Protocol lens
Event path
Focus lens
Run the path
1. StateRead the current endpoint state.
2. EventA packet, timer, or API call arrives.
3. GuardCheck whether the event is legal now.
4. ActionSend, store, retry, settle, or report.
5. NextMove or stay with a clear reason.

MQTT client state model

A simplified teaching model for connection and one QoS 1 publish. MQTT QoS packet state is separate from the TCP connection lifecycle.

Ready Timer idle
Protocol state machine diagram Clickable states connected by event transitions. The active state and next transition update as controls are used.
Application connect Guard checks that transport is available, then sends CONNECT and starts the connect timer.
Disconnected Initial state
Accepted
Current event Application connect
Guard result Allowed because the client is disconnected and the transport can open.
Action Send CONNECT, start connect timeout, remember clean-start/session request.

Implementation Context

These values are the hidden state a robust client needs while packets and timers move.

Stored ID

Client IDUsed to bind the protocol session.

Timer

connectStarted for the current step.

Retry

0No retry has been consumed.

Action Log

    Quick Reference

    State machine parts

    • State: remembered condition right now.
    • Event: packet, timer, API call, or failure signal.
    • Guard: condition that must be true before moving.
    • Action: side effect such as send, store, retry, close.

    Protocol differences

    • MQTT has a long-lived connection and separate packet/QoS exchanges.
    • CoAP often has compact message exchanges rather than a permanent connection.
    • AMQP layers connection, session, link, and delivery state.

    Debugging checks

    • Which state did the client believe it was in?
    • Was the triggering event valid in that state?
    • Which timer or retry counter changed the next action?
    Technical Accuracy Notes

    Teaching model limits

    The diagram is simplified to teach the state-machine pattern. It is not a complete normative state diagram for every packet and error in the specifications.

    MQTT caution

    MQTT connection state, subscription state, session state, and QoS packet state should not be collapsed into one state variable in a real client.

    CoAP and AMQP caution

    CoAP Message ID handles duplicate detection while Token matches request and response. AMQP uses nested endpoints and settlement state, not one flat connection state.

    Guided Practice

    Beginner task

    Run the normal path. Say the current state, event, guard, action, and next state out loud before stepping.

    Debug task

    Switch to Timeout. Watch which timer fires and which context value changes. Explain why retry is an action, not a state by itself.

    Implementation task

    Use Try invalid from each protocol lens. Identify whether the client should ignore, reject, close, or surface the event to application code.

    Continue With The Focused Modules

    Use this fundamentals page first, then move into the more specific protocol state-machine pages.

    Reference

    Compare timers, errors, state variables, and implementation notes across protocols.

    Open reference workbench

    Primary Sources

    The model uses simplified teaching paths, with terminology cross-checked against the protocol specifications below.

    OASIS MQTT Version 5.0 RFC 7252: CoAP OASIS AMQP 1.0 Transport