How does Klei ping dedicated servers?

[JackJohnsn]

I'm posting this topic in hopes to get a bit of details from Klei developers, or someone who is really familiar with this subject.

I'm running a dedicated server in a KVM environment, ( Ubuntu running inside CentOs ). However, I'm having the "???" ping problem.

Everyone can join, the server has no lag and ping is perfect for those near server ( around 10ms ). The problem is that most players don't see the ping ( some do, including myself ) which means server won't be listed properly.

I'd like to know how Klei servers ping dedicated servers. Some useful information would be like:

• Which protocol is used? Standard ICMP? or do they arrive as TCP/UDP?
• Which port is used to ping the server?
• Is there a specific domain/IP that I need to whitelist?
• Any other information so I can try and test it myself.

I've been helplessly trying to fix this for days. A little response is really appreciated.

 

What I've done so far:

• Set Master shard's port to 10999 and Cave shard's port to 10998
• Allowed + Forwarded UDP traffic that arrive to these ports to my VM
• Allowed + Forwarded ICMP packets that arrive to these ports to my VM
• Open required SteamCMD ports ( stated here on Valve's website )
• Add Cloudflare and Google's DNS servers to resolve.conf to make sure it's not a DNS issue

 @Ipsquiggle @255 @V2C @Diabu @zarklord_klei

[nome]

On 1/15/2022 at 5:09 AM, JackJohnsn said:

• Which protocol is used? Standard ICMP? or do they arrive as TCP/UDP?
• Which port is used to ping the server?
• Is there a specific domain/IP that I need to whitelist?

The ping is sent by the client to the server via a UDP packet to the dedi's listen port (usually 10999). Klei doesn't ping your server, the connecting client does. You would need to enable connections from all IPs to that port (or at least from the IPs of everyone you want to have a successful ping) to have it succeed.

[JackJohnsn]

6 hours ago, nome said:

The ping is sent by the client to the server via a UDP packet to the dedi's listen port (usually 10999). Klei doesn't ping your server, the connecting client does. You would need to enable connections from all IPs to that port (or at least from the IPs of everyone you want to have a successful ping) to have it succeed.

Thank you for the reply. But I'm wondering, how can sometimes clients connect but they don't see the ping? If they weren't able to ping, how can they connect? Isn't the connection to server also via UDP?

[nome]

14 minutes ago, JackJohnsn said:

Thank you for the reply. But I'm wondering, how can sometimes clients connect but they don't see the ping? If they weren't able to ping, how can they connect? Isn't the connection to server also via UDP?

Because in addition to direct UDP connections we also support platform-specific NAT traversal technologies. When the client is not able to connect directly it can fall back to those, but those do not support pings because generally their setup/teardown costs are quite substantial so you can only do it on a server you're about to join, not 10,000 servers in a list.

[Jinshi]

On 2/3/2022 at 8:32 AM, nome said:

we also support platform-specific NAT traversal technologies.

I'd be glad if you could explain how these NAT technologies work in detail ^-^

I run my servers by fowarding UDP traffic to cloud servers (via frp) to improve network performance. I've been dealing with some troubles, that traffic between clients & server sometimes can't be forwaded correctly (The traffic goes to P2P, showing '[P2P] Create session: **.**.**.**|1' instead of communicating with the localhost which frp is listening to, and cause large lags).

It would be appreciated if you could explain how the 'platform-specific NAT technologies' work so that I may be able to troubleshoot and adjust my portfowarding settings etc. ^-^

[nome]

8 hours ago, Hedwig said:

It would be appreciated if you could explain how the 'platform-specific NAT technologies' work so that I may be able to troubleshoot and adjust my portfowarding settings etc. ^-^

I'm afraid it's literally "platform specific". Not sure if I can talk about the console ones, but steam's NAT traversal technology is STUN/TURN based IIRC, I think they use one of the open source VoIP libraries to implement it.
They also have newer tech that always does relaying (clients can never directly communicate with one another but instead their traffic goes over Steam's backbone) but that came out substantially after DST did so we don't currently support it. https://github.com/ValveSoftware/GameNetworkingSockets (again, this is not the tech that DST uses, this is newer).

[Jinshi]

57 minutes ago, nome said:

I'm afraid it's literally "platform specific". Not sure if I can talk about the console ones, but steam's NAT traversal technology is STUN/TURN based IIRC, I think they use one of the open source VoIP libraries to implement it.

Thanks for the reply. (⌒▽⌒)

Since STUN/TURN is used, does it mean that if a client fails to communicate with the server directly, it will turn to TURN and steam (or klei?) will relay the connection? If so, could I tell from the console that which client(s) is being relayed?

[nome]

2 hours ago, Hedwig said:

Since STUN/TURN is used, does it mean that if a client fails to communicate with the server directly, it will turn to TURN and steam (or klei?) will relay the connection? If so, could I tell from the console that which client(s) is being relayed?

Steam will relay traffic if both the server and client are behind very restrictive NAT, yes.

[Jinshi]

57 minutes ago, nome said:

Steam will relay traffic if both the server and client are behind very restrictive NAT, yes.

I see. Thanks for your reply ^-^

[Jinshi]

3 hours ago, nome said:

Steam will relay traffic if both the server and client are behind very restrictive NAT, yes.

One more thing, is there any way to disable or forbid this relay?

[nome]

17 hours ago, Hedwig said:

One more thing, is there any way to disable or forbid this relay?

Not that I'm aware of, but I haven't really looked into it.

[Jinshi]

On 3/15/2022 at 11:08 AM, nome said:

Not that I'm aware of, but I haven't really looked into it.

Sorry to bother but there's one more thing I want to check, that who will relay traffic for players from other platforms (WeGame, PS, etc.) when they can't directly connect to each other through NAT?

[nome]

6 hours ago, Hedwig said:

Sorry to bother but there's one more thing I want to check, that who will relay traffic for players from other platforms (WeGame, PS, etc.) when they can't directly connect to each other through NAT?

On PS it's Sony, on WeGame it's WeGame, etc. Each platform provides NAT traversal services because otherwise people making multiplayer games would have to spin up and run a bunch of infrastructure for themselves and for smaller games that's just not feasible.  

[Jinshi]

17 hours ago, nome said:

On PS it's Sony, on WeGame it's WeGame, etc. Each platform provides NAT traversal services because otherwise people making multiplayer games would have to spin up and run a bunch of infrastructure for themselves and for smaller games that's just not feasible.  

I see. Many thanks!