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 »

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 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 »

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 Keep Alive & Client Take-Over Explained »

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: MQTT Last Will and Testament (LWT) Explained »