MQTT · Study deck

MQTT Packet and Broker Features

Picture a building sensor that publishes an alarm just before its receiver disconnects.

Broker Bex is your guide for this deck.

fund

Broker Bex, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Analyze MQTT Packet Structure: Decode binary MQTT packets field by field and calculate exact byte overhead for given topic lengths and QoS levels
Design Topic Hierarchies: Construct scalable, maintainable topic naming conventions that support wildcard queries for large device fleets
Calculate Bandwidth Savings: Apply optimization techniques — short topic names, binary payloads, topic aliases — and quantify savings across a device fleet
Implement MQTT 5.0 Features: Configure message expiry, topic aliases, and shared subscriptions in code and explain when each feature is appropriate

• Read packet fields.
• Design a narrow topic filter.
• Calculate topic-name and alias byte costs.
• Explain expiry, retained values, and session queues after reconnect.

Major section

In 60 Seconds

After reconnection, a new message, an old retained value, and a queued delivery can look alike unless each carries clear identity and time.

Bandwidth means how much data a path can carry in a given time.
A broker is the service that routes messages by topic.
Telemetry means measurements and status sent from a remote device for review.

Major section

In 60 Seconds (continued)

MQTT means Message Queuing Telemetry Transport.

Quality of service means the selected delivery level.
QoS is its short name.
This runway does not prove fleet capacity or exactly-once physical action.
The deeper sections cover packet fields, topic cost, retained values, sessions, delivery choices, service sizing, and failure tests.

Major section

Key Concepts

Topic Hierarchy Design: Best practice: device-type/device-id/measurement enables fine-grained subscription filtering.

