A Study of Transport Layer Protocol Utilisation in Game Design

In the development of network games, considerations of the different factors that affect players experience are a necessary part of design of computer games. The network which multiplayer computer games utilise is an important part factor effecting end user experience.

I seek to trace the development of TCP and UDP in relation of the Internet and then analyse current practices and issues in the utilisation of the Transmission Control Protocol and the User Datagram Protocol in online game design.

Introduction

TCP and the underlying IP were developed concurrently to the establishment of the Internet and the experience gained through use and experimentation on networks during the early days of the internet.

In the early days of the Internet’s precursor ARPAnet, it was originally a protocol named IP (Internet Protocol) that performed functions equivalent to those of both the network and transport layer in the OSI reference model. IP provided reliability at the transport layer while providing addressing at the Network Layer.

With an ARPAnet growing towards its technical boundaries in terms of capacity, the waste that IP implemented in terms of reliability of the transport layer came to be realised. IP was later separated in the implementation of the Transmission Control Program (RFC675) in the mid 70s and then became separated to TCP (RFC761) and IP (RFC760) at the start of the 1980s by DARPA. [1]

In the early 1980s internetworking of computers were not limited to the ARPAnet. Numbers of disparate networks such for commercial, research and academic purposes were in existence. Some of the earlier truly networked games grew as pet and research projects. A number of simple computer games were created as academic projects throughout the 1950s, 1960s and became more available in the 1970s with coin-operated machines and games installed onto mainframes at universities. [3] It took until the early 1980s until networks were beginning to be used to run video games.

With the installation of BITNET, an academic network became “the most widely used research communications network in the world for email, mailing lists, file transfer, and real-time messaging” towards the start of the 1990s. [4] BITNET did used the NJE (Network Job Entry) protocol (somewhat of an implementation of IBMs network [2]), and most users accessed it at their universities via a terminal of a connected mainframe which was time shared. Around 1982 the introduction of Text based persistent role playing games which operated via telnet such as MUD1 (‘multi user dungeon’) and MAD (‘multi access dungeon’) ran on these university mainframes, the latter widely credited as the first network game utilising BITNET while the former was licensed to CompuServe and run on their network after it’s initial life on a mainframe accessed via telnet. Others such games followed on the various disparate networks. [5]

ARPAnet was transferred to TCP/IP on Janurary 1st, 1983.[2] This opened the door to the implementation of UDP (RFC768), a transport layer protocol that worked over IP but was simple and fast because it dropped the reliability of TCP.

In 1986 academic networks like BITNET become integrated into CSNET (computer science research network). TCP/IP was used[2]. Around this time Commercial groups such as Prodigy, CompuServe, America Online, GEnie and Delphi begin to operate their own subscriber networks based on X.25 packet switched WANs. [6] Many of these networks provided subscription game services. A typical service was Quantum Link which connected Commodore 64 systems via a 1200bit/s dial-up modem, provided by Quantum Computer services [7][8].

In the early 1990s The ARPAnet which became increasingly known as the internet began to become more open, particularly with ISPs being allowed to connect to it and provide services to the public, connections numbered in the millions. Most commercially sold games such as Doom (1993) however only supported LAN connection between a few computers using the IPX protocol [9].

The release of the game Quake (1996) was an early on-line game including the use of the Internet Protocol[7], demonstrating client/server online games in practice on the IP protocol. In practice however, user experience while playing Quake proved to be variable based on network conditions and other issues still relevant today and are worthy of further study. [10]

TCP and UDP Side by Side

Since the implementation of ‘TCP/IP’, it has remained the main protocols used for communications across different forms of networks. While traffic unique to games and entertainment applications using TCP and UDP is common on the internet, IP, TCP and UDP have given rise many of the staple protocols in today such as: HTTP and FTP over TCP and DNS and DHCP and various streaming over UDP to name a few.

Though the basic usage and structure of TCP and UDP have remained the same (as above), it can be stated that opposed to the UDP standard which has not be made obsolete since 1981, changes and additions to TCP and IP were common during the 80s as noted in the prefaces of the specifications of ‘IPv4’ and ‘TCP’ in 1981 (RFC791 and RFC793 respectfully). The introduction of IPv6, Differentiated Services and ECN to TCP and IP serve as recent examples of this continuing change.

Practical considerations for use of TCP and UDP in game design

Multiplayer games are complex applications that require the accurate and timely aggregation of the game state among clients. Determining how accurate and how timely a game is only one factor in deciding which network protocol to use in implementing network capabilities.

