We're using MQTT extensively at Karma [1] as the communication protocol between our LTE devices and our backend services. It has worked really well for us, and we're super happy that we chose for MQTT in favour of our previous HTTP/JSON stack.
We're about to release a very detailed blog post about our MQTT setup on our blog [2], describing why and how we implemented our own MQTT server and how we hooked that up to our Ruby backend services and Redis. The post should be live somewhere this week.
MQTT is really nice for generic pubsub, but from what I've seen doesn't handle RPC-style transactions at all.
It is very hard to have something like this without requiring a whole bunch of ephemeral topics or lots of message id tracking on the client and server:
server> set this value to Z.
device> oops, in your previous command, Z is invalid.
Of course you can have an another service to handle this (HTTP API, CoAP, etc.,) but I think if MQTT added a command for something like this, then it would see a lot more adoption. It is nice to keep the broker in the middle of the communication to the devices even for RPC, simplifies a lot of things.
Another problem i keep running into, is that MQTT topics have no 'discoverability'. Each client must be hard coded to know exactly which topics to subscribe too, and know how to interpret the data on that topic.
It would be nice if an optional data model could be overlayed on top of MQTT, like BLE GATT does over ATT.
I would like to be able to things like:
(1) enumerate topics
(2) find topics of a specific type (which could be a UUID - something orthogonal to their physical tree structure)
(3) provide descriptors for topics with more metadata, etc.
I've found MQTT really useful in M2M/IoT situations, but I often found that I wanted to make use of existing HTTP based web solutions in combination with my MQTT networks.
As the first thing on my wishlist, I recently made a little python library [1] to aid people in pushing selected MQTT events to KeenIO[2]. It's mainly for development and testing, but I've found it pretty useful in my applications.
The protocol almost totally ignores security. They try to pass the buck downwards:
"As a transport protocol, MQTT is concerned only with message transmission and it is the implementer’s responsibility to provide appropriate security features. This is commonly achieved by using TLS."
and upwards:
"The Server MAY also use a security component to selectively authorize actions on the topic resource for a given Client."
This is a very weak security model. There's nothing like a distinction between "report body temperature" and "update pacemaker firmware".
MQTT defines a wire protocol (that includes transmitting user & client id). Most MQTT brokers have a granular authorisation model so the topics that request (or just publish) a body temperature reading would allow a different set of users to publish than the topics that would cause pacemaker firmware to be updated.
It would be nice if the protocol allowed extension points in the SUBSCRIBE action. Right now it's not possible to use dynamic authorization delegation using signatures.
This is a feature of a lot of open source MQTT brokers (Mosca, Mosquitto). We used Mosquitto for our app (http://www.clementine.io), and added dynamic auth for SUBSCRIBE and PUBLISH.
MQTT is not really machine-to-machine is it? Isn't it only machine-to-broker? Are there any uses of mqtt that operate in a more p2p decentralized setup?
I'm using MQTT on my current project that involves interactive applications running on solar powered devices.
I'm using RabbitMQ for the broker, it supports MQTT too, this means I can use MQTT on the clients and the services on the backend only needs to understand AMQP.
I made a simple RPC system on top of it, unfortunately it's a homegrown solution as I couldn't use RabbitMQ RPC features with MQTT.
MQTT is a protocol with public specification for lightweight client / message broker communications, allowing publish/subscribe exchanges. Multiple implementations of client libraries and brokers (Mosquitto, JoramMQ...) exists and are virtually compatible. MQTT just specifies the transport, and vaguely the application part (i.e. how data is handled and possibly stored, how clients are authorized...). The spec is not clear if data consumed on a topic is only real-time or possibly persisted. The spec doesn't state anything about how the message broker implementing MQTT could/should scale.
On the other hand, Apache Kafka is a message broker based on an internal "commit log": its focus is storing massive ammount of data on disk, and allow consumption in real-time or later (as long as data is still available on disk). It's designed to be deployable as cluster of multiple node, with good scalabily properties. Kafka uses its own network protocol.
So you are comparing two different things here: a standard pub/sub protocol (with multiple implementations), and a specific message storing/distributing software, vaguley of the same family with its own protocol.
I'd say that if you need to store massive amount of messages, to ensure batch processing, look more at Kafka. If you have lots of clients/apps exchanging messages in real-time on many indpendants topics look more at the MQTT (or even AMQP) message brokers implementations.
We're about to release a very detailed blog post about our MQTT setup on our blog [2], describing why and how we implemented our own MQTT server and how we hooked that up to our Ruby backend services and Redis. The post should be live somewhere this week.
1: https://yourkarma.com 2: https://blog.yourkarma.com/