Game Programming Algorithms and Techniques: A Platform-Agnostic Approach (2014)
Chapter 12. Networked Games
Networked games allow multiple players to connect over the Internet and play together. Some of the most popular games in recent years—whether Halo, Call of Duty, or World of Warcraft—either support networking or are exclusively networked games. Playing with or against another human provides an experience that even today cannot be matched by an AI.
Implementing networked games is a complex topic, and there are entire books on the subject. This chapter covers the basics of how data is transmitted over a network and how games must be architected differently in order to support networking.
Protocols
Imagine you are mailing a physical letter via the postal service. At a minimum, there is an envelope that has the addresses that define both where the letter is from and where it is going. Usually there also is some sort of stamp affixed to the letter, as well. Inside the envelope is the actual data you wanted to transmit—the letter itself. A packet can be thought of a digital envelope that is sent over a network. A packet has addresses and other relevant information in its header, and then the actual data payload it’s sending out.
For envelopes, there is a fairly standardized method of addressing. The from address goes in the top-left corner, the destination address is in the middle right, and the stamp goes in the top-right corner. This seems to be the norm in most countries. But for networked data transmission, there are several different protocols, or rules that define how the packet must be laid out and what must happen in order to send it. Networked games today typically use one of two protocols for gameplay: TCP or UDP. Some games also might use a third protocol, ICMP, for some limited non-gameplay features. This section discusses these different protocols and when they might see use.
IP
IP, or Internet Protocol, is the base protocol that must be followed to send any data over the Internet. Every protocol mentioned in this chapter, whether ICMP, TCP, or UDP, must additionally follow Internet Protocol in order to transmit data. This is even if the data is going to be transmitted over a local network. This is due to the fact that in a modern network, all machines on a local network will be assigned a specific local address that can be used to identify a particular local machine via IP.
The Internet Protocol header has a large number of fields, as shown in Figure 12.1. I won’t cover what most of the elements in the header mean, but countless resources online go over what each and every part of this header (and all the other headers in this chapter) refers to.
Figure 12.1 IPv4 header.
Two versions of Internet Protocol are in wide use: v4 and v6. An IPv4 address is a set of four 8-bit numbers (called octets) separated by a period. So, for example, an address on a local network might be 192.168.1.1. Because IPv4 addresses are 32 bit, there are roughly four billion possible combinations. This might have seemed like a huge number of addresses when IPv4 was first created in 1977, but in the modern day when even kitchen appliances connect to the Internet, four billion just was not enough.
To combat this problem, IPv6 was developed. It uses 128-bit addresses, so it can support an astounding 2128 addresses. Because the addresses take up four times the number of bytes, the IPv6 header must be different by necessity. One downside of IPv6 addresses is they are much more difficult to memorize because the full form is several hexadecimal numbers separated by semicolons, as in 2001:0db8:85a3:0042:1000:8a2e:0370:7334. IPv6 was officially “launched” on June 6, 2012, and at some point in the future, IPv4 will be deprecated. For now, most computers on the Internet are reachable via both IPv4 and IPv6 addresses. However, if your platform and ISP support it, switching on IPv6 is recommended.
ICMP
ICMP, or Internet Control Messaging Protocol, is not really designed to transmit large amounts of data over the network. Because of this, it cannot be used to send game data. That being said, there is one aspect of ICMP that is relevant when programming a multiplayer game: the ability toecho packets. Through ICMP, it is possible to send a packet to a specific address and have that packet be directly returned to the sender via the use of the echo request and echo reply ICMP modes. This echo functionality can be leveraged in order to measure the amount of time it takes for a packet to travel a round trip between two computers.
Knowing the round trip time, or latency, is useful in scenarios where there are multiple servers that a player can connect to. If the game measures the latency to all the possible servers, it will then be able to select the server with the lowest latency. This process of measuring the latency to a particular address is known as a ping.
When an echo request is sent, the recipient takes the packet’s payload and sends it all back in an appropriate echo reply packet. Because the ICMP header does not have any timestamp information, prior to sending out the echo request, the sender must determine the current timestamp and save it in the payload. When the payload comes back via the echo reply, the difference between the timestamp upon send and receipt can be computed, giving the round-trip time. This process is usually repeated a couple of times to get an average latency. The overall layout of an echo request packet is shown in Figure 12.2.
Figure 12.2 ICMP echo request packet.
The checksum in the ICMP packet is used to make sure there wasn’t any packet corruption in transmission, and is calculated from the values in the ICMP header and payload data. If a recipient gets an ICMP packet with a mismatched checksum, the packet gets rejected. Because the checksum is based on all the other data in the packet, it must be computed once the packet is ready to transmit. The identifier and sequence values are specific to echo requests—the identifier is usually unique per the machine, and the sequence value should be increased every time a new echo request is sent.
TCP
Transmission Control Protocol (TCP) is one of two methods a game might use to transmit data over the network. TCP is a connection-based protocol that provides for guaranteed delivery of all packets in the order they were sent. Guaranteed delivery may sound great initially, but as we’ll discuss, TCP is typically not as popular for games as the alternative protocol, UDP.
TCP is connection based, which means that before any data can be transmitted between two computers, they must first connect to each other. The way this connection is enforced is via a handshaking process. The computer requesting the connection sends a request to the target computer, telling it specifically how it wants to connect, and then the receiver confirms the request. This confirmation is further confirmed by the initial requester, completing the three step handshake process.
Once a TCP connection has been established, it is possible to send data between the two computers. As mentioned, all packets sent via TCP are guaranteed. The way this works is when a packet is sent via TCP, the receiver sends an acknowledgement of receipt. If the sender does not get the acknowledgement after a certain period of time (the timeout), it will resend the packet. The sender will continue sending that packet until it finally receives an acknowledgement, as illustrated in Figure 12.3.
Figure 12.3 In TCP, the sender keeps sending a packet until it receives an acknowledgement.
It turns out that TCP guarantees not only that all packets will be received, but that they will be received in the order they were sent. For example, suppose that three packets are sent in the order A, B, and C. If packets A and C arrive, but B doesn’t, the receiver cannot process packet C until it gets packet B. So it has to wait for packet B to be resent, and then once it finally is received, it’ll be able to move on. Depending on the packet loss, or percentage of packets that don’t make it through, this could really slow down the transmission of data, as shown in Figure 12.4.
Figure 12.4 TCP packets received out of order.
For a game, guaranteed ordering is usually an unnecessary bottleneck. What if packets A, B, and C in the preceding example contain information regarding the position of a specific player: that is, first the player was at position A, then at position B, and finally at position C. Once position C is received, the game really does not care about position B, as the player is no longer there. But with TCP, the game will be prevented from reading in position C until position B is received first, which is definitely not a desirable scenario.
There is one other helpful aspect of TCP to consider. All networks have an MTU, or maximum transmission unit, which determines the size limit for packets. If you attempt to send a packet that’s larger than the MTU, it will not go through. Thankfully, TCP is designed such that the operating system will automatically break up large blocks of data into the correct-sized packets. So if you need to download a 1MB file from the Web, the process of breaking it down into the appropriate-sized packets that must be received in the correct order is abstracted away from the application programmer when TCP is utilized.
In most scenarios, it probably will not be necessary to transmit such large amounts of data during gameplay. But there are some fringe uses where the automatic packet creation is helpful—for example, if a game supports custom maps, one issue is that new players may attempt to join a game session where they do not have the custom map. Using TCP, it would be possible to painlessly send that custom map, regardless of the size, to a new player trying to join the game.
That being said, for actual gameplay there are really only a few types of games that consistently use TCP. For a turn-based game, it makes sense to use TCP because all of the information sent over the network is presumably relevant, because it will define what actions a player performed on a particular turn. Another genre where TCP might see some use is in MMOs; most notably World of Warcraft utilizes TCP for all of its data transmission. That’s because all of the actions in WoW are strictly ordered, so it makes sense to use a protocol that has this ordering built in. But games that have more real-time action, such as FPS or any action games, typically do not use TCP/IP. This is because the forced guarantee of all packets might be to the potential detriment of the game’s performance.
Because TCP is a fairly complex protocol, the TCP header is as large as the IP header (20 bytes). The overall layout of the header is shown in Figure 12.5.
Figure 12.5 TCP header.
As with the IP header, I won’t cover every single element of the TCP header. However, one important concept bears mentioning—the port. Imagine an office has 50 employees at a particular address. In this scenario, it makes sense to have a total of 50 mailboxes, one for each employee. The receptionist will get the daily delivery of mail from the postal service, and then place each employee’s mail in his or her respective mailbox. Without a mailbox, it would be very frustrating for employees to find their mail because they would just have to go through an unsorted bin of every employee’s mail.
The same type of sorting is applied to the port when sending packets over the network. For instance, most web servers accept connections on port 80, which means data received on any other port can be ignored by the web server. There is a long list of Internet services and the ports they typically use, though the assignments are not strictly enforced. That being said, you probably don’t want to have your game use port 80 because a conflict could occur. There are roughly 65,000 ports to choose from, so although some do have standardized uses, most systems will have tens of thousands of ports available at any particular point in time. The game should select a port that it knows is not being used by any other program. Note that the source and destination port does not have to be the same, so although the web server will accept connections on port 80, the client connecting to the server can be on a different port.
UDP
User Datagram Protocol (UDP) is a connectionless, unreliable protocol. This means that you can just start sending UDP packets to a specific destination without first establishing a connection. And because it is an unreliable protocol, there is no guarantee that a packet will be received, no guarantee in what order packets will be received, and no functionality for acknowledgement of receipt. Because UDP is a much simpler protocol, the header for it is much smaller than TCP, as shown in Figure 12.6.
Figure 12.6 UDP header.
As with TCP, UDP also supports roughly 65,000 ports. The UDP ports are separate from the TCP ports, so there is no overlap if both UDP and TCP happen to be using the same port. Because UDP has no reliability, UDP transmissions can be much more efficient than TCP ones. But it also can be problematic in that there is no built-in way of knowing whether or not a packet actually was received. Although there might be some data that’s not necessarily mission critical (such as position information of opponents), there is going to be some data that is important to keeping the game state consistent. If you’re playing a multiplayer FPS and you fire your weapon, that information is important and its receipt must be guaranteed by the server and/or other players.
A tempting solution might be to use TCP for mission-critical information, and then UDP for the other data that’s not as important. But as shown in an INET 97 proceedings paper (mentioned in the references), TCP’s guarantee system running at the same time as UDP increases the number of UDP packets that are lost. A further issue is that even though the movement data may not be critical, and thus it makes sense to send it via UDP, we still need some way of knowing the order of the packets. Without any knowledge of ordering, if position B is received after position C, the player will incorrectly be moved to an old location.
Most games tackle this problem by using UDP, but then adding on a custom layer of reliability for the packets that need it. This additional layer can just be added at the start of the UDP data section—think of it as a custom protocol header added on. The minimum amount of data needed for basic reliability is a sequence number, which tracks which packet number it is, and then a bitfield for acknowledgements. By using a bitfield, a particular packet can acknowledge several packets at once, rather than needing to individually acknowledge each packet. This system also has flexibility, because if something truly does not need reliability or sequence information, it can be sent without that, as well. The actual implementation of this system is beyond the scope of this book, but a good starting point is the Tribes whitepaper in the references.
As mentioned before, UDP is the predominant protocol used for real-time games. Almost all FPS, action-oriented, RTS, and any other networked games that have time-sensitive information use UDP. It is also for this reason that almost all networking middleware designed for games (such as RakNet) only supports UDP.
Network Topology
Topology determines how the various computers in a networked game session are connected to each other. Although there are a large number of possible configurations, most games support one of two models: server/client or peer-to-peer. As with many decisions, there are tradeoffs and benefits of both approaches.
Server/Client
In a server/client model, there is one central computer (the server) that all the other computers (the clients) communicate with. Because the server is communicating with every client, in this model it is desirable to have a server with more bandwidth and processing power than the clients. For example, if a client sends 10KBps of data over the network, in an eight-player game that means the server must be able to receive 80KBps of data. This type of model is often referred to as a hub-and-spoke model, because the server is the central hub that all of the clients connect to, as inFigure 12.7.
Figure 12.7 Server/client model.
The server/client model is the most popular network topology used in networked games today. Most FPS, action games, MMOs, strategy games, turn-based games, and so on use a server/client setup. Of course there are some exceptions, as with everything, but by and large networked games employ server/client.
In the typical implementation of server/client, the server is considered authoritative, which means that it is required to verify most major client actions. Suppose a networked game allows players to throw dodge balls at other players; once a player gets hit by the dodge ball, that player is eliminated from that round. With an authoritative server, when a player wants to throw the dodge ball, the request goes to the server, which verifies that it is a valid action. Then the server will simulate the trajectory of the dodge ball and check every frame for whether or not any client was hit by the dodge ball. If a client gets hit, that client will then be notified by the server that they are out of the round.
The reason for the server verification is twofold. The first reason is that the server is going to have the most up-to-date position information of all the clients. One client throwing the dodge ball at another client might think they definitely hit that client, but that might be because they did not have fully up-to-date information regarding the target’s position. Furthermore, if the client can eliminate another player in the dodge ball game without being verified by the server, it would be quite possible for a programmer to make a cheat program that eliminates the other players. Cheating will be discussed in further detail later in this chapter.
Because of the authoritative nature of the server, implementing gameplay code for a server/ client game is more complex than in a single-player game. In a single-player game, if the spacebar fires a missile, the same code that detects the spacebar can create and fire a missile. But in a server/client game, the spacebar code must create a fire request packet that is sent to the server, and then the server notifies all the other players about the existence of the missile.
Because it’s a dramatically different approach, for games that intend to support both multiplayer and single-player modes, the best practice is to implement single player as a special case of multiplayer. This is done by default in many game engines, including the id Software engines. What this means is that single-player mode actually has the game running a separate server and client on the same machine at once. The advantage of making single player a special case of multiplayer is that any gameplay code that works in single player should also work in multiplayer. Otherwise, a network programmer may have to spend a great deal of time converting client-authoritative gameplay code to work in a server-authoritative setting.
If we go back to our sample dodge ball game, let’s imagine we want players to be able to lead targets. That is to say, they need some way of knowing in which direction the opposing players are travelling in order to make an educated throw that they expect to hit the target with. In the best case, a client can expect to receive updates regarding the position of opposing players from the server once every quarter of a second. Now imagine if the client only updated the positions of the opponents when the new position data is received from the server. That would mean that every quarter of a second, the opposing players are going to teleport to a new location. Imagine trying to aim a dodge ball in this scenario—it sure doesn’t sound like a very satisfying game to play!
To combat this, most games will implement some sort of client prediction, or the client making educated guesses of what happens in between updates from the server. In the case of movement, the way client prediction could work is that the server could send the position of the opposing players as well as the velocity of the opposing players. Then, for the frames between the server updates, the client can extrapolate the position of the opposing players based on their last known position and velocity, as demonstrated in Figure 12.8.
Figure 12.8 Client prediction extrapolates the position of the opponents in between server updates.
As long as the updates are frequent enough, the client should have a fairly accurate representation of the opposing players at all times. However, if the updates are infrequent due to a bad connection, the client prediction will be incorrect. Because the server is the final authority, the client must ultimately fix any discrepancies between the prediction and the actual positions. But if the prediction works well enough, it will appear smooth and seamless to the player.
This concept can also be extended to actions performed on the local end. If we want the gameplay to feel very smooth, as soon as a player presses the spacebar to throw the dodge ball, the throwing animation should begin onscreen. If the client waits until the server confirms the dodge ball throw, it might seem like the game is being unresponsive. The solution to this is that behind the scenes, while the server is actually verifying that the throw is valid, the local client can begin animating the dodge ball anyway. If it turns out that the throw was illegal, the client can correct the problem. But so long as the player is properly synchronized, the perception will be that the game is extremely responsive when dodge balls are being thrown.
Even though the server/client model is a very popular approach, there are some issues to consider. First of all, some games allow a single computer to be both the server and the client. In this case, there is a perceptible host advantage, which means that the player who’s both the server and the client will have all their actions instantaneously processed by the server.
One game where this problem cropped up was in the original Gears of War. What happened was that the shotgun damage was calculated with instantaneous ray casts. So what if two players both fire the shotgun at precisely the same time—with one player as the host, and the other player as a regular client? Well, time and time again, the host would always win the battle of shotguns. This lead to matches where everyone would try to get the shotgun because it was just so powerful. This issue was patched in fairly short order, but it was one of the reasons for the early dominance of the shotgun.
Another issue with the server/client model is that if the server crashes, the game immediately ends as all clients will lose communication with the server. It very difficult to migrate over to a new server (because all the clients will have incomplete information), so there is no potential for corrective action. This means that if a player is the host and is losing, that player can simply quit the game to boot all the other players, which isn’t very fun. But the flip side is that in a server/client model, if one client has really bad latency, it does not greatly affect the experience of any of the other players.
In any event, in order to prevent the issues associated with a host, many server/client games only support dedicated servers. In most cases, this means that the servers are set up in a specific location (often in a data center), and all players are required to connect to these servers (no one can be a host). Although it’s true that players with faster connections will still have an advantage over players with slower connections, any real advantage can be largely mitigated by having the servers at a third-party site. However, a downside of running dedicated servers in this manner is the increased cost of needing to deploy said servers.
Peer-to-Peer
In a peer-to-peer model, every client is connected to every other client, as shown in Figure 12.9. This means that there is a symmetric performance and bandwidth requirement for all of the clients. Because there is no single authority in peer-to-peer, there are a few possibilities: each client is simply an authority over their own actions, each client is an authority over another client, or each client simulates the entire world.
Figure 12.9 Peer-to-peer model.
One genre that commonly uses peer-to-peer is the RTS. The usual model used is a so-called lockstep model, where the network update is broken down into discrete “turns” of roughly 150ms–200ms. When any input actions are performed, the commands are stored in a queue and are only executed once the turn ends. This is why when you play a multiplayer game of StarCraft II, commands sent to units aren’t instantly processed—there is a perceptible delay before the units actually respond to the command because they are waiting for the end of the lockstep turn.
Because the input commands are sent over the network, every client in the RTS game is actually simulating all of the units. They are processing the inputs as if every player were local. This also makes it possible to save all your opponents’ commands and view them in an instant replay after the match is over.
The lockstep method results in the clients all being tightly synchronized with each other, and at no point will one player be ahead of another. Of course, there is a downside to this synchronization as well—if one client starts lagging, every other client must wait until that player catches up. But the lockstep approach is very popular for RTS games because it allows for a relatively small amount of data to be transmitted over the network. Rather than sending all of the unit information, the game is only sending a relatively small number of actions per minute, as even the best RTS player is not going to have more than 300–400 commands per minute.
Because in a peer-to-peer setup, every peer might be simulating part of the game world, the game state must be 100% deterministic. This can make it difficult to have gameplay based on chance; if a Zealot in StarCraft II could do a variable amount of damage based on virtual dice rolls, this might result in one peer simulating a round of combat differently than another peer. This doesn’t mean that random elements are entirely impossible in a peer-to-peer game (as in Company of Heroes), but that further effort must be taken to guarantee synchronization between peers.
Though RTS is arguably the main genre that sees peer-to-peer use, there are definitely other games that do so. One notable example is the Halo series, which uses a peer-to-peer model for its multiplayer. But that being said, it’s fair to say that peer-to-peer does not see nearly as much use in games as server/client does.
Cheating
A major consideration in any networked game is to ensure that the players have an even playing field. It’s the unfortunate truth that some players will do whatever they can to win, even if it involves breaking the rules of the game. In a networked multiplayer game, there are many ways rules can potentially be broken, and so whenever possible, networked games must be designed to prevent players from cheating.
Information Cheats
An information cheat is one where a player is able to get additional information that players normally are not intended to have. Suppose you are playing a game such as Team Fortress 2, which has a character that can use stealth to hide from other players. Normally, when the spy character goes into stealth mode, that character becomes invisible to all opposing players. But we already know that every so often, the server is going to be sending positional information of the other players. If the server is still sending the location information of the hidden character, it would not be that challenging for an experienced hacker to keep the spy visible, even in stealth mode.
The easiest way to stop information cheats is by limiting what information is available. In the case of the spy character, the solution would be to have the server stop sending position information for a character when in stealth mode. In this manner, even if a hacker figured out how to get the spy character to stay visible, all that would do is enable him to see the last location the spy was at prior to entering stealth mode. It still is cheating, but it typically won’t provide that much of an advantage.
But sometimes the solution isn’t quite that simple. For example, one cheat that’s very common in RTS games is the so-called map hack, which allows a player to see the entire map, including all of the opposing players. This can be a huge advantage in an RTS, because it allows a player to not only see the enemies’ movements, but also see what they are building. Because RTS games are built around the idea of certain units countering certain other units, this can be an insurmountable advantage.
Unfortunately, the solution of not sending the information can’t work in the case of the map hack, simply due to the way the lockstep model works. Because each peer simulates the entire game world, it necessitates knowing where all the enemy units are at all times. So the only real solution in this scenario is to attempt to institute cheating countermeasures. In the case of StarCraft II, Blizzard’s countermeasure is a cheat detection program called Warden. What Warden attempts to do is detect cheat programs that are running while the game is running, and if one is detected the account is flagged as a cheater. Periodically, Blizzard will then go through and ban all of the players who were marked as cheaters.
But the fact of the matter is that no cheat-detection program is unbeatable—this leads to almost a cat and mouse game where Blizzard updates Warden, cheaters get caught, and then cheat programs modify themselves so that Warden can’t detect them anymore. One popular countermeasure to Warden is to have a “kill switch” in the cheat program that exits immediately if a Warden update is detected, but such a system can only be successful for so long. In any event, Blizzard and any company that wants to have a serious competitive networked game must be very vigilant about preventing cheating.
Game State Cheats
Whereas information cheats can give one player an unfair advantage over the other players, a game state cheat can outright break the game. Once a player is able to modify the game state, that player can very quickly make the game unplayable. One scenario in which this can especially occur is when there is a host. If a player controls the server, it can be fairly difficult to prevent that player from cheating.
Suppose in the dodge ball game, the host sends out a message to every opponent that they were hit by a dodge ball and therefore eliminated from the round. Well, because the server is the authority, that could mean the game ends with the host as the winner. If third-party controlled dedicated servers can’t be used, there are a couple potential solutions. One would be to use one of the aforementioned cheat-detection programs; the other would be to add some client verification of the server commands. If the client sees that several players are eliminated at the same time, which is impossible, it can potentially trigger some code that says the server is cheating.
Man-in-the-Middle Attack
One of the most nefarious ways to cheat is to place a machine in between two machines that are communicating in order to intercept all the packets. This is known as a man-in-the-middle attack, and it’s especially an issue when plain text information is sent over the network. This style of attack is the primary reason why whenever you connect to a financial institution online, you use HTTPS instead of HTTP.
With HTTP, all data is sent over the network in plain text. This means that if you submit your username and password to a website that uses HTTP, it is trivial for the man-in-the-middle to steal that information. But with HTTPS, all the data is encrypted, which makes it nearly impossible for the man-in-the-middle to access the information. There are certain vulnerabilities that have been exposed in the HTTPS protocol, but practically speaking it should not be a big concern for most users.
In the case of a game, however, the biggest advantage of the man-in-the-middle attack is that it allows the cheating to happen on a machine that isn’t playing the game. This means that nearly all cheat-detection programs will be rendered impotent—they simply have no way of knowing that the packets are being intercepted and modified. A further concern is that having access to the packet information in general might allow a hacker to discover additional vulnerabilities in the game that can then be exploited.
One solution to this type of attack is to encrypt literally every packet so that only the server can decrypt and understand the packet. But this is probably overkill for most game information, and it does have the added overhead of needing to encrypt everything. But at the very least, whenever a game requires players to log in (such as in an MMO), some sort of encryption must be utilized to ensure that players don’t have their accounts stolen.
Summary
Networking is a very deep concept, and this chapter covered the important basics. The cornerstone of any networked game is the protocols that allow transmission of data over the network. Although TCP has guaranteed reliability, most games choose to use the more efficient UDP. Once the protocol is selected, the next major decision is what type of network topology will be utilized. Although the majority of real-time games today use a server/client model, most RTS games still use peer-to-peer. The topology will greatly influence how the networked game has to perform every update. Finally, an issue that every multiplayer game programmer has to face at one time or another is cheaters, and there are a number of countermeasures that can be employed to combat them.
Review Questions
1. What is the Internet Protocol? What is the difference between IPv4 and IPv6?
2. What is ICMP and how might it be used for a game?
3. What are the main characteristics of the TCP protocol?
4. What is a port in networking?
5. Why is the UDP protocol generally more preferable for real-time games?
6. What is a server/client model, and how does it differ from peer-to-peer?
7. What does client prediction entail? How does it enhance the gameplay experience for players?
8. Briefly describe how the peer-to-peer “lockstep” model works for RTS games.
9. Give an example of an information cheat and how it might be combated.
10. What is a man-in-the-middle attack, and how can it be prevented?
Additional References
Frohnmayer, Mark and Tim Gift. “The TRIBES Engine Networking Model.” This classic paper outlines an implementation of adding reliability and data streaming to UDP, as used in Tribes.
Sawashima, Hidenari et al. “Characteristics of UDP Packet Loss: Effect of TCP Traffic.” Proceedings of INET 97. This article goes into a very technical discussion as to why TCP acknowledgements can induce packet loss in UDP.
Steed, Anthony and Manuel Oliveira. Networked Graphics. Burlington: Morgan Kaufmann, 2009. This book provides an in-depth look at all the different layers involved with programming a networked game.