Reliable & unreliable messages over UDP. Robust message fragmentation & reassembly. P2P networking / NAT traversal. Encryption.

Overview

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 packet latency/loss, and detailed stats measurement
  • IPv6 support
  • Peer-to-peer networking:
    • NAT traversal through google WebRTC's ICE implementation.
    • Plug in your own signaling service.
    • Unique "symmetric connect" mode.
    • ISteamNetworkingMessages is an interface designed to make it easy to port UDP-based code to P2P use cases. (By UDP-based, we mean non-connection-oriented code, where each time you send a packet, you specify the recipient's address.)
    • See README_P2P.md for more info

What it does not do:

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

Quick API overview

To get an idea of what the API is like, here are a few things to check out:

  • The include/steam folder has the public API headers.
  • The Steamworks SDK documentation offers web-based documentation for these APIs. Note that some features are only available on Steam, such as Steam's authentication service, signaling service, and the SDR relay service.
  • Look at these examples:
    • example_chat.cpp. Very simple client/server program using all reliable messages over ordinary IPv4.
    • test_p2p.cpp. Shows how to get two hosts to connect to each other using P2P connectivity. Also an example of how to write a signaling service plugin.

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:

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.

Security

Did you find a security vulnerability? Please inform us responsibly; you may be eligible for a bug bounty. See the security policy for more information.

Comments
  • May we please have a C# wrapper?

    May we please have a C# wrapper?

    I want to start things off right and introduce myself. I am MostHated. I would like to request, please, that a C# wrapper be created so that us Unity users who are not the most amazing programmers in the world can still enjoy all the amazing Valve goodness.

    help wanted 
    opened by MostHated 52
  • Timeout on connect while retrieving routes/connecting

    Timeout on connect while retrieving routes/connecting

    Hi,

    Apologies if this isn't the correct place for a report (I'm using SteamNetworkingMessages from the Steamworks SDK).

    I've been working on a small shim that can replace the older SteamNetworking API for legacy games and I've run into an issue setting up a symmetric connection between two clients.

    For the handshake, each client initiates a connection to each other (there's a matchmaking server instructing them to start sending packets). This appears to start fine but quickly results in a timeout shown below:

    client 1

    [2021-05-19 01:22:19.569] [modengine] [warning] Steam: Messages session steamid:76561198216541595: created
    [2021-05-19 01:22:19.570] [modengine] [warning] Steam: [#3971098875 P2P steamid:76561198216541595] Our cert expires in 165312 seconds.
    [2021-05-19 01:22:19.572] [modengine] [warning] Steam: [#3971098875 P2P steamid:76561198216541595] Created connection for messages session
    [2021-05-19 01:22:20.317] [modengine] [warning] Steam: [#3971098875 P2P steamid:76561198216541595] Received P2P routes ack for revision 0 (latest revision is 1).
    [2021-05-19 01:22:20.857] [modengine] [warning] Steam: [#3971098875 P2P steamid:76561198216541595] Received P2P routes ack for revision 0 (latest revision is 1).
    [2021-05-19 01:22:21.314] [modengine] [warning] Steam: [#3971098875 P2P steamid:76561198216541595] Received P2P routes ack for revision 0 (latest revision is 1).
    [2021-05-19 01:22:21.808] [modengine] [warning] Steam: [#3971098875 P2P steamid:76561198216541595] Received P2P routes ack for revision 0 (latest revision is 1).
    ... snip ...
    [2021-05-19 01:22:29.570] [modengine] [warning] Steam: [#3971098875 P2P steamid:76561198216541595] problem detected locally (5003): App did not respond to Messages session request in time, discarding.
    

    client 2

    [2021-05-19 01:22:22.236] [modengine] [warning] Steam: Destroying relay 'sof#5 (139.45.193.10:27019)' because initial_ping_timeout
    [2021-05-19 01:22:22.237] [modengine] [warning] Steam: Destroying relay 'eat#38 (155.133.235.18:27052)' because initial_ping_timeout
    [2021-05-19 01:22:24.840] [modengine] [warning] Steam: Destroying relay 'sof#2 (139.45.193.10:27016)' because initial_ping_timeout
    [2021-05-19 01:22:24.841] [modengine] [warning] Steam: Destroying relay 'eat#58 (155.133.235.34:27034)' because initial_ping_timeout
    [2021-05-19 01:22:27.441] [modengine] [warning] Steam: Destroying relay 'sof#1 (139.45.193.10:27015)' because initial_ping_timeout
    [2021-05-19 01:22:27.442] [modengine] [warning] Steam: Destroying relay 'eat#37 (155.133.235.18:27051)' because initial_ping_timeout
    [2021-05-19 01:22:29.565] [modengine] [warning] Steam: [#3644006119 P2P steamid:76561199104113068] problem detected locally (5003): Timed out attempting to connect
    [2021-05-19 01:22:29.567] [modengine] [warning] Steam: [#3644006119 P2P steamid:76561199104113068] messages session problem detected locally: 5003 Timed out attempting to connect
    

    For some additional context, the clients send each other packets at approximately the same time before either has set up a session: client 1

    [2021-05-19 01:22:19.562] [modengine] [info] Sending packet to 11000010f46759b
    

    client 2

    [2021-05-19 01:22:19.557] [modengine] [info] Sending packet to 1100001442db9ac
    

    I have checked to see if the issue is simply that I'm not responding with AcceptSessionWithUser(...) when a messages session request comes in, but I've added some logging here and that callback is never invoked: https://github.com/garyttierney/ds3patch/blob/feat/ci/src/modengine_extension/p2p_session_manager.cpp#L106-L108

    The only thing that really stands out to me is the ACKs for revision 0 of the routes while the latest is revision 1, but I'm not sure if that's of any importance and have little experience with the GameNetworkingSockets code so may just be a red herring. I'm also looking at the code here: https://github.com/ValveSoftware/GameNetworkingSockets/blob/f98cd32f62877d31a3fe27fc91578e13f4f795c9/src/steamnetworkingsockets/clientlib/steamnetworkingsockets_connections.cpp#L2975 and there's a lot of logging that isn't present in my logs (filtering at k_ESteamNetworkingSocketsDebugOutputType_Everything), so maybe it's something more fundamentally wrong with how I'm setting this up.

    bug Need Retest 
    opened by garyttierney 22
  • Add versioning

    Add versioning

    Currently it is not clear when an API breaks or a feature is added. Tracking versions and releases (perhaps via something similar to GitFlow?) would make it much easier to integrate this software in another project without worries about if a change will break things out from under it.

    opened by elizagamedev 19
  • Excessive lock contention

    Excessive lock contention

    Right now thread-safety achieved via the excessive amount of locks, this leads to performance degradation and it's killing scalability. While locks aren't slow, lock contention is. Practical solution: remove any shared states/data, and re-design the core using inter-thread message-based communication without any contention. This approach scales perfectly for traditional networking on top of UDP sockets, Disruptor works best for this.

    Additional information regarding multi-threading you can find here.

    enhancement 
    opened by nxrighthere 18
  • compilation fails with WebRTC on windows using vcpkg

    compilation fails with WebRTC on windows using vcpkg

    it seems the current head fails during compilation, if i want it with WebRTC. the deafult config (without WebRTC) compiles flawlessly.

    log file:

    install-x64-windows-dbg-out.log

    error messages:

    ..\..\..\..\src\external\abseil\absl\hash\internal\hash.cc(51): error C2491: 'absl::lts_2020_02_25::hash_internal::CityHashState::kSeed': definition of dllimport static data member not allowed 
    ..\..\..\..\src\external\abseil\absl\numeric\int128.cc(28): error C2491: 'absl::lts_2020_02_25::kuint128max': definition of dllimport data not allowed 
    
    

    platform: win10 x64 (tried on win7 x64 too with the same result) compiler: visual studio 2019 (command prompt) command: .\vcpkg\vcpkg --overlay-ports=vcpkg_ports install gamenetworkingsockets --triplet x64-windows

    edit: i tried to modify ABSL_DLL macro to make it empty, but then it fails during installation with the error:

    `CMake Error at scripts/cmake/vcpkg_fixup_cmake_targets.cmake:72 (message):

    'C:/!/GameNetworkingSockets/vcpkg/packages/gamenetworkingsockets_x64-windows/debug/lib/cmake/GameNetworkingSockets' does not exist.`

    opened by anchor76 17
  • steamclient.dll is using broken version of openssl libs

    steamclient.dll is using broken version of openssl libs

    We just rolled out SteamNetworkingSockets as the new default for Unturned (AppId 304930) and it is working well for most players. Unfortunately after ConnectByIPAddress a minority of clients are entering the ProblemDetectedLocally state with error code 4003 and debug message:

    "Bad cert: CA key ### is not known to us" (e.g. key 18220590129359924542)

    Before ConnectByIPAddress we wait for the k_ESteamNetworkingAvailability_Current availability callback, so as far as I can tell we should be ready for authenticated connection. There are other players connected to these same servers, so I assume the certs were known to them.

    Are we missing a step to have the proper certs before connecting? If you can share any thoughts that would be greatly appreciated.

    Kind regards, Nelson

    steamworks 
    opened by SDGNelson 15
  • Increasing throughput of a connection

    Increasing throughput of a connection

    Hello,

    On a localhost I get around 1MB/s with the default config options. I am trying to reach 10MB/s.

    So far I have only found the SendRateMax option that could be limiting, increasing it to a much larger value gets me to 1.2MB/s. Changing the send buffer size doesn't seem to help. Is this a limitation due to the way the protocol is designed or am I missing something?

    Thanks, Max

    Need Retest 
    opened by yamashi 14
  • Maybe an odd question, but, is there a keepalive time for a game server?

    Maybe an odd question, but, is there a keepalive time for a game server?

    We have a game servers consisting of lobby and matches. They both use GNS. Anyway, we want our lobby servers keep alive as possible as we can. So it is like ~150 client connections per few minutes per lobby server connecting, do some stuff and disconnect. Standart lobby server/s. No big deal as they are many. They are dockerized apps. Problem is literally this; after 15 hours of a lobby server is initialized and run, it disconnects all of its clients and voila, no connections. We did many tests and this 15 hours is quite common instead of how many connections established or not in that interval. Do we have any config to set a game server's life time or something like that? Thank you very much.

    opened by Levendo 14
  • Windows CMAKE error: Cannot find EVP_MD_CTX_free in OpenSSL headers/libs

    Windows CMAKE error: Cannot find EVP_MD_CTX_free in OpenSSL headers/libs

    I'm trying to build the library for use in a personal game project (pure C++ using SDL. It's a thing). Using the instructions, the CMake ran into an error:

    -- OPENSSL_INCLUDE_DIR = C:/Program Files/OpenSSL-Win64/include/openssl
    CMake Error at CMakeLists.txt:100 (message):
      Cannot find EVP_MD_CTX_free in OpenSSL headers/libs for the target
      architecture.  Check that you're using OpenSSL 1.1.0 or later.
    

    I am using the 64-bit version of OpenSSL 1.1.1g and the Command Prompt for Visual Studio 2019.

    CMakerError.log:

    Determining if the EVP_MD_CTX_free exist failed with the following output:
    Change Dir: C:/dev/GameNetworkingSockets/build/CMakeFiles/CMakeTmp
    
    Run Build Command(s):C:/PROGRA~2/MICROS~2/2019/COMMUN~1/Common7/IDE/COMMON~1/MICROS~1/CMake/Ninja/ninja.exe cmTC_8f91b && [1/2] Building C object CMakeFiles/cmTC_8f91b.dir/CheckSymbolExists.c.obj
    
    [2/2] Linking C executable cmTC_8f91b.exe
    
    FAILED: cmTC_8f91b.exe 
    
    cmd.exe /C "cd . && C:\MinGW\bin\gcc.exe    CMakeFiles/cmTC_8f91b.dir/CheckSymbolExists.c.obj  -o cmTC_8f91b.exe -Wl,--out-implib,libcmTC_8f91b.dll.a -Wl,--major-image-version,0,--minor-image-version,0  "C:/Program Files/OpenSSL-Win64/lib/libcrypto.lib"  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
    
    c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: CMakeFiles/cmTC_8f91b.dir/CheckSymbolExists.c.obj:CheckSymbolExists.c:(.text+0x12): undefined reference to `EVP_MD_CTX_free'
    
    
    File C:/dev/GameNetworkingSockets/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
    /* */
    #include <openssl/evp.h>
    
    int main(int argc, char** argv)
    {
      (void)argv;
    #ifndef EVP_MD_CTX_free
      return ((int*)(&EVP_MD_CTX_free))[argc];
    #else
      (void)argc;
      return 0;
    #endif
    }
    

    C:/dev/GameNetworkingSockets/build/CMakeFiles/CMakeTmp is empty. I checked C:\Program Files\OpenSSL-Win64\include\openssl and evp.h DOES exist, but with the following setup:

    void EVP_MD_CTX_free(EVP_MD_CTX *ctx);
    # define EVP_MD_CTX_destroy(ctx) EVP_MD_CTX_free((ctx))
    

    EVP_MD_CTX_FREE is a function, not a macro. Is this expected? Should I be worried about my OpenSSL version? hmm.

    opened by kingoftheconnors 13
  • ENet like channels?

    ENet like channels?

    Does GNS provides ENet like channels? This is useful for the game logic and user-voice packets distinction to take more advantage of bandwidth through single connection.

    enhancement 
    opened by moien007 12
  • Compiling under Windows with MinGW

    Compiling under Windows with MinGW

    Does someone have success? The compiler throws a lot of errors. I'm currently trying to fix them, but there are too many. The code itself in some places is questionable like here and here.

    opened by nxrighthere 12
  • test_p2p is not working when trivial_signaling_server is remote.

    test_p2p is not working when trivial_signaling_server is remote.

    Many months ago with older code I had followed the P2P example and had successfully integrated peer-to-peer connections in my work. I have updated to recent code (yesterday) and in both my code and test_p2p I cannot connect through a trivial_signaling_server hosted remotely. Here is the output from test_p2p run on different computers as server/client (not even peer-to-peer yet):

    C:\install>test_p2p.exe --identity-local str:Fred --signaling-server [redacted].net:10000 --server 0.002538 Initialized low level socket/threading support. 0.005875 Creating listen socket, local virtual port 0 9.456763 Creating signaling session for peer 'str:Dan' 9.456966 [#2557448975 P2P str:Dan vport 0] Accepting 9.458360 [#2557448975 P2P str:Dan vport 0] Relay candidates enabled by P2P_Transport_ICE_Enable, but P2P_TURN_ServerList is empty 9.479485 Got remote candidate 'candidate:47202818 0 udp 2130706431 fe80::d06d:6887:6e67:ca56 49666 typ host' 9.479686 Got a rendezvous candidate at "[fe80::d06d:6887:6e67:ca56]:49666" 9.480165 Got remote candidate 'candidate:53002755 0 udp 2130706175 fe80::b814:8dcd:bb9b:78de 49667 typ host' 9.480587 Got a rendezvous candidate at "[fe80::b814:8dcd:bb9b:78de]:49667" 9.480950 Got remote candidate 'candidate:55689732 0 udp 2130705919 fe80::a8dd:69bc:b5b9:65a7 49668 typ host' 9.481305 Got a rendezvous candidate at "[fe80::a8dd:69bc:b5b9:65a7]:49668" 9.481883 Got remote candidate 'candidate:34685445 0 udp 2130705663 10.242.162.133 49669 typ host' 9.482774 Got a rendezvous candidate at "10.242.162.133:49669" 9.483069 Got remote candidate 'candidate:24887814 0 udp 2130705407 2601:643:4301:ffc0::3152 49670 typ host' 9.483386 Got a rendezvous candidate at "[2601:643:4301:ffc0::3152]:49670" 9.483690 Got remote candidate 'candidate:61096455 0 udp 2130705151 fe80::f9f6:fef0:10ec:a14f 49671 typ host' 9.483983 Got a rendezvous candidate at "[fe80::f9f6:fef0:10ec:a14f]:49671" 9.484274 Got remote candidate 'candidate:23872008 0 udp 2130704895 10.0.0.207 49672 typ host' 9.484563 Got a rendezvous candidate at "10.0.0.207:49672" 9.484849 Got remote candidate 'candidate:41861641 0 udp 2130704639 fe80::6ce8:1ee0:6057:1c59 49673 typ host' 9.485147 Got a rendezvous candidate at "[fe80::6ce8:1ee0:6057:1c59]:49673" 9.485473 SteamNetworkingSockets lock held for 27.6ms. (Performance warning.) AcceptConnection,BFinishCryptoHandshake,FinalizeLocalCrypto,P2P::AcceptConnection,CSteamNetworkConnectionP2P::CheckInitICE,CConnectionTransportP2PICE_Valve::Init,CConnectionTransportP2PICE_Valve::RecvRendezvous(x9) This is usually a symptom of a general performance problem such as thread starvation. 9.485776 Waited 6.9ms for SteamNetworkingSockets lock [ServiceThread] 9.488563 [#2557448975 P2P str:Dan vport 0] finding route 9.491560 Got remote candidate 'candidate:57740655 0 udp 1677721855 73.158.93.251 49672 typ srflx' 9.491619 Got a rendezvous candidate at "73.158.93.251:49672" 9.644941 WSASendTo [2601:643:4301:ffc0::3152]:49670 failed, returned -1, last error=0x2741 The requested address is not valid in its context. 9.846370 WSASendTo [2601:643:4301:ffc0::3152]:49670 failed, returned -1, last error=0x2741 The requested address is not valid in its context. 9.946943 WSASendTo [2601:643:4301:ffc0::3152]:49670 failed, returned -1, last error=0x2741 The requested address is not valid in its context. 9.997818 WSASendTo [2601:643:4301:ffc0::3152]:49670 failed, returned -1, last error=0x2741 The requested address is not valid in its context. 10.048949 WSASendTo [2601:643:4301:ffc0::3152]:49670 failed, returned -1, last error=0x2741 The requested address is not valid in its context. 10.098991 WSASendTo [2601:643:4301:ffc0::3152]:49670 failed, returned -1, last error=0x2741 The requested address is not valid in its context. 19.459016 [#2557448975 P2P str:Dan vport 0] problem detected locally (5008): Timed out attempting to negotiate rendezvous 19.698714 [#2557448975 P2P str:Dan vport 0] Guessed ICE failure to be 5001: Never received any remote candidates 19.700211 SteamNetworkingSockets lock held for 241.3ms. (Performance warning.) ServiceThread,CSteamNetworkConnectionBase::Think(x2),P2P::SetRendezvousCommonFieldsAndSendSignal,P2PTransportThink,CSteamNetworkingICESession::Think,CSteamNetworkingICESession::Think_TestPeerConnectivity This is usually a symptom of a general performance problem such as thread starvation. 19.700720 [#2557448975 P2P str:Dan vport 0] problem detected locally, reason 5008: Timed out attempting to negotiate rendezvous 19.701350 Shutting down low level socket/threading support.

    C:\install>test_p2p --identity-local str:Dan --identity-remote str:Fred --signaling-server [redacted].net:10000 --client 0.003564 Initialized low level socket/threading support. 0.093110 Connecting to 'str:Fred', virtual port 0, from local virtual port 0. 0.093347 Creating signaling session for peer 'str:Fred' 0.097802 [#2868680494 P2P str:Fred vport 0] Relay candidates enabled by P2P_Transport_ICE_Enable, but P2P_TURN_ServerList is empty 0.131627 SteamNetworkingSockets lock held for 36.5ms. (Performance warning.) ConnectP2PCustomSignaling,Base::BInitConnection,GetIdentity,FinalizeLocalCrypto,CSteamNetworkConnectionP2P::CheckInitICE,CConnectionTransportP2PICE_Valve::Init This is usually a symptom of a general performance problem such as thread starvation. 0.132033 Sending msg 'Greetings!' 0.132105 Waited 2.4ms for SteamNetworkingSockets lock [ServiceThread] 0.135526 [#2868680494 P2P str:Fred vport 0] Entered connecting state 0.195420 [#2868680494 P2P str:Fred vport 0] Sending P2P ConnectRequest 0.238255 [#2868680494 P2P str:Fred vport 0] Sending P2P ConnectRequest 0.448491 Got remote candidate 'candidate:47374689 0 udp 2130706431 fe80::a8ae:3024:ad51:cbb3 57697 typ host' 0.448596 Got a rendezvous candidate at "[fe80::a8ae:3024:ad51:cbb3]:57697" 0.449386 Got remote candidate 'candidate:19784034 0 udp 2130706175 10.0.0.82 57698 typ host' 0.449680 Got a rendezvous candidate at "10.0.0.82:57698" 0.449956 Got remote candidate 'candidate:36036963 0 udp 2130705919 fe80::2d28:5126:bc73:b41d 57699 typ host' 0.450239 Got a rendezvous candidate at "[fe80::2d28:5126:bc73:b41d]:57699" 0.450533 Got remote candidate 'candidate:37839204 0 udp 2130705663 fe80::24e4:a332:7c89:1908 57700 typ host' 0.450826 Got a rendezvous candidate at "[fe80::24e4:a332:7c89:1908]:57700" 0.451131 Got remote candidate 'candidate:44654949 0 udp 2130705407 fe80::45a0:6447:6fd5:55aa 57701 typ host' 0.451411 Got a rendezvous candidate at "[fe80::45a0:6447:6fd5:55aa]:57701" 0.451690 Got remote candidate 'candidate:33939814 0 udp 2130705151 10.242.174.98 57702 typ host' 0.451930 Got a rendezvous candidate at "10.242.174.98:57702" 0.452169 Got remote candidate 'candidate:48685415 0 udp 2130704895 fe80::10ea:99a0:c327:df52 57703 typ host' 0.452409 Got a rendezvous candidate at "[fe80::10ea:99a0:c327:df52]:57703" 0.452637 Got remote candidate 'candidate:54878568 0 udp 2130704639 fe80::edcc:5f88:c546:e080 57704 typ host' 0.452847 Got a rendezvous candidate at "[fe80::edcc:5f88:c546:e080]:57704" 0.453078 [#2868680494 P2P str:Fred vport 0] Received ConnectOK in P2P Rendezvous. 0.453751 [#2868680494 P2P str:Fred vport 0] finding route 0.453794 SteamNetworkingSockets lock held for 5.5ms. (Performance warning.) ReceivedP2PCustomSignal,InternalReceivedP2PSignal,P2P::ProcessSignal,CConnectionTransportP2PICE_Valve::RecvRendezvous(x9),BRecvCryptoHandshake,BFinishCryptoHandshake(x2) This is usually a symptom of a general performance problem such as thread starvation. 0.454065 [#2868680494 P2P str:Fred vport 0] finding route 0.454068 Waited 5.6ms for SteamNetworkingSockets lock [ServiceThread] 10.448574 [#2868680494 P2P str:Fred vport 0] problem detected locally (5008): Timed out attempting to negotiate rendezvous 10.448803 [#2868680494 P2P str:Fred vport 0] Guessed ICE failure to be 5001: Never received any remote candidates 10.449642 [#2868680494 P2P str:Fred vport 0] problem detected locally, reason 5008: Timed out attempting to negotiate rendezvous 10.449734 Shutting down low level socket/threading support.

    opened by fred4d 4
  • IGameServersService Interface

    IGameServersService Interface

    Interface: https://partner.steamgames.com/doc/webapi/IGameServersService wiki: https://developer.valvesoftware.com/wiki/Master_Server_Query_Protocol Request URL: https://api.steampowered.com/IGameServersService/GetServerList/v1/?key=SteamWebAPIKey&limit=50000&filter=\gamedir\csgo\nand\1\gametype\valve_ds\dedicated\1

    There is no information about working with "CLOUD_SERVER_CONTROLLER" in the documentation. Why is this scaling devkit not described?

    Is this some kind of new devkit? since I see that it is duplicated more than 10,000 times having the same information, but in partner.steamgames.com I can't find any information

    opened by PhilCarterL 0
  • NULL reference crash.

    NULL reference crash.

    It is possible for nullptr to be returned from:

    IBoundUDPSocket *CSharedSocket::AddRemoteHost( const netadr_t &adrRemote, CRecvPacketCallback callback )

    This nullptr will get assigned to pRequest->m_pSocket at least in:

    CSteamNetworkingSocketsSTUNRequest *CSteamNetworkingSocketsSTUNRequest::SendBindRequest CSteamNetworkingSocketsSTUNRequest *CSteamNetworkingSocketsSTUNRequest::CreatePeerConnectivityCheckRequest

    Subsequent dereferences of m_pSocket will naturally crash.

    bug 
    opened by fred4d 1
  • Can't do unauthenticated UDP connections

    Can't do unauthenticated UDP connections

    I'm trying to get unauthenticated UDP connections to works and afaict it should be possible to have a direct connection without logging in to steam or any internet access as long as AllowWithoutAuth is set. Correct?

    I don't get any immediate error, but the server (which called CreateListenSocketIP) is continuously getting the error "We don't know our local identity." when trying to accept the incoming connection. I looked a bit at the code and I suspect that while the connecting client sets the local identity here, that part seems missing for the server?

    I'm using the Steamworks SDK, not the open source version if it makes any difference.

    steamworks 
    opened by maxha651 5
  • P2P test in symmetric mode not working

    P2P test in symmetric mode not working

    The first peer trying to connect gets this error after the second peer tries to connect:

    src\steamnetworkingsockets\clientlib\../steamnetworkingsockets_internal.h(767): Assertion Failed: !IsLocked()
    Assertion failed: !"TEST FAILED", file GameNetworkingSockets\tests\test_common.cpp, line 46
    

    Second peer still trying to connect while first peer crash

    i get this error in current branch and release versions v1.4.1 and v1.4.0, but works fine in v1.3.0

    Steps to reproduce: Just execute test_p2p.py and will fail in symmetric mode Im using WebRTC enabled.

    opened by rafadsm 1
Releases(v1.4.1)
  • v1.4.1(Jun 16, 2022)

    Added a native ICE client, so P2P can be done without WebRTC. This client is beta and is not enabled by default, unless WebRTC support is disabled. The client does not currently support TURN.

    Improvements and bugfixes:

    • Fix protocol bug in malicious sender protection, that could cause asserts and possibly dropped reliable messages if packet loss and latency were both extremely high.
    • Polling will now use epoll on supported platforms (e.g. linux).
    • IPv6 parsing now supports dotted-decimal-style IPv4-mapped IPv6 addresses, e.g. ::ffff:123.45.67.89
    • Fix deadlock if API calls were made from custom P2P callbacks that needed to lookup a connection by handle
    • Public headers no longer #define POSIX, which conflicts with other libraries
    • Improvements to platform detection and compatibility on various console platforms

    No public interfaces were changed

    Source code(tar.gz)
    Source code(zip)
  • v1.4.0(Jan 27, 2022)

    Version 1.4.0 adds support for multiple lanes, improves compliance with vcpkg best practices, and has numerous smaller bugfixes and improvements.

    This brings the library in sync with the Steamworks SDK version 153a.

    Multi-lane support

    "Lanes" can be used to control head-of-line blocking behaviour. You can control the priority level of each lane and how bandwidth should be shared between different lanes.

    Lanes are similar to what QUIC calls "streams", and what other networking APIs call "channels".

    See ISteamNetworkingSockets::ConfigureConnectionLanes for details.

    Misc bugfixes / improvements

    • Fixed bug setting the connection userdata via the config var k_ESteamNetworkingConfig_ConnectionUserData, which is necessary when setting it at connection creation.
    • Simplified iteration of configuration values and controlling when to list "dev" values.
    • Added configuration values to configure TURN servers for use by WebRTC
    • Improved handling of closing connections in the linger state that did not need to linger.
    • Attempt to clean up connections on library shutdown that were left open or in the linger state.
    • Added several more tests
    • You can now build the cert tool by passing -DBUILD_TOOLS=ON to cmake
    • Improved cmake files, manifests, and build instructions to improve compliance with vcpkg best practices. (Some work still remains in this area. If you are a cmake/vcpkg expert, please help!)
    • Added a test/example project that shows how to pull in this library using vcpkg, without fetching or compiling the code directly.
    • Removed a bunch of declarations for Steam internal things from the headers
    • Added a CI build for windows on github

    Other changes

    • The "FakeIP" framework was added to the Steamworks SDK. That feature requires Steam backend support and is not supported in this opensource code, but the declarations are present in the header.
    • GetQuickConnectionStatus renamed to GetConnectionRealTimeStatus and now can return information about the status of each outbound lane. SteamNetworkingQuickConnectionStatus was also renamed to SteamNetConnectionRealTimeStatus_t.
    Source code(tar.gz)
    Source code(zip)
  • v1.3.0(May 30, 2021)

    Major changes

    Performance improvements

    Implemented a fine-grained locking strategy to greatly reduce lock contention, especially if API calls are made from multiple threads. (See issue #50.)

    Added ISteamNetworkingMessages

    This interface is primarily useful for porting existing code that expects to be able to make ad-hoc sendto/recvfrom calls to arbitrary addresses, and does not consistently use the abstraction of a "connection".

    Other improvements

    • Header files are now compatible with Steamworks SDK headers. You can easily switch between using the Steamworks SDK and a standalone library for the networking interfaces in this library, even making the determination at runtime.
    • Added a mechanism to customize (most) memory allocations.
    • Numerous bugfixes related to P2P and ICE

    Compatibility

    Some interfaces were renamed related to custom P2P signaling. Otherwise there were no major API-breaking changes. This update is compatible with the Steamworks SDK 1.51 release.

    Source code(tar.gz)
    Source code(zip)
  • v1.2.0(Sep 4, 2020)

    • Added support for peer-to-peer connections.
      • NAT-punched connections, using google webrtc's ICE implementation.
      • Plugin architecture for signaling service.
      • Symmetric connect mode
      • For full details, see README_P2P.md
    • Reworked callback mechanism, improving compatibility with Steamworks version.
    • Easier Windows configuration using vcpkg
    • Numerous bugfixes, etc.

    This update corresponds to the Steamworks SDK 1.50 release.

    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Feb 28, 2020)

    Changes from v1.0:

    • Added poll groups
    • Added method to send multiple messages in a single API call without copying the message payload
    • Added methods to set options at socket creation time, or set multiple options atomically
    • Reworked flat interface
    • Libsodium support
    • Numerous bugfixes, etc.

    This update corresponds to the Steamworks SDK 1.48 release.

    Source code(tar.gz)
    Source code(zip)
  • 1.0.0(Mar 14, 2019)

Owner
Valve Software
Valve Software
ENet reliable UDP networking library

Please visit the ENet homepage at http://enet.bespin.org for installation and usage instructions. If you obtained this package from github, the quick

Lee Salzman 2.2k Oct 2, 2022
Simple and small reliable UDP networking library for games

libquicknet Simple and small reliable UDP networking library for games ❗ libquicknet is under development and not suitable for production code ❗ The m

null 23 May 12, 2022
Data-oriented networking playground for the reliable UDP transports

NetDynamics is a data-oriented networking playground for the reliable UDP transports. The application was created for stress testing and debugging a p

Stanislav Denisov 91 Aug 28, 2022
Simple local P2P chat on UDP sockets

Local P2P Chat This is a fully decentralized chat. To communicate, simply run it on computers in a single local network (using one port). All messages

Anton Khalitov 17 Sep 7, 2022
Mongoose Embedded Web Server Library - a multi-protocol embedded networking library with TCP/UDP, HTTP, WebSocket, MQTT built-in protocols, async DNS resolver, and non-blocking API.

Mongoose - Embedded Web Server / Embedded Networking Library Mongoose is a networking library for C/C++. It implements event-driven non-blocking APIs

Cesanta Software 8.8k Sep 28, 2022
Portable, single-file, protocol-agnostic TCP and UDP socket wrapper, primarily for game networking

Documentation This is a header-only library, as such most of its functional documentation is contained within the "header section" of the source code

null 65 Aug 29, 2022
A simple C library for sending messages over the lightning network

A simple C library for sending messages over the lightning network

William Casarin 31 Sep 13, 2022
QuantumGate is a peer-to-peer (P2P) communications protocol, library and API written in C++.

About QuantumGate is a peer-to-peer (P2P) communications protocol, library and API. The long-term goal for QuantumGate is to become a platform for dis

Karel Donk 83 Sep 17, 2022
QUIC, a multiplexed stream transport over UDP

QUIC, a multiplexed stream transport over UDP QUIC is an experimental protocol aimed at reducing web latency over that of TCP. On the surface, QUIC is

Devsisters Corp. 1.7k Sep 27, 2022
(Test assignment) Transfer files over the network using a homegrown UDP protocol

Требования Linux x86_64 gcc >= 4.9 (C++11) Сборка $ make Запуск $ make run -j5 -j5 позволяет серверу и четырём клиентам запуститься одновременно. В

Alexander Batischev 2 Dec 18, 2021
A protocol for secure client/server connections over UDP

netcode netcode is a simple connection based client/server protocol built on top of UDP. It has the following features: Encrypted and signed packets S

The Network Protocol Company 2.2k Sep 30, 2022
A protocol for secure client/server connections over UDP

netcode netcode is a simple connection based client/server protocol built on top of UDP. It has the following features: Encrypted and signed packets S

The Network Protocol Company 2.2k Sep 30, 2022
Dohd is a minimalist DNS-over-HTTPS daemon that redirects all DoH queries to a local DNS server running on localhost:53 (UDP)

dohd Dohd (pron. doh-dee) is a minimalist DNS-over-HTTPS daemon that redirects all DoH queries to a local DNS server running on localhost:53 (UDP). Fe

Dyne.org 14 Jun 26, 2022
A NAT router with an FTP honeypot using a canarytoken

ESP8266_Router_Honeypot A NAT router with an FTP honeypot using a canarytoken by @spacehuhn and @kodykinzie based on the espcanary library. Requiremen

Skickar 60 Sep 15, 2022
zrp is a nat-passthrough reverse proxy written in modern c++.

zrp is a nat-passthrough reverse proxy written in modern c++. A major use case is to expose a local server via a remote server with public IP.

Coleman 11 Nov 23, 2021
Node-portmapping allows to forward ports on Network Address Translators (NAT)

Multi-protocol NAT Port Mapping for Node.js node-portmapping allows to forward ports on Network Address Translators (NAT). It implements the protocols

Paul-Louis Ageneau 5 Jun 24, 2022
New generation message broker service

Push1st Push1st is open source multiple protocol PUB/SUB message broker server (Pusher, MQTT, RAW WebSocket). Key features Suitable for distributed on

Naveksoft 16 Jan 18, 2022
Login and send instagram direct message to any user ;)

DM-THIS-USER Very simple instagram tool,The idea is not in the tool, but in how to deal with the C language, especially with the openssl library and c

0xDADDY 6 May 14, 2022
:zap: KCP - A Fast and Reliable ARQ Protocol

KCP - A Fast and Reliable ARQ Protocol README in English 简介 KCP是一个快速可靠协议,能以比 TCP 浪费 10%-20% 的带宽的代价,换取平均延迟降低 30%-40%,且最大延迟降低三倍的传输效果。纯算法实现,并不负责底层协议(如UDP

Linwei 11.7k Sep 28, 2022