Network Gaming Backend Services by ps94506


									                                                                        2005:318 CIV


Network Gaming Backend Services

                   Thomas Karlsson

                   Luleå University of Technology

                  MSc Programmes in Engineering

    Department of Computer Science and Electrical Engineering
                Division of Computer Engineering

            2005:318 CIV - ISSN: 1402-1617 - ISRN: LTU-EX--05/318--SE
Network gaming backend services

          Thomas Karlsson

        14th December 2005
This master thesis was carried out at Agency 9 in Lule˚ , from May to October
2005 as the final part of my masters degree in Computer science at Lule˚ Univer-
sity of Technology.
    I would like to thank Tomas and Khashayar at Agency 9 for giving me the
opportunity of this thesis and for support during the work. And I would also like
to thank Johan Kristiansson for great feedback on the report.

As multiplayer network gaming becomes more popular, the numbers of players
and servers increase. A popular multiplayer game can have thousands of servers
and players. Such a game requires a system for players to find fast game servers
with specific characteristics. Furthermore more functionality such as player rank-
ings can be provided to make the game even more popular.
    This thesis evaluates different backend services for network computer games.
Services for finding game servers on the Internet and selecting subsets of these
servers are studied and how to create such services are investigated. Licensing,
statistics and player rankings are also examples of services that are studied.
    The main focus of the thesis is put on the system for finding game servers.
A prototype including a master server, a game server API and a game client API
has been designed, implemented and tested. Test show that the system can han-
dle thousands of servers and players. Furthermore has an authentication system
for letting game servers authenticating players been designed, implemented and

1   Introduction                                                                                                                     3
    1.1 Problem definition . . . . . . . . . . . . . . . . . . . . . . . . .                                                          3
    1.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                         4
    1.3 Delimitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                       6

2   Network backend services                                                                                                          7
    2.1 Server browser design . . . . . . . .                        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
    2.2 Network protocols . . . . . . . . .                          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    8
    2.3 Server side vs client side filtering . .                      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    8
    2.4 Master server . . . . . . . . . . . .                        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    9
        2.4.1 Traffic . . . . . . . . . . . .                         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    9
        2.4.2 Security . . . . . . . . . . .                         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   10
        2.4.3 Failure . . . . . . . . . . .                          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   11
    2.5 Game server . . . . . . . . . . . . .                        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   11
    2.6 Game client . . . . . . . . . . . . .                        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   12
    2.7 Web client . . . . . . . . . . . . . .                       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   12
    2.8 Authentication server . . . . . . . .                        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   12
        2.8.1 Creating secure license keys                           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   14
        2.8.2 Security . . . . . . . . . . .                         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   14
    2.9 Statistics . . . . . . . . . . . . . . .                     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   15

3   Implementation                                                                                                                   16
    3.1 Overview . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   16
    3.2 MINA . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   17
    3.3 Master server . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   18
         3.3.1 Protocol .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   18
         3.3.2 List . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   18
    3.4 Game server API      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   19
    3.5 Game client API      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   19
         3.5.1 Network .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   20
         3.5.2 GUI . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   20

    3.6   Web Client . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   22
          3.6.1 PHP . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   24
          3.6.2 Databasebuilder .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   24
    3.7   Authentication server . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   24
          3.7.1 License key . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
          3.7.2 Communication .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25

4   Evaluation                                                                                                                26
    4.1 Testing . . . . . . . . . . . . . . . . . . .                     .   .   .   .   .   .   .   .   .   .   .   .   .   26
         4.1.1 Theoretical limits . . . . . . . . .                       .   .   .   .   .   .   .   .   .   .   .   .   .   26
         4.1.2 Test setup . . . . . . . . . . . . .                       .   .   .   .   .   .   .   .   .   .   .   .   .   27
         4.1.3 Investigation into response time .                         .   .   .   .   .   .   .   .   .   .   .   .   .   27
         4.1.4 Investigation into maximum load .                          .   .   .   .   .   .   .   .   .   .   .   .   .   28
         4.1.5 Investigation into throughput . . .                        .   .   .   .   .   .   .   .   .   .   .   .   .   29
         4.1.6 Authentication server . . . . . . .                        .   .   .   .   .   .   .   .   .   .   .   .   .   30
         4.1.7 Source of errors . . . . . . . . . .                       .   .   .   .   .   .   .   .   .   .   .   .   .   31
    4.2 Comparison with similar work . . . . . .                          .   .   .   .   .   .   .   .   .   .   .   .   .   31

5   Discussion                                                                                                                33
    5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                  33
    5.2 Problems encountered . . . . . . . . . . . . . . . . . . . . . . . .                                                  35
    5.3 Further work . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                  35

A Abbreviations and acronyms                                                                                                   i

B Test results                                                                                                                ii

Chapter 1


Agency9 is a software development company. Their main product is AgentFX
which is a 3D engine in Java for creating computer games. Nowadays it is es-
sential for a computer game to have an online component to be successful. It is
important to make a game which provides a simple way to get started and is in-
teresting to play. To achieve and improve these features a number of backend ser-
vices can be provided. They will hopefully result in a more popular and playable
     Agency9 has made a network computer game, Megacorpsonline. This is a
simple shoot’em’up game to demonstrate their 3D engine. It lacks essential fea-
tures like player scores and functionality for the player to find online game servers.
It is hard to integrate existing backend services in Megacorpsonline since most
games are written in C/C++ and existing services are made for them and Mega-
corpsonline is written in Java.
     The main goal with this thesis is to create a scalable system that makes it easy
for the player to find online game servers. Furthermore, other backend services
should be considered and evaluated. Services such as licensing, statistics and
player rankings.

1.1 Problem definition
This thesis focuses on finding game servers for players. For example: When a
game server is started in i China, how does a person in Sweden find that game
server? And how does he find the game server at the house next door? And how
does he know which server is which? When he has played on different servers
for a while can he see his game statistics and compare to other players? These
are questions that could be solved by various backend services for multiplayer
network games. The following problems will try to be answered by this thesis.

   • The first main problem in this thesis is how to locate servers on Internet.

   • The second problem is to select a subset of the servers that has specific
     characteristics. Should the client fetch all the servers and filter them locally
     or should it fetch just a subset of the servers?

   • Can a generic system be implemented for different types of games, with a
     API that makes it easy for adding the system to an existing game written in
     Java. And a GUI that makes it easy for the player to find a game server with
     specific characteristics.

   • AgentFX is written in Java and the previous problems should be solved in
     Java. Nevertheless, programs in Java can be started with Java web start
     directly from a web browser just by clicking on a link. This yields the
     question if the first two problems also can be solved with a web interface?
     And can such an web interface be made to be responsive with a large number
     of servers?

   • A common problem for software developers today is pirated software [10].
     Can the developer be ensured that only paying players are allowed to play a
     network game?

   • Another service that makes game-play more interesting is statistics and
     ranking, how can statistics and player rankings be generated from a set
     of game servers? And how can the generated statistics be validated to be
     accurate? Can cheating be prevented?

