Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MQTT – machine-to-machine connectivity protocol

mqtt.org

Post reply on HN
Print view View original

11–20 of 20 posts

Re: MQTT – machine-to-machine connectivity protocol

#11

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

Re: MQTT – machine-to-machine connectivity protocol

#14

Post by lyha »

k__ wrote: post #13

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.

Re: MQTT – machine-to-machine connectivity protocol

#15

Post by clumsysmurf »

kbaker wrote: post #9

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,…

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.

Re: MQTT – machine-to-machine connectivity protocol

#16

Post by 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.

Re: MQTT – machine-to-machine connectivity protocol

#17

Post by jonquark »

Animats wrote: post #11

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

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.

Re: MQTT – machine-to-machine connectivity protocol

#18

Post by mdaniel »

marceldegraaf wrote: post #7

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 ou…

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

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

Re: MQTT – machine-to-machine connectivity protocol

#19

Post by k__ »

lyha wrote: post #14
k__ wrote: post #13

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…

Thank you. Then Kafka seems the right choice :)
Post reply on HN