MQTT · Study deck
MQTT Session Management
Picture a delivery box that sleeps between door events.
Broker Bex is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Configure Session Persistence: Select and configure clean versus persistent sessions for specific device types and use cases
- Implement Secure MQTT: Apply TLS encryption, certificate-based authentication, and topic-level ACLs for production deployments
- Distinguish Session Behaviors: Compare clean session and persistent session behaviors and justify the choice for a given scenario
- Design Reconnection Strategies: Construct exponential backoff with jitter to prevent thundering-herd reconnection storms
Major section
In 60 Seconds
When it reconnects, it needs the right waiting messages, but an old event must not appear as a new opening.
- Telemetry means readings and status sent by a remote device.
- Message Queuing Telemetry Transport (MQTT) means a lightweight way for devices to exchange messages.
- A broker means the service that passes messages from senders to receivers.
Major section
In 60 Seconds (continued)
Quality of service means the delivery promise chosen for a message; it is called QoS.
- Latency means the delay between an action and its result.
- Transport layer security means protection for a network stream; it is called TLS.
- The box and receiver must agree on one final state.
Major section
In 60 Seconds (continued)
This runway does not guarantee the physical door result or long-term storage.
- MQTT session management determines whether the broker remembers a client's subscriptions and queues messages during disconnection.
- A persistent session (clean_session=false) preserves subscriptions and buffers QoS 1/2 messages for offline clients, while a clean session starts fresh on every connection.
- Misconfiguring sessions is a top production pitfall, causing either unbounded queue growth or silent message loss.
Major section
Start With A Sleeping Device · Key Concepts
While it sleeps, the broker must decide whether to forget it, queue messages for it, expire its old session, or reject a duplicate client ID.
- Session management is the story of what MQTT remembers while clients disappear and return.
Major section
For Beginners: MQTT Session Management · The Power Nap Problem
"I sleep for 10 minutes at a time to save energy," said the battery. "But when I wake up, have I missed important messages?".
- Any messages sent while you slept are gone.".
Major section
Putting Numbers to It: Persistent Session Queue Memory Growth · Interactive Lab: MQTT QoS Comparison
(Units throughout this example use the decimal/SI convention established above: 1 kB = 1,000 bytes, 1 MB = 1,000,000 bytes, 1 GB = 1,000,000,000 bytes.).
- Broker queue limit (MQTT 5.0 message expiry):: Set message_expiry_interval = 3600 (1 hour) to drop messages older than 1 hour: $$ M_{\text{queue\_max}} = 60 \times 140 = 8.4\text{ KB per sensor (capped)} $$.
Try it: Putting Numbers to It: Persistent Session Queue Memory Growth · Interactive Lab: MQTT QoS Comparison in the chapter
Major section
Try It: QoS Delivery Simulator · Checkpoint: QoS Tradeoffs
QoS 0: ~80/100 delivered (80%), 0 duplicates, about 1,000 ms, baseline battery use (100%).
- QoS 1: 100/100 delivered (100%), about 4-6 duplicates, about 1,500 ms, about 150% battery use.
- QoS 2: 100/100 delivered (100%), 0 duplicates, about 2,500 ms, about 250% battery use.
Major section
Security Considerations · Unencrypted MQTT: A Critical Security Risk
The QoS lab answers "will the message arrive?" The production question is different: "who can read, publish, or replay it while it travels?".
- Unencrypted MQTT transmits credentials and data in plain text--network sniffers can capture usernames, passwords, and all sensor readings.
Major section
Common Pitfall: Misunderstanding MQTT QoS Levels · Try It: QoS Level Selection Advisor
The mistake: MQTT QoS levels (0, 1, 2) are often misunderstood.
- QoS 0 offers no delivery guarantee, QoS 1 guarantees at-least-once delivery (may duplicate), and QoS 2 guarantees exactly-once delivery.
- Diagnose the problem from cause to corrective action.
Major section
Pitfall: Expecting Clean Session to Queue Messages for Publishers · Pitfall: Using Random Client IDs with Persistent Sessions
The Mistake: Developers configure clean_session=false on publishing devices (sensors), expecting the broker to buffer their outbound messages when the network is down.
- Developers assume that if subscribers get queued messages, publishers should too.
- For ESP32, use the MAC address or chip ID.
Major section
Checkpoint: Persistent Session Hygiene · Pitfall: QoS Mismatch Between Publisher and Subscriber
Finish with Expiry is not optional at fleet scale: MQTT 5 Session Expiry Interval or Mosquitto persistent_client_expiration 7d bounds how long unused state can consume memory.
- They're confused when messages are duplicated or lost at the subscriber despite using QoS 2 for publishing.
Major section
Pitfall: Session Expiry Flooding on Broker Restart · Try It: Exponential Backoff with Jitter Visualizer
The Mistake: Developers deploy hundreds of IoT devices with persistent sessions (clean_session=false) and long keep-alive intervals (300+ seconds).
- When the broker restarts or fails over, all devices attempt to reconnect simultaneously, overwhelming the broker with CONNECT packets and queued message delivery.
Major section
Deep-Dive Note: Session State Boundaries
A persistent session is a broker-side state budget, not a general reliability switch.
- The useful state is specific: subscriptions, queued QoS 1 or QoS 2 messages for an offline subscriber, and in-flight QoS acknowledgement exchanges that have not finished.
- QoS 1 is PUBLISH -> PUBACK, so a lost PUBACK can create a duplicate.
Major section
Deep-Dive Note: Session State Boundaries (continued)
MQTT 3.1.1's clean_session=false combines "start fresh" and "keep the session" into one flag.
- MQTT 5 separates those choices with Clean Start plus Session Expiry Interval, so a client can resume existing state but still give the broker a retention budget.
- QoS 2 is PUBLISH -> PUBREC -> PUBREL -> PUBCOMP, so the broker and client need packet-id state to resume the exchange exactly once after a reconnect.
- A clean session discards that in-flight state; a persistent session can preserve it if the broker's expiry and queue limits have not removed the session.
Deck summary
Key takeaways
When it reconnects, it needs the right waiting messages, but an old event must not appear as a new opening.
- Quality of service means the delivery promise chosen for a message; it is called QoS.
- This runway does not guarantee the physical door result or long-term storage.
- While it sleeps, the broker must decide whether to forget it, queue messages for it, expire its old session, or reject a duplicate client ID.
- "I sleep for 10 minutes at a time to save energy," said the battery. "But when I wake up, have I missed important messages?".
Retrieval practice
Recall check 1 of 4
Broker Bex says: answer from memory, then check your reasoning.
Q1Why is using port 1883 for MQTT in production environments a security risk?
Show answer
Answer: C Port 1883 transmits data in plain text without encryption, making it vulnerable to eavesdropping and man-in-the-middle attacks.
Retrieval practice
Recall check 2 of 4
Broker Bex says: answer from memory, then check your reasoning.
Q2A smart home system uses a public MQTT broker (test.mosquitto.org) for controlling door locks. What are the main security concerns?
Show answer
Answer: D see answers page
Q3What security measures should be implemented for a production MQTT system controlling critical infrastructure?
Show answer
Answer: D
Retrieval practice
Recall check 3 of 4
Broker Bex says: answer from memory, then check your reasoning.
Q4A fleet of 500 delivery vehicles uses MQTT to receive route updates from a dispatch server. Vehicles frequently enter tunnels where they lose connectivity for 5–15 minutes. Which session configuration is most appropriate?
Show answer
Answer: B Command receivers that experience intermittent connectivity (vehicles in tunnels, sensors in basements, mobile devices) need persistent sessions (clean_session=false) combined with QoS 1 or 2 to ensure messages are queued during disconnection and delivered on reconnection.
Retrieval practice
Recall check 4 of 4
Broker Bex says: answer from memory, then check your reasoning.
Q5Place each persistent-session event where it lives so you can diagnose whether a reconnect resumes stored subscriptions and queued messages or silently starts a new session.
Show answer
Answer: A Place each persistent-session event where it lives so you can diagnose whether a reconnect resumes stored subscriptions and queued messages or silently starts a new session.
Q6Complete the MQTT v5 client with session expiry and message expiry interval:
Show answer
Answer: A MQTT v5 uses SessionExpiryInterval (seconds) to control how long the broker retains session state after disconnect.
Print reference
Answers 1 of 2
Answer key.
- C · Port 1883 transmits data in plain text without encryption, making it vulnerable to eavesdropping and man-in-the-middle attacks.
- D · Major security risks: 1) Anyone worldwide can subscribe to your topics and see your lock commands, 2) No authentication means anyone can publish commands to unlock your door, 3) Shared infrastructure with unknown users, 4) No data encryption, 5) No topic-level access control.
- D
Print reference
Answers 2 of 2
Answer key.
- B · Command receivers that experience intermittent connectivity (vehicles in tunnels, sensors in basements, mobile devices) need persistent sessions (clean_session=false) combined with QoS 1 or 2 to ensure messages are queued during disconnection and delivered on reconnection.
- A · Place each persistent-session event where it lives so you can diagnose whether a reconnect resumes stored subscriptions and queued messages or silently starts a new session.
- A · MQTT v5 uses SessionExpiryInterval (seconds) to control how long the broker retains session state after disconnect.