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

21–30 of 76 posts

Re: MQTT turns 25

#21

Post by miljen »

formerly_proven wrote: post #15
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!

That is an interesting question. Here you can see the actual popularity of each library within Boost: https://grafikrobot.github.io/boost_lib_stats/. Also, see the comments at https://www.reddit.com/r/cpp/comments/130bzj8/has_boost_lost.... My company has been heavily utilizing Boost.Asio and Boost.Beast, so we've definitely reached for Boost in newer projects as well.

Re: MQTT turns 25

#22

Post by logifail »

klysm wrote: post #19
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.

> 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

(If we ignore retained messages) MQTT brokers are not designed to store data, so there's no need to be concerned about durability because there simply isn't any...(!)

It is (just) a messaging protocol.

Re: MQTT turns 25

#25

Post by spacechild1 »

formerly_proven wrote: post #15
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!

AFAICT Boost.Asio is still the go-to networking library. (Though Asio is also available as a standalone outside of Boost, I didn't know that until recently.)

Apart from that, Boost has quite a few goodies such as Boost.Json, Boost.Program_options, Boost.Interprocess, Boost.Lockfree, Boost.Unordered, Boost.Dynamic_Bitset, etc.

Some libraries, like Boost.Atomic, Boost.Thread, Boost.Chrono and Boost.Filesystem, simply became obsolete with modern C++ versions. In fact, they served as the blueprint for the corresponding C++ standard libraries.

Personally, I have been wary of using Boost in the past because it's such huge library, but CMake integration is actually quite good these days and I found it pretty easy to use. Documentation is also quite good IMO.

Re: MQTT turns 25

#26

Post by vv_ »

dloranc wrote: post #17

What do you think about LwM2M in comparison with MQTT?

It is not directly comparable because LwM2M was originally developed for device management, while MQTT is primarily used for transferring telemetry or other opaque data.

My personal gripe with LwM2M is that it uses CoAP (Constrained Application Protocol) as its primary transport protocol. Since CoAP is based on UDP, you’re forced to rely on DTLS for authentication and encryption. Managing sessions with DTLS can be quite frustrating, and unlike TCP, there’s no reliable indication of when a session is closed by your peer.

Another issue is that it doesn't strictly follow the client-initiated communication pattern and can receive unsolicited messages from the server. I have found this to be very unreliable in real-world conditions for Device Management use cases.

Re: MQTT turns 25

#27

Post by ronameels »

MQTT is being used a lot more in recent years inside of factories for sharing data between machines. Historically it's been used in Oil & Gas for SCADA (getting data from remote well sites).

10+ years ago we added it to Kepware (OPC server) and streamed tag values to "the cloud". I was at a conference giving a presentation on it when Arlen Nipper, one of the creators of MQTT, came up after the presentation and said I did a "decent job". It was humbling :). Fast forward to today, and we have a new company (HighByte) modeling factory data at the edge and sending it via MQTT, SparkplugB (protocol over MQTT), direct to S3, Azure Blob, etc, etc.

All that to say, MQTT is a big driver in Industry 4.0, and it's cool to see it so heavily used all these years later.

Re: MQTT turns 25

#28

Post by DannyBee »

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…

So your client just sucks here.

My experience with the eclipse clients (paho, etc) is similar to yours in both python and C++, - it makes it overly complicated and seems very low level. It also is somewhat buggy because of the architecture.

I believe (perhaps wrongly), it's all basically maintained by one person or close to it (only one person has contributed to the C++ client in the past 6 months, for example, and nobody has contributed in the past 3), so i kind of understand how it's gotten this way over time.

I filed a simple PR (1 word change) to fix an obvious bug and it took 2 years to review it and accept it with no changes. Again not a complaint, just trying to portray how the state feels - a lot of libraries, bugs, and work, and few overworked people helping get it all done.

I moved to other clients and the experience is much much better in python, rust, C#, and C++.

Most of them have a good combination of high and low level API's, so if you just want to send a message on a topic, you don't have to worry about acks, retries, etc.

But if you need control, you can get it.

Honestly, i worry at this point that keeping paho/etc alive in this state is doing more harm than good - if they were officially dead it would at least force the issue. Right now you end up with users who have an experience like yours, and then either give up on MQTT or assume they are doing it wrong :)

Re: MQTT turns 25

#29

Post by NortySpock »

My most recent foray into MQTT was using the MQTT 3.1.1 compatibility mode in NATS, which was pretty easy to set up once I got the permissions sorted out.

Works great for my smart home needs while also letting me explore latency and throughput load testing if I want to have a little fun.

Re: MQTT turns 25

#30

Post by fartfeatures »

ronameels wrote: post #27

MQTT is being used a lot more in recent years inside of factories for sharing data between machines. Historically it's been used in Oil & Gas for SCADA (getting data from remote well sites). 10+ years ago we added it to Kepware (OPC server) and streamed tag values to "the cloud". I was at a conference giving a presentation on it when Arlen Nipper, one of the creators of MQTT, came up after the presentation and said I…

Is MQTT being used in places where previously Modbus would have been used?
Post reply on HN