brynet is a header-only C++11 TCP stack with HTTP, WebSocket and SSL

Header only and dependency free is the whole pitch

brynet is a header-only cross platform high performance TCP network library using C++ 11, and the feature list leads with the properties rather than the features: header only, cross platform across Linux, Windows and MacOS, multi-threaded, and None depend.

The no-dependency claim is the one that decides whether you use it. A header-only library is added by copying headers into your include path or pointing your build at them, and there is nothing to link, nothing to version, and nothing to keep in step with your compiler's ABI. There is no asio, no boost, no OpenSSL unless you ask for it. The cost is compile time and binary size, since every translation unit that includes a brynet header parses all of it.

The compatibility list is what tells you how old this codebase is. Visual C++ 2013 and later in 32 and 64 bit, GCC 4.8 and later in 32 and 64 bit, and Clang with C++ 11 support. Those are the toolchains of the early 2010s, and they are the floor rather than the tested range, which is a reasonable design target for a library that wants to be usable in whatever environment a company has.

The macro list is short. BRYNET_VERSION and BRYNET_USE_OPENSSL, the second being how you turn on the SSL support. A library with two configuration macros is a library that tries hard to be inert until you need it, and that philosophy carries through the rest of the design.

The project description notes that it can be installed with vcpkg, and links the vcpkg port directly, so a Windows developer gets it through the standard package manager rather than by vendoring headers by hand.

HTTP, HTTPS, WebSocket and IPv6 are in the box, not in an add-on

The feature list says the library supports HTTP, HTTPS, WebSocket, SSL support and IPv6, and that is the reason to consider a from-scratch TCP library rather than a transport-only one.

Most networking libraries stop at bytes on a socket and leave the protocols above to you. brynet ships the protocol layers, which is demonstrated by the examples directory. There is an Http and Websocket Server example, an HttpServerClient example, a BenchWebsocket example which the README describes as a benchmark websocket client, a PromiseReceive example which uses the promise style to receive an HTTP response, and a WebSocketProxy example described as a proxy server between a websocket client and a binary protocol server.

That last example is worth a second look, because it is the shape of a real use case. A websocket client speaking to a binary protocol server is exactly the impedance mismatch that appears in game networking and in device protocols, and the example means you can copy the pattern rather than design it.

The promise-style HTTP response is a second design point. Receiving an HTTP response is where a callback-based socket API gets awkward, because the response arrives later and the caller has to keep its state alive in between. A promise-style receive keeps the caller in a straight line of code, and the example shows the pattern.

IPv6 support is listed alongside SSL, which is the combination you need for a modern server: a dual-stack listener and encrypted transport. The SSL support is opt-in through BRYNET_USE_OPENSSL, so a project that does not need encryption does not carry OpenSSL headers into its build.

The README also notes that documentation is in Simplified Chinese, at docs/main.zh-cn.md, and the repository has a docs/ directory alongside the examples. That is worth noting for anyone evaluating the library, since it affects how easily you would get help with it.

The benchmarks are from a virtual machine and read as a smoke test

The benchmark section is the part of the README that most needs a careful reading, and the reason is stated in the first line: under localhost, using a CentOS 6.5 virtual machine, with the host machine being Win10 on an i5.

So the numbers are a localhost loopback measurement on a virtualised CentOS 6.5. That is a configuration that measures the library's own overhead with the network stack in the same kernel, and it says nothing about behaviour over a real network with real latency and real loss.

The PingPong benchmark is described as server and client both using one thread with a packet size of 4k. The Broadcast benchmark uses two network threads and one logic thread on the server and one network thread on the client that also processes logic, with every packet 46 bytes and containing the client's id, where the server broadcasts to all clients on receiving from any client and the client replies when the id matches its own.

The HTTP benchmark is the most familiar, because the output is a standard ab tool report. On a 100 concurrency level it shows 500000 complete requests with 0 failed requests over 17.734 seconds, 28194.36 requests per second as the mean, a mean time per request of 3.547 ms, and 2257.75 Kbytes per second received.

