GameNetworkingSockets: Valve's UDP Transport Layer for Games

The gap GameNetworkingSockets fills between raw UDP and a full netcode stack

Raw UDP gives you datagrams and nothing else. You still have to decide what happens when one is lost, how to split a large message across the MTU, how to encrypt the payload, and how two players behind home routers find each other. GameNetworkingSockets is Valve's answer to that layer. The README describes it as "a basic transport layer for games", and the feature list is exactly the set of problems that sit below gameplay code.

The API is connection-oriented like TCP but message-oriented like UDP, so you send discrete messages rather than a byte stream. Messages can be larger than the underlying MTU because the protocol performs fragmentation, reassembly and retransmission for reliable messages. Both reliable and unreliable message types are supported on the same connection, which matters for games that mix state updates with occasional important events.

The audience is narrow and clear. This is a C++ library for people building real-time multiplayer games or similar low-latency applications. If your project is a web service, a file transfer tool or anything that tolerates a stream abstraction, the message-oriented API and the P2P machinery are weight you do not need.

Ack vectors, lanes and per-packet encryption inside the wire protocol

The reliability layer is the part worth reading the source for. The README points to src/steamnetworkingsockets/clientlib/SNP_WIRE_FORMAT.md and says the design is based on the ack vector model from DCCP (RFC 4340, section 11.4) and Google QUIC. Instead of a sliding window, the receiver reports the status of every packet number, and because the sender remembers which segments went into each packet, it can deduce exactly which segments need retransmission. That is a different mechanism from TCP-style cumulative acknowledgements, and it is the reason the library can retransmit selectively without head-of-line blocking across the whole connection.

Head-of-line blocking control is exposed through lanes. Multiple message streams can share one connection, and the README says you can assign strict priority values, softer weight values that control bandwidth sharing, or a combination. The entry point is ISteamNetworkingSockets::ConfigureConnectionLanes in include/steam/isteamnetworkingsockets.h. For a game with a small critical channel and a bulk channel, this is the knob that decides which one stalls when the link is congested.

Encryption is per packet: AES-GCM-256, with Curve25519 used for key exchange and certificate signatures. The README states that the shared key derivation and per-packet IV design follow the approach used by Google's QUIC protocol. Encryption is not an add-on module here; it is part of the packet format.

Peer-to-peer connectivity runs on Google WebRTC's ICE implementation for NAT traversal, and the README says you plug in your own signaling service. There is also a "symmetric connect" mode, and ISteamNetworkingMessages, an interface the README describes as designed to make it easy to port UDP-based code to P2P use cases, where each send names the recipient's address rather than using a connection handle.

Building GameNetworkingSockets and sending your first reliable message

The README does not contain build instructions. It says: "See BUILDING for more information", and the repository has BUILDING.md and BUILDING_WINDOWS_MANUAL.md at the top level, plus CMakeLists.txt and CMakePresets.json. That is where the actual steps live, and they differ by platform, so read those files rather than guessing at flags.

The repository also ships vcpkg.json and a vcpkg_ports/ directory, and the examples folder contains vcpkg_example_chat/, which suggests a vcpkg-based path to the dependencies. The plain CMake route is the other option. A typical configure step looks like this:

cmake -S . -B build
cmake --build build

What you should see is a build tree under build/ containing the library and, if examples are enabled in your configuration, the example binaries. The exact targets depend on the options in BUILDING.md, so check that file before assuming a binary name.

The first real thing to read is examples/example_chat.cpp. The README calls it a "very simple client/server program using all reliable messages over ordinary IPv4", which makes it the smallest complete picture of the API: create a socket, connect, send, receive. After that, include/steam/isteamnetworkingsockets.h is the interface you will spend most of your time in, and include/steam/steamnetworkingtypes.h holds the supporting types.

If you want P2P rather than client/server, tests/test_p2p.cpp is the reference. The README says it shows how to get two hosts to connect using P2P connectivity and doubles as an example of writing a signaling service plugin. For a runnable signaling endpoint, examples/trivial_signaling_server.py and the matching trivial_signaling_client files are in the tree.

What GameNetworkingSockets deliberately leaves to you

The README is unusually direct about the ceiling. Under "What it does not do" it lists higher level serialization of entities, delta encoding of changed state variables, and compression. Those are the responsibilities of the game layer above the transport. If you were hoping for a replication framework that decides which fields changed and packs them, this is not it, and no amount of configuration will make it one.

The distribution itself has a boundary. The README says the library has shipped on consoles, mobile platforms and non-Steam stores, and that you should contact Valve to get access to that code, because "we are not allowed to distribute it here". The public repository is the portable subset. If console support is a requirement, that is a conversation with Valve, not a build flag.

There is also a services boundary. The README notes that some features are only available on Steam, naming Steam's authentication service, signaling service and the SDR relay service, and that access to SDR on other platforms is not offered to all partners at this time. The open source library gives you the protocol and the P2P machinery; it does not give you Valve's relay network.

Finally, the naming is a real adoption hazard. The main interface is called SteamNetworkingSockets and many files carry "steam" in their names. The README addresses this head on: "Steam is not needed", and you can use the code for whatever purpose you want. Still, expect reviewers and new contributors to ask why a non-Steam project links a Steam-named library.

GameNetworkingSockets versus ENet and rolling your own reliability layer

The natural comparison is ENet, and the difference is in the reliability mechanism rather than the feature checklist. ENet is a long-standing C reliability layer over UDP with channels and a command-based protocol. GameNetworkingSockets takes the ack vector approach from DCCP and QUIC, which lets the receiver communicate the status of every packet number and lets the sender retransmit only the segments that were actually lost. The README also documents lane configuration with strict priority and weighted sharing, which is a more explicit bandwidth policy than a simple channel model.

Encryption is the second real difference. GameNetworkingSockets encrypts every packet with AES-GCM-256 and uses Curve25519 for key exchange, as part of the protocol. With a thinner library you either add a crypto layer yourself or ship plaintext on the wire.

The third difference is P2P. NAT traversal through WebRTC ICE, a pluggable signaling service and the symmetric connect mode are in the box. ENet is a client/server transport; if you want peer connectivity there, you build the discovery and hole-punching yourself.

The trade-off runs the other way too. GameNetworkingSockets is C++ and depends on WebRTC's ICE implementation for the P2P path, which is a heavier dependency tree than a small C library. If you only need reliable ordered delivery between a client and a server you control, and both ends are on the open internet or a LAN, that machinery buys you nothing.

Maintenance, licence and the cost of tracking the protocol

The repository is not archived, and the last push was on 2026-08-27. Releases are recent: v1.6.0 on 2026-06-03, v1.5.1 on 2026-05-04 and v1.5.0 on 2026-04-28. The CI badges in the README cover Ubuntu, Windows, MacOS, iOS, a soak test and Linux flavors, which tells you the platforms Valve builds on every change. None of that is a promise about your platform, but it does mean the portable code is exercised continuously.

Upgrade cost is the part teams underestimate. This is a wire protocol, so client and server must agree on it. A library upgrade that changes the protocol means old clients cannot talk to new servers unless the library keeps backward compatibility, and the README does not document a compatibility policy or a rollback procedure. Plan for the fact that your players' installed clients are the constraint, not your build pipeline.

The licence is BSD-3-Clause. That is permissive: you can use the code in closed-source products, and there is no copyleft obligation to publish your game's source. The usual obligations of a BSD-style licence still apply, and the repository has a LICENSE file and a SECURITY.md worth reading. This is a description of the licence text, not legal advice; if your organisation has a policy on third-party code, run it through that process.

One more cost: the language bindings listed in the README are third party. C# has ValveSockets-CSharp and Facepunch.Steamworks, Go has nielsAD/gns and Rust has hussein-aitlahcen/gns-rs. If your team is not writing C++, you are depending on a binding that Valve does not maintain, and its release cadence will not match the core library's.

Editorial conclusion

Adopt GameNetworkingSockets if you are writing a real-time multiplayer game in C++ and want a connection-oriented, message-oriented transport with encryption and P2P connectivity without building the reliability layer yourself. Do not adopt it if you need entity replication, delta encoding or compression, or if a plain TCP or UDP socket already covers your traffic. Before committing, verify the build path for your platform in BUILDING.md, check whether your target consoles are covered by the code that is not distributed here, and confirm that your signaling service can be plugged into the P2P flow described in README_P2P.md.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. Releases
5. ValveSoftware/GameNetworkingSockets on GitHub