MQTT Concepts
Conceptual overviews provide relatively high-level, general background information about key aspects of MQTT. Each section below pairs the official specification with the matching chapter of HiveMQ’s MQTT Essentials, a well-known, easy-to-follow explainer series, for readers who want the same idea explained a second way.
Topics and Wildcards
A topic is just a UTF-8 string of slash-separated levels, e.g. home/livingroom/temperature — MQTT does not require topics to be created or registered in advance; publishing to one simply brings it into existence. Subscribers can match more than one topic at a time with two wildcards: + matches exactly one level, and # (only legal as the last character) matches everything below that point.
How + and # subscription filters match against a topic tree.
Quality of Service (QoS)
MQTT offers three delivery guarantees, chosen per-message by the publisher and re-negotiated down to whatever the subscriber asked for. Higher QoS means a stronger guarantee but more round trips and more state to track on both ends.
The packet exchange behind each QoS level.
Sessions and Connections
Every client connects with a CONNECT packet carrying a client ID, optional credentials, a keep-alive interval, and a clean session flag. A clean session starts empty and is discarded on disconnect; a persistent session lets the broker remember the client’s subscriptions and queue QoS 1/2 messages while it is offline, so it can pick up where it left off on reconnect.
- Client, broker & server connection establishment — HiveMQ
- Persistent session and queuing messages — HiveMQ
- Keep alive & client take-over — HiveMQ
Retained Messages and Last Will
A retained message is the last known good value on a topic: the broker stores it and immediately delivers it to any new subscriber, so a client doesn’t have to wait for the next update to know the current state (useful for something like “is the light on”). A Last Will and Testament (LWT) is a message the client registers at connect time that the broker publishes on the client’s behalf if it disconnects ungracefully — the standard way to detect a crashed sensor or a dropped network link.