Clan Web Sites, Online Games and Hosting

Latency Compensation Techniques input immediately, rendering player and opponent movements before getting authoritative responses from the server. Broadly, there are two categories of prediction that can take place. In the first prediction category, the client takes input from the player and predicts the server response related to only the player s units. We call this Player Prediction . In the second prediction category, the client predicts the location of units that are not controlled by the player, being controlled either by other players or by a computer. We call this Opponent Prediction (even if some of the other units are not necessarily on another team).1 6.2.1 Player Prediction The client can predict the server response, allowing the game client to respond to user input and render player actions before getting the authoritative response from the server. This allows the game to appear immediately responsive to the user input, not needing to take a round-trip to the server and back before impacting the game. In fact, the response can be as fast as a non-networked game, thus completely removing any network latency. Using prediction, however, means the game state on the server (and the state on other client machines) will differ somewhat from the game state on the client. The amount it differs depends on the round-trip latency and, to some extent, the user actions taken. The client must therefore fix up any discrepancies in the game state when it finally does get a response from the server. The player prediction process is depicted in Figure 6.4. Time User input Render input Process and validate input Message: user input Message: ok with updateFix up Figure 6.4 Client-server in which client renders input with predicted state before getting ok from server 1 Prediction of units controlled by others is often called Dead Reckoning [Dead reckoning, CLC99, DF98], but that name does little to help remember the technique, hence our term Opponent Prediction .

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Adult Web Hosting services

88 Networking and Online Games: Understanding and Engineering Multiplayer Internet Games Predicted Algorithm Sample user input Pack up data and send to server Determine visible objects and game state Render scene Receive updates from server and upack Fix up any discrepancies Repeat. As an illustration of the effects of latency on this architecture, consider the screen- shots in Figure 6.5, in which both game consoles (the client and server) are connected to the same television. In the figure, the client s display is the larger picture, while the server s display is inset in the picture-in-picture. The client puts a man in motion (causing a football player to go from left to right across the screen), the result is that the client sees the in-motion player movement first, and subsequently, the player is one or two steps ahead on the client s display than he is on the server s display. We have manually drawn a box around the man in motion on each display to indicate the player of interest. Notice how the boxed player for the client in the large picture is further to the left than the boxed player for the server in the inset picture. The notable additional step the player prediction approach has that the basic client server approach does not is the step to fix up any discrepancies . These discrepancies may occur because the server still has the master copy of the game state, and this master copy may differ from the predicted copy the client has. As an example, suppose the user moves an avatar to the right. The game at the client sends this movement Figure 6.5 Depiction of state inconsistency (Madden NFL 2003). The large picture showing the first player s view differs from the second player s view, shown by the smaller, inset picture. A black box (drawn manually, not by the game) highlights the main difference

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Adult Web Hosting services

86 Networking and Online Games: Understanding and Engineering Multiplayer Internet Games (a) (b) (c) Figure 6.3 Illustration of the effects of latency on passing (Madden NFL 2003). (a) User is pressing throw, but throw is not processed yet because of latency. (b) Throw starts processing here because of the latency. (c) Defender intercepts throw! User curses As another example, in Figure 6.3, the user is trying to get the quarterback to throw ( pass ) the ball to a receiver. The receiver might only be away from a defender ( open ) for a short window of time before crossing the boundary and being too close to the defender. At the start of play, as the receiver begins his route, the user presses the pass button in order to deliver the pass to reach the receiver at the boundary between defenders. The receiver should catch the ball at the boundary since he is open. However, because of the latency, the processing of the quarterback throwing the ball actually begins too late. By the time the ball reaches the receiver, the receiver has fully crossed the boundary and the defender catches the ball instead (an interception ). These examples, and many more like them in real-time game genres of all kinds, occur quite frequently in online games unless latency compensation techniques are deployed. 6.2 Prediction Instead of waiting for the server to respond to each client action before rendering it, the client can predict the server response, allowing the game client to respond to user

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Adult Web Hosting services

