Every MQTT packet has a size — from a tiny 2-byte PINGREQ to a large PUBLISH carrying a firmware update. In MQTT 3.1.1, receivers had no way to tell senders what maximum packet size they could handle. A memory-constrained embedded gateway would just crash when a 10 MB PUBLISH arrived. A publisher had to guess: is this Server… Read More: MQTT 5 Maximum Packet Size Explained: Property 0x27 »

MQTT was designed for publish/subscribe — fire-and-forget messaging from many publishers to many subscribers. For two decades, that’s what MQTT did. If you wanted classic request/response (“send a query, get back exactly one answer for that query”), you had to use HTTP, AMQP, or roll your own correlation scheme on top of MQTT topics. MQTT 5 added native… Read More: MQTT 5 Correlation Data Explained: Request/Response Pattern »

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 »

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 »

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 »

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 »