Skip to main content

Sessions

A session is the broker-side state for a Client ID.

Clean Session vs Clean Start​

  • MQTT 3.1.1 — Clean Session. 1 = no state kept; 0 = a persistent session (subscriptions, inflight QoS 1/2, and an offline queue survive disconnects and replay on reconnect).
  • MQTT 5 — Clean Start + Session Expiry are independent: Clean Start decides whether prior state is wiped at connect; the Session Expiry Interval decides how long the session persists after disconnect (0 = discard on disconnect). A client can Clean Start a fresh and persistent session.

Offline queue​

While a persistent client is disconnected, matching messages are queued in memory (bounded by limits.max_queue) and delivered in order on reconnect. Queuing accepts QoS 0/1/2, but only QoS 1/2 records are WAL-appended; QoS 0 and some metadata are not recovered after a restart.

Durability scope​

With storage on and sync = batch/always, an acknowledged QoS 1/2 publish is crash-durable, and — on a persistent session — an acknowledged subscription is flushed to the WAL before the SUBACK, so a crash cannot drop an acked subscription. QoS 0 messages and some MQTT 5 metadata (User Properties, the Retain-As-Published flag) are not recovered across a restart.

Keep-alive & will​

The broker closes a connection after 1.5× the negotiated keep-alive with no packet (a keep-alive of 0 disables the deadline), then publishes the client's will, if one was set on CONNECT. (Will properties are currently dropped.)