MQTT was born as a publish/subscribe protocol — messages flow from many publishers to many subscribers with no expectation of a response. This model fits telemetry perfectly: sensors publish, dashboards subscribe, nobody waits for anyone. But when you need one client to ask another client a specific question and get one specific answer back, pub/sub alone falls short.… Read More: MQTT 5 Request Response Pattern Explained: RPC Over MQTT »
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 »
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 »
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 »
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 »