1.2 Related work
Network multiplayer gaming has grown very popular during the past years with
Counter-strike [17] as one of the big pioneers and today Word of Warcraft [18] is
very popular. The time when people manually had to type in IP-addresses to game
servers is in the past. A popular network game today must provide some system
for players to easy find the game servers or opponents of their choice. Nowadays
there are many different systems that provides services for games. According to
[12] Kali was the first to provide a system for browsing online game servers. Now
it has the capability to browse and filter 400 different games.
    GameSpy [20] provides probably the biggest system today with many differ-
ent services for network games, and it has millions of users and supporting over
400 different games on different platforms. GameSpy has many products that pro-
vides gaming services e.g. GameSpy Arcade, GameSpy Arena and Roger Wilco.
GameSpy Arcade is a systems for handling games and game servers, it keeps track

of installed games and their updates, lets players chat with other players and start
peer-to-peer games with them, and it has a server browser for finding the fastest
servers. GameSpy Arena is another system for multiplayer gaming, it supports
many platforms and uses ladders to create competitions between players or teams.
Roger Wilco is a “virtual walkie-talkie” that lets player talk with each other during
the game.
    On the network side GameSpy provides the GameSpy query protocol [3], it is
a protocol designed for querying game servers about status information to be used
by game server browsers. It is probably the most frequently used query protocol
by many different games. The protocol uses UDP/IP for communication. Each
query consists of a series of key value pairs. There are four main queries that
can be sent to the server basic, info, players and rules, there is also a status-query
which is a sum of all four. Quake 3 protocol is like the GameSpy protocol a
commonly used protocol for querying game servers. It only has one query and a
response to queries which contains rules for the game server and the connected
players. The Quake 3 master server is a server with basic filter options, the list
query is followed by option as empty, full and demo. [19] is the online gaming services provided by Blizzards Entertain-
ment [21] for their games like Warcraft, Diablo and Starcraft. servers
communicate with their client products and provides chat rooms and list of game
servers to join. They also provide services such as ladder ranking and client up-
grades. FSGS and bnetd are two emulations. Bnetd was an emulation
of blizzards services letting people play Blizzards games. Free Standard
Game Server (FSGS) is a project that evolved from bnetd. Blizzard took legal
actions against these projects [14] and they were shut down because they claimed
that the programmers violated the Digital Millennium Copyright Act (DMCA)
and Blizzards end user license agreement (EULA).
    XQF [22] and aGSM [23] are third party game server browsers. They do not
provide any master servers, only a client that can browse existing game servers.
XQF is a server browser for the Linux platform and aGSM is only running on
Windows. On a lower level there are libraries that implement many of the games
query protocols such as GameSpy-, quake- and ase-protocols. Gamestat and qstat
are two such libraries for querying game servers. XQF uses qstat as underlaying
technology for querying master- and game-servers.
    The systems studied in this thesis uses similar strategies to provide browsing
and searching between servers. They uses some sort of master servers holding list
of game servers. The master servers can be a dedicated server optimized for this
particular work to a web server using HTTP for the server lists. Many games uses
GameSpy protocol for querying the game server about information. The Quake 3
protocol is also a commonly used protocol. Most systems runs on Windows only
due to that most games only runs on Windows, some systems runs on Linux, but

they are all more or less limited to run on a single type of operating system. These
system could probably be used to provide services for games made with in Java
with AgentFX, but they would then be limited to run only on the platforms the
system runs. Creating a new system in Java will allow the services to run on all
the platforms that AgentFX will run. Furthermore a web services can be created
to start Java games directly from a web page.

1.3 Delimitation
There are many different types of multiplayer games from virtual worlds with
thousands of players to one-on-one games for only two simultaneous players. This
thesis focus on services for FPS-type games but services can be used for other
games with a limited number of players on each game server. And due to the fact
that the thesis is limited in time, it has been limited to focus on certain services for
such games. A server browser system is the main focus, a basic server browser
system with a master server and API for the game client and game server is to
be designed, implemented and evaluated. Additional time will go to design and
implement an authentication server and client API.

Chapter 2

Network backend services

This chapter considers different backend services which can be used in multi-
player network computer games. It also considers different technologies that can
be used for these services.

2.1 Server browser design
This is an example of a system for letting players find game servers. The system
consists of three parts: the server browser (a part of the game client), the master
server and the game servers. The master server is a rendez-vous point for the game
servers and game clients to meet. The traffic flow of the system is the following
(see Figure 2.1): 1. Game servers sends messages to the master server telling
where they can be found. The master server stores this information in a list. 2.
The server browser asks the master server for the list of game servers. 3. The

                      Figure 2.1: A server browser system

master server replies with a list. 4. Then each one of the game servers in the list
is queried for information such as players and rules used by the game server. 5.
Game servers reply with information. This information is then used by the player
to decide on which game server to play.
    The master server approach described above is commonly used by systems
today, an alternative approach could be to instead of the master server use a peer-
to-peer approach. This would be more complex to design and implement but
advantages as bandwidth and computational power would be increased with more
users, and there is no single point of failure in the system.

2.2 Network protocols
The communication between the different parts of the system can be done in a
number of ways. As communication will be over Internet TCP and UDP are most
likely to be used. On top of them can either an application layer protocol like SIP
[9], protocols similar to the GameSpy protocol, or an own designed protocol be
used. An advantage to use an existing commonly used protocol like GameSpy is
that it makes the game compatible with other game browsers and no time has to
be spent on reinventing the wheel, which can save development time.
    When deciding which transport to use several factors must be taken into con-
sideration. A difference between TCP and UDP is that TCP is reliable and connec-
tion persistence which requires overhead in maintaining connections. UDP on the
other hand is unreliable and requires low overhead. The master server will handle
thousands of connections, the message sessions will be fairly short. In the case of
the game server it is a one way communication. Considering these factors UDP
is probably the best protocol, especially since the large number of connections
would create large overhead in handling connections with TCP and the master
server should be designed for optimal performance. For the game servers UDP
is probably also the better choice since it requires less overhead and the status
queries should not affect the in-game server performance.

2.3 Server side vs client side filtering
When designing the system, filtering of servers is a essential feature since there
can be thousands of servers and yet only a handful clients are interested in playing.
There are two approaches to this problem, either the master server is queried for a
subset of the game servers, or the game client fetches all game servers and filters
them locally. The advantages with master server filtering is that it reduces the
network traffic on the master server and the game servers since the client does not