Consider these two arguments:

• As games with fast pace require players to receive real-time data, clients cannot stop and wait for packets to be received as TCP would allow.

• Important data representing the state of the game cannot be dropped, as UDP would allow, without resulting in a loss of synchronicity between client and server and between individual clients – until the application can restore synchronicity resulting in a skewed game outcome.

Although the choice is more then a reliability or speed binary as many factors that influence the end result of different implementations and should be considered, even in application design.

• Reliability can be maintained in applications using UDP by implementing reliability at the application level or at other higher layers thereby allowing games to maintain acceptable reliability while lowering the overhead by using UDP packet streams.

• Either short periods latency and other loss of synchronicity is usually tolerable by players and can be accounted for by creating more complex best-guess behaviour at the application level to fill in these gaps.

• Uncritical game state outside of client domain can be omitted from data being sent to the client such as events out of the players field of view.

• Applications can control the behaviour of the protocols below. For example TCP can be forced not to queue data before being sent with the TCP_NODELAY option, overriding its standard behaviour of implementing Nagle’s Algorithm to determine when to send a packet.

However at the lower levels, there are still issues that effect the choice of protocol in game design:

• Network factors such as frame size, bandwidth and latency can limit when and how frequently a packet can be sent, and how reliable it is in transporting the packet to the destination.

The protocols and systems themselves can serve as bottlenecks depending on the amount of traffic:

• Using TCP and UDP simultaneously can effect the performance of IP. Apparently TCP tends to induce packet loss in UDP packets. [11]

Current and future technological changes could impact on the use of TCP and UDP.

• Certain network configurations in games may require port forwarding to be set up on routers and may potentially limit game usability as many will be unsure about how to implement port forwarding.

Case studies

In an effort to learn more about current practices, I’ve conducted packet capture on four different games and will present some information and insights from the results.

A. Starsiege: Tribes

This game was released when most players used 56kbps dialup connections however that started to change a few years into the game. The games is typically played in servers with about 15-20 players and is a fast-paced FPS game in which player sprites move quickly and is similar in nature to the aforementioned Quake. It has LAN functionality as well.

Observations:

100% of packets were UDP.

The server sent frames that were uniformly 79 bytes (37 bytes data) with about 1 in 40 packets being 93 bytes (51 bytes data).

The Client sent packets that were mostly 63 bytes (21 bytes data) and a few packets one or two bytes little more or less

20 frames were transferred in both directions on average during the test; 12 from the server and nine from the client.

B. World of Warcraft

This is a 2004 MMORPG in which thousand of player connect to servers with different areas, RPGs are typically no as fast paced as other genres of games.

Observations:

95% Were TCP packets, which was surprising.

About half of the TCP frames implemented WOW above TCP which were (88 bytes in total) had about 22 bytes of data in the WOW data segment.

30% were (54bytes) with ACK in them and no data
The other 20% were data (between 100bytes and 300bytes sizes were quite various).

About 12 frames per second were sent on average during the test.

Most of the WOW over TCP packets were not recognisable by Wireshark however, some of them contained fields such as ‘Realm List’ indicating structure at that level.

C. Enemy Territory: Quake Wars

This game is a fast paced FPS game, about 10 years after the original Quake game.

Observations:

The game uses almost 100% UDP

95% of UDP packets were pretty standard
The client sent packets mostly 60 byte frames (18 bytes data). The client received packets from multiple IPs during the games. They varied from 100 to 1000 bytes

260 frames were transferred per second on average during the test.

5% of the packets had Quake III Arena Network Protocol over UDP which had a structure similar to this:

D. Farmtown

Farmtown is a basic Flash game in which game persistence is maintained via a server database. It is accessible via Facebook.

Flash is known to work closely with HTTP as Flash applications are most commonly found imbedded on web pages. Flash applications are known to not be able to transport data through UDP as yet and many implementations of flash games that have real time requirements have quite poor results when used on connections with low bandwidth or high latency.

5 frames were transferred per second on averageduring the test.

The game used a combination of TCP and HTTP (over TCP) communications at a quite intermittent rate.

SIN ACK and FIN messages were around 54 bytes which made up 70% of packets

The other 30% of packets were a combination of HTTP 1.1/ 200 OK, get and post commands (100-400 bytes) about 2 per second

Hey, over here!

I'm Michael, a game programmer from Melbourne, Australia who has been developing games for mobile, handheld and web platforms - also writing on game programming and design theory as well as personal experiences as a game developer and gamer.