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 »
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 relies on long-lived TCP connections to push messages efficiently in both directions without polling. That design works well when connections behave the way TCP says they will, and breaks down badly when they do not. On mobile, cellular, and satellite links, a connection can quietly stop carrying data while still looking, to both sides, as if it… Read More »
MQTT is built to run over networks that are not reliable, so it has to assume that clients will sometimes vanish without warning. A client can drop because its battery died, its radio lost signal, its host crashed, or anything else that prevents it from sending a normal disconnect. The rest of the system needs a way to… Read More »
In MQTT, a publishing client has no guarantee that a subscribing client will actually receive its message, because pub/sub decouples them. The publisher’s only guarantee is that the message arrives at the broker; from there, delivery to subscribers depends on who is currently subscribed. Similarly, a client that has just connected and subscribed has no guarantee about when… Read More »
MQTT does not behave like a classical message queue, but under specific conditions it can queue messages for clients. That capability is one of the protocol’s most important reliability features for devices on unreliable networks, and it depends entirely on a concept called the persistent session. Understanding when a session is persistent, what the broker stores in it,… Read More »
Quality of Service, almost always written QoS, is the agreement between the sender of a message and its receiver about the guarantee of delivery for that specific message. It is one of MQTT’s defining features and the single biggest reason the protocol works well over networks that are slow, congested, or unreliable. Rather than forcing every application to… Read More »
Topics are how MQTT decides which client receives which message. Because MQTT uses topic-based filtering (sometimes called subject-based filtering), the topic attached to every message is the entire basis for routing: the broker matches published topics against the topic filters that clients have subscribed to, and delivers accordingly. One distinction is worth fixing in your mind from the… Read More »
Once a client has connected to a broker, almost everything it does comes down to three operations: publishing messages, subscribing to topics, and unsubscribing from them. Each operation has its own control packet, and most are confirmed by an acknowledgement packet from the broker. Understanding the fields these packets carry, and the acknowledgements they trigger, is what lets… Read More »
Every MQTT system is built from two kinds of participant: clients and a broker. A client is any device that speaks MQTT; the broker is the central hub that every message passes through. Before any messages can flow, a client must establish a connection to the broker, and that handshake, the CONNECT and CONNACK exchange, carries the settings… Read More »