

MQTT – machine-to-machine connectivity protocol - knowbody
http://mqtt.org/

======
marceldegraaf
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](https://yourkarma.com) 2:
[https://blog.yourkarma.com/](https://blog.yourkarma.com/)

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

[https://blog.yourkarma.com/engineering-for-
growth](https://blog.yourkarma.com/engineering-for-growth)

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

~~~
clumsysmurf
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.

------
bizzleDawg
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](https://github.com/ZoetropeLabs/keenmqtt)
[2]: [https://keen.io](https://keen.io)

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

~~~
jonquark
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.

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

~~~
samirez
This is a feature of a lot of open source MQTT brokers (Mosca, Mosquitto). We
used Mosquitto for our app
([http://www.clementine.io](http://www.clementine.io)), and added dynamic auth
for SUBSCRIBE and PUBLISH.

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

------
justinsaccount
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?

------
soupbowl
I can't wait for [http://www.matrix.org](http://www.matrix.org) to mature. But
this looks interesting.

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

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

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

[https://verne.mq](https://verne.mq)

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

~~~
lyha
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.

~~~
k__
Thank you. Then Kafka seems the right choice :)

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

