ST-CS-10-339-75
March 2002

2.  Bandwidth Issues  (U)

The basic problem of only being able to transfer a finite amount of data per second is that if so much is happening that the amount of data the server needs to send per second to the client is greater than the amount which can be sent per second, something has to give. What happens is that some data - potentially crucial data, such as a player firing his gun - is simply not sent.

Imagine a player with a 56k modem. This has a client to server data rate of 3 kilobytes a second, and a server to client data rate of 5 kilobytes/second. (The majority of connection types are assymmetric, and transfer more data in one direction than the other).

To start with, our player is ambling along in a deserted section of the map. Nothing much is really happening except his position is changing, so the client needs to send very little data to the server - roughly about 1 kilobyte a second. Likewise, the server has nothing much to tell the client since nothing is happening near him.

Now, however, the player goes round a corner and enters a combat area. Suddenly, his client needs to be sent a lot of information - there are many players in view, lots of guns firing, grenades going off and so on. The server ends up needing to send the client 10 kilobytes per second of data to keep him informed of what is happening, but - alas - the client can only recieve 5 kilobytes per second. What happens? the server simply cannot send the full 10 kilobytes a second, so it has to chose which 50 percent of the data to be sent will be dumped, and which 50 percent to actually send.

As the reader might expect, This Is Not Good.

Exactly how this is done relates to a second issue, which is how the data sent between the client and server is organised - basically, the server can actually drop quite a lot of data without really screwing things up for the client.

Real-time games are rather like rolls of film. The faster the frame rate, the more realistic the movement shown. But the frame rate here is not the frame rate generated by the video card but rather how often per second the server updates the client with information about what is happening.

Imagine the server only tells the client once every five seconds what has happened. The client would see players jerking huge distances, would entirely miss grenades going off, and would often die without seeing his opponent, because his world only updates once every five seconds.

Now imagine the update rate is one per second; a big improvement, our player no longer misses grenades going off and sees players moving in a reasonably continous (if jerky) motion; but still at one update per second, he still finds aiming very difficult.

Now imagine the update rate is twenty-five times a second. Suddenly, our player is in business. His client is updated so often that the illusion of uniform movement is achieved.

However, there is a conflict here. The more often the server updates the client, the more data per second the server has to send to the client. If too much data is generated, more than the communication link between the client and server can support, then the server has to begin dropping data.

When this happens, the server simply temporarily reduces the frequency of updates. The client's view of the world degrades, but remains functional.

If, alternatively, it is the client who is sending too much data to the server, then the client reduces the frequency of updates to the server.

Importantly, the more action is going on around a player, the more data has to be sent per update. So 35 updates per second might well work fine in a deserted section of map, but will fail badly in combat.

This is where the user finally gets some say in configuring the behaviour of his client. The amount of bandwidth a client has is fixed, but how often the client and server update each other is entirely up to the user. This gives the user a crude but useful control over the amount of data sent (crude because the amount of data per update varies and the user has no control over this).

Configuring client-server communication in Half-life is basically a matter of knowing how much bandwidth you have and then figuring out how often updates can occur without saturating the data link when the action heats up.