Topic Level: Segment between / separators — each level represents a dimension of the topic hierarchy.
Single-Level Wildcard (+): Matches exactly one topic level: sensors/+/temperature matches sensors/room1/temperature.
Multi-Level Wildcard (#): Matches remaining levels: sensors/# matches all topics starting with sensors/.

Major section

MQTT's Secret Features

A retained publication gives a new subscriber the broker's most recent value for that topic.

It may be stale, so include a timestamp or other freshness evidence.
A Last Will message lets the broker publish an offline status after an unexpected disconnect.
A persistent session can retain subscriptions and queue eligible QoS 1 or QoS 2 messages while a client is offline.

Major section

Designing Topic Hierarchy for Smart Building

Each floor has 20 rooms with temperature sensors, occupancy detectors, and smart lighting.

Access patterns: The dashboard shows all temperatures while HVAC controls one floor.
The first three levels locate the source, the device-type level separates families such as sensors and lights, and the final level states what is measured or commanded.

Smart building MQTT topic hierarchy showing building, floor, room, device type, and measurement topic levels with example wildcard subscriptions.

Major section

MQTT 5.0 Features

MQTT 5.0 adds per-message controls so the same names can expire stale data, shrink repeated topics, and distribute subscriber work.

After a topic alias is established, a later publish can omit a 30-byte topic name.
Both packets retain the 2-byte topic-length field; the later packet has a zero-length name and a 3-byte Topic Alias property (1-byte identifier plus 2-byte value).
Establishing the alias costs 3 extra bytes once.

Major section

Concept Relationships

EMQX: Distributed clustering; its published 10M+ connection result is a cluster benchmark, not a per-node guarantee.

Edge gateway design includes topic bridging.
MQTT control packets have a fixed header of at least two bytes; a variable header and payload appear where the packet type calls for them.
Design topic hierarchies that support precise wildcard filters.

Major section

Deep-Dive Note: Packet Evidence and Retained State

Advanced MQTT features are easiest to debug when packet evidence and broker state stores are kept separate.

The fixed header's first byte identifies the control packet, and for PUBLISH the low nibble carries DUP, the two QoS bits, and RETAIN.

Retained messages are broker-side topic state: the publisher marks one PUBLISH as retained, the broker stores it as the current value for that topic, and a later subscriber receives it immediately.

Major section

Deep-Dive Note: Packet Evidence and Retained State (continued)

A quiet client can prove it is alive with 0xC0 0x00 (PINGREQ, zero remaining bytes), while a retained QoS 1 publish might start with 0x33: packet type 3, DUP=0, QoS=01, and RETAIN=1.

A useful packet note records the raw first byte, decoded flags, Remaining Length bytes, topic length, topic string, packet identifier when QoS is above 0, and payload length.
Topic-name shortening and MQTT 5 topic aliases save bytes in the variable header, but they do not change QoS, retain, or session behavior.
That evidence prevents two common misdiagnoses.

Deck summary

Key takeaways

After reconnection, a new message, an old retained value, and a queued delivery can look alike unless each carries clear identity and time.

MQTT means Message Queuing Telemetry Transport.
Topic Hierarchy Design: Best practice: device-type/device-id/measurement enables fine-grained subscription filtering.
A retained publication gives a new subscriber the broker's most recent value for that topic.
Each floor has 20 rooms with temperature sensors, occupancy detectors, and smart lighting.

Retrieval practice

Recall check 1 of 3

Broker Bex says: answer from memory, then check your reasoning.

Q1You're designing an MQTT topic structure for a fleet of 500 delivery trucks. Each truck has GPS, fuel level, and engine temperature sensors. The service needs one subscription for all data from a truck and another for GPS across the fleet. Which topic hierarchy is most appropriate?

Afleet/truck-001/gps, fleet/truck-001/fuel, fleet/truck-001/temp.

Bgps/truck-001, fuel/truck-001, splitting one truck across roots.

Ctruck-001-gps, truck-001-fuel, flattening the device hierarchy.

Dfleet/sensors/truck-001/gps, putting all sensor data in one payload.

Show answer

Answer: A This hierarchical structure enables: (1) individual truck queries with fleet/truck-001/#, (2) all GPS data with fleet/+/gps, (3) all data with fleet/#.

Retrieval practice

Recall check 2 of 3

Broker Bex says: answer from memory, then check your reasoning.

Q2An IoT sensor publishes temperature readings every 10 seconds over a cellular link with a 42-byte topic name. After upgrading to MQTT 5.0, the developer enables topic aliases. How much bandwidth is saved per message after the alias is established, and which other MQTT 5.0 feature could NOT be replaced by a topic alias?

A39 bytes saved: 42-byte topic minus 3-byte alias; not shared subscriptions.

B42 bytes saved: omit the topic entirely; not message expiry.

C44 bytes saved: count topic length twice; not retained messages.

DNo bytes saved: assume aliases affect only broker CPU, not wire data.

Show answer

Answer: A Both packets carry the 2-byte topic-length field; the later PUBLISH omits the 42-byte name and adds a 3-byte Topic Alias property, saving (2 + 42) - (2 + 0 + 3) = 39 bytes.

Retrieval practice

Recall check 3 of 3

Broker Bex says: answer from memory, then check your reasoning.

Q33a: Broker stateWhat does an MQTT client register at connection time so the broker can publish its state after an ungraceful loss?

AMQTT Broker (Session + Retained Store)

BNew subscriber (gets retained msg)

CDevice with LWT configured

DPublisher with retain=True

Show answer

Answer: C The client registers its will topic and payload during connection before an ungraceful loss can occur.

Q43b: Offline will registrationComplete the MQTT publisher with retained messages and Last Will and Testament:

Aclient.will_set('gateways/gateway_01/status', 'offline', qos=1, retain=True)

Bclient.set_will('gateways/gateway_01/status', 'offline', qos=1)

Cclient.lwt('gateways/gateway_01/status', 'offline', retain=True)

Dclient.will_message('gateways/gateway_01/status', 'offline')

Show answer

Answer: A will_set() pre-registers a message the broker publishes if this client disconnects unexpectedly.

Print reference

Answers

Answer key.

A · This hierarchical structure enables: (1) individual truck queries with fleet/truck-001/#, (2) all GPS data with fleet/+/gps, (3) all data with fleet/#.
A · Both packets carry the 2-byte topic-length field; the later PUBLISH omits the 42-byte name and adds a 3-byte Topic Alias property, saving (2 + 42) - (2 + 0 + 3) = 39 bytes.
C · The client registers its will topic and payload during connection before an ungraceful loss can occur.
A · will_set() pre-registers a message the broker publishes if this client disconnects unexpectedly.