MQTT – machine-to-machine connectivity protocol | Hacker News Reader

MQTT – machine-to-machine connectivity protocol

mqtt.org

65 pointsknowbody19 comments

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.

1: https://yourkarma.com 2: https://blog.yourkarma.com/

To save you the trouble of searching for it, this is the more relevant link:

https://blog.yourkarma.com/engineering-for-growth

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.

[1]: https://github.com/ZoetropeLabs/keenmqtt [2]: https://keen.io

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 works OK on Android via Paho library, but it seems that changes to upcoming "Android M" will reduce its usefulness.

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.

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 can't wait for http://www.matrix.org to mature. But this looks interesting.

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.

It's ok (I use it a bit at work), but from reading the specs it seems like AllJoyn is much more powerful (though I haven't used AllJoyn).

Also the QoS parameter means different things depending on which server you use.

Keep an eye on this MQTT broker. It supports clustering, for me the "selling point".

https://verne.mq

Someone told me to use Apache Kafka instead, because it scales better. What do you think?

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.

Thank you. Then Kafka seems the right choice :)

I wonder how hard it is to just use AMQP in these scenarios

Reply on news.ycombinator.com