Re: async-mqtt5 review

From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2024-10-25 12:43:07

2 octobre 2024 à 18:51 "Christian Mazakas via Boost" <boost_at_[hidden] mailto:boost_at_[hidden]?to=%22Christian%20Mazakas%20via%20Boost%22%20%3Cboost%40lists.boost.org%3E > a écrit:
> 
> I think there's a lot of utility in MQTT, but what I'd like to see in the
> future for libraries like these is a first-class interface _without_ I/O.
> For example, I'm not sure I saw any fuzzing of the underlying parsing code.
> A non-I/O based interface makes this trivial.

> By focusing on creating a pure protocol library, you give users the ability
> to add MQTT to their own I/O layers which has the extensibility and
> genericity I'd expect from a Boost library. It will also likely enable the
> library to be compiled which in this case would be a huge boon.
> 
> For example, I have an asynchronous runtime which is dramatically faster
> than Asio and I'm capable of handling low-level networking coding but I
> can't use this library with my own. Instead, I'd have to roll my own MQTT
> support. In the ideal case, I'd be able to treat this library like I would
> Botan and I'd add MQTT support non-intrusively.

I'm surprised that this remark did not raise more reaction. I'd like to put a 
very big +1 on what Christian said.

For what it's worth, the platforms i'm currently mostly working with are 
Xenomai/Linux and FreeRTOS. Asio is unusable on both. I don't think it 
can be used on Zephyr OS as well. AFAIK it can't be used in any real time / 
embedded os (well, maybe RTLinux or Qnx).

MQTT is advertised as an IOT protocol. I know so-called things are growing more 
and more to be standard linux devices, but there are still plenty of them which
are not. My understanding is that the proposed library is not usable in such 
platforms, due to the lack of asio. Is that correct?

If it is, the next question is what would be the amount of effort that would
be needed to put the parsing / interpretation layers outside the networking layer, 
and if there are there any plans to do it?

Christian mentionned fuzzing as an immediate benefit. My experience tells the same,
pure protocol libraries are a lot easier to unit test than io libraries.

> All this being said, a protocol library that comes with an Asio-based impl
> is perfectly fine. My only qualm is when the library _only_ supports Asio
> as seems to be the case here.

I would even add that supporting asio is a very good case of testing the validity
of the design of an underlying protocol library. A pure protocol library which
has not been tested against asio may well miss its target.

Regards,

Julien