Latency Compensation Techniques Basic Algorithm (Client Side) Sample user input Pack up data and send to server Receive updates from server and unpack Determine visible objects and game state Render scene Repeat. If the latency between the client and server is large enough, the user is aware of the delay between the commands given to the game and the response to the game state. As an example of this impact, consider an online American football game (e.g. Madden NFL Online) in which the player is responding to events on the screen but the input is lagged to the server by about a second. In Figure 6.2, the running back is running toward the left side of the field to avoid the defender. The user sees that there is an open lane along the sideline and pushes the controller up to run between the defender and the sideline. However, because of the latency, the processing of this input is delayed by the round-trip time to the server (one second, in this example) so that the command is actually processed after the runner goes out of bounds. Because of the latency, the user failed to gain as many yards on this running attempt as she/he would have if there was no latency. (a) (b) (c) Figure 6.2 Illustration of the effects of latency on running (Madden NFL 2003). (a) User is pressing left and the player moves left. (b) User is pressing up, but player continues left because of latency. (c) Running back goes out of bounds! User curses

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services

84 Networking and Online Games: Understanding and Engineering Multiplayer Internet Games (b) It will be quite some time before broadband is globally adopted by all online game players. (c) There is an increasing number of mobile, wide-area wireless environments that cannot benefit from the fixed infrastructure of broadband to the home. (d) Despite technology improvements, a certain amount of network delay will always remain because of the speed of light in fibre. For example, coast-to-coast delays across the United States of America cannot be less than about 25 milliseconds, not counting any additional delays from buffering. Intercontinental times will be even higher. Most games today basically run on a client server architecture with a single, authoritative server that handles the game logic. The clients collect input from the user and send it to the server. The server computes game state, sending the revised game state information back to the client. The client then renders the new game state to the player, and the process repeats. In some cases, the server can also act like a client, allowing a player to use the same machine as the server. In this case, the player offers to host a game. That player s computer then acts like a server for all players, as well as a client for the current player. This is still fundamentally a client server architecture, even though it may look like client client (or peer-to-peer) on the surface, in that all machines are being used as game clients. To illustrate the effects of latency on this basic architecture, consider the client to be where the user input is taking place. In the basic client server model, the client sends a message to the server when user input is received. The server processes (and validates) the input and sends the results back to the waiting client to render on the local display. Thus, the players actions are lagged by the round-trip latency between client and server. When the client acts in this manner, it is often called a Dumb client since it only acts on commands from the server, and is depicted in Figure 6.1. Time User input Render input Process and validate input Message: user input Message: ok user input Figure 6.1 Basic client-server with dumb client. Client only renders output of user input when it receives input ok from server

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services

Latency Compensation Techniques The delay (and variance in delay) illustrated in Chapter 5 comes from both delay caused by processing updates and delay caused by the network. While processing delay can be reduced by hardware and game algorithm improvements, networking delay is harder to reduce. There is an old network saying: Bandwidth problems can be cured with money. Latency problems are harder because the speed of light is fixed you can t bribe God. David Clark, MIT The first section of this chapter presents the need for latency compensation techniques against the backdrop of a basic client server game architecture. Next, we talk about how the architecture can be enhanced using prediction, both for the server response to user input and for the behaviour of other units, to mitigate the impact of latency. Manipulation of game time using time delay and time warp can equalise gameplay for players with disparate latencies to the server. Various data compression techniques primarily reduce game bitrates, but in doing so can also reduce latency by reducing the time to process network data. Although not network related, visual tricks can reduce the user awareness of any remaining residual latency. Lastly, latency compensation can also have an impact on cheating and cheat detection, and so extra precautions must be taken. 6.1 The Need for Latency Compensation While there has been substantial work in network congestion control toward reducing queuing delay at routers and reducing packet loss (thus avoiding extra delays added by any retransmissions), substantial delays remain, especially for network connections over the Internet to last-mile hops in home residences. Some see broadband as a solution for the latency problems with online gaming. However, while broadband generally offers significant improvements in network bitrates, there are other factors in network designs that limit the benefits of broadband. (a) Despite the promise of higher bitrates, some broadband solutions still have periodic high latencies or significant packet loss during congestion. Networking and Online Games: Understanding and Engineering Multiplayer Internet Games Grenville Armitage, Mark Claypool, Philip Branch . 2006 John Wiley & Sons, Ltd

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services

