Re: [Boost-users] Boost.Beast vs Boost.Asio

Subject: Re: [Boost-users] Boost.Beast vs Boost.Asio
From: Cristian Morales Vega (cristian_at_[hidden])
Date: 2018-12-03 18:25:07

On Mon, 3 Dec 2018 at 16:58, Vinnie Falco via Boost-users
<boost-users_at_[hidden]> wrote:
> It is true that there is a notable lack of authoritative tutorials and
> guides on all of the finer aspects of using Boost.Asio (and by
> extension, stand-alone Asio and Networking TS). I don't think it is
> fair to expect that the author of Asio (Christopher Kohlhoff) should
> be responsible for writing these things.

I would not expect Christopher to be responsible for writing these
things. But you have already written it, if you would offer the patch
to add that documentation to Asio wouldn't Christopher take it? It's
likely it would reach a wider audience if it were in Asio instead of
in Beast. There must be people interested in Asio but not in
HTTP/Websocket who may not have bothered to look into the Beast docs.

> > - beast::test::stream (to be fair, it's in experimental)
>
> Interfaces in _experimental/ are very likely to change which is why
> they are specially marked. They can also have bugs or lack
> documentation. As these things become fully baked they will be
> promoted to public interfaces (moved from _experimental to one of the
> public interface directories).

Sure, but wouldn't make sense for it to be in Asio's experimental
instead of in Beast's experimental? It would have a wider audience,
which would give you more feedback.

> > But now we even have code to work around issues in Boost.Asio which
> > ideally would simply be fixed in Boost.Asio. For example:
> > beast::ssl_stream.
>
> asio::ssl::stream implementation does not handle scatter/gather I/O.
> When you call write() with a buffer sequences having length greater
> than one, it results in a separate I/O for each element of the
> sequence. This kills performance, especially in Beast where the
> implementation makes heavy use of buffers_cat. Beast's ssl_stream
> class is a wrapper which intelligently flattens these sequences at the
> expense of allocating memory.
>
> I think there's an OpenSSL interface for handling a vector of buffers,
> so if it was fixed in Asio it would be better as there would be no
> need to allocate memory. I don't know enough to attempt a fix but
> maybe there is someone else who could?

Fair enough. Better to have a workaround than nothing. But until
somebody with more OpenSSL knowledge comes with a proper fix, wouldn't
the workaround be better in the Asio repository?

To be fair, I don't know how the different Boost libraries are
developed. Maybe it's too difficult for the developer of one library
to contribute to another library?