State
A named condition where a protocol waits for a legal event, such as "awaiting CONNACK" or "waiting for ACK".
Compare MQTT, CoAP, and AMQP state machine patterns, timers, errors, and implementation state
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.
A named condition where a protocol waits for a legal event, such as "awaiting CONNACK" or "waiting for ACK".
A packet, timer, API call, or link failure that asks the state machine to move or reject the request.
A guard checks whether a transition is allowed. An action sends a packet, starts a timer, records state, or closes safely.
Robust clients keep identifiers, timers, sessions, and in-flight exchanges so retries and recovery are not guesses.
MQTT has a connection/session state plus separate in-flight packet exchanges for QoS 1 and QoS 2.
| Protocol | State scope | Timer / reliability rule | Implementation state to keep |
|---|
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.
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.
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.