Changes between Initial Version and Version 6 of Ticket #3700


Ignore:
Timestamp:
Jan 4, 2017, 3:12:23 PM (7 years ago)
Author:
elexis
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #3700

    • Property Component Core engine → Network
    • Property Summary Finish-rejoin lag → Running the NetClient in a separate thread
    • Property Priority If Time Permits → Must Have
    • Property Milestone Backlog → Alpha 22
    • Property Keywords beta added

  • Ticket #3700 – Description

    initial v6  
    1 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").
     1Since the `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).
    22
    3 It happens whenever a game has been played for a while (much serialized data).
    4 The game appears to be frozen for 5 to 15 seconds.
     3Some 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.
     4-------
     5Original report (only one symptom of the underlying problem):
     6~~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").
    57
    6 Here is what happens:
    7 1. The client is starting to rejoin.
    8 2. The server sends the client a lot of serialized data.
    9 3. The client needs a significant time to deserialize it.
    10 4. Meanwhile the game has continued (i.e. new turns)
    11 5. 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.
     8~~It happens whenever a game has been played for a while (much serialized data).
     9~~The game appears to be frozen for 5 to 15 seconds.
    1210
    13 With #3242 rejoins happen more often, so the problem accumulates more in that situation.
    14 ---------
     11~~Here is what happens:
     121. ~~The client is starting to rejoin.~~
     132. ~~The server sends the client a lot of serialized data.~~
     143. ~~The client needs a significant time to deserialize it.
     154. ~~Meanwhile the game has continued (i.e. new turns)~~
     165. ~~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.~~
    1517
    16 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.
     18~~With #3242 rejoins happen more often, so the problem accumulates more in that situation.
    1719
    18 For the time being, #3241 helps.
     20~~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.