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
• Bound expiry and queue memory.
• Separate each quality-of-service leg from application outcome.
• Protect reconnect with TLS, identity, topic rules, and jitter.
Major section
In 60 Seconds · Start With A Sleeping Device · Key Concepts
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.
Major section
For Beginners: MQTT Session Management · The Power Nap Problem
A sleeping client may disconnect for ten minutes.
- With a persistent session, the broker may retain subscriptions and queue eligible QoS 1 or QoS 2 messages until the client reconnects, subject to session expiry, message expiry and queue limits.
Major section
Lab Setup · Try It: QoS Delivery Simulator
Hardware (Simulated):: Work through the two parts: the ESP32 sketch makes QoS 0 publish attempts with local skips, and the separate calculator illustrates QoS 0, 1 and 2 under modeled transfer disruptions.
- Subscriber delivery requires separate measurement.
- It deliberately skips about 20% of publish attempts at the application layer; that is not network packet loss or a subscriber delivery measurement.
Try it: Lab Setup · Try It: QoS Delivery Simulator in the chapter
Major section
Checkpoint: QoS Tradeoffs · Security Considerations
In the chapter's simulator, 20% independently missed MQTT-level transfers over 100 QoS 0 sends gives an expected 80 deliveries and 20 losses; ordinary TCP packet loss would usually be retransmitted.
- QoS 1 retries can yield duplicates if PUBACK is lost; delivery still depends on a working connection and retained session state.
Major section
Unencrypted MQTT: A Critical Security Risk · Public MQTT Brokers: Never for Production
Unencrypted MQTT transmits credentials and data in plain text--network sniffers can capture usernames, passwords, and all sensor readings.
- An attacker on your Wi-Fi network can see every temperature reading, door lock command, and camera feed.
- The cost is minimal compared to the security risk.
Major section
Checkpoint: Securing MQTT Sessions · Common Pitfalls
Port 1883 is plaintext; port 8883 adds TLS so credentials, topics, and payloads are not visible to ordinary network observers.
- Public test brokers are useful for learning only: no authentication, no private topic namespace, and no production control over who can read or publish traffic.
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 has no MQTT acknowledgment, QoS 1 transfers a message at least once and can duplicate it, and QoS 2 transfers it exactly once on that MQTT leg.
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.
- Neither makes the broker a buffer for publications the offline client has not sent.
Implement local message buffering on the publisher side.
Major section
Checkpoint: Persistent Session Hygiene · Pitfall: QoS Mismatch Between Publisher and Subscriber
Persistent sessions queue messages to offline subscribers; they do not store outbound publications for a sleeping publisher, so publishers still need local buffering.
- A stable client ID is part of the session contract.
- 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).
- After a broker restart or failover, synchronized client retries can overload recovery with CONNECT packets and queued message delivery.
Major section
Decision Framework: Clean vs Persistent Session Selection · Interactive Calculators
No session expiry configured (orphaned sessions consume memory forever).
- Assuming the broker grants the requested subscription QoS, the subscriber leg uses no more than the minimum of publication and granted subscription QoS.
- The delivery counts below are hypothetical outage outcomes, not predictions from TCP packet loss.
Try it: Decision Framework: Clean vs Persistent Session Selection · Interactive Calculators in the chapter
Major section
Label the Diagram · Code Challenge · 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.
Deck summary
Key takeaways
When it reconnects, it needs the right waiting messages, but an old event must not appear as a new opening.
- A sleeping client may disconnect for ten minutes.
- Hardware (Simulated):: Work through the two parts: the ESP32 sketch makes QoS 0 publish attempts with local skips, and the separate calculator illustrates QoS 0, 1 and 2 under modeled transfer disruptions.
- In the chapter's simulator, 20% independently missed MQTT-level transfers over 100 QoS 0 sends gives an expected 80 deliveries and 20 losses; ordinary TCP packet loss would usually be retransmitted.
- The mistake: MQTT QoS levels (0, 1, 2) are often misunderstood.
Retrieval practice
Recall check 1 of 5
Broker Bex says: answer from memory, then check your reasoning.
Q1This broker exposes a conventional plaintext MQTT listener on port 1883. Why would using that listener in production be 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 5
Broker Bex says: answer from memory, then check your reasoning.
Q2What is the purpose of topic-level access control (ACL) in MQTT?
Show answer
Answer: B Topic-level ACLs (Access Control Lists) restrict which clients can publish/subscribe to specific topics.
Q3A publisher uses QoS 2 but the subscriber is granted QoS 0; what is the subscriber-leg QoS?
Show answer
Answer: B The broker uses no more than the lower publication and granted subscription QoS.
Retrieval practice
Recall check 3 of 5
Broker Bex says: answer from memory, then check your reasoning.
Q4A broker has 1,000 offline subscribers, each with 50 queued messages of 140 bytes; about how much payload-plus-overhead memory is queued?
Show answer
Answer: C 1,000 × 50 × 140 gives the approximate queue bytes.
Retrieval practice
Recall check 4 of 5
Broker Bex says: answer from memory, then check your reasoning.
Q5A developer sets clean_session=false on a temperature sensor that publishes QoS 0 data every 30 seconds and never subscribes to any topics. What is the most significant problem with this configuration?
Show answer
Answer: C Persistent sessions can retain subscriptions, eligible queued messages and in-flight QoS 1/2 exchange state.
Retrieval practice
Recall check 5 of 5
Broker Bex says: answer from memory, then check your reasoning.
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.
- B · Topic-level ACLs (Access Control Lists) restrict which clients can publish/subscribe to specific topics.
- B · The broker uses no more than the lower publication and granted subscription QoS.
- C · 1,000 × 50 × 140 gives the approximate queue bytes.
- C · Persistent sessions can retain subscriptions, eligible queued messages and in-flight QoS 1/2 exchange state.
Print reference
Answers 2 of 2
Answer key.
- A · MQTT v5 uses SessionExpiryInterval (seconds) to control how long the broker retains session state after disconnect.