MQTT Protocol IoT Messaging Publish Subscribe QoS

Understanding MQTT protocol architecture, message flow, topic design, Quality of Service levels, retained messages, last will testament, and why MQTT dominates IoT communication.

The Publish-Subscribe Model

Why Not Request-Response?

In HTTP, a client must request data from a specific server. This creates tight coupling — the client must know the server's address, the server must be available when the client asks, and scaling requires the server to handle increasing load. For IoT with thousands of sensors and multiple consumers, this model breaks down.

MQTT uses publish-subscribe (pub-sub): producers publish messages to named topics without knowing who (if anyone) will receive them. Consumers subscribe to topics of interest and receive messages automatically when published. A central broker handles all routing.

Decoupling Benefits

MQTT Protocol Details

Connection Lifecycle

1. CONNECT — Client sends connection request with client ID, optional username/password, keepalive interval, and optional Will message
2. CONNACK — Broker acknowledges connection (success or failure code)
3. SUBSCRIBE — Client subscribes to topics of interest
4. PUBLISH/RECEIVE — Messages flow based on publications and subscriptions
5. PINGREQ/PINGRESP — Keepalive heartbeat when no messages flowing
6. DISCONNECT — Clean disconnection

Topic Structure

Topics are UTF-8 strings using forward-slash hierarchy:

Topic Wildcards

Subscribers can use wildcards:

• + (single level): building/+/room301/temperature matches floor1, floor2, floor3...
• # (multi-level): vehicle/truck42/# matches ALL topics under truck42
• Combined: building/+/+/temperature matches temperature in any room on any floor

Quality of Service (QoS) Levels

QoS 0: At Most Once (Fire and Forget)

• Fastest, lowest overhead (no ACK packets)
• Message may be lost if network drops during transmission
• Use for: Frequent sensor readings where losing one is harmless (next reading comes soon)

QoS 1: At Least Once

• Guaranteed delivery (retransmits until acknowledged)
• May deliver duplicates (if ACK is lost, sender retransmits)
• Use for: Important events where duplicates are acceptable (alerts, commands)

QoS 2: Exactly Once

• Guaranteed single delivery (no loss, no duplicates)
• Highest overhead (4 packets per message delivery)
• Use for: Financial transactions, billing events, critical one-time commands

QoS Comparison

Retained Messages

When a message is published with the retain flag set, the broker stores the last message on that topic. Any new subscriber immediately receives this retained message upon subscribing — they do not have to wait for the next publication.

Without retain: New dashboard connects → sees nothing until sensor publishes next reading (could be 30 seconds) With retain: New dashboard connects → immediately receives current temperature (retained from last publication)

This solves the "late joiner" problem and ensures the system state is always available to new subscribers.

Last Will and Testament (LWT)

When connecting, a client can register a "will" message with the broker. If the client disconnects unexpectedly (network failure, crash — NOT a clean DISCONNECT), the broker automatically publishes the will message on the client's behalf.

Typical LWT:

• Topic: device/sensor42/status
• Message: "offline"
• Retain: true

This enables automatic device health monitoring. The dashboard subscribes to status topics and immediately knows when any device goes offline, without polling.

MQTT vs Other IoT Protocols

MQTT in Practice

Popular Brokers

Real-World Deployments

• Facebook Messenger — Uses MQTT for mobile push notifications (billions of devices)
• AWS IoT — MQTT is the primary device communication protocol
• Home Assistant — Smart home platform uses MQTT for device integration
• Tesla vehicles — Report telemetry to cloud via MQTT
• Industrial SCADA — Sparkplug B specification standardizes MQTT for industrial use

Key Takeaways

1. MQTT's publish-subscribe model decouples message producers from consumers in space, time, and synchronization — ideal for dynamic IoT environments
2. The minimum 2-byte header makes MQTT extremely bandwidth-efficient compared to HTTP's 100+ byte headers — critical for constrained networks
3. Three QoS levels (0, 1, 2) provide explicit trade-offs between delivery guarantee and protocol overhead — choose per message type
4. Retained messages solve the late-joiner problem by immediately delivering current state to new subscribers without waiting for next publication
5. Last Will and Testament enables automatic offline detection — the broker publishes on behalf of crashed clients
6. MQTT runs over TCP, providing reliable byte-stream delivery that simplifies client implementation on constrained devices
7. MQTT dominates IoT messaging because it was purpose-designed for the constraints IoT devices face: limited bandwidth, unreliable connections, and battery power