Nice analysis, hoping too to see relays available to us On Fri, Oct 21, 2016 at 7:00 PM, Ragnos <ragnos.utz...@gmail.com> wrote:
> 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 > > <wickedplayer...@gmail.com <mailto:wickedplayer...@gmail.com>> 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 > >> Csgo_servers@list.valvesoftware.com > >> <mailto:Csgo_servers@list.valvesoftware.com> > >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/ > csgo_servers > >> <https://list.valvesoftware.com/cgi-bin/mailman/listinfo/ > csgo_servers> > > _______________________________________________ Csgo_servers > > mailing list Csgo_servers@list.valvesoftware.com > > <mailto:Csgo_servers@list.valvesoftware.com> > > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers > > <https://list.valvesoftware.com/cgi-bin/mailman/listinfo/ > csgo_servers> > > > > > > _______________________________________________ > > Csgo_servers mailing list > > Csgo_servers@list.valvesoftware.com > > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers > > > _______________________________________________ > Csgo_servers mailing list > Csgo_servers@list.valvesoftware.com > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >
_______________________________________________ Csgo_servers mailing list Csgo_servers@list.valvesoftware.com https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
