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.
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.
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.
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.
[1]: https://github.com/ZoetropeLabs/keenmqtt [2]: https://keen.io
"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".
In the scenario the phone would go to sleep, incoming data on a socket should wake it up - then you could grab a wakelock and do some work.
However with the new Doze mode(s) this no longer seems to be the case. Now the only way to wake the phone up externally now is with GCM.
Its too early to know for sure (more previews of M will be released) but I'm curious how this end.
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.
Also the QoS parameter means different things depending on which server you use.
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.