WebSocket++: header-only RFC6455 with swappable transports

Four transports sit behind the same connection object

The protocol code and the byte mover are separate concerns here. WebSocket++ ships headers only and implements RFC6455, while the network layer arrives through transport modules instead of being fixed in place. Three come ready: one built on raw char buffers, one built on C++ iostreams, and one built on Asio, which itself can be supplied by Boost or standalone. A fourth path is the one you author, because the readme also states that end users can write additional transport policies to support other networking or event libraries.

The examples tree already separates those choices by directory name, which is the quickest way to see them. examples/iostream_server/ and examples/external_io_service/ sit beside examples/echo_server/, examples/broadcast_server/ and examples/testee_server/. Everything above them is a message and event based interface, and swapping the transport does not change the way a handler reads.

Header only still leaves you a build system to drive

Header-only describes what you link, not what you run. At the root you still find CMakeLists.txt, a cmake/ directory and websocketpp-config.cmake.in for CMake users, plus SConstruct for the SCons path, so the project expects its test/ and tutorials/ directories to be built by a real tool. Around those sit .travis.yml for continuous integration, a Doxyfile for documentation generation, changelog.md and roadmap.md for release history and intent.

No install command appears anywhere in the readme. What it offers instead are three destinations: the project website at http://www.zaphoyd.com/websocketpp/, the user manual at http://docs.websocketpp.org/, and the GitHub repository. Cloning the tree is the only step the readme implies.

git clone https://github.com/zaphoyd/websocketpp/

Everything after that, including which examples to compile first, has to come out of the manual or the example directories themselves.

Boost or the C++11 standard library, with no third option

Dependency choice is a single switch with two positions: the C++11 standard library or Boost. That switch reaches into the Asio transport, which works with Asio from Boost or with standalone Asio, and it is the reason one feature bullet can claim portability across Posix and Windows, 32 and 64 bit, and Intel, ARM and PPC targets without naming a distribution.

The same list claims thread safety outright and nothing qualifies it. No object list, no locking rules, no statement about which callbacks run on which thread. Treat that claim as an entry point to the user manual rather than as a design you can rely on without reading it first.

Draft protocol coverage stops at the server side

Protocol support is asymmetric. RFC6455 support is described as full, for both roles. Under that sits partial support for Hixie 76 and for Hybi drafts 00 and 07 through 17, and that line carries a qualifier in parentheses: server only.

The qualifier is the entire constraint. A WebSocket++ server can still answer a legacy handshake from an old client, which matters when a long-lived embedded or legacy client has to keep talking to a new service. The client role has no matching path, since it speaks RFC6455. If your deployment also runs the other direction, a WebSocket++ client reaching a legacy draft-only server, you need a different plan, and the readme names no negotiation mode or compatibility flag that would reconcile the two sides.

TLS, IPv6 and proxies are feature bullets without instructions

Secure WebSockets, IPv6 and explicit proxies appear as three items in a feature list, and the tree backs the first one with examples/echo_server_tls/ and examples/print_client_tls/. That is the full extent of what the repository states about all three.

There is no certificate path in the readme, no mention of which TLS backend to configure, no proxy address sample, and no note about whether each of the transports carries TLS the same way. Explicit proxies, in the phrasing used here, means a proxy you configure rather than one the library discovers for you. Budget a session with the manual at http://docs.websocketpp.org/ before committing to wss endpoints or an outbound proxy path, because none of those choices can be settled from the readme.

Twenty-five example directories, named for the job each one proves

The examples directory holds 25 subdirectories, and the naming is descriptive enough to work as an index. Basic pairs come first: echo_client and echo_server, echo_server_both, print_client and print_server, plus the TLS variants echo_server_tls and print_client_tls. Then come the ones aimed at a single job: broadcast_server and simple_broadcast_server for pushing a message out to many connections, telemetry_client and telemetry_server for streaming data, sip_client for a signalling client, subprotocol_server for negotiating a subprotocol, and debug_client with debug_server for inspecting frames.

The remaining names cover plumbing that usually gets written by hand: handler_switch, associative_storage, enriched_storage, external_io_service, testee_client and testee_server, scratch_client and scratch_server, and dev. Since nothing installs as a package, these directories are the fastest route to a working configuration of a given transport.

Tags stopped at 0.8.2 while master kept receiving commits

Version numbers tell a sharper story than activity does. The readme header reads WebSocket++ (0.8.2), and the release list confirms 0.8.2 as the newest tag, published on 2020-04-19, preceded by 0.8.1 on 2018-07-16 and by 0.8.0 four days earlier on 2018-07-12. The last push landed on 2026-05-04, so commits continue to reach the default branch while no release has been cut in more than six years.

For planning, hold on to that split. Pin to a tag, read changelog.md and roadmap.md to judge what the untagged work amounts to, and assume your team carries its own patch level. Two more repository facts belong in the same review: pull requests are supposed to go to the develop branch rather than master, and the licence field reads NOASSERTION while a COPYING file sits at the root, so read that file before shipping anything.

Editorial conclusion

Choose WebSocket++ when you want RFC6455 in C++ without committing the whole program to Boost.Asio, and when a team can carry its own patch level. Walk away if you need tagged releases with security fixes or a vendor behind the project. Before committing, read changelog.md and roadmap.md, open the COPYING file, confirm your compiler and standard library pairing, and target the develop branch if you intend to send a pull request.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. zaphoyd/websocketpp on GitHub