Re: [boost] [async-mqtt5] Formal review starts today

Vinnie, thanks for reviewing the library! Here are the answers to your questions. These should probably not go into official documents but rather into separate doc. Motivation We needed a robust, automotive-grade MQTT client for our commercial projects. Most of these projects require a highly stable, bug-free MQTT implementation, as our systems are typically deployed in automotive environments where any software malfunction can lead to costly repairs. Another motivation for developing an industrial-grade MQTT library was our collaboration with automotive partners who produce vehicle tracking devices. Over the years, we've encountered numerous reliability issues with these devices, most of which were related to custom implementations of network data transmission. MQTT, originally designed in 1999 to address exactly these problems, seemed like the perfect solution to help these companies resolve at least the network-related issues. Since our projects are C++-based, we were looking for an MQTT implementation that wasn’t tied to any specific commercial cloud infrastructure. For instance, Amazon AWS offers its own MQTT client, but it's deeply integrated into the AWS ecosystem and isn't practical for use outside of it. We analyzed the two most popular open-source C-based clients, Eclipse Mosquitto and Paho. While these libraries are mature and stable, they don’t integrate well with the asynchronous model of ASIO, which we wanted to use in our projects. We also spent considerable time trying to integrate Mr. Kondo's mqtt_cpp library https://github.com/redboltz/mqtt_cpp, which is an earlier version of his MQTT client. Although it internally uses ASIO, it exposes its functionality through simple, non-awaitable callbacks. While we were able to wrap it with an ASIO-compliant asynchronous interface, extensive testing revealed surprising bugs within the library itself. Additionally, the library's internal structure was highly complex, making it extremely difficult to understand and maintain. Given that MQTT is relatively straightforward to implement, we decided to write our own MQTT client that would be fully ASIO-compliant and rock-solid. Implementation The Async.MQTT5 library was deliberately designed with an extremely simple public interface. Notably, it automatically handles all network errors and performs reconnections when the network link goes down. From our experience, one of the most complex and error-prone aspects of working with MQTT is managing the protocol's behavior during client reconnections to the broker. The three libraries we mentioned earlier leave connection error handling to the user, which inevitably complicates the user’s code and increases the likelihood of errors. By eliminating this problematic aspect, the library becomes straightforward and easy to use, as long as the user follows fundamental Asio guidelines. That said, the Async.MQTT5 library sees about 200 (non-unique) daily clones, with only 17 issues reported so far since its initial release. We take this as a positive sign of the library’s stability. Async.MQTT5 has been in use for about a year, since the fall of 2023. We specifically measured the performance in terms of PUBLISH message throughput. We hit the broker's limit (where the broker could no longer handle the volume of messages) while publishing 2KB payloads from a Raspberry Pi 4 on a 1GBit/s local network. Apart from that, we did not perform other benchmarks. HiveMQ is probably the most known user. Rimac is also quite well known. Pixie AS is another one. I believe it should be possible to get review of the library from those and other companies, although it would need some time.

On 20.10.2024., at 18:15, Vinnie Falco via Boost wrote:

On Tue, Oct 15, 2024 at 11:16 PM Klemens Morgenstern via Boost < boost@lists.boost.org> wrote:

...

The library has been developed by mireo, a GPS/GIS software development company, and their CTO Ivica Siladić submitted it.

Ivica, thank you for submitting this library.

In my opinion, the most important quality of a submission is its usage in production systems or in other projects. I prefer libraries to demonstrate utility by gaining popularity or usage well ahead of the review.

Can you please explain the history of this library? Example questions:

* What was the motivation for writing async-mqtt? * Did you first try using other already-existing libraries and if so, what was the experience?. If not, then why not? * How long has async-mqtt been in production? * Are there any benchmarks or performance metrics? * What are notable experiences with the production usage? * What other companies or projects are using async-mqtt? * Can we reach out to the other users and get their feedback (or better yet, a review)?

This is important, and I believe this information should be in the documentation of the library and permanently available. Furthermore, if there are other mqtt libraries which use Asio (or even in C++) I would like to see a comparison of differences between async-mqtt and the best 1 or 2 competitors. For example, have a look at this information from Beast:

https://www.boost.org/doc/libs/1_86_0/libs/beast/doc/html/beast/design_choic... https://www.boost.org/doc/libs/1_86_0/libs/beast/doc/html/beast/design_choic... https://www.boost.org/doc/libs/1_86_0/libs/beast/doc/html/beast/design_choic...

I think I should mention that there's another mqtt library that has

...

been proposed for boost, but has yet to find a review manager: https://github.com/redboltz/async_mqtt

The documentation for mireo/async_mqtt should include a section which compares itself to redboltz/async_mqtt. This is useful whether or not the Mireo library is accepted, as users who are looking for an MQTT library will be more well-informed by this data.

As a side note, the author of redboltz/async_mqtt should also do all of the above, if not already done.

Thanks

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Thanks, Ivica Siladic