Network Latency, Jitter and Loss perform classification at the edges and assign trusted DSCP values to game packets as they progress across the ISP s network. (Any packet heading to or from the game server s IP address and port is considered a game packet regardless of the client s IP address and port number.) In principle, the game client might use a signalling protocol to inform the ISP, on a case-by-case basis, when a new flow of game packets begins. This would inform the ISP of the specific 5-tuple associated with any particular game traffic. However, at the time of writing this book, no ISP implemented any such IP signalling protocol that is of use to a game client. (And if they did, there would be a number of difficult questions regarding authentication of signalling messages to ensure that only legitimate game clients were telling the ISP this 5-tuple represents game traffic .) An emerging approach is for ISPs to automatically detect game traffic by looking for particular statistical properties rather than specific 5-tuple values or well-known port numbers. Once a flow has been identified as having the statistical properties of game traffic, the flow s 5-tuple can be passed out to routers along the path who need to provide preferential treatment [STE2005]. When the ISP classifies on a 5-tuple, it becomes difficult for an opportunistic client to create packets that look like game traffic even though they are not. Given that the source and/or destination IP addresses are a key part of the 5-tuple classification rules, the opportunistic packets would have to actually be going to or from a known game server in order to gain preferential treatment. This is unlikely to be generally useful to non-game applications. Given that there are hundreds of ports on which game traffic might exist, and thousands of IP addresses that might represent game servers, ISPs and game developers face an interesting challenge to correctly, safely and securely identify game traffic for preferential treatment. This is very much an open question, unsolved as of the time of writing. 5.4 Measuring Network Conditions We can use the ping command to get an approximate sense of the RTT between one of our hosts and one of the other endpoints on the Internet. Ping is available on UNIX- derived systems (for example, FreeBSD and Linux) and Microsoft Windows systems. Ping uses Internet Control Message Protocol (ICMP) packets [RFC792] to probe a specified remote host and to measure the time it takes for the probe packet to go out and return. There is a caveat regarding ping many routers handle ICMP messages differently from regular packets, and thus ping can sometimes return RTT estimates that are higher (by a few milliseconds) than the RTT that would be experienced by actual TCP or UDP traffic along the same path. Nevertheless, running multiple repeated pings against a fixed, remote IP host can reveal paths where the RTT fluctuates around a reasonably consistent average value. Ping defaults to using a small, 64-byte IP packet. However, the user can force the use of larger ICMP packets in order to reveal the possible effect of serialisation delay along the path. Another tool that can provide insight into network path characteristics is traceroute (under UNIX-derived systems) or tracert (under Windows). Traceroute attempts to estimate the RTT to each router hop from your host to a nominated destination host. The difference in RTT reported at different numbers of hops away from your host can
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
Network Latency, Jitter and Loss Packet 1 Packet 2 Packet 3 Packet 4 Packet 1 Packet 2 Packet 3 Packet 4 Packet 5 Packet 1 Packet 2 Packet 3 Packet 4Packet 5 Packet 5 Packet 1 Packet 2 Packet 3 Packet 4 Packet 5 Time No preferential queuing for transmission of packets Preferential transmission queuing for packet 5 Arrival Transmission Figure 5.3 Preferential queuing and scheduling can allow priority packets to jump the queue transmission. The game packet has effectively jumped the queue of normal packets. (A real-world analogue would be a police car going around a queue of cars and trucks waiting to enter a single-lane toll road.) Because many scenarios involve only two priority levels, routers may also choose a simpler classification scheme based on a 6-bit Differentiated Services Code Point (DSCP) embedded in the IP header [RFC2474, RFC2475]. Often the 5-tuple classification occurs near the edges of an ISP network, and the result is encoded into the packet s DSCP field. Core routers then use simplified classification rules based on the DSCP to assign packets into priority and normal queues. Packet loss is also controllable on a per-queue basis. Each queue can be allocated different amount of space, ensuring that game packets can still be queued even when the normal traffic queue is full and starts to drop packets. Each queue may implement a different form of active queue management [RFC2309]. We have deliberately simplified this discussion to focus on the key elements. There are many different variations on classification, queuing and scheduling algorithms, which we do not need to explore here. Interested readers might refer to a book on IP quality of service for more details (for example [ARM2000]). 5.3.2 Link Layer Support for Packet Prioritisation Unfortunately, classification, queuing and scheduling at the IP packet layer does not solve all our problems when facing serialisation delays on low-speed links. Consider the real- world case of a police car jumping a queue of cars and trucks for entry into a single-lane toll road. The normal traffic is a mixture of short cars and long articulated trucks. Yet no matter how much priority we give the police car, if a long truck commenced onto the toll road an instant before the police car arrived, it may still have to wait awhile at the entrance to the single-lane toll road. There is no way for the police car to pull back the truck, or slice the truck in half, in order to avoid waiting. The same occurs when, for example, an ADSL modem only prioritises upstream traffic into game and normal categories at the IP packet level. In Figure 5.3, if packet 1 was
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
76 Networking and Online Games: Understanding and Engineering Multiplayer Internet Games for the best. This means identifying some IP packets as worthy of better service than other IP packets, and this carries with it many questions of how to differentiate between types of IP packets and what constitutes better service. 5.3.1 Preferential IP Layer Queuing and Scheduling There is not a lot we can do about packet loss due to bit errors except invest in and install high-quality link technologies. On the other hand, we can provide some control over congestion-induced loss, latency, and jitter by preferentially handling and forwarding important game packets over and above other traffic. Preferential treatment occurs in many real-world situations. Airlines have separate check-in counters for business and first-class passengers. Freeways have high-occupancy or peak-period lanes restricted to cars carrying multiple passengers. Police and emergency services vehicles can gain temporary preferential treatment and road access by turning on their sirens and warning lights. Central to any of these schemes is the goal of letting some people jump the queue and get ahead of others. This requires three steps classification (to identify who or what deserves preferential treatment), separate queuing (to isolate those getting preferential treatment) and scheduling (to actually provide the preferential treatment). The same applies in IP networks. Congested routers need to classify, separately queue and preferentially schedule some packets over others. Output ports that previously used only one queue will now have two (or more) queues one for normal best effort service, and another for high-priority packets. Many edge and access network routers today are capable of classifying IP packets using five pieces of information from inside each packet: The packet s source and destination IP addresses, The packet s protocol type, and Source and destination port numbers (if the packet is TCP or UDP). This is sometimes referred to as flow classification, microflow classification or 5-tuple classification. A set of rules in each router dictates which combinations of IP address and port numbers are considered priority packets and which are not. On the basis of these rules, every packet can be classified into a high-priority or normal priority queue. Ultimately, the scheduler decides when to transmit packets from each queue. Serialisation delays still apply to each packet transmission, and congestion-induced transmission delays and the potential for packet loss still exist. However, these events now occur on a per-queue basis. By splitting traffic into separate queues, we isolate the game traffic from much of the queuing and serialisation delays that afflict regular best effort traffic. Consider the two cases in Figure 5.3. Five packets converge on a congested router interface the first four are just regular traffic, the fifth packet is associated with an active game. In the absence of preferential queuing and scheduling, all five packets will be queued and transmitted in order or arrival. However, imagine if the router implements two queues normal and high priority. The first four packets can be placed in the normal traffic queue. The fifth packet is recognised as a game packet, placed in the high-priority queue, and is transmitted as soon as the current packet from the normal queue finishes
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Mac Web Hosting services
74 Networking and Online Games: Understanding and Engineering Multiplayer Internet Games 100-Mbit/sec home LAN and NAPT-enabled broadband router 192.168.0.13 192.168.0.12 ISP 192.168.0.1128.80.6.200 80-byte packets 1500-byte packets 128-Kbit/sec uplink Figure 5.2 A congested uplink can introduce jitter through queuing streams of different sized packets Consider the case of two home computers on a single 100-Mbps Ethernet LAN, communicating to the outside world over a broadband 128 Kbps link (perhaps early cable modem or ADSL service, Figure 5.2). Host 1 is generating a stream of 80-byte IP packets, one every 40 ms. Assume (for the sake of argument) link layer overheads on the broadband link add a fixed 10 bytes, making the frame 90 bytes long. These frames take 5.6 ms to transmit at 128 Kbps. Now host 2 suddenly decides to transmit a random stream of 1500 byte IP packets, with a mean interval of 500 ms. These larger packets arrive at the cable or ADSL modem and take roughly 94.4 ms to transmit. From host 1 s perspective, its stream of 80-byte IP packets now experience random jitter much of the time the packets go through immediately, but every so often there are a couple of packets that are delayed by up to 94.4 ms in excess of their usual transmission time. When host 2 s 1500-byte packet arrives at the broadband modem, subsequent packets from host 1 (which are arriving every 40 ms) must be queued for up to 94.4 ms while the 1500-byte packet is transmitted. After that, the queued 80-byte packets are transmitted (in 94.4 ms at least two packets are likely to have arrived from host 1). Host 1 s packets who were queued suffer additional latency relative to their siblings who arrived while the broadband modem s queue was empty. There is one more source of jitter that only affects IP over PPP/High-level Data Link Control (HDLC) [RFC1662]) over serial links. HDLC framing implements a technique known as byte stuffing to ensure reliable identification of frame boundaries over serial links. In simple terms, whenever the byte 0×7E appears in the IP packet, it is replaced by two bytes 0×7D-0×5E for transmission over the serial link. Thus, for example, a User Data Protocol (UDP)payload containing only the value 0×7E repeated 200 times would appear to be a 238-byte UDP/IP/PPP frame. However, the two hundred 0×7E bytes would each be doubled, resulting in a 438-byte frame being transmitted over the link. The associated serialisation delay would be that of a 438-byte frame rather than a 238-byte frame. In short, the serialisation delay over such links can be randomly influenced by the unknowable distribution of HDLC control bytes in the IP packets. In Chapter 10, we will look at typical game traffic packet sizes and inter-packet intervals information that can help estimate latency and jitter over various links. 5.2.5 Sources of Packet Loss in the Network A packet may be lost at many different points within the network, and for a number of entirely different reasons.
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 First, at the physical layer all links experience a finite (albeit usually extremely low) rate of data corruption which we refer to as bit errors, and characterise by a link s bit error rate. Bit errors may be introduced by poor signal-to-noise ratios in the digital-to-analogueto-digital conversion process, resulting in erroneous encoding or decoding of data. Bit errors may simply be due to electrical glitches in hardware. Some link technologies encode additional information within each frame to enable limited reconstruction of a frame after one-or two-bit errors. This is known as forward error correction,(FEC). In any case, uncorrected bit errors are usually discovered through cyclic redundancy check (CRC) calculations at both the transmitting and receiving end of a link. The CRC is a 16or 32-bit value mathematically calculated during transmission and sent along with each frame, and then recalculated at the receiver. If the original and recalculated CRCs differ, the frame is discarded. Since this can occur anywhere along an IP path, there is no way to inform the end hosts why or how their packet was lost. Second, transient congestion can become so severe that queuing points along the path simply run out of space to hold new packets. When this happens new packets are simply dropped until the queue(s) have emptied enough to take new packets. This is the network s most aggressive form of self-protection against too much traffic. Some networks even employ proactive packet drop mechanisms that introduce a random, nonzero loss probability well before the queue is full. (This is referred to as active queue management, with the most well-known variant known as Random Early Detection (RED) [RFC2309]). Proactive packet dropping is intended to force TCP-based applications to slow down before congestion becomes too serious, but they have little effect on non-reactive UDP-based game traffic (except to cause packet loss). Third, dynamic routing changes do not always converge immediately on a fully functional and complete end-to-end path. When route changes occur, there can be periods of time (of tens of seconds to minutes) where no valid shortest path exists between previously connected sources and destinations. This manifests itself as unexpected packet loss affecting tens, hundreds or thousands of packets. 5.3 Network Control of Lag, Jitter and Loss Online games, particularly the real-time interactive genres, need greater control over network latency, jitter and loss than more traditional email, online chat and web surfing applications. In this section, we will briefly review the mechanisms that ISPs can deploy to control network conditions on behalf of game players, and the difficulties faced by ISPs in utilising these techniques effectively. One approach is for ISPs to ensure that their link and router capacities far exceed the offered traffic loads, and to utilise creative routing of traffic to ensure that no single router becomes a point of serious congestion. Attractive because of its conceptual simplicity, this approach tends to be practical only for large or core network operators who have flexible access to physical link infrastructures (for example, a telephone company that owns both an ISP and the underlying optical fibre between cities). The just deploy more bandwidth approach tends not to work where high speed technologies simply cannot be deployed in a cost-effective manner (for example, where 100-Mbps home LANs meet sub-1 Mbps broadband access links, as in Figure 5.2). ISPs and consumers must contemplate ways of prioritising access rather than simply hoping
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 Statistical multiplexing assumes that everything will be okay if the average bit rate of all the inbound packet streams does not exceed the capacity of the outbound link. Or alternatively stated, most of the time most packets do not arrive at the same time and will not collide with each other s need for the outbound link . Of course, in reality, packet arrivals do coincide. When multiple inbound packets arrive at the same instant for the same outbound link, the packets are queued up and transmitted one after the other. We will refer to this situation as transient congestion. As previously noted, transmitting a single packet on a physical link introduces a finite serialisation delay proportional to the link s speed. Consequently, any packet queued up for transmission on a particular link will experience additional latency due to the serialisation delays of every packet in the queue ahead of it. We refer to this as queuing delay. Queuing delays appear under many guises in everyday life. Teller service at your local bank, or check-in at your favourite airline, involve queues to cope with customer arrival patterns that are bursty and that often exceed the processing capacity of the available tellers or check-in agents. The delay you personally experience can be short or long, depending on how many people arrived just before you and how fast the tellers (or check-in agents) are processing previous customers. In a typical consumer environment, queuing delays are seen when multiple computers on a home LAN try to send packets out through the same cable modem or ADSL modem. When outbound packets converge on the broadband router they will be queued up, waiting their turn to be transmitted on the upstream link to the ISP (which is usually ten to a hundred times slower than the local LAN link). Another form of queuing delay occurs on shared links where only one host can transmit at a time, and a link access protocol operates to share transmission opportunities amongst attached hosts. A modern example involves 802.11 b/g wireless LANs (so-called WiFi networks). The Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) mechanism and four-way handshake protocol (to avoid hidden-node problems) create access variable delays that depend on the traffic load on the wireless network (number of clients and/or number of packets per second being sent). For example, 802.11 b networks have been shown experimentally to add 50 to 100 ms to the RTT when heavily loaded by bulk TCP file transfers [NGUYEN04]. 5.2.4 Sources of Jitter in the Network As noted in Chapter 4, the actual path taken by a stream of packets can vary over time. When a route change occurs, the new path may be shorter or longer (in both kilometres and number of hops). Packets sent immediately after the route change will still get to their destination and yet experience a different latency. Route changes are usually uncommon, but can create a noticeable change in lag between a game client and server. On links that introduce noticeable serialisation delay, we can experience jitter due simply to the variations in size between consecutive packets sent over the link. This relates directly to congestion-induced queuing delay. Queuing delay depends entirely on the statistical properties of other traffic sharing a congested outbound link not just when and how fast the competing packets arrive, but their size distribution too. Because transient congestion depends on the vagaries and burstiness of entirely unrelated traffic, the queuing delay seen by any particular flow of packets can seem entirely random.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
Network Latency, Jitter and Loss Link layer bit errors causing packet corruption or Routing transients temporarily disrupting the path. 5.2.1 Propagation Delay and the Laws of Physics The speed of light dictates the top speed with which any information can propagate in a particular medium (air or optical fibre, for example). The speed of transmission along copper wires and cables is usually less than the speed of light in air, depending on the particular physical construction of the cables (for example, the dielectric properties of the insulation). Since the speed of light is finite, the laws of physics impose a lower bound on latency between geographically distant points on the Internet. We refer to this latency as propagation delay. As the speed of light is roughly 299,792 kilometres per second, propagation delays become noticeable over links spanning many thousands of kilometres or where the path hops through a number of routers each thousands of kilometres apart. For example, a 12,000-km path (roughly Sydney to Los Angeles in an airplane) would exhibit at least 40-ms latency (or 80-ms RTT) simply because of the finite speed of light. Most game players will come across this issue when they are connected to servers in different states or countries. It is also possible to find a high latency network path between two geographically close sites if the sites connect to the Internet via different ISPs (as noted in Chapter 4). A rough rule of thumb for propagation delay is latency (ms) = (distance of link in kilometres)/300 (If the speed of light in the medium is less than 300,000 kilometres per second the latency will be higher. This would be the case, for example, in optical fibre where the speed of light is about 30 % slower than that in a vacuum.) 5.2.2 Serialisation Serialisation occurs in many real-life situations. Crowds of people getting on a bus go through the door one at a time; we board planes one at a time; a worker loads crates onto a truck one at a time; and the one remaining bank teller who has not taken a lunch break can only process us one at a time. Serialisation occurs on most link layers, and is another source of latency in IP networks. Most link technologies are, at their lowest level, serial in nature. Frames are broken into sequences of bytes, and the bytes are sent one bit at a time. The finite period taken to transmit an IP packet one bit at a time is referred to as serialisation latency.This period of time depends on the speed of the link (in bits per second) and the length of the packet being sent. Serialisation latency adds to any speed of light delays experienced by a packet. Depending on the link layer technology, there might be extra bits at the beginning and end of each byte (traditional serial ports, for example) or at the beginning and end of each frame (standard Ethernet LANs, for example). Thus, the total serialisation latency experienced by an IP packet also depends on the framing protocol used by a particular link layer. Consider the time taken to transmit a 1500-byte IP packet on a 100-Mbps Fast
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
72 Networking and Online Games: Understanding and Engineering Multiplayer Internet Games Ethernet LAN and a nominally 56-Kbps V.90 dial-up connection using Point-to-Point Protocol (PPP) [RFC1661]): On the Ethernet link, a 1500-byte IP packet becomes 1526 bytes long (8 bytes of ethernet preamble, 12 bytes for source and destination MAC address, two bytes ethernet protocol type and 4 bytes trailing Cyclic Redundancy Check [CRC]), or 12,208 bits. At 100 Mbps, it takes 122 microseconds to transmit the frame containing this packet. On a V.90 dial-up link, the uplink is limited to 33.6 Kbps while the downlink rarely exceeds 51 Kbps. If we further assume PPP encapsulation of 8 bytes, the 1500-byte IP packet requires 1508 8 = 12,064 bits to transmit. Thus, a 1500-byte IP packet takes 359 ms to transmit towards the ISP (upstream) and 237 ms towards the client (downstream). Serialisation latency is primarily an issue with low-speed links common in consumer access networks (for example, dial-up modem service or consumer Asymmetric Digital Subscriber Link, ADSL). Using the above numbers, even a small 40-byte IP packet (48 bytes including PPP overhead) takes 11.4 ms on a V.90 upstream and 7.5 ms on a V.90 downstream (contributing 19 ms to any RTT measured using 40-byte packets). A similar situation occurs on high speed links when your ISP imposes temporary rate caps. For example, consider an ISP using ADSL2 + to offer 4 Mbps downstream service and a customer who has exceeded the download limit for the month. The ISP temporarily applies a rate of 64 Kbps until the end of the month, imposed at the IP packet level. Although each packet is still individually transmitted at 4 Mbps, the ISP achieves a 64Kbps long-term rate cap by limiting the number of packets per second that can be sent. The effective serialisation delay is as though the ADSL2 + link was literally running at 64 Kbps. Serialisation latency should only be calculated once (at one end of the link) since the receiving end is pulling bits off the link at the same rate that the transmitting end is sending them. Aside from a slight offset in time due to propagation delay, the transmission and reception processes occur essentially concurrently. A rough rule of thumb for serialisation delay is latency (ms) = 8*(link layer frame length in bytes)/(link speed in Kbps) (Note that for some link technologies, such as Asynchronous Transfer Mode (ATM) and Data over Cable Service Interface Specification (DOCSIS), the relationship between link layer frame length and IP packet length is nonlinear and nontrivial to calculate.) 5.2.3 Queuing Delays One of the core underlying assumptions of the Internet s best effort philosophy is that everyone s traffic is largely bursty and uncorrelated, allowing us to benefit from a concept known as statistical multiplexing. Multiplexing occurs when multiple inbound streams of packet traffic converges on a single outbound link at a particular router or switch. The inbound packets are multiplexed (interleaved in time) onto the outbound link. However, unlike traditional telephone company networks IP routers do not prearrange guaranteed timeslots on the outbound link for the competing inbound packet streams.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
70 Networking and Online Games: Understanding and Engineering Multiplayer Internet Games Time t1 Packet 2 Packet 3 Time t 2 Interval d2 Interval d3 Interval d4 Packet 1 Interval d1 Destination Source IP Network Latency: t2 t1 Jitter: d3 > d1, d4 < d2 Packet 1 Packet 2 Packet 3 Figure 5.1 Latency and jitter affect streams of packets travelling across the network All three have a negative impact on online game play. Latency affects the absolute sense of real-time interactivity that can be achieved within the game context. The latency of a network path between client and game server puts a lower bound on how quickly game-state information can be exchanged and consequently limits each player s ability to react to situational changes within the simulated game world. Jitter can make it difficult for players (and the game engine itself) to compensate for long-term average latency from the network. Jitter must be kept as low as possible. The consequences of packet loss should be self-evident game-state updates are lost, and the game engine (at client and/or server) must cover up the loss as best as it can. In the rest of this chapter, we will review the various sources of latency, jitter and loss inside ISP networks, and briefly outline the technical methods ISPs can utilise to reduce and control these characteristics. 5.2 Sources of Latency, Jitter and Loss in the Network Three main sources of delay add cumulatively to the total latency experienced by a packet. Finite propagation delays over large distances (we must obey the laws of physics) Serialisation delays (particularly over low bit rate links) Congestion-related queuing delays. A number of mechanisms introduce jitter by causing variations in latency from one packet to the next. Path length changes Packet size variations and Transient congestion. Packet losses are typically due to: Excess transient congestion causing queues to overflow;
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
Network Latency, Jitter and Loss Regardless of game genre, the realism of online game play depends on how well the underlying network allows game participants to communicate in a timely and predictable manner. In the previous chapter, we broadly reviewed the nature of modern IP network services. In this chapter we will discuss in more detail three characteristics of best effort Internet Protocol (IP) service latency, jitter and loss that have a significant impact on game play experience and game design. We will also look briefly at the technical methods Internet Service Providers (ISPs) can utilise to control these characteristics of their network services. 5.1 The Relevance of Latency, Jitter and Loss As noted in the previous chapter, IP packets carry information between sources and destinations on the network. Latency refers to the time it takes for a packet of data to be transported from its source to its destination. In many networking texts, you will also see the term Round Trip Time (RTT) in reference to the latency of a round trip from source to destination and then back to source again. In many cases the RTT is twice the latency, although this is not universally true (some network paths exhibit asymmetric latencies, with higher latencies in one direction than the other). In online gaming communities, the term lag is often colloquially used to mean RTT. Variation in latency from one packet to the next is referred to as jitter.There are a number of mathematically precise ways to define jitter, usually depending on the timescale over which the latency variation occurs and the direction in which it occurs. For example, a path showing an average 100 ms latency might exhibit latencies of 90 ms and 110 ms for every alternate packet fairly noticeable jitter in the short term, even though the long-term average latency is constant. Alternatively, the path might exhibit latency, that is, drifting 90 ms, 95 ms, 100 ms, 105 ms, 110 ms, 105 ms, 100 ms…and so on. For our purposes, it is sufficient to know that latency can fluctuate slowly or rapidly from one packet to the next. Figure 5.1 summarises the key difference between latency and jitter. Packet loss refers to (not surprisingly) the case when a packet simply never reaches its destination. It is lost somewhere in the network. A path s packet loss characteristic is often described in terms of packet loss rate or packet loss probability (ratio of the number of packets lost per number of packets sent). 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