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.
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/SyncReadS...
http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/reference/SyncWrite...
http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/reference/AsyncRead...
http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/reference/AsyncWrit...
* 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_streamb...
* 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.