have to query all the game servers. On the other hand it increases the work load on
the master server, the client need to query the master server every time a new filter
is applied or a new search is done. Server side filtering can not filter the servers on
ping, since the ping must be done from the client to be interesting for the player.
Hence, some client side filtering must be implemented either way. Only using
server side filtering generates higher work load on the master server and no server
side filtering generates more traffic. By combining server- and client-side filtering
both server load and traffic can be optimized.
    Another way to filter is to let different master servers hold different type of
game servers. E.g. There can be master servers for game servers based in Europe,
America or Asia. Or there can be master servers for different type of game types.

2.4 Master server
The core of the system is the master server, it is the bridge between the game
clients and the game servers. It has one main purpose, to hold a list of all the
available game servers so the game clients can find the game servers. The re-
quirements of the master server is straightforward, it should be able to receive
add/keepalive/remove messages from game servers and receive queries from game
clients and reply with the list of game servers.

2.4.1 Traffic
As the master server is the center of the system and everyone communicates with
it the traffic on the master server can with many servers and players be quite
staggering. The master server should be able to handle a lot of traffic, since it is
the core of the system, everyone uses it and if it does not work no players can find
any game servers.
     The add/keepalive packets from game servers can be pretty small, they just
have to contain port to the server, the IP-address can be read from the IP header.
The remove packets are the same size. Even with many servers the direct traffic
generated by game servers is fairly small. Indirect the servers adds six bytes(four
bytes for the IP-address and two bytes for the port number) to the server list and
accordingly six bytes to each server list response to the clients.
     The traffic to and from the client creates much heavier load on the master
server. The server is supposed to reply with a list of all the game servers. This
list can contain thousands of servers. Each server in the list is represented by four
bytes for the IP address and two bytes for the port number. In an larger system
there may be over 10000 game servers, in this case the response will be 60 KB. If
there are 10000 players and they send requests every 15 minutes there are about 10

queries per second, this results in 600 KB/sec (4.8 Mbps) traffic from the master
    There is a problem with the large server lists, when sending big UDP packets
over Internet they either get discarded or if allowed they get segmented by routers
and sent in smaller packets, this is an ineffective way and not commonly used
nowadays. Instead there are two optional methods to send large amounts of data.
Either send small packages that will not be segmented or use path MTU discovery
[24], this method discoverers the maximum size a packet can have.
    In order to send the list to the clients the list has to be divided into smaller
parts. There are two ways the list can be sent to the clients. Either the whole list
is divided and all the packets are sent right away or with a short delay between
them to avoid to flood the client. Or the client sends requests for each packet. If
the client send a request for each packet it makes it easier for the client to handle
with lost packages and the client is not flooded with packages, although it creates
slightly more traffic and load on the master server.

2.4.2 Security
The server described above has no security built in, everyone can register servers
and request server lists. Hence, it is open to denial of service (DoS) attacks. It is
easy to send false keep alive messages with spoofed IP-address in the IP header
[15]. Such an attack will fill the server list with bogus game servers trying to force
the master server to run out of memory. Since each server only takes 6 bytes it is
quite hard to force the server to run out of memory, a server with 512M RAM can
hold a list with 85 million servers. The real harm in such an attack is that when
the list get large, and when clients query that large list they will get bogus servers
and the master server will probably run out of bandwidth long before it runs out
of memory if there are many clients requesting the list.
    What can be done to prevent such attacks? One solution is to apply a chal-
lenge/response system. When an add message is received the master server sends
a challenge to the game server to see if it exists, and is only added if it replies with
the correct answer. The downside is that such a system generates more load and
traffic on the master server. This system handles the problem with spoofed IP-
headers, still a distributed DDoS attack can be done to fill the servers with bogus
    Another DoS attack could be to send queries for the list with spoofed IP-
headers, forcing the master server to run out of bandwidth, but this attack will
only give effect as long as the requests keep coming.

2.4.3 Failure
As UDP is unreliable and does not ensure that the packages reaches its destination,
failure has to be dealt with. In the case of add/keepalive/remove messages from
the game server there is no harm in loosing a packet. Add/keepalive messages will
be sent with approximately ten minutes apart and the timeout before purging non
responsive servers should be set higher. If a remove message is lost the server will
eventually timeout fairly soon and the harm of having a few non responsive servers
in the server list is no big drawback. Servers are known to crash or terminate
unclean without sending remove messages sometimes. When it comes to lost
queries and server list packages the client can resend the last query if the server
has not replied within a given amount of time.

2.5 Game server
In this system (outside of the in-game server) the game server has two main tasks,
register to a master server so the players can find the server and reply to status
queries from clients. The first task is pretty easy, just send keep alive messages
with a certain amount of time between (five or ten minutes) and send a remove
message when the server terminates. The second task is a little more complicated,
it has to reply with information about the server when a client request it. Different
games will probably have different types of data to show. A network protocol will
have to be implemented that is not game type specific. Looking at the protocols
used on the market today, the GameSpy protocol [3] is the most frequently used,
data is sent in clear text over UDP/IP. It is well documented which makes it easy to
implement. There are some other protocols frequently used by games e.g. Quake
3 protocol and ASE (all-seeing eye protocol), they are not as generic and not as
well documented. By using the GameSpy protocol the server gets compatible with
other systems. It also facilitates testing, since existing software can be used to test
the server.
    A reply to a status query is about 1-2 KB depending on how many rules and
players there are at the server. In the case of 10000 players sending queries each
15 minutes, there are about 10 queries per second, this results in traffic from the
server of about 10-20 KB/sec which should not affect the in-game server perfor-
    The GameSpy protocol uses UDP/IP and has a way of handling divided pack-
ages, with every package there is a query number and a package number and with
the final package there is a final flag. However there is no way to retrieve lost
packages, so if something is lost the whole query must be sent again.
    The only way this server could be compromised is to flood it with queries,

risking it to run out of bandwidth. But this is only for the GameSpy part of the
server, there could probably be easier to perform some more malicious kind of
attack on the in-game server, but that is not covered in this thesis.

2.6 Game client
The requirements on the servers are quite brief since they only does a few simple
things. The client on the other hand has to deal with both servers and user input
from the player, therefore the requirements gets more complicated. The client is
divided in two main parts, a network backend and a GUI. The network part should
handle all connections to both server types and logic for connecting and handling
master servers and their game servers. The GUI should use the network part and
handle all communication with the user. It should be possible to use the network
part and write a separate in-game GUI with e.g. openGL. The GUI should be easy
to understand and present the master servers and their game servers in an easy
way. It should also contain functions for filtering the game servers based on the
information they hold.

