MQTT Session State Manager

Inspect the broker-side session records that make MQTT reconnects reliable or risky.

Learner-ready MQTT session state manager with ClientID lookup, Clean Start and Clean Session comparison, Session Present diagnosis, expiry cleanup, duplicate ClientID takeover, queue pressure, and broker state feedback.

MQTT sessions Broker state ClientID Reliability

MQTT Session State Manager

An MQTT connection is the live network link. An MQTT session is the remembered state tied to a ClientID. Use this workbench to inspect what the broker keeps, discards, resumes, or cleans up when IoT devices disconnect and reconnect.

Current diagnosis Resume stored session safely

Session Present 1 - broker found state

Expiry status 24 h left

Broker pressure Low

First idea Connection and session are different.

The TCP or WebSocket connection can drop, while the MQTT session record may remain at the broker.

Lookup key ClientID is the shelf label.

To resume a session, the reconnecting device must use the same ClientID and compatible clean-session settings.

Stored state The broker remembers selected items.

Subscriptions and QoS 1/2 delivery state can survive. Retained messages are a separate topic-level feature.

Decision signal Session Present tells the client what happened.

If the CONNACK says no session was present, the client should rebuild subscriptions and local assumptions.

1. CONNECT arrivesRead protocol, ClientID, and clean flags.

2. Locate ClientIDFind an existing session record or create a new one.

3. Apply clean ruleResume, discard, or start fresh.

4. Restore stateSubscriptions and in-flight QoS state become active again.

5. Drain queueDeliver stored QoS 1/2 messages if policy allows.

6. Manage cleanupExpiry, takeover, and orphan pressure are evaluated.

Guided task

Trace a reconnect from the broker's point of view

Step through the sequence. Watch the session shelf, the CONNACK result, and the broker pressure signal change together.

Scenario presets

Try common broker decisions

Manual controls

Change the session request

Protocol model MQTT 5.0: Clean Start + Expiry MQTT 3.1.1: Clean Session

Reconnect request Resume or keep persistent state Start fresh; rebuild state

ClientID behavior Same stable ClientID Different ClientID New random ClientID every boot Duplicate of an active device

Session expiry or broker cleanup policy Delete immediately at disconnect Keep for 1 hour Keep for 6 hours Keep for 24 hours Keep for 72 hours Keep until administrative cleanup

Offline time: 6 h

connected4 days offline

Stored QoS 1/2 publishes: 4

nonebusy topic

Broker queue limit: 6

tightgenerous

Other orphaned session records: 1

clean registrymessy registry

Incoming CONNECT

MQTT 5.0 Clean Start 0 Stable ClientID

ClientID plant-room-meter-17

Requested lifetime 24 h session expiry

CONN

Stage 1 packet Broker receives CONNECT and reads session flags.

Broker session registry

State drawer

Broker can resume the stored session.

The ClientID matches, the request asks to resume, and the expiry window has not elapsed. The client can rely on Session Present and process queued QoS 1/2 messages.

CONNACK Session Present 1

Stored subscriptions 3 restored

Queued delivery 4 delivered

Messages lost or expired 0

Operational risk Low

MQTT 5.0 Clean Start and Session Expiry are separate.

Clean Start decides whether to begin with old state. Session Expiry decides how long state survives after disconnect.

MQTT 3.1.1 Clean Session combines start and persistence behavior.

Clean Session 1 starts clean. Clean Session 0 asks the broker to resume and store session state after disconnect.

ClientID Stable identifiers are required for useful persistence.

Random ClientIDs create new shelves at the broker, so old subscriptions and queues become unreachable orphans.

Session Present The client must read this CONNACK flag.

If it is 0, rebuild subscriptions. If it is 1, the broker accepted an existing session for that ClientID.

Technical notes and primary sources

Server session state Server state includes the existence of a session, subscriptions, and QoS 1/2 delivery state.

This workbench keeps retained messages separate because retained messages belong to topics, not to one client's session queue.

QoS 0 nuance Do not design reliable offline delivery around QoS 0.

MQTT 5 allows broker discretion in some storage behavior, but portable offline reliability should use subscriptions and QoS 1 or QoS 2.

Duplicate ClientID A second connection with the same ClientID takes over the network connection.

The broker closes the old connection. This can be useful for failover, but accidental duplication can kick active devices offline.

Broker limits Protocol persistence still needs operational limits.

Set expiry, queue limits, and cleanup policies so abandoned devices do not consume broker memory or disk forever.

OASIS MQTT 5.0 specification OASIS MQTT 3.1.1 specification

Practice prompts

Design check A battery sensor sleeps for eight hours.

Which settings let it receive QoS 1 command messages after reconnect without creating long-lived abandoned sessions?

Troubleshoot A dashboard no longer receives messages after reconnect.

Check Session Present first. If it is 0, the client must resubscribe instead of assuming the broker still has state.

Operations The broker has thousands of inactive sessions.

Look for random ClientIDs, missing expiry limits, and offline queues that outlive the business value of the messages.

Reliability A command must not be lost during a short outage.

Use stable ClientIDs, persistent sessions, QoS 1/2 publishing, and broker limits sized for the expected outage window.