[PATCH] Running the NetClient in a separate thread
|Reported by:||elexis||Owned by:||elexis|
|Priority:||Must Have||Milestone:||Alpha 24|
Description (last modified by )
NetClient is running in the same thread as the map generation, the loading screen can entirely block the client for a couple dozen of seconds, thus the client appears to be offline ("losing the connection") while joining or rejoining the game. This can cause the disconnect of the client while loading the game (some players can't rejoin anymore).
Some of the map generator calls are threaded, but it were more sustainable if the client is executed in a separate thread, avoiding repetition of this problem.
Original report (only one symptom of the underlying problem):
Since a chat-message is displayed when a client has finished rejoining (#1949), one can easily observe a reoccuring, distinct type of lag ("finished-rejoin lag").
It happens whenever a game has been played for a while (much serialized data).
The game appears to be frozen for 5 to 15 seconds.
Here is what happens:
The client is starting to rejoin. The server sends the client a lot of serialized data. The client needs a significant time to deserialize it. Meanwhile the game has continued (i.e. new turns) In order to finish the rejoin, the client simulates the new turns while all other clients wait for him. This is the finish-rejoin lag. With #3242 rejoins happen more often, so the problem accumulates more in that situation.
In order to solve or reduce the impact of the issue, the playing clients could progress one turn for every five turns that the rejoined client computes. Hence the rejoined client still catches up with the other clients, while those are still able to play.
Change History (38)
comment:6 by , 4 years ago
|Summary:||Finish-rejoin lag → Running the NetClient in a separate thread|
comment:14 by , 4 years ago
|Summary:||Running the NetClient in a separate thread → [PATCH] Running the NetClient in a separate thread|