How the GameServer works (mantis 3845)

[jK]

This is a response to http://springrts.com/mantis/view.php?id=3845

First something about SimFrames:
In Spring SimFrames only depend on _commands_, means the GameServer sends only commands ("move unit a to b") to the GameClients and those calculate then the unitpositions etc. based just on those commands. The GameServer _never_ sends unit positions, unit states, deaths, ... to the GameClients!
Based on that, for the GameServer a SimFrame is _nothing_ else than sending NET_NEWFRAME to the gameclients, and obv. it can send those even when the GameClients didn't finished their computations on current frames -> the GameServer creates SimFrames ahead (from game and GameClient view).

Now some images:
This what ppl assume how it works:

Code: Select all

                            v current frame
 GamesServer: --------------x
 GameClient:  ---(x-y)

-> GameClient is alway a bit behind GameServer cause there is a network lag
So GameServer send now the y remaining SimFrames to gameclient, when the client recv them we got:

Code: Select all

 GamesServer: --------------x-----------x+y
 GameClient:  --------------x

Now we define
SpringPing := time("GameServer gets response that GameClient finished X") - time("GameServer added/created frame x") -> means it's not pure netping!

So the GameClient sends to the GameServer that it recv'ed and processed SimFrame "x":

Code: Select all

 GamesServer: --------------x-----------x+y-----------x+2y
 GameClient:  --------------x-----------x+y

So the SpringPing should be:
=> SpringPing = 2y/SIM_FRAMES_PER_SEC = 2y/30

Now imagine an ideal world the client is able to process the SimFrames in zero time exactly when it recv them, then SpringPing would be equal to NetPing!
Strangely we _never_ observe anything near that in real world, e.g. we got 20ms netping to the server and Spring still shows 80-130ms ping. Why does this happen?

The answer is simple ...

The GameServer creates SimFrames ahead (from GameServer view)
to compensate fluctuations in netlag.

So instead of the first sketch we get:

Code: Select all

                             v current frame    v most recent `ahead simframe`
 GamesServer: --------------(x)ooooooooooooooo(x+n)
 GameClient:  ---(x-y)

 o := `unprocessed/ahead simframes`

So when the GameClient is still processing (x-y) the GameServer already send the next y+n frames, which will recv soon at the GameClient.

Code: Select all

 GamesServer: --------------(x)-----------(x+y)ooooooooooooooo(x+y+n)
 GameClient:  --------------(x)ooooooooooooooo(x+n)

So the GameClient has now n additional frames it can process even when it lose contact with the GameServer. -> netlags are compensated this way


Now we know the Pros, what are the Contras?
Imagine the GameClients wants now to issue a command in SimFrame (x-y):

Code: Select all

 GamesServer: --------------(x)ooooooooooooooo(x+n)
 GameClient:  ---(x-y)

The GameServer will recv it a bit later:

Code: Select all

 GamesServer: --------------(x)-----------(x+y)ooooooooooooooo(x+y+n)
 GameClient:  --------------(x)

-> The GameServer recvs the command in SimFrame (x+y), but what will it do now? It already created the next n SimFrames and it cannot modify them cause they are already send via the net!
So the GameServer must add the GameClient's command in SimFrame (x+y+n).
-> When an user gives a command it will be happen 2y+n SimFrames later!

This also explains why SpringPing is so high, it's the same reason:
SpringPing := (2y+n) / 30 with y:= netping/2 (in simframes) & n := #ahead simframes

So "n" directly influences the responsiveness of the Game, the higher n is the longer it takes till the user sees his commands being issued. This even matters for singleplayer matches cause those do nothing else than running the GameServer locally -> netping is 0 then, but "n" is not! So the user even gets a lag with localhost matches!

How does this matter?
It's a question of balance, setting n too high makes the game unresponsive, making it too low can make it `laggy` when the internet connection is unstable (=ping is fluctuating != not packet drop rate), means that the GameClient runs out of SimFrames and the game stops for a few microseconds till it gets new packets from the server.

[zwzsg]

Here are two articles explaining the same topic with simpler words:
http://www.gamasutra.com/view/news/126022/
http://www.gamasutra.com/view/news/35886/

Wait, no, I meant this one:
http://www.gamasutra.com/view/feature/3094

[Licho]

Can you make it configurable so that we can test if this casues jitter?

[jK]

Here are two articles explaining the same topic with simpler words:
http://www.gamasutra.com/view/news/126022/
http://www.gamasutra.com/view/news/35886/

Wait, no, I meant this one:
http://www.gamasutra.com/view/feature/3094

Not the same.
What I wrote isn't about the sync system, it's about how the GameServer creates simframes, and that it always creates a few ahead, so the client can still process them when losing contact to server for a short time interval.

And that the way it does is the cause of the sometimes long response times, esp. when the match gets huge and clients don't catch up with simframes processing -> server still creates more and more new simframes (sometimes 10secs into the future!) and the client isn't able to process them fast enough

[jK]

Can you make it configurable so that we can test if this casues jitter?

It's not that simple, truth is there is no real "n", instead it's like always a combination of multiple codes:
the code that decides to spawn new simframes is:
https://github.com/spring/spring/blob/d ... .cpp#L2238

my commits are:
https://github.com/spring/spring/commit ... b058e17cd9
https://github.com/spring/spring/commit ... 118f76784b

[Licho]

In that case perhaps it could be a bit more adaptive .. clients could report that they have run out of frames due to network jitter and createnewframe could take that into account.

[Google_Frog]

Could we have a build without those two commits as a way to test whether they are responsible for the reported issue? I don't even know if this change is related to the issue but the easiest way to check is to have people test builds without it.

Edit:
Hang on, those commits are from 9 months ago. Are they included in 91.0? If so then they are probably not responsible for this issue.

[Shadowfury333]

Would the unit animations rely on SimFrames being sent, or is that supposed to be handled by client. That's the issue here more than anything, I was partly guessing regarding the Synced thing because the animation and map scrolling issue seemed directly related to ping.

[zwzsg]

Unit animation is synced.

[KingRaptor]

Given the way simframes work as explained here, does it make sense to stagger operations done in GameFrame() over several frames as opposed to doing everything in one frame?

[PicassoCT]

Good Explanation - Thanks JK