Название-Сеть в Играх 2006год_Язык-Eng

world accurately. They need to be small because upstream bandwidth is usually highly constrained in dial-up, DSL or cable-modem scenarios.

10.2.2 Controlling Snapshot and Command Rates

Let us take the example of Wolfenstein Enemy Territory (ET) [WET2005]. By default, ET servers tick 20 times per second (a tick every 50 ms) and their clients usually request 20 snapshots per second. If a client requests a higher snapshot rate, such as 30 or 40 per second, the server continues to send snapshots every tick – once every 50 ms. If a client requests 15 snapshots per second, the ET server rounds this up to the next multiple of tick intervals – 100 ms – which corresponds to 10 snapshots per second. The desired snapshot rate can be changed in-game using the client-side console command ‘snaps’. (This observation also applies to Quake III Arena [QUAKE3], the engine on which Wolfenstein ET was based.)

Half-life 2 (HL2) [HALFLIFE2004] behaves slightly differently. By default, the HL2 server ticks 66 times per second (once every 15 ms) [HL2NTWK]. As with ET, a HL2 client cannot request more snapshots per second than the HL2 server’s tick rate (in this case, 66). However, the situation is rather different when HL2 clients request less than 66 snapshots per second. Rather than simply rounding up to the next multiple of 15 ms, the server mixes transmission intervals to approximate the client’s requested snapshot rate over many packets.

For example, a request for 30 snapshots per second results in an uneven mix of packets sent at 30 ms and 45 ms intervals that averages out to 30 packets per second. A request for 50 snapshots per second results in an uneven mix of packets at 15 ms and 30 ms intervals, again averaging out to 50 packets per second. The snapshot rate can be changed in-game by modifying the client-side ‘cl updaterate’ variable.

Some games may also allow configurable server-side limits to override the client-side request. For example, setting HL2’s ‘sv minupdaterate’ server-side variable to 30 would impose a minimum rate of 30 snapshots per second on clients whose ‘cl updaterate’ was less than 30.

FPS games usually also allow capping of the downstream server-to-client traffic in bytes per second (not just packets per second). For example, HL2’s client-side ‘rate’ setting allows a client to specify the maximum rate at which it can accept traffic in bytes per second. It might seem redundant to have separate limits on rate (in bytes per second) and snapshots (in packets per second). However, the bytes per second limit protects your downstream link when the snapshot packets become large. If necessary, the snapshot packet/second rate will be temporarily reduced if the product of packet length and transmission frequency exceeds the bytes/second rate set by a client.

Command traffic in the client-to-server direction can also be constrained by the player. In Quake III Arena, the client-side variable ‘cl maxpackets’ specifies a cap on the number of command packets per second that the client will transmit to the server. This value dictates a lower bound on inter-packet arrival times from client to server.

In the following two sections, we will look in detail at the packet size distributions and inter-packet arrival distributions of some well-known FPS games.

158 Networking and Online Games: Understanding and Engineering Multiplayer Internet Games

Client-to-server packet size distribution per map (Half-life)

Figure 10.5 Half-life packet sizes: Client-to-server over three different maps

Quake III Arena shows similar client-to-server packet-size distribution curves to Quake II and Half-life in Figure 10.6 (two separate client curves are shown, essentially the same distributions). An additional truth about server-to-client packet-size distributions is illustrated in Figure 10.7 – the snapshots carry more information on average as the number of players goes up. (This example is taken from [LANG2004], where the same map was played multiple times with different numbers of players). Wolfenstein ET client-to-server traffic shows a similar packet-size distribution to that of Quake III Arena.

In general, snapshot size distributions are relatively constant over time for a given map type and number of players. Unfortunately, it is not immediately evident how to predict the likely packet-size distribution of a given map without previous measurements of actual game-play traffic.

A similar set of results emerge from the Xbox game Halo 2 [HALO2004]. Figure 10.8 and Figure 10.9 show the server-to-client and client-to-server packet-size distributions respectively, measured on a LAN when playing in ‘System Link’ mode [ZANDER2005a]. As expected, the server-to-client distributions increase and broaden out as the number of players increases. However, unlike the earlier PC-based games, a single ‘client’ (Xbox console) may have one to four players on it. This results in four possible client-to-server distributions – similarly shaped but with progressively larger packets to carry additional player action messages to the server. Halo 2’s client-to-server packets only appear in certain discrete sizes, always in multiples of 4 bytes and spaced 8 bytes apart. (The lines in Figure 10.9 visually associate data points rather than imply a continuity of packet sizes between data points.)

Figure 10.10 and Figure 10.11 show the server-to-client and client-to-server packet-size distributions seen with HL2. Since server-to-client size distribution generally varies with

For a game such as Quake III Arena or Wolfenstein ET, if there are n players on your server, all requesting 20 snapshots per second, then (100 × (n − 1)/n) percent of the measured inter-packet intervals will be in the sub-millisecond region. The same applies to HL2 if the clients have all requested 33 or 66 snapshots per second. The inter-packet interval distribution becomes more complex to predict when concurrently connected HL2 clients request different snapshot rates.

Table 10.1 shows the default snapshot rates for a number of well-known FPS games along with the server’s tick rate (where known).

Snapshot intervals do not generally vary with map choice or number of players. However, game server tick timing can fluctuate by a few milliseconds due to central processing unit (CPU) load, resulting in observable jitter of snapshot transmissions.

Client-to-server intervals of the PC-based FPS games are more difficult to characterise.

•Client transmissions towards the server are uncorrelated (so inter-packet intervals of the aggregate traffic close to the server are spread widely).

•Many games have user-configurable rates (and thus minimum inter-packet interval) at which they send updates from client to server.

•Actual distributions seem to depend strongly on each player’s game-play behaviour, the client settings and their system’s technical capabilities (e.g. CPU speed and graphics card hardware acceleration) [LANG2003, LANG2004].

transmit their updates at regular 40 ms intervals, same as the server-to-client inter-packet interval.) [ZANDER2005a]

One final note. When interpreting inter-packet interval statistics, be aware that you may sometimes find multiple clients hiding behind a single IP address. Two or more people playing on your Internet-based server from their home LAN will usually be connecting through a home ‘gateway’ implementing Network Address Translation (NAT). Their user datagram protocol (UDP) packets will have the same home IP address. It is important to always use both the port number and IP address to differentiate remote clients. (You may also be able to confirm multiple distinct client machines behind the NAT box by the unique ‘IP ID’ field patterns in packets from each client [BELLOVIN2002].)