2.7 Web client
By using Java web start a program can be downloaded and started by a click on a
link in a web browser. This gives a simple way of players to test new games. A
web interface for browsing servers is now also of interest, as the player can surf
the web for a game and with one click try it out without have to install anything
(except the Java runtime environment). The problem with building a web based
server browser is to make it fast and responsive, by using the same method as
with the Java client the pages would be terribly slow with many game servers in
the system and searching would be a nightmare since for every search all game
servers has to be queried. Server side filtering could solve the problem. Another
solution is to build a database with info over all game servers and keep it update it
every 10 minutes of so. Then the web interface can use the database to search in.
This solution would make the web client fast, responsive and it should be easy to
implement since the hard work building the database and querying all servers can
be done fairly easy by modifying the Java client.

2.8 Authentication server
It costs a lot of money to develop a game and the market for pirated games are
huge [10], the issue comes up on how to ensure that only the ones that paid for

the game are able to use it. It is impossible to make an absolutely safe application
[13]. If someone wants to use a program they will find a way. Even if using
a license key that is impossible to crack it is easy for the hacker to bypass the
code that checks the license key. Hence, the software almost always can be used
cracked, but with implementing licensing you can provide further services such
as game servers for registered users, game statistics and automatic updates.
     If the licensing is put on the game server instead of on the client, then the
client is always allowed to be used. But if it fails to authenticate when trying to
join a game on a game server it gets kicked out. Now the software can be used
but it is worthless without a valid license key. But there is a problem with this
approach as well, if people will be able to put up their own game servers, and
the game server can be hacked then the algorithm for creating and validating the
keys could be tampered with. It is impossible to make a absolutely safe server but
by using private key for signing the license-key and a public key for validating
no fake key generator could be made since the game server does not contain the
code for creating keys. Another solution is to create a global authentication server
which the game servers authenticates players against, then no checking has to be
done by the game server. An advantage of having a global authentication server
is to be able to register users and save their license keys so only one user can use
the same license key, and further can the authentication server be used to provide
further services, such as player statistics and rankings.
     Trusting the game servers is a problem when they authenticates the users to the
authentication server. Someone can put a bogus game server and let clients con-
nect to it and gather license keys, usernames and passwords. Parts of the informa-
tion should therefore be encrypted all the way from game client to authentication
server to make it hard to gather complete information about user accounts.
     Besides licensing the authentication server can be used to keep track of users
and what keys are in use, allowing every key to be used by only one user. A brief
requirement list would include that the server should be able to register a user with
a key, authenticate an existing user and removing an user.
     Similar to the master server the load on the authentication server will be very
high in a system with many players. And it is very bad if the authentication
server becomes non responsive since then no one can be authenticated and no
one can play the game. So it would be desirable to have multiple authentication
servers to share the load between and a failover system for backup if one server
fails or is compromised by hackers. However, the use of multiple authentication
servers leads to another problem. Should there be one database where the users are
stored or one for each authentication server. Multiple databases gives a problem
of synchronization between the databases, and one database makes the system a
little more vulnerable, but is probably preferred since it not that vulnerable since
it is hidden behind the authentication servers.

2.8.1 Creating secure license keys
There are a few basic requirements when creating license keys, first every key
should contain an unique identifier, second it should contain an expiration date
and third it should contain some sort of checksum or signature so it is hard to
guess. It should also be impossible to reverse engineer the key to create a key
generator, and it should be human readable and fairly easy for human to write into
the program.
    If licensing should be preformed by the the game client or the game server
the code of creating a license key should not be in that software. They must be
able to verify that a key is valid without knowing how to create one. This can be
done by using digital signatures with a public/private key pair [16]. First sign the
license key with the private key and then the public key can be used to check if
the license key was really signed with the private key. If all the licensing is done
on a separate authentication server then creating a license key can be made a little
easier. The same algorithm can be made for creating and verifying the key. This
can be done by calculating a MD5 or SHA-1 checksum, MD5 should be avoided,
maybe even SHA-1 see [11].
    The first method with signing the keys with private keys creates keys of 128
bytes length. The MD5 hash method creates keys of 16 bytes and SHA-1 creates
a key of 20 bytes. The keys has to be made readable to humans, one way is to
show the hex values, this requires double the amount of digits than the length of
the key in bytes. Another way is to Base64 [4] encode it this creates a key that is
greater than the original key by a ratio of 4:3.

2.8.2 Security
Besides creating secure license keys there are more security issues to consider
when making an authentication server. To send license keys, user names and pass-
words in clear text over the Internet is not a good idea, so some sort of encryption
is required. Secure socket layer SSL [2] is a way to provide public/private key
pair encryption over TCP/IP. The SSL connection takes some time to establish,
and this along with using a key that is hard to guess this prevents repetitive key
guessing. Nevertheless, the slow start of an SSL connection can be used for denial
of service attacks. By starting many connections the server will either run out of
sockets or get very slow. This can be reduced by keeping short idle timeout and
disconnecting users with false login attempts.

2.9 Statistics
Everybody wants to be the champion of the world. And by adding global statistics
and player rankings to a game, everybody can fight to be number one. This will
increase the competitive feeling when playing the game. It is simple for a game
server to build local statistics and player rankings. The big challenge with creating
global game statistics is to ensure that all the data is correct. There will always be
people trying to cheat and adding false data to gain higher position on the ranking.
    First of all a player database is needed and player authentication on the game
server is required. An authentication server will take care of these things. And
each game server can build local statistics. How do we gather all the local game
statistics? And how do we know that the data is valid? Gather the data can be
as easy as getting the list of game servers from the master server and query each
game server for statistics with a query protocol. But how can the game servers
be trusted? Without any system to ensure that it is a real game server someone
could put up a bogus game server that replies with false statistics. The only way
to be entirely sure that the game server can be trusted is for the same company to
provide the game server so no person outside can modify the data. But there is still
a problem with people trying to cheat in the game for example with wall-hacks
and auto-aim.

Chapter 3


This chapter describes which parts are implemented and how they are imple-
mented. All parts are written in Java with the Eclipse development environment
on Linux except the web interface which are written in PHP. For network commu-
nication MINA framework is used.

3.1 Overview
The network services implemented are (see Figure 3.1) a server browser system
consisting of a master server, a game server API, a game client API and a web
client. An authentication server has been implemented as well. The basic func-
tions of the system is as follows. The game server API is used to register to the

                          Figure 3.1: System overview

master server and reply with info to the game client API. Game client API are

used by the player to find game servers with specific characteristics. It sends re-
quests to the master server for lists of game servers, then it requests info from the
game server API. Parts of the game client API is used to build a database over
all game servers. This database is used by the web client to show available game
servers. The authentication server is to be used by the game servers to validate
that connecting player have a valid license key.
    A simple scenario when the system is used could look like this. A player
starts the game client, it sends a request to the master server which replies with
a list of servers. The game client sends request to all these server, which replies
with information such as which map it is using, what rules are set and where it is
located. The player filters the server list to show only the servers with a certain
map, and sorts the server on ping. The server with the lowest ping is chosen
and a connection is started. When the player connects the game server sends an
authentication request with the clients license key to the authentication server, the
authentication server answers that the key is valid and the player can play.

