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

Subject: Re: [Boost-users] Boost.Beast vs Boost.Asio
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2018-12-03 16:57:48

On Mon, Dec 3, 2018 at 7:45 AM Cristian Morales Vega via Boost-users
<boost-users_at_[hidden]> wrote:
> There are lots of things which I would expect to be in Boost.Asio
> which are actually in Boost.Beast. Why?
>
> Most of it is "helping" code/docs. For example:
> - Documentation about (and public interfaces to simplify) the creation
> of composed operations
> https://www.boost.org/doc/libs/develop/libs/beast/doc/html/beast/using_io/writing_composed_operations.html

It states very clearly in the Beast documentation, that an
understanding of Asio is required. Of course, this doesn't stop people
who are new to Beast, new to Asio, new to Networking, new to C++, new
to programming (or all of the above) from picking up the library and
trying to implement something.

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 expect this situation to change once Networking TS is merged into
the standard. By making networking a standard, it reduces the risk and
increases the incentive for authors and publishers to produce these
missing educational materials. As far as networking goes, I believe
C++ is behind largely because of decisions made by wg21, which is the
ISO group responsible for updating and producing the C++ standards.
Fortunately, competition and pressure from other languages has lit the
proverbial fire and networking is finally being taken seriously
(although some people, like myself, think that fire could be stoked a
bit).

> - beast::buffers_cat

I follow Chris' design work closely and I think his "layered" approach
is the right way to build up libraries. Asio provides the low level
building blocks which cannot be further decomposed without losing
portability. My opinion is that most C++ users should not be writing
code for Asio or Networking TS. These interfaces are mainly designed
for building layers on top of it, layers such as Beast. End users want
to perform an HTTP GET to retrieve a file using a single line of code.
They don't want to have to know about the intimate details of the
protocol. Even Beast could be considered too low-level for most
end-users. I wrote Beast mainly as a run up in the ladder of
abstractions, so that other people could build on it.

With respect to buffers_cat, yeah - it is really handy! There is no
question that it has utility. Although I don't know that Asio is the
place for it. There are other ways to implement buffers_cat with
different tradeoffs. For example, you could use a fixed C-style array
of const_buffer. This would accomplish type-erasure at the expense of
a larger structure.

That said, I have proposed some of Beast's buffer sequence adaptors
for the standard library:

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1145r0.html>

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

> 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?

> I am asking myself
> how to handle an increasing amount of references to Beast that in a
> future could change to Asio (potentially with slightly different
> names/semantics). So I am writing this hoping for some light on the
> situation.

Well, you can be ready with the find and replace tool :)

Regards