ST-CS-10-339-75
March 2002

3.  Latency Issues  (U)

As mentioned earlier, the latency of the connection between the client and server is one of the major factors affecting client-server communication.

The basic problem is this; the server recieves information from all of the clients telling the server what the clients are doing. The server is constantly updating the state of the Counter-Strike world with this information, and then telling all the clients about the current state of the world.

So, consider a player who presses the move-forward button. 250ms later, the server recieves this information. Until this has happened, that movement does not exist because the server does not know about it.

Once the server knows, it updates the position of that player, and tells the other clients connected to the server that the player has moved.

250ms later, all the other clients recieve this information and finally see on screen what the original player is doing.

Except of course it is actually what he was doing 500ms ago! what every player sees on screen is the position of all the players about one half of a second in the past.

There is a subtle issue here, however, which must be understood. There is a difference between what the other player is doing (which was 500ms ago) and what the server knows about (which is 250ms ago).

When a player aims and fires at another player, what matters is the position of the target that the server knows about - not the position that the target player's client knows about, because that information has not yet reached the server - so how can the server know?

So, consider what happens when a player aims at another player and fires. He is actually aiming at the position of the player 500ms ago from the point of view of the target player, but only 250ms ago from the point of view of the server.

It then takes 250ms for the information that our player has fired to reach the server. Clearly, if nothing was done about these delays, aiming at a target would be very hard; it would be necessary to aim at where the target will be in 500ms time to score a hit.

The solution is a rather neat. The server keeps a history of the of the position of players for the last half second or so. When the information about the player firing reaches the server, the server knows how long it took that information to arrive (say, 241ms for a particular shot) and also knows the approximate latency of the player being shot at (say, 210ms) and so looks back in the history of positions by the sum of those two length of times (451ms) to see if, when our player fired, the target was actually under his crosshair.

What the server is doing is figuring out what the world looked like to the player who fired, when he fired. If the player was on target, then he should get his hits, even if the world has changed since he fired (or even before he fired, as is actually the case).

This way players can aim at their targets, rather than having to manually lead them.

This is also why players sometimes die after having run round a corner, out of the line of sight of their opponent. They were hit before running around the corner, but the server only realised they were dead some time later when the information about the gun that killed them being fired reached the server and of course there is an additional delay required for the server to tell the dead player's client that the player has been killed.

Clients can indicate to the server they wish to use or not use the server side position history (e.g. if they wish to be able to aim at targets, or if they would prefer to manually lead).

The command to control this is cl_lc. Set to 1, the client uses the history, set to 0 the client does not.

The following footage illustrates the differences in gameplay.

In the left hand video pane, the client is using the server history. The pistol is fired when the target is under the crosshair. Some time later, the data indicating the gun has been fired reaches the server, which looks back in the position history and determines that a hit was achieved when the gun was fired. The player who was shot is then told this, and when that information reaches him, his model shudders with the bullet hit.

In the right hand video pane, the client is not using the server history. The pistol is fired when the target is under the crosshair. Some time later, the data indicating the gun has fired reaches the server. The server simply looks at the current position of all players to see if the path of the bullet has hit anything. Of course, in this case, the target has moved on and no hit was achieved - despite the shot being dead on target when it was fired.