|
|
Boost : |
From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2024-04-29 16:51:43
I have looked over your documentation, and I think I'd prefer mireo's
API for clients. Your library seems more low-level, which is not ideal
for simple clients.
However, support for a server is a different story. I think there
might be space for two libraries, mireo/async-mqtt5 as the easy-to-use
client, and your library as the low-level one for fine-tuning and
servers.
I would be very interested how you and the mireo team see any
potential overlap/synergy/conflict with those two mqtt libraries.
On Mon, Apr 29, 2024 at 11:42 PM Takatoshi Kondo via Boost
<boost_at_[hidden]> wrote:
>
> Dear Boost Developers,
>
> I'd like to propose a MQTT library to the Boost Libraries.
>
> Repository link: https://github.com/redboltz/async_mqtt
> Document link: https://redboltz.github.io/async_mqtt/doc/5.0.0/index.html
>
> Here is characteristics of async_mqtt:
> - C++17 or later is required.
> - async_mqtt supports Boost.Asio style completion tokens.
> - e.g. use_future, deferred, use_awaitable, callback functions, etc
> - Not only MQTT client but also MQTT server is supported.
> - User can use this library to develop MQTT broker.
> - Sample MQTT broker application is included.
> - Both MQTT v3.1.1 and v5.0 are supported.
> - In addition, undetermined protocol version is supported for server
> implementation. In this case, the protocol version is decided when you
> receive CONNECT packet.
> - Continuous packet sending
> - Users can send the next MQTT packets before the previous sending
> is not completed (completion handler is not invoked yet).
> - Auto acquiring/mapping topic alias is supported.
> - In addition, when resending a PUBLISH packet after reconnecting,
> the topic alias is removed and the original topic is restored. It is
> required by MQTT v5.0 spec.
> - Packet based send()/recv() APIs.
> - MQTT has various packets and some of their fields are optional. In
> order to keep simple APIs, async_mqtt uses packet based APIs.
> - See https://redboltz.github.io/async_mqtt/doc/5.0.0/tutorial/send_recv.html
> - Layered archtecture
> - async_mqtt can have predefined TCP, TLS, WS, WSS, and user
> defined underlying layer. Users can access the underlying layer using
> next_layer() member function of MQTT endpoint. So you can configure
> any layers by yourself. e.g. tcp_no_delay, set send/recv buffer size,
> etc
> - See https://redboltz.github.io/async_mqtt/doc/5.0.0/tutorial/create_endpoint.html
> - High performance
> - See https://redboltz.github.io/async_mqtt/doc/5.0.0/performance.html
>
> Background
>
> I have developed another mqtt library mqtt_cpp
> https://github.com/redboltz/mqtt_cpp since 2015. It is widely used but
> has some limitations. For example:
> - The functions are directly mapped to packets(publish, subscribe,
> etc), so optional features are not designed cleanly.
> - Due to set_publish_hander / on_publish style handler design,
> Completion Token cannot be supported.
>
> Based on this 9years experience, I designed the new MQTT library. This
> is async_mqtt.
>
> I would appreciate if you could endorse this library.
>
> Regards,
> Takatoshi Kondo
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk