Skip to content

/ GameNetworkingSockets

Reliable & unreliable messages over UDP. Robust message fragmentation & reassembly. Encryption.
reliable-messages networking game-development realtime-messaging
C++ C CMake Meson Shell Python Other
  1. C++ 74.5%
  2. C 21.7%
  3. CMake 2.2%
  4. Meson 0.5%
  5. Shell 0.5%
  6. Python 0.4%
  7. Other 0.2%
Branch: master
Find file
Clone or download

Clone with HTTPS

Use Git or checkout with SVN using the web URL.

Open in Desktop Download ZIP

Latest commit

@fletcherdvalve
fletcherdvalve Fix inverted logic 
Revert part of 705bc0e, which managed to
refactor code without improving it in any way AND introduce an inverted
logic bug.

This causes us to spam panic keepalives when we are timing out much
faster than intended.

Also, when deciding if it is time to take action, use inclusive comparisons.
If we ask to wake up at a certain time, and we do actually manage to wake up
at that exact time, then we should take action.  This is probably extremely
rare, however in an environment with limited timer precision, it could be
more common.
Latest commit 8f60b0e May 30, 2020

Files

Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.travis travis/install-archlinux: do full update before installing dependencies May 1, 2020
cmake implement libsodium support Jan 21, 2020
examples Added "poll group" interface. Dec 5, 2019
include Add ICE failure codes May 28, 2020
src Fix inverted logic May 30, 2020
tests Move 25519 crypto to a separate header. Feb 5, 2020
.gitignore Ignore more build directories. Jan 30, 2019
.travis-run-local.py travis-run-local: add options to filter down to specific architecture… Jan 21, 2020
.travis.yml travis: disable fedora:rawhide for now Feb 28, 2020
BUILDING.md Fix typo May 5, 2020
CMakeLists.txt add options for building included tests and examples May 6, 2020
GameNetworkingSockets.code-workspace code-workspace: replace workspaceRoot with workspaceFolder Jan 11, 2019
LICENSE Placeholder README and updated license. Mar 23, 2018
README.md Update README regarding P2P support May 20, 2020
README_P2P.md Fix typos, etc. May 27, 2020
meson.build meson: add -Duse_crypto and -Duse_crypto25519 options Jan 21, 2020
meson_options.txt implement libsodium support Jan 21, 2020

README.md

GameNetworkingSockets Build Status

GameNetworkingSockets is a basic transport layer for games. The features are:

  • Connection-oriented API (like TCP)
  • ... but message-oriented (like UDP), not stream-oriented.
  • Supports both reliable and unreliable message types
  • Messages can be larger than underlying MTU. The protocol performs fragmentation, reassembly, and retransmission for reliable messages.
  • A reliability layer significantly more sophisticated than a basic TCP-style sliding window. It is based on the "ack vector" model from DCCP (RFC 4340, section 11.4) and Google QUIC and discussed in the context of games by Glenn Fiedler. The basic idea is for the receiver to efficiently communicate to the sender the status of every packet number (whether or not a packet was received with that number). By remembering which segments were sent in each packet, the sender can deduce which segments need to be retransmitted.
  • Encryption. AES-GCM-256 per packet, Curve25519 for key exchange and cert signatures. The details for shared key derivation and per-packet IV are based on the design used by Google's QUIC protocol.
  • Tools for simulating loss and detailed stats measurement
  • IPv6
  • Peer-to-peer connections. Read this for more info about what's required.

What it does not do:

  • Higher level serialization of entities, delta encoding of changed state variables, etc
  • Compression

Why do I see "Steam" everywhere?

The main interface class is named SteamNetworkingSockets, and many files have "steam" in their name. But Steam is not needed. If you don't make games or aren't on Steam, feel free to use this code for whatever purpose you want.

The reason for "Steam" in the names is that this provides a subset of the functionality of the API with the same name in the Steamworks SDK. Our main reason for releasing this code is so that developers won't have any hesitation coding to the API in the Steamworks SDK. On Steam, you will link against the Steamworks version, and you can get the additional features there (access to the relay network). And on other platforms, you can use this version, which has the same names for everything, the same semantics, the same behavioural quirks. We want you to take maximum advantage of the features in the Steamworks version, and that won't happen if the Steam code is a weird "wart" that's hidden behind #ifdef STEAM.

The desire to match the Steamworks SDK also explains a somewhat anachronistic coding style and weird directory layout. This project is kept in sync with the Steam code here at Valve. When we extracted the code from the much larger codebase, we had to do some relatively gross hackery. The files in folders named tier0, tier1, vstdlib, common, etc have especially suffered trauma. Also if you see code that appears to have unnecessary layers of abstraction, it's probably because those layers are needed to support relayed connection types or some part of the Steamworks SDK.

Building

See BUILDING for more information.

Language bindings

The library was written in C++, but there is also a plain C interface to facilitate binding to other languages.

Third party language bindings:

Roadmap

Here are some large features that we expect to add to a future release:

Bandwidth estimation

An earlier version of this code implemented TCP-friendly rate control (RFC 5348). But as part of the reliability layer rewrite, bandwidth estimation has been temporarily broken, and a fixed (configurable) rate is used. It's not clear if it's worth the complexity of implementation and testing to get sender-calculated TCP-friendly rate control implemented, or a simpler method would do just as good. Whatever method we use, needs to work even if the app code inspects the state and decides not to send a message. In this case, the bandwidth estimation logic might perceive that the channel is not "data-limited", when it essentially is. We could add an entry point to allow the application to express this, but this is getting complicated, making it more difficult for app code to do the right thing. It'd be better if it mostly "just worked" when app code does the simple thing.

P2P improvements

The peer-to-peer support needs several improvements.

You can’t perform that action at this time.