82 Networking and Online Games: Understanding and Engineering Multiplayer Internet Games [RFC2309] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang, Recom mendations on Queue Management and Congestion Avoidance in the Internet , RFC 2309. April 1998. [RFC2686] C. Bormann, The Multi-Class Extension to Multi-Link PPP , RFC 2686. September 1999. [RFC2687] C. Bormann, PPP in a Real-time Oriented HDLC-like Framing , RFC 2687. September 1999. [STE2005] L. Stewart, G. Armitage, P. Branch, S. Zander, An Architecture for Automated Network Control of QoS over Consumer Broadband Links , IEEE TENCON 05, Melbourne, Australia, 21 24, November, 2005. [TR017] ADSL Forum, TR-017: ATM over ADSL Recommendation , 1999.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Mac Web Hosting services

Network Latency, Jitter and Loss Average jitter per map versus average latency per map Jitter (ms) 80 70 60 50 40 30 20 10 0 0 100 200 300 400 500 600 700 Latency (ms) Figure 5.5 Jitter versus latency measured from an active Quake III Arena server in Australia [ARM2004] paths where delay accumulates from many router and link hops also places more likely to contribute to jitter. References [ARM2000] G. Armitage, Quality of Service in IP Networks: Foundations for a Multi-Service Internet , Macmillan Technical Publishing, April 2000. [ARM2004] G. Armitage, L. Stewart, Limitations of using Real-World, Public Servers to Estimate Jitter Tolerance of First Person Shooter Games , ACM SIGCHI ACE2004 Conference, Singapore, June 2004. [DOCSIS] CableLabs, Data-Over-Cable Service Interface Specifications Radio Frequency Interface Specification SP-RFIv1.1-I01-990311 , 1999. [I311] ITU-T Recommendation I.311, B-ISDN General Network Aspects , August 1996. [NGUYEN04] T.T.T. Nguyen, G. Armitage, Quantitative Assessment of IP Service Quality in 802.11b Networks and DOCSIS networks , Australian Telecommunications Networks & Applications Conference 2004, (ATNAC2004), Sydney, Australia, December 8 10, 2004. [RFC792] J. Postel, Internet Control Message Protocol , STD 0005, RFC 792. September 1981. [RFC1661] W. Simpson Ed, The Point-to-Point Protocol (PPP) , STD 51, RFC 1661. July 1994. [RFC1662] W. Simpson Ed, PPP in HDLC-like Framing , STD 51, RFC 1662, July 1994. [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474. December 1998. [RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. An Architecture for Differentiated Services. RFC 2475. December 1998.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Mac Web Hosting services

80 Networking and Online Games: Understanding and Engineering Multiplayer Internet Games reveal links that include significant propagation delays. Traceroute can assess paths using different sized probe packets, which can be used to reveal serialisation delay sensitivities along a path. (As of writing, Windows XP s tracert did not allow configuration of the probe packet s size.) Both traceroute and tracert can resolve the IP addresses into domain names of routers seen along a path. If the ISPs have used human-readable names, you can sometimes infer things about the geographical path being followed (e.g. if city names are encoded in the domain names of the router interfaces seen by traceroute). There are many web sites around the Internet that offer traceroute facilities from their location. You can find a list of pointers to such sites at http://www.traceroute.org For example, Figure 5.4 shows one of the listed sites (located at Telstra in Canberra, Australia) revealing the effect of propagation delay when performing a traceroute to www.lucent.com (192.11.226.2, based in New Jersey, USA). The traceroute output shows about 5 ms between first and seventh hop, then ~145 ms between seventh and eighth hops (from Sydney to Los Angeles) followed by another jump between Los Angeles and New York of ~70 ms (essentially next door to New Jersey). Note that the ~145-ms RTT between Sydney and Los Angeles is substantially higher than the ~80 ms estimate in Section 5.2.1. This can be attributed to the lower propagation speed of signals in optical fibre, queuing delays over multiple hops and the fibre s indirect physical path between Sydney and Los Angeles being much longer than 12,000 km. Another approach is to use information gathered by a modified game server. Figure 5.5 shows one published experiment where RTT samples from an active Quake III Arena server were used to plot the average jitter (per map played) against the average latency (per map played) [ARM2004]. One of the paper s conclusions was that jitter typically never exceeded 20 % of the average latency. Another observation from Figure 5.5 is that there are two broad clusters one where jitter is low regardless of latency (out to 300 ms latency) and another where jitter is roughly proportional to latency. The former is attributed to paths where most latency is propagation delay. The latter is attributed to 1 FastEthernet6-0.civ-service1.Canberra.telstra.net (203.50.1.65) 0.225 ms 0.193 ms 0.268 ms [..] 7 i-7-0.syd-core02.net.reach.com (202.84.221.90) 5.457 ms 5.636 ms 5.349 ms 8 i-0-0.wil-core02.net.reach.com (202.84.144.101) 153.923 ms 153.935 ms 154.057 ms [..] 11 0.so-3-0-0.CL1.LAX15.ALTER.NET (152.63.117.90) 153.84 ms 154.67 ms 154.303 ms 12 0.so-5-0-0.XL1.NYC9.ALTER.NET (152.63.0.174) 227.725 ms 265.947 ms 227.653 ms [..] 17 192.11.226.2 (192.11.226.2) 228.585 ms 229.29 ms 227.779 ms Figure 5.4 Traceroute from Australia to the USA showing long-haul propagation delays

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Mac Web Hosting services

78 Networking and Online Games: Understanding and Engineering Multiplayer Internet Games 1500 bytes long and had begun transmission just before packet 5 arrived, no amount of preferential queuing at the packet level could avoid packet 5 having to wait until packet 1 is transmitted. A partial solution to this scenario is offered by link layer technologies capable of concurrently interleaving multiple IP packets during transmission. For example, most consumer ADSL services actually run ATM over the ADSL physical layer, and then implement their packet service over a single ATM virtual channel [TR017, ARM2000]. However, in principle, the ADSL modem could utilise two or more parallel virtual channels upstream towards the ISP, and send different streams of cells on each virtual channel [I311]. Game packets and normal packets would be segmented onto distinct virtual channels and their constituent cells interleaved in time according to the packet s priority. Recall that ATM cells are only 53 bytes long (carrying 48 bytes of payload and 5 bytes of header). Thus, the serialisation delay experienced by a game packet drops down to the time it would take to send an ATM cell belonging to the normal packet already in flight. It is as though the police car could cut the truck in half. Unfortunately, ATM over ADSL is not used in this manner as of the time of writing, although it remains a distinct possibility as ISPs grapple with offering the best control of jitter and latency on the upstream side of consumer broadband links. Similar approaches are theoretically possible with Multi-Class Multi-Link (MCML) and Real-Time Framing (RTF) PPP over serial links [RFC2686, RFC2687] and segmenting packets across minislots in DOCSIS-based cable modem systems [DOCSIS]. Further discussion of such schemes is beyond the scope of this book. 5.3.3 Where to Place and Trust Traffic Classification Much of the classification, queuing and scheduling techniques discussed so far are practical with today s technology. The major stumbling block faced by ISPs today actually revolves around how they know, for certain, what packets to give priority to at any given time. (Or, in the terminology of this chapter, which packets are game traffic deserving preferential treatment.) Conversely, how does the ISP ensure that only authorised traffic gets preferential treatment? Only a game client and game server know for sure what IP packets constitute game traffic. The ISP wishing to provide preferential service must configure their routers with the 5-tuple rules or DSCP values that identify packets deserving preferential treatment. But how does the ISP initially discover the right 5-tuple or DSCP values? Ask the game clients for 5-tuple values? Trust the game clients to set the DSCP to a well-known value? In general, ISPs should not trust an outside entity (which includes hosts it does not control) to set the DSCP value appropriately. If it becomes well known that DSCP == 1 results in priority traffic handling, every application on every host will naturally be inclined to set DSCP to one on their outbound packets. We would be right back at the beginning of the problem, with everyone s packets classified into the game traffic queue. Thus the assignment of DSCP values must be performed by routers the ISP trusts, typically at the edges of the ISP s network. DSCP assignment will occur after 5-tuple classification by the ISP s router. This begs an obvious question how does the ISP s router know which 5-tuples represent game traffic? If an ISP hosts its own game server, then it knows one side of the 5-tuple the IP address and port number of the game server. This information may well be sufficient to

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services