ReactiveDrop
Game Networking Sockets / Steam Datagram Relay
From forums: https://steamcommunity.com/app/563560/discussions/2/5595176692474775857/
[Suggestion] Remove ISteamNetworking.h
src/public/steam/isteamnetworking.h is marked as deprecated by valve. It could be removed and migrate to new headers.
Btw, it is expected that two players behind nat devices can connect via isteamnetworkingmessages/sockets, but i failed today, even after changed from broadband(chinatelecom) to 4g net (china unicom). I think this might be caused by the absence of steam data relay(have not looked deep into the code yet).
I want to do this, but as the networking code is part of the engine and Valve doesn't have the resources to maintain the 2010 branch of Source Engine, it's going to be tricky.
We already use ISteamNetworkingUtils for the lobby ping feature, but ISteamNetworkingSockets is going to need some edits to the engine for it to work. (Possibly requiring runtime binary patches and vtable injection.)
Is it possible to use steam fake ip system? Binds the server to a fake ip and clients connect to it.Documentation says TF2 has the similar problem that IP-based networking is coded into the engine.
Or perhaps, write a small networking shell. It takes over all external net loads that sends to other players. Server binds to localhost.
Since the game has some kind of dropping net packages, i guess udp is used.
My idea is run a local small proxy. Clients connect to the proxy using steamnetworking.
The proxy marks the real source and send to 127.0.0.1. The marker could be source port in upd packages. THe proxy holds a port-client mapping. When a package arrives via steam networking, the proxy wraps the package and fill the source port. Then send the package to 127.0.0.1.
The server is expected to send package to the specified port of 127.0.0.1. The proxy then wraps it back to steam networking, by unmapping the port to real source. This wont take to much cpu time for cpp and the delay will be acceptable(typically 0-1ms for loopback address)
The basic plan is to find a minimally intrusive way to intercept the engine's use of WinSock and ISteamNetworking and instead route those calls through ISteamNetworkingSockets. Maybe "basic" isn't the right word.
Currently, the game will try to use ISteamNetworking (the deprecated one) if the host has a persistent Steam ID (which dedicated servers do not), and otherwise use UDP. Prior to this year, it preferred UDP and would try ISteamNetworking as a fallback. (The only change is that net_steamcnx_enabled is now set to 2 if relays are enabled.)
Just stumbled upon this URL, that seems to be hardcoded into some files shipped with Reactive Drop (and also is present inside .mdmp dumps):
grep: ./srcds_crash_2023_4_22T17_42_25C0.mdmp: https://api.steampowered.com/ISteamApps/GetSDRConfig/v1?appid=563560
grep: ./srcds_crash_2023_4_22T17_45_55C0.mdmp: https://api.steampowered.com/ISteamApps/GetSDRConfig/v1?appid=563560
grep: ./steamclient.dll: https://api.steampowered.com/ISteamApps/GetSDRConfig/v1?appid=563560
grep: ./steamclient64.dll: https://api.steampowered.com/ISteamApps/GetSDRConfig/v1?appid=563560
https://api.steampowered.com/ISteamApps/GetSDRConfig/v1?appid=563560
The Steam Datagram Relay Config is how we compute lobby pings currently. In the future, we might do more with it, but that would require engine changes.
https://developer.valvesoftware.com/wiki/Steam_Datagram_Relay#Requirements
Your dedicated server needs to be running in a data center that is part of the Valve network. At this time, we are only supporting the major providers Amazon AWS, Microsoft Azure, and Google Cloud.
Found this snippet, wonder if it's still a requirement.