Re: [boost] [beast] socket versus stream

Subject: Re: [boost] [beast] socket versus stream
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-07-02 12:23:06

On Sun, Jul 2, 2017 at 5:16 AM, Bjorn Reese via Boost
<boost_at_[hidden]> wrote:
> The HTTP API provides a set of free function for all operations, so
> all interaction follows this pattern:
>
>   operation(socket, args);
>
> The WebSocket API wraps an Asio socket in a stream, so all operations
> are like this:
>
>   stream.operation(args);
>
> I realize that the latter choice is a consequence of using SSL, but I
> am wondering why there is no socket.operation(args) style for the
> former?

The question is, why does HTTP use

    beast::http::read(socket, buffer, parser);

while WebSocket uses:

    ws.read(buffer);

Its not really related to SSL but rather, reflects the fact that
WebSocket connections are stateful. The beast::websocket::stream
maintains information needed in between calls to read and write. For
example there are user defined options, the control callback, the
permessage-deflate state, and various control structures needed to
"park" composed operations to give callers the illusion that read,
write, ping/pong, and close operations can be performed concurrently.
These have to be stored in an object associated with the lifetime of
the connection:
<https://github.com/vinniefalco/Beast/blob/78a065ba39836d91d7e70d93de7f9140f518083b/include/beast/websocket/stream.hpp#L137>

I thought about having a beast::http::stream<> wrapper for HTTP/1 (its
definitely needed for HTTP/2) but what would go in it? You could maybe
put a parser in there. But in order to choose a Body type based on the
request header you need to select the Body type at runtime. Affixing a
parser to an HTTP "stream" wouldn't allow that use case. So there's
really no state to be maintained. Therefore, Beast opts for HTTP free
functions since that is the most simple and straightforward solution.

Thanks