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

MQTT turns 25

andypiper.co.uk

Post reply on HN
Print view View original

11–20 of 76 posts

Re: MQTT turns 25

#11

Post by exe34 »

ericvsmith wrote: post #10
baruchthescribe wrote: post #8

Reposting my comment from five years ago: I once had a client where the only port available for me to use on their firewalls was for MQTT (1883) because that's how we were getting sensor data from them. They would not open anything else for us no matter how we implored them so I wrote a live TCP wrapper over MQTT to get around it. It was a local multithreaded TCP daemon that listened for outbound requests on a certai…

I’ve worked at places where subverting firewall rules like this would get you fired. I now refer to such situations where I’m forced to twiddle my thumbs while no work gets done as “letting the process work”.

I always kick this kind of decision upwards: we can do it this way and break this rule, so I need director level approval, or we can wait until the customer blinks.

Re: MQTT turns 25

#13

Post by Risse »

roland35 wrote: post #4
Uptrenda wrote: post #2

The cool thing about MQTT is there's so many servers for it that are completely public -- and intentionally so. You can use it for real time messages but I think it also has quality modes that allow for some persistence. Some of these servers have stat pages that show how much data they transfer. Usually phenomenal amounts of data. It's pleasing to me as someone doing a lot of stuff with open source networking to hav…

Have any examples of public servers?

Helsinki Regional Transport (HSL) has a public server with realtime position of all of their vehicles (buses, trains).

https://digitransit.fi/en/developers/apis/4-realtime-api/veh...

Re: MQTT turns 25

#14

Post by n_plus_1_acc »

exe34 wrote: post #11
ericvsmith wrote: post #10

Earlier quoted context omitted.

I’ve worked at places where subverting firewall rules like this would get you fired. I now refer to such situations where I’m forced to twiddle my thumbs while no work gets done as “letting the process work”.

I always kick this kind of decision upwards: we can do it this way and break this rule, so I need director level approval, or we can wait until the customer blinks.

Yes. Ask your boss for approval and tell them otherwise nothing will get done.

Re: MQTT turns 25

#15

Post by formerly_proven »

miljen wrote: post #12

Fun fact: at the same time, the most famous C++ library, Boost, is reviewing the `async-mqtt5` implementation ( https://github.com/mireo/async-mqtt5 ) to be included in Boost as Boost.MQTT: https://lists.boost.org/Archives/boost/2024/10/index.php

Is Boost still something people reach for in newer projects? Anecdotally most adoption I've seen happened in the 00s and very early 2010s (pre everyone mandating C++0x/C++11), I only rarely see it around these days.

edit: boost.org is a blast from the past, still looks exactly like I remember it from like 2008. Down to the "Get Boost" shopped on an emergency off button!

Re: MQTT turns 25

#16

Post by this_user »

Having recently used MQTT for a project, I can't say that I'm a huge fan. There are a lot of options in the protocol where it's not immediately clear what they do and why they are important, or in what combination they need to be used to make sure things work as intended, and the documentation is often not great at explaining. Part of this may also be on the Eclipse Mosquitto Python client that I had been using. I took me several days to figure out that the client was running into a race condition on a slower system that resulted in subscriptions to topics silently being ignored which caused the associated callbacks to malfunction despite following their documentation 100%. Overall, this has been one the messiest experienced I have ever had with a protocol, certainly one that isn't that old.

Re: MQTT turns 25

#18

Post by vv_ »

There aren’t many telemetry transfer protocols suitable for IoT besides MQTT (especially for resource constrained systems). It is incredibly simple to implement, has numerous libraries available in various programming languages, is supported by major cloud providers and is designed to operate over TCP (meaning you avoid DTLS).

We have shipped many products that use MQTT for telemetry transfer to various different vendor servers and it always just worked. It was never a pain-point in stark contrast to CoAP or some proprietary protocols.

Re: MQTT turns 25

#19

Post by klysm »

joezydeco wrote: post #9

I had a lot of fun on an embedded systems project recently where I used MQTT as an interprocess messaging system. Broker and clients on the same machine. If I needed to sniff or debug something it was as easy as putting the device on the network and using MQTT Explorer to record or inject messages. I could even let coworkers that were working remotely work with the system by opening the port outside the LAN.

Haven’t seen this done much but it does seem to have some desirable properties. My biggest concern when using it as a system component has been durability guarantees. I don’t have a lot of trust on broker implementations not to lose data.

Re: MQTT turns 25

#20

Post by jorl17 »

this_user wrote: post #16

Having recently used MQTT for a project, I can't say that I'm a huge fan. There are a lot of options in the protocol where it's not immediately clear what they do and why they are important, or in what combination they need to be used to make sure things work as intended, and the documentation is often not great at explaining. Part of this may also be on the Eclipse Mosquitto Python client that I had been using. I to…

My experience using MQTT has been through the paho python MQTT library, and, while we definitely have managed to get a lot done, it has been a terrible experience.

Everything about it rubs me the wrong way. The API design, the poor documentation, even the way they seem to not adhere to typical python conventions.

It looks like it's easy to start using it, but then the breadth of protocols and implementations start getting to you. At a point in time, I remember the only reliable way we had of knowing if we had successfully connected to a server was to try to subscribe to a topic twice and catch a specific error code on the on_connect message (which actually was documented as a success code at the time). I know how crazy it sounds and maybe there was a better way to do it, but, if there was, I don't think it was that easy to find.

It's easy to complain, though. I'm very grateful so many people have worked to create this library. If they hadn't, I wouldn't have built what we've built with it. I really admire people who take on these huge projects.

Post reply on HN