PING/PONG

[bibim]

So you want to prevent lobby clients to detect when the server becomes unavailable?

[abma]

So you want to prevent lobby clients to detect when the server becomes unavailable?

no, the client has to do the same as the server: if no data received for time z, send ping...

so maybe more general (for server & client):

- if no data received from remote side for time > x , send ping
- if no data / pong received from remote side for time > x + y, disconnect remote side

the other approach would require to have the same fixed time settings on both sides.

[bibim]

abma, sorry but I don't follow your logic at all.

Please explain clearly what you are trying to solve with this new server initiated PING.

I think I explained clearly in my previous post that adding this server initiated PING cannot solve the PING spam as long as clients timeouts aren't adjusted as well.

As I explained, clients not only ping to say they are alive, but also to check if server is alive. If they want to check that server is alive every time they don't receive any data for 10s, your server initiated PING sent every time client doesn't send data for 60s won't solve anything and won't even be used.

[cleanrock]

thats why i want a server initiated ping:

the idea for server side ping is:
- if no data received from client longer than x, server sends ping
- if x+y time no data/PONG received from client: disconnect "dead" client

client doesn't have to care about values, it just have to respond with PONG to a PING from server. also, ping is only send when needed.

benefit: client doesn't need to care about timeout values & timeout values can be changed server-side when needed, no useless PING's send.

+1 (if we must have ping/pong)

[abma]

As I explained, clients not only ping to say they are alive, but also to check if server is alive. If they want to check that server is alive every time they don't receive any data for 10s, your server initiated PING everytime client doesn't send data for 60s won't solve anything and won't even be used.

hu?
client pings to check server is alive, server pings to check if client is alive. server initiated ping solves that no agreement about timings have to be made. if client doesn't respond connection is closed by server and vice versa.

[bibim]

Ok I will try yet another way of explaining it...

Your server-initiated PING will be used by the server to detect broken client.

The existing client-initiated PING which was used by the client both for saying "I'm alive" and to detect if the server is still alive, will now only be used to detect if the server is still alive.

But if previously the client decided to check every 10s if the server was alive, it has no reason to change this value, it will still send PING every 10s to check if server is alive (when no other data is received).

As I said, your server-initiated PING will NOT solve the PING spam issue by itself. Clients have to adjust the frequency at which they check that server is up. In other words, the shortest timeout will be used to exchange PING commands. So you gain NOTHING concerning spam.

[abma]

As I said, your server-initiated PING will NOT solve the PING spam issue by itself. Clients have to adjust the frequency at which they check that server is up. In other words, the shortest timeout will be used to exchange PING commands. So you gain NOTHING concerning spam.

true, it won't solve the ping spam! it would allow the client to set a lower ping value then set on server side, but motivation for clients to to that are pretty low, yes.

my problem is: how often to ping / how long to wait for a client? allowing the client to set/change these values would allow bad behaving clients, to set by server isn't possible, it would require all clients to change.

an alternative would be, to set the ping values at the login-process, this would allow enforcement at server side, too, maybe thats better? this would require a change, too but it could be changed in future by some config var at the server.

i miss the constructive critism

by just enforcing it at server side as it is, many things would broke, especially springie/nightwatch. atm enforcing it is imo a nogo.

[bibim]

springie/nightwatch would break? are you sure? Springie is older than SPADS, I'm sure it used to send PING commands as required by lobby protocol at least.

[abma]

yep, tried in practical :)

springie's connect code is somewhat weird:

it tries to connect the same user multiple times: so if the ping time is lower than the ghost timeout value, springie kicks out its own sessions on the lobby server.

but the ghost timeout value should be kept low, to allow quickly a reconnect, when something crashed.

i don't see a possibility about how to increase the ping time without increasing the "ghost timeout" without breaking springie.

fixing zero-k's connect code would be best... i can't do it, licho won't, others can't as well it seems, see http://code.google.com/p/zero-k/issues/detail?id=1992 for details

