Server connect with immediate disconnect

[Andarix]

Currently, there is again the problem that a player is immediately disconnected when connecting to my server.

The message that the client is no longer synchronized with the server is not very helpful, as there is no indication which computer is too slow.

Is it possible to give the server an adjustable time parameter that can be used to set the waiting time for connecting?

With such a parameter, it would be possible to wait for the transmission time to the clients.

[prissi]

I am not sure what waiting time you mean. Do you mean a waiting time for the server before resuming?

The server only restarts after sending the entire game plus reloading. Thus, the server has to do a little more work with transmitting, reloading game, reloading password, and then announcing to all clients. One could of course waiting another second or so after reloading.

But I rather think that in the immediate disconnect cases other factors contribute more, like a very different latency of the network connection or to short timeout so packets are lost. Since the protocoll is TCP, it should be impossible to recieved a resume command before all transmission is finished (on both sides!)

[victor_18993]

I have not reviewed the networking code for this yet, so this is only a possible direction to investigate.
Perhaps part of the problem is not the waiting time itself, but that the client currently receives too little information about why the synchronization failed.

It may be worth checking whether we can distinguish cases such as the client having very high latency compared with the server, a timeout during synchronization, or the connection being lost/closed from the server side.
If the networking layer already knows the reason for the disconnect, perhaps the improvement could simply be to propagate that information clearly to the client instead of always ending with a generic "client is no longer synchronized with the server" message.

That would at least make these cases much easier to diagnose before deciding whether an additional configurable delay is actually necessary.

I can investigate the current connection/synchronization flow and see what information is available at the point where the disconnect is triggered.