3.2 MINA
All parts of the system uses network communication, either as servers or clients
or both. To ensure that the focus of the implementation is to create protocols and
the functionality wanted a network framework MINA [1] is used to handle the
network threads. MINA is a network application framework for Java. It provides
an unified API for various transport types such as TCP/IP, UDP/IP and In-VM
pipe communication. It also provides both I/O and protocol filters such as SSL
filter and unit testability. MINA provides an API for creating scalable and high
performance network applications.
    MINA can be used in two ways. With I/O-layer data communication is done
with data buffers or with the protocol layer then data communication is done with
objects. Codec classes performs the transformation between data buffers and mes-
sage objects. Once a protocol is implemented it works for all different transport
types MINA supports. All parts that use network communication are built with
MINAs protocol layer.
    MINA unfortunately does not support broadcasting or multicasting yet. Broad-
casting is a feature that is needed in the server browser for full functionality. In
order for the server browser client to send broadcasts to find servers on the local
subnet a minor change was made in MINA’s DatagramAcceptor class.

3.3 Master server
The master server is a fairly simple server with only three use cases. The imple-
mentation is chosen to be optimized for performance, so security improvements
and features such as filtering are not implemented. It is designed to handle a large
number of requests from thousands of clients. Therefore UDP is chosen as pro-
tocol to focus on handling the share load of messages and not have to handle the
overhead TCP-connections brings. No server side filtering or challenge response
system are implemented, only the basic functionality is implemented to optimize
performance. There are two main parts of the server, the network backend and
the server list handling. The network backend is implemented with MINA. MINA
handles all threads management and NIO and makes it easy to implement a server
since the focus can be on implementing the protocol and functionality.

3.3.1 Protocol
The master server protocol uses UDP/IP for communication. There are three dif-
ferent incoming messages and one outgoing. The outgoing packages are limited
in size to 1450 bytes to avoid that they get segmented by routers. An incoming
packet has the following structure:

|--4 byte header--|--1 byte type--|---data---|

Where the packet type can be keep alive, remove or get server-list. The data is in
the case of keep alive and remove two bytes for the port number. The get server-
list messages has four bytes which indicates which server to start the reply with
since the outward going packages can only be 1450 bytes so only 233 servers can
be sent in each package. An outgoing packet has the following structure:

|--4 byte header--|--data--|

Where the data is six bytes (four for the IP address and two for the port number)
for each server in the list. When there are less servers in the list than can be put in
message a server with address is added to show that it is the last

3.3.2 List
In addition to the master server networking part it contains a list class. The list
class contains a list of servers and functions for adding new servers, updating
timestamp on existing servers, removing servers and a timer for removing servers
with old timestamps. The server list is implemented as an ArrayList as this should

give good performance for this application, and all the actions on the list are syn-
chronized to avoid simultaneous editing from the timer and incoming requests.
Instead of a list in the memory a database can be used, but it is slow compared to
a list and makes the server harder to install. When using a list there is one draw-
back. If the server crashes, the entire list is lost, but this is not a big issue since
in a few minutes the game servers will have sent new add/register messages. If
server side filtering should be implemented, a database might be of interest when
selecting parts of the list.

3.4 Game server API
The game server API has two objectives. First it should wrap the GameSpy pro-
tocol and second it should send keep-alive messages to the master server. It is
designed to be easy for the developer to add the GameSpy part to their game
server. The GameSpy protocol is a text based protocol that uses UDP/IP for com-
munication and has four main queries. The API contains one main class Status-
Connection see figure 3.2, it uses MINA to setup a server. Incoming status request
are decoded by a GameSpy decoder class and events are fired to the StatusListener
interface. The connection to the master server MasterConnection is created by the
StatusConnection class and the information about that connection is read from a
XML file.

                       Figure 3.2: Game server main classes

3.5 Game client API
The servers are fairly simple and just replies to queries, the game client gets more
complicated as it both sends these queries and has to deal with the data that is

returned. It is divided in two parts, a GUI that handles the user input, and a
network part that handles all the communication with the servers.

                         Figure 3.3: Game client overview

3.5.1 Network
The network part is able to query master servers for game server lists and then get
info from all the game servers in that list. The main class in the network-API is the
MasterServer, it is the class that the GUI uses, see figure 3.4. It represents a master
server and contains a list of game servers. It provides methods for receiving master
server list and getting information about the servers in the list. The GameServer
is a storage class and holds data about a game server.
    The server monitor creates network connections with MINA. Since all the pro-
tocols uses UDP, the incoming messages can be divided into several packets, the
MessageQueue queues and merges divided messages until all parts of a message
is received. The ServerConnectionQueue contains a queue for the game servers
that should be updated. It contains a thread that creates a maximum of 50 simul-
taneous connections to game servers, it sends new messages if a server does not
respond and eventually remove timed out servers from the queue. The protocol
codec classes implements the GameSpy protocol and the master server protocol.

3.5.2 GUI
The GUI is designed to present the server data in a comprehensive way for the
player. The main class of the GUI is the ServerAgent, see figure 3.5. It is the
owner of the classes for the master server list, the filter list, the game server table
and the game server info lists. It also handles all actions from the user, and the

Figure 3.4: Game client main classes

communication with the ServerAgent package. The main window class puts the
ServerAgent in a window and adds menus, tool bar and status bar. The program-
mer can choose to integrate the ServerAgent in his own program or use it as a
separate window.

                          Figure 3.5: GUI main classes

    The master server list presents different master servers available, see Figure
3.6 The game servers of selected master server is shown in the game server table.
There are two special kind of master servers which are not real master servers.
One is for storing favorite servers, all servers in this master are put there by the
user. The other is for showing the game servers on the local sub-net, these servers
are found by broadcasting a status query on the default port game servers listens

3.6 Web Client
The web client should have almost the same functionality as the game client. It
should display the game servers of a specified master server, and the user should
be able to preform searches but with a web interface. The web client could be
implemented entirely in a script language like PHP, and do the same thing as the
Java game client. However, when searching all game servers have to be queried
for each search. Instead the Java application from the game client is already im-
plemented and can be used for querying servers. It is in the web system reused for
querying servers and build a database for the PHP pages to fast and easy search
trough for servers. The drawback with this is that the database is not always up-
dated, since the updates only happen with a amount of time in between maybe 15
minutes. Nevertheless it reduces the load on the master server and game servers
since only one client queries them instead of thousands, the load now instead is
placed on the web server.

Figure 3.6: The server browser user interface

3.6.1 PHP
The PHP pages are for displaying the game servers for the player and providing
functionality to search for servers. A MySql database is used where the servers
are stored with some information for searching. The web pages also provide func-
tionality for showing more information about a specific server, this is achieved by
using gsQuery [8], a PHP class for querying game servers with the GameSpy pro-
tocol. And finally they provide a way of starting the game directly by clicking a
link in the web browser, this functionality is provided by Java web start.

3.6.2 Databasebuilder
The database builder uses the ServerAgent package (see figure 3.7) for retrieving
a game server list from a master server and then fetch information about the game
servers and store them in a database. The updates are scheduled regularly. The
database builder uses the info from the game servers and saves name, address,
number of players, map, game type and location. Since the PHP-pages can not
ping game servers from the client, and ping from the web server or the database
builder is not interesting, location is the only means for the player to know how
good the connection to the server he has.

                   Figure 3.7: Database builder main classes

3.7 Authentication server
An authentication server is for validating that only the ones with a valid license
are able to play the game. It has to be able to register users with license keys,

authenticating users, remove users and change user data. A database is required
to save the username, passwords and license keys to be able to authenticate the
users, and so no user can register with a key that is already in use.
    Furthermore there are numerous security issues that has to be dealt with when
designing an authentication server. The license keys has to be secure, i.e. people
should not be able to alter or reproduce a key. The usernames, passwords and
license keys should not be sent in clear text over the Internet. Furthermore a
database has to be created to keep track of the users and which keys are in use,
since every key should only be used by one player.

3.7.1 License key
The license key includes a unique id, a expiration date and a checksum. It also
has to be human readable. The first part of the key is 3 bytes of unique identifier,
this gives room for 16 million keys. The second part is a 2 byte expiration date, its
the number of days from year 2000 until the key expires. This gives a maximum
valid key until 2179. And the final part of the key is a checksum of the previous
parts and a password for the ability to generate different keys. The key generation
and validation class is designed with polymorphism so that the algorithm for cal-
culating checksum can easily be replaced. Now MD5 or SHA-1 is implemented,
but vulnerabilities has been found in these algorithms, at the moment SHA-1 is
preferred but it is recommended that they should be replaced with a more secure
hash algorithm in the future, see [11]. These kind of keys are not to be used in a
program with locally licensing, because then they are easy to reverse engineer by
examining the code that creates them and a key generator can easily be made.

3.7.2 Communication
The security of the communication channel is done over TCP/IP by SSL - se-
cure socket layer. This is done by using public-private key pair cryptography [7].
MINA provides a SSL I/O-filter that uses Java 5 cryptography classes, this made
it easy to implement SSL. Public and private keys and a trust relationship has to
be created for the communication to work.

Chapter 4


This chapter evaluates the work that has been done by testing and comparing it to
similar works. The master server has been thoroughly tested, the authentication
server and other parts have only had basic functionality tests and some minor
performance tests to see that they can handle adequate volumes of data.

4.1 Testing
The master server is the center of the system, if it does not work properly it be-
comes impossible to find game servers. Therefore, it is important to find all its
weaknesses, the stability and performance has to be thoroughly tested and verified.
Three different tests has been conducted, response test, stress test and throughput
test. Response tests are performance tests under anticipated load. Response times
for various transactions are measured. Stress test are to determine the load which
a system fails and how it fails. Throughput test are a performance test where
throughput is measured instead of response time.
    If an authentication server is used it is another essential part that will break the
whole system if it fails. The tests on this server have not been as extensive. One
test has been done to establish the maximum number of authentications the server
can handle each second.

4.1.1 Theoretical limits
The game servers generates very little direct traffic, every 10 000 servers which
each are sending a keep alive message every 10 minutes, and each keep alive
packet is 32 bytes the 10 000 servers generates: 16.7 packet per second which
equals 533 bytes per second or about 0.5 KB/s. Indirect the servers generates
more traffic i.e. when a player retrieves a server list each game server generates

6 bytes. Every 10 000 servers generates 60 KB. Every 1 000 players updating
every 10 minutes generates now 1.67 server lists per second which is about 100
KB/s of traffic. A 10 Mbps connection can handle 1280 KB/s. Since thousand
players generates 100 KB/s There can be approximately 12800 players on a 10
Mbps connection.
    The calculations show that a server with a 10 Mbps connection can theoreti-
cally handle approximately 12800 players with 10 000 servers. With a 100 Mbps
connection it could handle approximately 128000 players with 10 000 server.
These numbers are theoretical and only takes the bandwidth generated by the play-
ers in consideration. If the server is able to process such an amount of requests is
so far unknown.

4.1.2 Test setup
The test setup consists of three computers, one with the master server, two load
generators which test software that can simulate a number of clients and one client
that measures response time. To simulate clients the game client software backend
has been used to send server list request. Request has been sent periodically with a
delay between them based on how many clients it should simulate. The delays has
been calculated with the assumption that an average player sends updates every
10 minutes. The use of several load generators is because that the load generators
should not be saturated before the master server is.
    The master server was run on a computer with the following specifications:
Ubuntu Linux with Kernel 2.6.10
AMD Athlon XP 2200+ (1800 Mhz)
512 Meg RAM
10/100 Mbps Ethernet

4.1.3 Investigation into response time
Response tests are preformed in two ways: response time as server list increases
and response time as concurrent users increase. The tests are done with client-
and server-simulators that sends the theoretical amount of traffic generated by
servers and clients, based on the assumption that each player and server sends
updates every 10 minutes. The response time is measured by a client that sends
list requests, and measure the time until the entire list is received.
     The first test was done with a constant simulated number of 2000 users and
the number of servers are set at seven different values between 1000 and 50000
servers. The second test was done with a constant amount of 1000 servers and the
number of clients was varied between 100 and 100000 in ten steps, see Appendix

B for all measured data. When changing the load of the server the measured values
was observed to ensure that the server had stabilized at a certain load. Then values
were measured three times and the median of the values was taken.

               Figure 4.1: Response time as game servers increase

    The response time increases with the size of the server list, see Figure 4.1. This
is as expected as a lot more data has to be sent. There can be 233 servers in every
datagram package, and next package is requested when the previous is received,
if one package takes t time to receive, n packages takes n*t time to receive. The
response time when the number of clients increase is almost constant, it only
increases slightly when the master server is under high load.

4.1.4 Investigation into maximum load
The purpose with the stress test is to determine the maximum load a server can
handle before it fails. And also how the server fails. Stress test are also done
in two ways. Increasing the number of servers with a constant number of clients
until the master server becomes unresponsive or crashes. Or increasing the num-
ber of clients with a constant number of servers until the master server becomes
    The stress test was done increasing server list traffic until the server CPU were
at 100%. This were at about 1500 KB/sec, the server then started not to respond
to all requests. Even with more traffic the server ran stable for about a half hour
until it run out of heap space memory. By increasing the servers and the VMs
memory the server would probably be able to handle higher loads.