[bibim]

yep, tried in practical :)

You mean you tried after enforcing the higher PING delays I guess? Because currently it seems Springie is set to send PING every 10s so it shouldn't have any problem with a ghosting delay of 15s.

Btw, according to this code, it seems Springie doesn't check if it already sent data during last 10s before sending a PING command. So it actually sends a lot of unneeded PINGs, even if the server timeout was as low as 10s. That might explain a bit the spam you observed...

But seriously, we don't need to be able to reconnect 16s after a hard crash... (hard crashes are quite rare and often require system restart anyway, and normal crashes should close socket correctly).

I agree that Springie connect code seems a bit weird, but once again this whole ghost system is bringing more problems than it adds functionalities imo.

If we use a simple basic timeout of 60s (if client didn't sent data for 60s it is disconnected), it will be much better overall. Changing the PING interval in Springie would then be a one line change, even if it would still send a lot of unneeded PINGs if current code is kept...

edit: or if you really want to keep that "allow-reconnect-after-16s-from-unclosed-session" feature, and noone is willing to fix Springie connect code, I guess you could just disable it for Springie based on the lobby client name...

[abma]

Btw, according to this code, it seems Springie doesn't check if it already sent data during last 10s before sending a PING command. So it actually sends a lot of unneeded PINGs, even if the server timeout was as low as 10s. That might explain a bit the spam you observed...

for the test ping was set to 30, but then the errors began because ghost timeout was still 15.

But seriously, we don't need to be able to reconnect 16s after a hard crash... (hard crashes are quite rare and often require system restart anyway, and normal crashes should close socket correctly).

agree!

I agree that Springie connect code seems a bit weird, but once again this whole ghost system is bringing more problems than it adds functionalities imo.

If we use a simple basic timeout of 60s (if client didn't sent data for 60s it is disconnected), it will be much better overall. Changing the PING interval in Springie would then be a one line change, even if it would still send a lot of unneeded PINGs if current code is kept...

you mean, no kicking of existing connections at all? yeah, that would be a good path, didn't think about that

that wasn't possible before my change, as clients sometimes never timed out when crashed.

[abma]

ok, i've removed the "ghosted" feature:

https://github.com/spring/uberserver/co ... 81c371b718

that means (atm, as PING isn't directly enforced yet):
- if a lobby doesn't send PING and does an unclean exit, it can't login again for a possible very long time (DENIED Already logged in.). It is advised to implement PING if you want a stable connection and want be able to reconnect fast if something went wrong.
- the client has to send a PING every 30 seconds:
http://springrts.com/dl/LobbyProtocol/P ... ING:client
- a PING can be skipped when other data was/is sent by the client, server checks for the last time when data was received from the client.

when PING is enforced this will happen:if the server didn't receive data with from the client within 60 seconds it disconnects the client.

thanks bibim for your help/feedback/opinion(s) and patience!

[bibim]

Thanks abma, however please consider rephrasing this:

The client should send this command every ~30 seconds, to maintain a constant connection to the server. The server will assume a timeout occured if it does not hear from the client for more than 60 seconds. To figure out how long a it takes a reply to from the server to the client, use a message ID with this command.

by something like:

Code: Select all

This command must be used by the lobby clients to maintain their connection to the server. It serves 2 purposes: notify the server that the client is still alive, and check if server is still available.
The server will assume a client died if it does not receive any data from it for one minute. Similarly, a lobby client should consider the server became unavailable if it does not receive any data from it for one minute. So, if nothing has been sent to server for 30 seconds, it is recommended to send this command to reset the server side timeout. Similarly, if no data has been received from server for 30 seconds, it is recommended to use this command to detect if server has become unavailable.
Additionally, this command can be used to compute the round trip delay time to lobby server (in this case a message ID should be used so the PONG response can be associated with the corresponding original PING request)

[abma]

done: http://springrts.com/dl/LobbyProtocol/P ... ING:client thx!