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
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.htm... - 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