4.1.5 Investigation into throughput
The volume tests are done at the same time as the load test, measuring the number
of packages per second the server handles and the amount of traffic in KB/s. This
measurements are done with vnStat [5], a program that can measure the average
packet flow and traffic during a short period of time (5 seconds).

                   Figure 4.2: Traffic as game servers increase

    The volume of increasing proportionally with the number of users, and with
the number of servers see Figure 4.2 and Figure 4.3. This is as expected since
every user requests a server list and the server list is proportional to the number of
servers. At 30000 servers there is higher load than expected see Figure 4.2. This
is probably caused by other processes that uses the processor or the network, this
would probably stabilize in a while. All measured results are shown in Appendix
    In order to validate the test results some comparison with calculated values of
traffic and package flow are made.
    Calculations of average package flow and traffic for 2000 servers and 2000
users. Assuming that updates are done every 10 minutes. Package flow by 2000
servers are 3.33 packages each second. This represents 3.33 * 35 bytes each
in incoming traffic. Traffic generated by 2000 clients are also 3.33 requests per
second. The server list of 2000 servers is divided in 233 server chunks, which
gives 8.58 packages. So the clients generate 3.33 * 9 packages = 30.0 packages
each way. Average incoming packages per second are 30 + 3.33 = 33.33 and
average outgoing per second are 30.

                      Figure 4.3: Traffic as users increase

    Average outgoing traffic are calculated by adding the total size of package
headers to the size of the server list and multiplying this with the number of re-
quests per second. The size of the server list is 12000 bytes. The package headers
are 30 bytes each and with 9 packages per request the total is 270 bytes. Each
request generates 12270 bytes, with 3.33 requests per second we get a outbound
traffic flow of 40.9 KB/s. Incoming packages are 35 bytes of size. Average in-
coming traffic are 30 packages a 35 bytes generated by clients + 3.33 packages a
35 bytes generated by servers gives a inbound traffic flow of 1.2 KB/s.
    If we compare these calculated values with the measured values which can be
found in Appendix B we see that the measured results are very near the calcula-
tions e.g. 40.9 KB/s calculated outgoing traffic against 41.24 measured and 33.3
incoming calculated packages per second against 33 measured. Another calcula-
tions with 1000 servers and 5000 users gives following results: Average incoming
traffic: 1.5 KB/s Average outgoing traffic: 51 KB/s Average incoming packages
per second: 43.2 Average outgoing packages per second: 41.5 These calculated
values does also agree with the measured values in appendix B.

4.1.6 Authentication server
The tests on the authentication server were done to determine the maximum num-
ber of connections the server could handle, and what sets the limits of the number
of authentication requests. Two scenarios were covered one with a small database
(10 registered players) and one with a large database (25000 registered players).

The server can handle about 40 requests per second in both scenarios so the data-
base size is not a real issue with the server. If players sends authenticate requests
with 10 minutes apart in average this refers to about 24000 players which one au-
thentication server can handle. The traffic on the server at this point is only about
35 KB/s in and 45 KB/s out. Neither the traffic load nor the amount of registered
players in the database sets the limits for this server. The probable bottleneck of
the server is the encryption calculations.

4.1.7 Source of errors
The number of clients is not the number of clients concurrently connected to the
master server it is the estimated number of clients that creates a certain amount
of traffic. Since there is no way to calculate a valid amount of traffic a client
produces the client estimate can be wrong, and probably the number of clients
and their update rate will vary during the time of day.
    The load on the computer can be other than just the load the server creates,
this load can influence the test result. Other network traffic can occur that shows
up in the test results.

4.2 Comparison with similar work
Every successful network game today provides backend services that lets the user
easy find game servers. This thesis has made a generic server browser system for
implementing in games written in Java. How does this work differ from products
on the market today e.g. GameSpy? Similarities?
     GameSpy provides a system with services for many different games and game
types. Their server browser is separated from the game clients i.e. the same
program can be used for several games. Furthermore they provide more services
such as chatting with other players and starting peer-to-peer games. ServerAgent
is a smaller system designed for games with dedicated servers and to be integrated
as a part of a game client, although it provides the same basic functionality, such
as searching and filtering servers for finding the fastest servers. It lacks some
functionality such as chats and search for players, and support for different games.
Although this functionality should be an easy task to implement.
     As ServerAgent is made to be integrated within a game, its server browser
functionality is almost exactly the same as a standalone server browser as XQF,
except the support for multiple games. With minor adjustments and implemen-
tations of other master server protocols it could be used as a standalone server
browser for many different games.

    The ServerAgent system can be compared to many different games like Quake
3, Counter-strike and other games that provide their own server browser. Like
many other games ServerAgent uses the GameSpy protocol which lets programs
programs that can query GameSpy servers e.g. qstat to query the game servers.
What differs between the game servers is that the ones that uses ServerAgent is
written in Java, and due to the fact that it is only a prototype developed during a
limited amount of time it is not as full featured. A comparison of performance
against another system would have been interesting, but no such data has been
found and no complete system with master server is freely available.
    Since the ServerAgent system is written in Java to be compatible with AgentFX.
Where other systems is often based on a specific platform, ServerAgent on the
other hand is designed to run on any machine that supports Java. It also provides a
web interface that lets the player browse the servers with a web browser and start
the game by clicking on a link on the web page.

Chapter 5


This chapter discusses the work that has been done, the test results and whether
the problems defined in the beginning has been solved. Furthermore it takes up
problems encountered during the thesis and what further work can be done to
improve and evolve the current work.

5.1 Conclusion
The first problems stated in the beginning was how to find a specific type of servers
on the Internet and selecting subsets of these with specific characteristics. There
are more than one way these problems can be solved. The approach chosen is to
use a master server as a rendez-vous point for servers and clients. This approach
was chosen because it was the simplest approach and the approach used by nearly
all systems today. Servers registers to the master server and clients can fetch a
list of all the game servers. The client then receives info from all game servers,
based on this info the player can select subsets of the servers. Although the master
server could be used to filter servers as well to reduce traffic on the master- and
game-servers but it is chosen not to do so because it induces more load on the
master server. Nevertheless it should not be disregarded as combining the two
methods can be used to optimize the systems performance. The game server- and
game client-API has been designed to be very easy to implement. The game client
GUI has also been designed with ease of use in mind.
     The implementation of the master server is focused on speed and not security,
therefore it is unfortunately open to denial of service attacks. The master server
has been thoroughly tested to find its limitations. Tests shows that the server can
handle tens of thousands of servers and clients, and it runs stable at long periods
under normal load. Calculations of throughput show almost identical values as
the measured. There are two possible bottlenecks of the server either bandwidth

