Wednesday, April 11, 2018

MQTT Sucks (First Post)

So I saw that HackADay is having a chat about MQTT.

That seems as good as anything for an inaugural post on.

TL;DR: MQTT sucks.

The problem with the spec, as it is, is a simple one: there isn't enough spec there.

1. Authentication


With the spec basically having the equivalent of Basic Auth as your only option, every MQTT endpoint system ends up coming up with some idiot way to work around it. Sometimes it is an SSL key, sometimes it is a bearer token (put in either of the user/pass fields chosen at random). Unlike HTTP, MQTT is supposed to be about limited devices, but by leaving so much open to interpretation, you are basically burning firmware for a particular devices that is going to be nailed to a particular MQTT endpoint implementation.

2. Message Format


Much like authentication, the lack of any real delineation of message format in the spec means that everything does something different. If you want to use ThingsBoard, you need one channel hierarchy and message format for a device. If you want to use Google or Amazon's, you have to use their particular message format. Again, you are nailing your device to a particular endpoint implementation, or you end up having to do an MQTT -> MQTT transformation layer for anything that you want.

3. The Current Crop of Servers


As noted at the end of the last bit, unless you want to be nailed to one particular way of doing things, you end up having do build a proxy layer to adapt from one MQTT to another MQTT. Of course, though, none of the current endpoint implementations support doing this from within the server, so you have to cobble together something on your own, which is just ridiculous. Even Google and Amazon that already have powerful data pipeline tools don't let you accept a message and then transform it within their data pipeline tools; the message has to be perfectly formatted before they will receive it in the first damned place.

We really need a new spec, or at least a clarification of the original that deals with the following:

  1. Authentication. AuthN should really be done with encryption keys, but the protocol needs a way for a client to request provisioning access from an endpoint with a pre-existing key, rather than provisioning a key on an endpoint and having to put it onto a device. 
  2. We need a standard format for at least a channel specification. That specification should include the concept of "this" as a hierarchy param, an separate channels that imply sequenced data vs configuration or updates to static data. That is:
    • /clients/this/configuration <- {ipAddress="10.10.10.10" name="weatherstation1"}
    • /clients/this/sequence <- { "temperatureK"="300.15" }
    • Other standard channels could be defined, but it should be assume that each device should listen on /clients/this/configuration for provisioning and configuration updates.
    Then when someone wants to subscribe to events from "weatherStation1" they can subscribe to /clients/[provisioned synthetic id]/sequence.
  3. While MQTT as simple TCP and over websockets is already pretty standard, it makes no sense at all to me that IP Multicast isn't an option. Given the generally restrictive network environments lots of IoT type systems want to play in, it makes much more sense for a hub device on a given network environment to be able to grab messages out of "the air" and store and forward them onto a next leg network system.
MQTT isn't the only IoT protocol going on, but it is the one with the most traction right now. It is just too incompatible between environments to be REALLY useful. It wouldn't take much at all to get some standards around channel/message structure to solve most of these problems.

No comments:

Post a Comment