I’ve been spending a lot of time reading and responding to MQTT questions on Stackoverflow and I’m struck that the same basic misunderstandings keep coming up. I’m no expert on MQTT certainly (there’s a guy who posts under the handle hardlib who knows far more than me) but I do have experience in education–namely in breaking subjects down in a way that people without a broad knowledge base can understand–so I’m hoping that I can correct a few misconceptions with this post.
MQTT is a protocol, not a program
This seems to be the most fundamental misunderstanding. Many questions ask things like “how do I reply to MQTT messages” or “how can I edit MQTT messages on a server?” There are potentially meaningful answers to these questions but they all miss the fact that MQTT is simply a well defined and useful protocol. Upper-level considerations such as how an application responds to a message, how messages are retained on servers, and so on and so forth are all handled by the broker, publisher, and client–not by the MQTT specification itself. Therefore if you want to meaningfully ask a question about MQTT you must (generally) at least specify the broker you are using if not explain the entire ecosystem that you are building or using.
Indeed, if you have anything beyond a passing interest in MQTT you really should read the standard which is superbly written and quite clear.
MQTT is not an instant messaging platform
Unfortunately Facebook’s use of MQTT seems to have suggested to every developer that MQTT is a person-to-person messaging standard. But it isn’t! MQTT is a machine-to-machine standard. This is an important distinction because MQTT was never designed to supply the kinds of things a messaging platform requires (message history, the ability to retract messages etc.). Now, as Facebook proves, you can use MQTT as the underlying communications protocol for a messaging platform or application but you will have to program all of the additional facilities that you require that go beyond the standard and a few niceties added by specific brokers. So asking about how to build an instant messaging application with MQTT is a bit like asking how to build a website that uses HTTP: it is a meaningful, but absurdly broad question.
MQTT topics do not exist without content
Probably the most common misunderstanding I see in questions revolves around the idea that MQTT topics exist without content. It is an easy mistake to make given that MQTT hierarchies look a lot like file paths or other familiar things. But MQTT just doesn’t work like that. Topics in MQTT are not indicators of a place or anything like that, they are simply routing instructions that the broker uses to move payloads from publishers to subscribers.
Here is an example that might clarify this a bit. Say you have a directory called /spam/eggs/ in which there is a file called payload. The full path of that file would be /spam/eggs/payload. In this case the directory /spam and /spam/eggs literally exist on your hard drive. However in the case of MQTT the equivalent statement /spam/eggs/payload simply tells the broker to send the message to all subscribers subscribed to #, / #, /spam/#, /spam/eggs/#, or /spam/eggs/payload. There are a few others that I left out for brevity, but you get the point. This distinction may not seem important, but I’ve seen it at the root of many false understandings of how MQTT works.
MQTT topics should not start with a /
To make the point above, I intentionally made a subtle mistake. Did you catch it? Adding the / to the front of the topic created an entirely unnecessary topical level. This is more of a pet peeve than a real problem, but I see people doing this constantly. The addition of this first topic level is not only unnecessary but, if you aren’t aware of it, it can lead to real confusion.
I hope this has been of use, and I’m more than willing to answer any questions or make any corrections necessary to these points. But while I’m writing, do you have anything that drives you crazy about how people understand MQTT?