October 2013 WebSocket++ Update

Summary

Two 0.3.x alpha releases have been made since the last update. No major features have been added. A few minor features have been added and many bugs have been fixed. Highlights of these are included below, the full release notes can be found in the repository itself as well as on the Change Log page.

Highlighted Changes

  • Removes dependency on boost/std <regex> library. This brings full C++11 compatibility to GCC 4.6+ and avoids the requirement of bundling the rather large boost regex binary for space constrained embedded applications.
  • HTTP header processing case sensitivity has been reworked. Case used for reading headers is ignored per HTTP 1.1 spec. Case for headers you set will be preserved to help deal with other HTTP implementations that require certain cases.
  • Bundled third party library licenses have been consolidated in the COPYING file. Sha1 library was replaced with a different one under a BSD license rather than a freeware license to address concerns about ambiguous license wording. All bundled libraries now use Expat MIT or BSD licensing.
  • Asio transport introduces stop_listen method to allow a server to stop accepting new connections.
  • iostream transport introduces set_secure, set_remote_endpoint, eof, and fatal_error methods to allow users of this transport to pass information about the connection through to the library.
  • Updates close code types and validation based on recent updates to the IANA registry.
  • Updates to asio transport thread safety and re-introduces strands to allow io_service thread pools to work again.
  • Removes unused experimental code. This should reduce memory usage and improve performance, especially of creating and destroying connections.

Roadmap for 0.4.x

The alpha4 release today will likely be the last 0.3.x alpha. The next release will be tagged 0.4.x as there will be a few (very minor) breaking api changes.

  • 0.4.x will be backwards compatible with 0.3.x other than the minor issues described below.
  • If the hybi working group final spec is ready in time, the permessage-deflate extension will be included.
  • Pooled message buffer policies (more detail below) & flow control.

Specifically, exceptions thrown by the library will be uniformly of type websocketpp::exception. Right now there is a mix of websocketpp::exception and websocketpp::lib::error_code. websocketpp::exception behaves like normal C++ exceptions. It derives from std::exception and provides the usual exception interface. An error_code will be retrievable from the websocketpp::exception if needed. If you are presently catching websocketpp::lib::error_code you will need to update that code when 0.4.x is released. In addition, a small handful of previously deprecated methods (mostly ones that were renamed to be consistent with the rest of the library like iostream::readsome will also be removed.

Lastly, 0.4.x will include an overhaul of the message buffer system. This may involve some breaking changes to generating and sending raw message pointers. The present APIs for that are placeholders and clearly labeled as such. If you only use the send(string) and send(void*,length) methods there will be no change for you. If you use send(message_ptr) you will have a number of new options. In particular, there will be a plugable system for message buffers with at least three bundled by the library.

  • Basic allocate per message strategy. This is lock free and is optimal in terms of memory usage. It offers no control over total resource usage and may be slow due to repeated allocations per message.
  • Per connection message pool strategy. This is locked at the connection level. It is not memory usage optimal, but will allow control over the total memory usage per connection and may have significant performance benefits due to re-using buffers without reallocating memory.
  • Per endpoint message pool strategy. Similar to per connection but locked and shared at the endpoint level. More memory efficient but also more contention for buffers for multithreaded applications. Will allow an entire endpoint to run within a fixed memory budget.

The latter two options will include additional APIs for managing flow control.

Add new comment