or server CPU load. A fast server can saturate a 10 Mbps line before the CPU runs
at 100% load. The server can handle maximum load for shorter periods of time,
but running at full load for more than half an hour forces it to run out of memory.
This is possibly due to requests are coming in faster than they can be handled or
Java memory management is not able to clean up fast enough. The system has
also been compared to similar systems on the market, and it has the same basic
functionality as them although it is not as full featured since it is developed as a
prototype during a short period of time. Unfortunately its performance can not be
compared to other systems since no such data is available and no complete system
is available for tests.
     An addition to the previous problems was to create a web client interface for
finding and filtering servers. The main problem here is to make it responsive
since the system uses client side filtering, for each search all servers would have
to be queried from the web server, with many users the web server would have
enormous load and the pages would be terribly slow. To overcome this parts of
the client made in Java is made to build a database over online game servers. Then
the web server queries the database for subsets of the list. As Java can be started
directly from the web, games can be started directly from a web browser.
     The question to prevent the use of pirated games has also been covered. There
is no simple way to ensure that no one can use a software, local key checks can
be removed by hackers. To create a tamper resistant software is a very complex
matter and would require more time then this thesis can offer. Nevertheless, when
using a network game the user can be denied to play at a server if he does not
have a valid license key. An authentication server for handling authentication
of users and license keys has been created. It can generate unique license keys
with an id number an expiration date and an checksum. The server also has a
database for storing users and their license keys to ensure that each license key is
used only once. The system only has an authentication server and a client at the
moment that communicates over a encrypted channel. For a full featured system
the authentication process has to go through the game server, but the game server
should not be able to see the users password. Then someone it could make a phony
game server and collect usernames, license keys and passwords. So parts of the
traffic should be encrypted when passing the game server.
     Considerations has also been made of using the authentication server database
for building a system of global statistics collection and ladder rankings. But here
further security and trust issues has aroused. Every server can keep its own sta-
tistics and player ranking, but when gathering statistics from several servers the
data must be validated in some way, so no one make use of a phony game server
to gather false data to improve his rankings. No way to achieve this has been
suggested. The only way to make sure the statistics is accurate is if the same com-
pany runs all game servers. But even then the problem persists of players that is

cheating in the game.

5.2 Problems encountered
There have been some problems arising when working on this thesis. Most of
them originated in Javas memory management, forcing the client or servers to
exit due to lack of memory.
    On Linux a program can only have a limited amount of open file handles at
the same time. When updating a large server list and connecting to thousands
and thousands of servers it forced the client eventually to exit with no more file
pointers. Default it was able to have 1000 file pointers open, and the client had
only 50 opened simultaneously, but Java did not clean up the file pointers fast
enough. This problem can be fixed by increasing the maximum number of file
pointers allowed, or decreasing the number of simultaneously opened sockets.
This problem does not seem to appear on Windows.
    Another problem was a memory leak in the web clients database builder, forc-
ing it to run out of memory after a couple of days. Memory leaks can still be
found in Java, somewhere there are objects that there still are references to. In this
case under certain circumstances a return from a method was done before a SQL
statement was closed. These statements was still referenced to by the database
connection. This was hard to find but easy fixed by closing the statement before
returning from the method.
    When the master server is under very high load, may be a DoS attack, it exits
running out of memory. This problem is hard to do anything about, increasing the
memory of the application can use, makes the server able to handle more traffic
but does not make it invulnerable.

5.3 Further work
First there are improvements to be made on the current systems. The master server
is simple and optimized for speed. It can be extended to support server side fil-
tering and some sort of challenge response system for the game servers to make it
more resisting to DoS attacks. Some failover/redundancy system to use an alter-
nate server if a master server experience heavy load could be investigated.
    The server browser UI could be improved. With chats and searching or filter-
ing players. The server browser could be implemented as a standalone program
and support could be added for different master- and game-server protocols to
make it a multi-platform generic server browser like XQF or aGSM.

    Besides making the current server browser system more extensive other back-
end services that has not been fully covered by this thesis can be deployed. Some
sort of global statistics collecting program with player rankings could be imple-


 [1] Lee,         Trustin,      (2004),        MINA        Features,       URL:     (2005-10-

 [2] Onyszko, Tomasz, (Jul 19, 2002). Secure Socket Layer, URL: Socket Layer.html (2005-

 [3] UT server query URL: Server Query

 [4] Josefsson, S, (July 2003). The Base16, Base32, and Base64 Data Encodings,
     URL: (2005-10-13)

 [5] Toivola, Teemu. vnStat, URL: (2005-10-13)

 [6] Secure      Sockets      with      JSSE     &       OpenSSL          URL: (2005-10-13)

 [7] Hahnfeld, Nils, (15 March 2002). Cryptography tutorial, URL: http:// (2005-10-13)

 [8] gsQuery, URL: (2005-11-01)

 [9] SIP: Session Initiation Protocol, URL:

[10] First annual BSA and IDC software piracy study (July 2004), URL: IDC Piracy study July 2004.pdf

[11] Garretson,        Cara        (02     Nov        2005).        Vulnera-
     ble      security     algorithms     raise      concerns,        URL:,10801,105875,00.html

[12] Kali FAQ, URL: (2005-11-11)

[13] Software protection: The need, the solution, the reward. URL: HL/HASP HL WP/
     HASP HL WP/HASP HL WP Software Protection.pdf (2005-11-11)

[14] emulation FAQ. URL:

[15] Tanase, Matthew, (March 11, 2003). IP Spoofing: An Introduction, URL: (2005-11-14)

[16] Digital Signature Tutorial. URL:

[17] Counter-Strike official web site. URL: (2005-

[18] World of warcraft official web site. URL:

[19] URL: (2005-12-13)

[20] GameSpy web site. URL: (2005-12-13)

[21] Blizzard Entertainment URL: (2005-12-13)

[22] XQF game server browser. URL: (2005-12-

[23] aGSM alternative game server monitor. URL: (2005-

[24] PMTU (Path MTU) Discovery. URL:

Appendix A

Abbreviations and acronyms

API - Application Programming Interface
DDoS - Distributed Denial of Service
DMCA - Digital Millennium Copyright Act
DoS - Denial of Service
EULA - End User License Agreement
FPS - First Person Shooter
GUI - Graphical User Interface
I/O - Input / Output
IP - Internet Protocol
KB/s - Kilobytes per second
MD5 - Message Digest algorithm 5
MINA - Multipurpose Infrastructure for Network Applications
Mbps - Megabits per second
MTU - Maximum Transission Unit
NIO - New I/O
PHP - PHP: Hypertext preprocessor
SHA - Secure Hash Algorithm
SIP - Session initiation protocol
SSL - Secure Socket Layer
SQL - Structured Query Language
TCP - Transmission Control Protocol
UDP - User Datagram Protocol
VM - Virtual Machine
XML - Extensible Markup Language

Appendix B

Test results

          Figure B.1: Master server test result


To top