Re: [boost] New Lib "Beast", HTTP + WebSocket protocols

Subject: Re: [boost] New Lib "Beast", HTTP + WebSocket protocols
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2016-04-29 08:31:03

> On Fri, Apr 22, 2016 at 8:13 PM, David Stone <david_at_[hidden]> wrote:
> > How does this compare to www.zaphoyd.com/websocketpp
> 
> We have experience with websocketpp as it is the solution we have been
> using in our open source peer to peer software
> (http://github.com/ripple/rippled) for the last five years. It is that
> experience that drove the development of this new library as its
> replacement. Since the WebSocket protocol starts with a HTTP
> handshake, we also developed Beast.HTTP as an added bonus - think of
> it as a double feature at the drive-in.

Thanks for the lengthy explanation of your library features. However to get
back to the question originally asked (which you haven't really answered):
'How does this compare to www.zaphoyd.com/websocketpp'? Why should I use it
and not websocketpp?

Thanks!
Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu

> 
> Beast.WebSocket has these things going for it:
> 
> * Construct a stream from a socket or ssl::stream that's already
> connected or accepted:
> 
>     boost::asio::ip::tcp::socket sock(ios);
>     websocket::stream<boost::asio::ip::tcp::socket> ws(std::move(sock));
> 
> * Accept a WebSocket handshake request with bytes that have already
> been read from the socket:
> 
>     template<class ConstBufferSequence>
>     void websocket::stream::accept(ConstBufferSequence const& buffers);
> 
> * Accept a WebSocket HTTP request handshake that was already parsed
> (e.g. from Beast.HTTP):
> 
>     template<class Body, class Headers>
>     void websocket::stream::accept(http::request<Body, Headers> const&
> request);
> 
> * Wraps any object meeting these type requirements, use your own type
> if you want:
> 
>     websocket::stream<YourTypeHere> ws(...);
> 
>     The type requirements (sync, async, or both):
> 
> http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/reference/SyncRea
> dStream.html
> 
> http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/reference/SyncWri
> teStream.html
> 
> http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/reference/AsyncRe
> adStream.html
> 
> http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/reference/AsyncWr
> iteStream.html
> 
> * Receive functions accept any object meeting the requirements of
> Streambuf, permitting custom memory management strategies including
> the use of statically sized buffers. For example games using messages
> of fixed length.
> 
>     Streambuf type requirements:
>       http://vinniefalco.github.io/beast/beast/types/Streambuf.html
> 
> * In the Asio doc, Christopher Kohlhoff alludes to alternate
> implementation strategies for boost::asio::streambuf using multiple
> discontiguous buffers of varying sizes. We fulfill this idea with an
> optimized stream buffer that follows the strategy he described,
> providing a useful building block for sending and receiving variable
> size data. See:
> 
> 
> https://github.com/vinniefalco/Beast/blob/master/include/beast/basic_strea
> mbuf.hpp
> 
> * Interfaces are designed to closely resemble Asio in every possible
> way. This includes support for the extensible asynchronous model -
> support for std::future and stackful/stackless coroutines right out of
> the box. The library is designed to eliminate the learning curve for
> those familiar with Asio:
> 
>     extern void handle_read(boost::system::error_code ec);
> 
>     websocket::stream<boost::asio::ip::tcp::socket> ws(ios);
>     ...
>     websocket::opcode op;
>     beast::streambuf sb;
>     ws.async_read(op, sb, std::bind(&handle_read, std::placeholders::_1));
> 
> * All functions are template driven so everything is transparent to
> the compiler, including completion handlers passed to asynchronous
> initiation functions and objects used as buffers.
> 
> By design, Beast.WebSocket avoids doing these things:
> 
> * Managing the io_service
> * Managing a listening socket
> * Managing threads or a thread pool
> * Requiring the use of exceptions in certain places
> * Imposing a particular message buffering strategy
> * Using std::function for asynchronous callbacks
> * Requiring callers to know the size of the message in advance.
> 
> The last point above is especially important for applications that
> produce data incrementally. For example, a huge JSON reply that comes
> from a database query.
> 
> Planned improvements for Beast.WebSocket include:
> 
> * Explicit proxy support with basic authentication
> * Tools for parsing subprotocols and message headers
> * permessage compression:
>   https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-28
> 
> Years of experience working with Asio and and WebSockets have gone
> into the development of this library. It tries to be a natural
> extension of Asio, in a manner that is as narrow and lean as possible
> to provide maximum flexibility and performance.
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost