It's 1am here, so no proof-reading. Cheers folks... I've experimented a bit with it. I got to the point where srcds actually listened to incoming proxied traffic (by setting +sv_steamdatagramtransport_port xy) but the relays won't forward my connection attempts. You can verify your srcds is configured "correctly" by checking your "status" printout for the following line:
sdt : =[G:1:nnnnn] on port xy The only issue i found (besides it's not working at all, but thats the relays "fault") is that the additional SDT port is not respecting the ip or ip_steam cvars. That port listens to all interfaces, which could cause problems on multihomed hosts. There are no cvars to control this behaviour, including hidden cvars. I think that should be fixed by either go after the "ip" cvar or giving it it's own like it has been done with ip_tv and ip_tv1 for that additional gotv-instance. I propose "ip_sdt". I think the relays have to be configured to acknowledge either certain gameserver steamid's or predefined ip ranges, since Valve doesn't applies GSLT restrictions to their own server version. (The clientside sdt debug logging shows their servers run anonymous SteamID's) Steam already knows which steamid belongs to which ip:port, it has to be the relay then. If Valve want's to use SDT globally, there are only two ways to do so: Option one would be routing every single bit of traffic from and to community servers through their clusters. That means HUGE amounts of traffic, way to inefficient, no way they are doing that. Also, ping times and overall networking quality to everything else than Valve servers would most likely get worse because the routing would be optimized for their own data centers. Option two, obviously, is to give us access to the relay software. Assuming the relays have to sign in into steam like srcds, it would be easy to feed the clients with information about which server is connected to which relay cluster. That also could replace the current masterserver system and by that the old server browser, and lays foundation for future changes like IPv6. That option also suggests we could be able to construct our own relay clusters to generate some kind of redundancy, just like Valve does. Wild theory: I think the only reason we can't use SDT with our servers right now is that valve isn't done with the part where the client get's the information which relay(cluster) to use with community servers. Right now it's done via matchmaking, but that won't work for everything non-valve. With DotA2 they had no need to work on that because there is no offical community srcds. But then again it was easy to port the existing DotA2-code over since our matchmaking originates from there. Would be great to get some kind of confirmation on that from Valve, but not getting one would match their corporate identity... **tl;dr:** community srcds is already to able to work with SDT, but valve's relays just don't want to. imho best and most efficient way to utilize SDT with community srcds would be to make the software generally available, feed all needed info from community relays into steam and back to the clients, and replace the old server browser while you're at it. Only reason we can't utilize SDT right now is most likely good ol' "not done yet". Cheers! Ragnos Am 10/18/2016 um 2:23 PM schrieb Marco Padovan: > I've personally been playing with "multiple ingress points" (nats and > network forwads) many times... > > They works properly con call of duty/quake3 netcode but they were not > working on sourceds netcode... > > We can provide both the edge servers, and the gameservers themself as > long as the game is able to digest NAT / ip forward... having > something running natively like valve does on the official servers > would be even better. > > Hoping they will come forward with some details for the general public > to set them up too > > On Tue, Oct 18, 2016 at 10:32 AM, wickedplayer494 > <[email protected] <mailto:[email protected]>> wrote: > > The Steam Datagram relay system only deals with how clients > connect to Valve's own server network, so for community server > operators, it will be irrelevant. Also, today's update didn't > affect the server version, so even if the Steam Datagram system > was made available to community servers, the relevant commands > would not work because of that. > > On 10/18/2016 3:07 AM, Marco Padovan wrote: >> >> Hi, >> >> How can we setup steam datagram relays on community servers? Is >> there any documentation out there? >> >> >> >> _______________________________________________ >> Csgo_servers mailing list >> [email protected] >> <mailto:[email protected]> >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >> <https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers> > _______________________________________________ Csgo_servers > mailing list [email protected] > <mailto:[email protected]> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers > <https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers> > > > _______________________________________________ > Csgo_servers mailing list > [email protected] > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers _______________________________________________ Csgo_servers mailing list [email protected] https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