The distribution numbers are more informative than the mean. Every percentile from 50% to 99% is served in 4 ms, and the longest request is 7 ms. A tight distribution like that on a loopback test says the implementation is not producing variable latency under load, which is a meaningful property, and it is also exactly what you would expect from a benchmark where the network never introduces delay.

None of these numbers should be used to predict production throughput. They are useful as a regression reference and as evidence that the library does not degrade under concurrent load.

cmake builds the examples and tests, and make installs the headers

The build instructions are two short lists.

To build the examples and the tests:

cmake . -Dbrynet_BUILD_EXAMPLES=ON -Dbrynet_BUILD_TESTS=ON

And then, on Windows you open brynet.sln and build it, while on Linux or MacOS you only enter make. The Visual Studio solution is generated by CMake, so the two platforms share one configuration rather than having separate project files to keep in step.

For installation the steps are:

cmake .
sudo make install

The repository root has a CMakeLists.txt, and the examples have their own examples/CMakeLists.txt, so the examples are a separate target that you can switch on. There is a tests/ directory, which the same flag enables, and a .clang-format and a .clang-tidy pair for the style and the static analysis. A GitHub Actions workflow named build-and-test has its badge at the top of the README.

The examples directory lists eleven files, which is a good indication of what the library actually does rather than what it claims to do. There are PingPongServer, PingPongClient and SingleThreadPingPongServer for the raw throughput case, BroadCastServer and BroadCastClient for the many-to-many case, HttpServer, HttpClient, BenchWebsocket, PromiseReceive and WebBinaryProxy for the protocol cases.

The SingleThreadPingPongServer alongside the multithreaded one is the interesting pairing. It lets you measure what the threading model costs, which is the number that matters when you are deciding whether the multi-threaded design is worth its complexity for your workload.

The project is used by other libraries, and the licence needs a second look

The users list names five projects by the same author, and they show what the library is used for. There is a Redis proxy, a project called gayrpc which sounds like an RPC framework, gaylord which is described as a distributed virtual actor framework, Joynet which is a Lua network library, and a grpc-gateway.

The distributed virtual actor framework is the one that tells you the most about the library's real capabilities. A virtual actor model needs many connections, each with its own state, and it needs them to be cheap to create. That is exactly the workload a from-scratch TCP stack is good at, and it is not the workload a general purpose async framework is designed around.

The licence needs a second look, and this is a genuine discrepancy rather than a judgement call. The project metadata records the licence as MIT, and there is a LICENSE file in the repository root. But the README carries a licence badge pointing at the NPL, the 996 Prohibited License, hosted in the 996.ICU repository. Those are not the same thing, and the NPL is a separate licence hosted in the 996.ICU repository.

So the stated intent and the repository's own metadata disagree. Before you ship brynet in a commercial product, read the LICENSE file in the repository and confirm which terms actually apply, and if it is the NPL, its terms will differ from the MIT record in the metadata. The MIT record in the metadata may simply be a leftover from an earlier state of the project.

The release record is old. The recent tags are v1.12.2 from 2022-12-17, v1.12.1 from 2022-07-21, and v1.12.0 from 2022-07-03. The repository is not archived and the last push was on 2026-05-25, so commits continue to land on master without new tagged releases.

Editorial conclusion

Adopt brynet if you are writing a C++ service that needs TCP, HTTP, WebSocket or SSL without pulling in an asynchronous framework and its dependency tree, and you value being able to read the whole implementation. Do not adopt it for a project that needs a maintained standard library or a modern toolchain baseline, since the last tagged release is v1.12.2 from 2022-12-17 and the compatibility list starts at Visual C++ 2013. Before you build, confirm your compiler meets the stated floor, decide whether the SSL support needs OpenSSL via the BRYNET_USE_OPENSSL macro, and check the licence situation, because the project metadata records MIT while the README badge references the NPL prohibited license.

Frequently asked questions

Official sources

1. IronsDu/brynet on GitHub
2. Issues
3. License: MIT
4. README
5. Releases