from Hacker News

MQTT – machine-to-machine connectivity protocol

by knowbody on 8/9/15, 8:08 AM with 19 comments

• by marceldegraaf on 8/9/15, 4:54 PM

  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/

• by kbaker on 8/9/15, 6:28 PM

  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.

• by bizzleDawg on 8/9/15, 2:41 PM

  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

• by Animats on 8/9/15, 6:55 PM

  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".

• by zimbatm on 8/9/15, 1:44 PM

  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.

• by clumsysmurf on 8/9/15, 5:25 PM

  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.

• by justinsaccount on 8/9/15, 7:01 PM

  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?

• by soupbowl on 8/9/15, 6:43 PM

  I can't wait for http://www.matrix.org to mature. But this looks interesting.

• by reefab on 8/9/15, 8:17 PM

  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.

• by IshKebab on 8/9/15, 4:21 PM

  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.

• by elisiariocouto on 8/10/15, 12:44 PM

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

  https://verne.mq

• by k__ on 8/9/15, 7:02 PM

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

• by platz on 8/9/15, 4:53 PM

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