MQTT Session Management Workbench

Trace how MQTT brokers keep or discard client session state across disconnects.

Learner-ready MQTT session management workbench with Clean Start, Clean Session, Session Expiry, ClientID, queued-message, QoS, message-expiry, and queue-limit feedback with desktop/mobile visual verification.

MQTT Session state Reconnects

MQTT Session Management Workbench

A connection is temporary, but a session can outlive that connection. Use this workbench to see when the broker keeps subscriptions and offline messages, when it returns Session Present, and why stable ClientIDs matter for sleepy or unreliable IoT devices.

Current case Sleepy meter resumes

Session Present 1 on reconnect

Offline delivery Queued QoS 1/2 messages drain

What is stored? Session state belongs to a ClientID.

The broker can remember subscriptions, queued QoS 1/2 messages, and in-flight QoS handshake state for a returning client.

Why it matters Sleepy devices miss commands while offline.

A persistent session lets a sensor sleep, reconnect with the same identity, and receive missed reliable messages.

Try first Press Step through the default case.

Watch the subscription stay on the broker, messages enter the queue, and Session Present become true on reconnect.

Common surprise Clean Start and Session Expiry are different in MQTT 5.

Clean Start controls whether a connect resumes old state. Session Expiry controls how long state survives after disconnect.

Guided controls

Run a reconnect case

Use the scenarios for common IoT patterns, then adjust one setting at a time.

Session settings

Reconnect identity and lifetime

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

Reconnect request Resume existing session Start clean and discard old state

Client identity Reconnect with same ClientID Reconnect with a different ClientID

MQTT 5 session expiry after disconnect 0 minutes: delete immediately 5 minutes 60 minutes 24 hours Never expire

Offline traffic

Messages published while the client sleeps

Publish QoS QoS 0 - at most once QoS 1 - at least once QoS 2 - exactly once handshake

Offline messages: 4

Offline duration: 12 min

1 min120 min

MQTT 5 message expiry No message expiry property 3 minutes 30 minutes 90 minutes

Broker queue limit: 6 messages

Interactive workbench

Broker session shelf

Step through the flow to see where the broker keeps state and where messages are lost.

IoT client

Connected ClientID sensor-17

Subscription filter building/+/cmd

Reconnect request Clean Start 0 / resume

Broker session state

Session stateStored for sensor-17

SP=1

Stored subscriptionbuilding/+/cmd

active

Offline queue preview

Command publisher

QoS 1 topic matches

Publish topic building/17/cmd

Offline payloads 4 control messages

Connect CONNECT + SUBSCRIBE

Session resumes and queued commands drain

The same ClientID reconnects without starting clean before the session expires, so the broker returns Session Present = 1 and delivers the stored QoS 1/2 messages.

Session Present 1

Reconnect resumes stored state.

Stored subscriptions 1

Subscriptions are session state, not retained messages.

Queued offline 4

QoS 1/2 messages can wait for the client.

Delivered 4

Delivered when the session resumes.

Lost or expired 0

No loss in this configuration.

Clean Start

In MQTT 5, Clean Start = 1 tells the broker to start a new session. Clean Start = 0 asks the broker to reuse an existing session if one is still present.

Session Expiry

In MQTT 5, Session Expiry controls how long state survives after disconnect. An interval of 0 deletes the session when the network connection closes.

MQTT 3.1.1

MQTT 3.1.1 combines the teaching idea into Clean Session: true starts fresh and discards state; false keeps a persistent session.

ClientID

Session state is keyed by ClientID. A rebooting device that generates a new ClientID cannot resume the old subscription or offline queue.

Broker stores

Subscriptions, queued QoS 1/2 messages for matching subscriptions, and in-flight QoS state can be part of the server-side session.

Broker does not solve

Sessions do not create history for topics without subscriptions, do not replace retained messages, and do not prove that an actuator completed an action.

QoS 0 nuance

MQTT 5 allows a server to store QoS 0 pending messages, but clients should not rely on that optional behavior. This workbench treats reliable offline delivery as QoS 1/2.

Broker policy

Real brokers impose queue limits, expiry rules, persistence storage limits, and administrative cleanup. Design for those limits explicitly.

Technical notes and primary sources

This model follows the MQTT distinction between connection lifetime, session state, Clean Start or Clean Session, ClientID, QoS, and expiry. It intentionally separates retained messages from session queues: a retained message is broker topic state; a queued offline message belongs to a client session.

• Use Session Present as a diagnostic signal: true means the broker is resuming a previous session for that ClientID.
• Use stable ClientIDs for devices that need offline delivery. Random ClientIDs are appropriate only for clients that do not need session continuity.
• Use QoS 1 or QoS 2 for messages that should survive a subscriber disconnect, then check broker limits and message expiry.

OASIS MQTT 5.0 specification OASIS MQTT 3.1.1 specification

Practice prompts for independent learners

Predict

Set MQTT 5, resume, same ClientID, 5 minute session expiry, and 20 minute offline duration. Before stepping, predict Session Present and delivery.

Compare

Switch only the publish QoS from 1 to 0. Explain why the broker cannot be relied on to drain those messages later.

Diagnose

Use the Wrong ClientID preset. Decide whether the old broker session is gone or simply unreachable by the new client identity.

Design

For a battery sensor that wakes every hour, choose a session expiry, message expiry, and QoS level that avoids stale commands.