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

On Fri, Apr 22, 2016 at 8:13 PM, David Stone 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::streamboost::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 void websocket::stream::accept(http::request 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::streamboost::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