yasio gives game clients one socket API across TCP, UDP and KCP

One API over three transports

The library describes itself as a lightweight cross-platform asynchronous networking library focused on clients and on network services for game clients built with various game engines, supporting Windows, macOS, iOS, Android, ohos, Linux, FreeBSD and other Unix-like systems. The feature list leads with the part that matters most for a game client: TCP, UDP and KCP transports are supported, and the API is unified across them. That unification is the design decision. A game client that talks to a real time server, downloads a file over HTTP and sends a voice stream has three transport requirements, and the usual outcome is three libraries with three event loops and three error handling conventions. The TCP packet boundary handling is also handled by the library, so the business code does not have to think about it, and the API can handle all network events for multiple connections.

The C++20 floor and the C++11 compatibility headers

There is a version floor worth reading before anything else, and it changed recently. The README states that since version 4.4.0 the minimum supported C++ standard is C++20. That is a real constraint for a library that has historically advertised itself for C++11, C++14 and C++17, and the topic tags still list all of them. The way the project reconciles the two is by shipping its own versions of the newer standard library components, in `yasio/string_view.hpp`, `yasio/shared_mutex.hpp` and `yasio/memory.hpp`, so they can be used with a C++11 compiler. The list of what is provided is specific: cxx14::make_unique, cxx17::string_view, cxx17::shared_mutex, cxx20::starts_with, cxx20::ends_with, plus yasio::byte_buffer and yasio::pod_vector. If you are on an old toolchain you can still use the library, but the 4.4.0 line has raised the bar for the modern one.

Building the test program with g++ in one line

There is a quick way to try the library without a build system, and it is worth using before you commit to integrating it:

g++ tests/tcp/main.cpp --std=c++11 -DYASIO_HEADER_ONLY -lpthread -I./ -o tcptest && ./tcptest

The macro is the point. The library supports a header only integration mode, and all you need to define is the `YASIO_HEADER_ONLY=1` preprocessor macro, with the file name spelled either that way or as `YASIO_HEAD_ONLY=1` in the feature list. The same flag is what makes the library usable in an environment where linking a static library is awkward, which in practice means game engines with unusual build systems.

The CMake path is the one to use for real work, and the README gives both the generator choice and how to open the result in an IDE:

git clone --recursive https://github.com/simdsoft/yasio
cd yasio

cmake -B build
cmake --build build --config Debug

On macOS with Xcode the generator flag becomes `cmake -B build -GXcode`, and afterwards the project opens as `build/yasio.xcodeproj` on macOS or `build/yasio.sln` on Windows.

SSL comes with a prebuilt library you may not be able to use

The SSL story has a wrinkle that will bite on Windows. The CMake scripts default to OpenSSL as the SSL backend and download it automatically from the 1kiss repository, but the prebuilt library is compiled with VS2022, MSVC 14.39. If your system does not have that version installed, the documentation says to pass the CMake parameter `-DYASIO_SSL_BACKEND=2`, and gives the cross-platform one-click build script as the way to do it:

powershell build.ps1 -p win32 -a x64 -xc "-DYASIO_SSL_BACKEND=2"

The repository holds the `1kiss/` directory, which is that download source, alongside a `3rdparty/` directory and a `certs/` directory. SSL is supported for both client and server roles, based on OpenSSL or Mbed TLS, so the two backends are a choice rather than a limitation, and the non-blocking DNS resolution is based on c-ares, which is a separate dependency you inherit when you use that feature.

The engine and scripting bindings

The integration section is the strongest argument for the library, because it lists where it has actually been used in production. The applications section names projects using it for client networking, including a mobile title that the README says has run stably on tens of millions of mobile devices since its October 2018 release, an audio and voice chat project, and a cross-platform engine. The integrations list covers Unity, with a pure C# wrapper and a Lua variant, and Unreal Engine, with the plugin plus variants for the Tencent Lua integrations and UnLua. The Lua and Cocos2d-x jsb bindings are also listed as supported features, along with the Cocos Creator jsb 2.0 binding, and the repository has `examples/` directories for an FTP server, a JavaScript example and a Lua example. Each binding is a separate repository, which is a reasonable way to keep the core free of engine dependencies.

The smaller conveniences that save code

Beyond the transports, the feature list contains a set of small things that each remove a chunk of boilerplate. There is Unix domain socket support, binary reading and writing through the obstream and ibstream utility classes, and a .NET compatible integer compression encoding in the form of 7Bit Encoded Int and Int64, which is the thing you want if you are talking to a C# or Java server. There is microsecond precision timers, multicast support, and IPv4, IPv6 or Apple IPv6_only networking. A separate section covers the header only mode again, and a `yasio.pc` file at the repository root and a `manifest.json` suggest the library is consumable through the usual packaging machinery, with a `CMakePresets.json` and a `mkdocs.yml` for the documentation, which lives at learn.simdsoft.com/yasio.

Where the project stands

The release history shows steady work on the 4.x line, with v4.4.1 from 2026-08-03, v4.4.0 in May 2026 and v4.3.3 two days later in May. The last push to the dev branch, which is the default branch, was on 2026-09-10. The licence is a custom one that GitHub cannot classify, with the terms in the LICENSE file and a Boost Software License 1.0 file in the repository as well, and the project also carries an AppVeyor configuration for the older Visual Studio builds alongside a GitHub Actions build workflow and a CodeQL analysis workflow. The repository root is a conventional CMake project with a `yasio/` source directory, `tests/`, `docs/`, `examples/`, `tools/`, `certs/`, the `3rdparty/` and `1kiss/` dependency directories, a `CHANGELOG.md` and a `benchmark.md`.

Editorial conclusion

Adopt yasio if you are writing a game client and want one networking API across TCP, UDP and KCP with the packet boundary handling already done, since that is the problem the library exists to solve. Do not adopt it if your project is stuck on an older C++ standard, because the minimum is C++20 from version 4.4.0 onwards. Verify first which SSL backend you can build against, since the CMake scripts default to OpenSSL and download a prebuilt library compiled with a specific Visual Studio version, and check the C++ standard your toolchain defaults to before you plan the integration.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. simdsoft/yasio on GitHub