Category Archives: MQTT

MQTT is a lightweight, publish/subscribe messaging protocol designed to move small amounts of data efficiently across networks where bandwidth is scarce, latency varies, and connections are unreliable. Invented in 1999 by Andy Stanford-Clark and Arlen Nipper for connecting remote sensors over satellite links, it has since become an OASIS and ISO/IEC standard and one of the most widely used protocols in the Internet of Things.
This category is a complete technical reference for the MQTT protocol. The articles explain how MQTT actually works rather than just what it does: the decoupled publish/subscribe model and the role of the broker, the binary packet format and its 15 control packet types, topic structure and wildcards, and the three Quality of Service levels that guarantee delivery over unreliable transports. They also cover the session and reliability mechanisms (persistent sessions, retained messages, Last Will and Testament, and keep alive) and the protocol’s security layers.
A dedicated set of articles covers MQTT 5, the current version, including user properties, session and message expiry, shared subscriptions, topic aliases, the request/response pattern, flow control, and enhanced authentication.

MQTT 5 Topic Aliases Explained: Per-Connection Bandwidth

A factory floor PLC publishes temperature data to the topic factory/site-A/line-3/station-5/conveyor-7/motor/temperature every 100 milliseconds. That’s a 65-byte topic name sent 10 times per second, every second of every day. Over 24 hours, the topic name alone consumes 56 megabytes of bandwidth — not the payload, just the topic string. Multiply by hundreds of similar sensors and you have… Read More: MQTT 5 Topic Aliases Explained: Per-Connection Bandwidth »

MQTT 5 Flow Control Explained: Receive Maximum

In MQTT 3.1.1, the question “how many QoS 1 messages can I have in flight at once?” had no clear answer. The spec didn’t say. Implementations varied — some Servers accepted thousands of pipelined PUBLISH packets; others would only process one in-flight message per client. Clients that wanted predictable behavior had to assume the worst (one in-flight message… Read More: MQTT 5 Flow Control Explained: Receive Maximum »

MQTT 5 Negative Acknowledgements: Reason Codes Explained

For two decades MQTT 3.1.1 gave you one of two answers to every operation: it worked, or it didn’t. When a PUBLISH failed, you got nothing actionable back — just silence or a disconnect. When a SUBSCRIBE half-failed (one topic accepted, one rejected), you couldn’t tell which was which. When the Server kicked you off the network, you… Read More: MQTT 5 Negative Acknowledgements: Reason Codes Explained »

Enhanced Authentication in MQTT 5 Explained

For two decades, MQTT clients authenticated to the Server the same way: send a username, send a password, hope the Server accepts. That worked for the IoT prototypes of the 2000s. It does not work for modern industrial systems where credentials rotate, identities federate, and a plain-text password traveling over the wire is a security incident waiting to… Read More: Enhanced Authentication in MQTT 5 Explained »

MQTT 5 vs MQTT 3.1.1: Differences, Features & Migration

If you have used MQTT 3.1.1 for a few years and are wondering what MQTT 5 actually changes, or if you are starting a new deployment and need to decide between the two, this is the article that gets you there directly. The two versions share the same core protocol — publish/subscribe over TCP, three QoS levels, retained… Read More: MQTT 5 vs MQTT 3.1.1: Differences, Features & Migration »

MQTT 5 User Properties Explained: Custom Metadata

If you have ever built a system on MQTT 3.1.1 and ended up encoding metadata into topic names or stuffing JSON envelopes inside payloads to carry information about the message, you have already felt the gap that user properties fill. MQTT 3.1.1 had no place for application-defined metadata in a message; the protocol’s headers were rigidly defined, and… Read More: MQTT 5 User Properties Explained: Custom Metadata »

MQTT 5 Reason Codes, Reason Strings, and Negative Acknowledgements

If you have ever debugged an MQTT 3.1.1 deployment where a client mysteriously refuses to connect, or where a publish silently fails to reach its subscribers, you have run into MQTT 3.1.1’s biggest weakness: it tells you almost nothing about what went wrong. The handful of CONNACK return codes are vague, most other packets carry no failure indicator… Read More: MQTT 5 Reason Codes, Reason Strings, and Negative Acknowledgements »

MQTT 5 Session & Message Expiry Intervals Explained

Two of the most practical additions in MQTT 5 are about time: how long the broker should hold on to a client’s session, and how long it should hold on to an individual message. In MQTT 3.1.1, neither was a protocol concern. A persistent session lived indefinitely on the broker until something explicitly wiped it, and a queued… Read More: MQTT 5 Session & Message Expiry Intervals Explained »

What’s New in MQTT 5? Features, Changes & Why Upgrade

MQTT 5 is the current version of the protocol. It was ratified as an OASIS standard on 7 March 2019, succeeding MQTT 3.1.1, which had been the standard since 2014. MQTT 5 is not a rewrite. It is an evolution of MQTT 3.1.1 that keeps the core (publish/subscribe, topics, QoS, sessions, retained messages, LWT, keep alive) and adds… Read More: What’s New in MQTT 5? Features, Changes & Why Upgrade »

MQTT Over WebSockets Explained: Browsers, Ports, TLS

MQTT runs on top of TCP. That works well almost everywhere it is deployed: on embedded devices, gateways, servers, and desktop tools. There is one environment, though, where it does not work directly: the browser. A web page cannot open a raw TCP connection, which means a JavaScript MQTT client cannot connect to a broker over plain MQTT… Read More: MQTT Over WebSockets Explained: Browsers, Ports, TLS »