GGS-report/report.lyx
2011-05-17 19:07:20 +02:00

8216 lines
179 KiB
Text
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

#LyX 2.0 created this file. For more info see http://www.lyx.org/
\lyxformat 413
\begin_document
\begin_header
\textclass report
\begin_preamble
\usepackage{indentfirst}
\usepackage{tocloft}
\usepackage{calc}
\date{}
\usepackage[section] {placeins}
\def\myClearpage{%
\ifvmode
\ifnum \@dbltopnum =\m@ne
\ifdim \pagetotal <\topskip
\hbox{}%
\fi
\fi
\fi
% \newpage
\write\m@ne{}%
\vbox{}%
\penalty -\@Mi
}
\def\myCleardoublepage{\myClearpage\if@twoside \ifodd\c@page\else
\hbox{}\if@twocolumn\hbox{}\fi\fi\fi}
\usepackage{morefloats}
\usepackage{graphicx}
\usepackage{subfig}
\usepackage{tocloft}
\renewcommand{\cftchapfont}{\bfseries}
\renewcommand{\cftchappagefont}{\bfseries}
\renewcommand{\cftchappresnum}{Chapter }
\renewcommand{\cftchapnumwidth}{6em}
\oddsidemargin 0.5in
\textwidth 6in
\topmargin 0.0in
\textheight 8.0in
\setlength\topskip{24pt}
\footskip 0.75in
\usepackage[compact]{titlesec}
\titleformat{\chapter}[display]
{\vskip-8em\normalfont\bfseries}
{\LARGE\raggedright\thechapter}
{14ex}
{\vspace{-20ex}%
\LARGE\raggedleft}
[\vspace{1ex}%
{\titlerule[1pt]}]
\usepackage[absolute]{textpos}
\usepackage{fancyheadings}
\pagestyle{fancy}
\lhead{\thechapter}
\usepackage[hmargin=3cm,vmargin=3.5cm]{geometry}
\usepackage{algorithmic}
\usepackage{listings}
\usepackage{color}
\definecolor{lightgray}{rgb}{.9,.9,.9}
\definecolor{darkgray}{rgb}{.4,.4,.4}
\definecolor{purple}{rgb}{0.65, 0.12, 0.82}
\lstdefinelanguage{JavaScript}{
keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break},
keywordstyle=\color{blue}\bfseries,
ndkeywords={class, export, boolean, throw, implements, import, this},
ndkeywordstyle=\color{darkgray}\bfseries,
identifierstyle=\color{black},
sensitive=false,
comment=[l]{//},
morecomment=[s]{/*}{*/},
commentstyle=\color{purple}\ttfamily,
stringstyle=\color{red}\ttfamily,
morestring=[b]',
morestring=[b]"
}
\lstdefinelanguage{Erlang}{
keywords={typeof, true, false, catch, return, null, catch, switch, var, if, in, while, do, else, case, break, expose},
keywordstyle=\color{blue}\bfseries,
ndkeywords={class, export, boolean, throw, implements, import, this,erlv8_vm, erlv8_fun_invocation
,erlv8_object},
ndkeywordstyle=\color{darkgray}\bfseries,
identifierstyle=\color{black},
sensitive=false,
comment=[l]{\%},
morecomment=[s]{/*}{*/},
commentstyle=\color{purple}\ttfamily,
stringstyle=\color{red}\ttfamily,
morestring=[b]',
morestring=[b]"
}
\usepackage{float}
\floatstyle{ruled}
\newfloat{code}{thp}{lop}
\floatname{code}{Code}
\usepackage{nomencl}
\makenomenclature
\renewcommand{\nomname}{Glossary}
\end_preamble
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman lmodern
\font_sans default
\font_typewriter default
\font_default_family rmdefault
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\spacing onehalf
\use_hyperref false
\papersize a4paper
\use_geometry false
\use_amsmath 1
\use_esint 1
\use_mhchem 1
\use_mathdots 1
\cite_engine natbib_authoryear
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\use_refstyle 0
\index Index
\shortcut idx
\color #008000
\end_index
\paperwidth 11in
\paperheight 8.5in
\leftmargin 1.25in
\topmargin 0in
\rightmargin 1in
\bottommargin 1.7in
\secnumdepth 2
\tocdepth 2
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle empty
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header
\begin_body
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
begin{textblock*}{
\backslash
paperwidth}(0mm,40mm)
\end_layout
\begin_layout Plain Layout
\backslash
begin{center}
\end_layout
\begin_layout Plain Layout
\backslash
includegraphics[width=
\backslash
paperwidth-200px]{graphics/logo}
\end_layout
\begin_layout Plain Layout
\backslash
end{center}
\end_layout
\begin_layout Plain Layout
\backslash
end{textblock*}
\end_layout
\begin_layout Plain Layout
\end_layout
\begin_layout Plain Layout
\backslash
begin{textblock*}{
\backslash
paperwidth}(21mm,240mm)
\end_layout
\begin_layout Plain Layout
University of Gothenburg
\end_layout
\begin_layout Plain Layout
\end_layout
\begin_layout Plain Layout
Department of Computer Science and Engineering
\end_layout
\begin_layout Plain Layout
\end_layout
\begin_layout Plain Layout
Gothenburg, Sweden 2011
\end_layout
\begin_layout Plain Layout
\end_layout
\begin_layout Plain Layout
Bachelor's thesis 2011:44
\end_layout
\begin_layout Plain Layout
\backslash
end{textblock*}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
author{
\end_layout
\begin_layout Plain Layout
Jonatan Pålsson
\end_layout
\begin_layout Plain Layout
\backslash
\backslash
\end_layout
\begin_layout Plain Layout
Richard Pannek
\end_layout
\begin_layout Plain Layout
\backslash
\backslash
\end_layout
\begin_layout Plain Layout
Niklas Landin
\end_layout
\begin_layout Plain Layout
\backslash
\backslash
\end_layout
\begin_layout Plain Layout
Mattias Petterson
\end_layout
\begin_layout Plain Layout
}
\end_layout
\begin_layout Plain Layout
\backslash
title{
\backslash
Huge{A Generic Game Server}}
\end_layout
\begin_layout Plain Layout
\backslash
maketitle{ }
\end_layout
\begin_layout Plain Layout
\end_layout
\end_inset
\end_layout
\begin_layout Abstract
Today users of network games often experience failures of the servers while
playing or downtime due to maintenance.
Additionally game developers often perform the difficult task of reinventing
a game server to meet their needs.
The purpose of this thesis is to design a reliable game server which supports
different types of games simultaneously.
\end_layout
\begin_layout Abstract
It is investigated if the techniques and tools used in the telecom industry,
specifically the programming language Erlang and the Open Telecom Platform
(OTP) framework, can be used to create a highly reliable game server.
To make the server generic, it is investigated if virtual machines can
be used to run the actual games, thereby allowing the games to be developed
in different programming languages.
\end_layout
\begin_layout Abstract
A prototype is developed in Erlang using OTP.
The prototype features basic fault tolerance and is connected to the Google
V8 JavaScript virtual machine to run games written in JavaScript.
\end_layout
\begin_layout Abstract
The test results show that it is possible to design a server using the tools
originally intended for telecom software and it is indeed possible to create
a generic game server, capable of running different games, written in different
languages.
\end_layout
\begin_layout Abstract
This thesis concludes that simple games can easily be developed to work
reliably by making use of a generic server.
It should be worthwhile attempting to develop more advanced games using
the techniques described in this thesis.
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
pagenumbering{roman}
\end_layout
\begin_layout Plain Layout
\backslash
setcounter{page}{3}
\end_layout
\begin_layout Plain Layout
\backslash
renewcommand
\backslash
contentsname{Table of Contents}
\end_layout
\begin_layout Plain Layout
\backslash
renewcommand{
\backslash
cfttoctitlefont}{
\backslash
hfill
\backslash
Large}
\backslash
renewcommand{
\backslash
cftaftertoctitle}{
\backslash
hfill}
\end_layout
\begin_layout Plain Layout
\backslash
renewcommand
\backslash
cftpartdotsep{6.6}
\end_layout
\begin_layout Plain Layout
\backslash
renewcommand
\backslash
cftchapdotsep{6.6}
\end_layout
\end_inset
\begin_inset CommandInset toc
LatexCommand tableofcontents
\end_inset
\end_layout
\begin_layout Standard
\begin_inset Newpage newpage
\end_inset
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
pagenumbering{arabic}
\end_layout
\begin_layout Plain Layout
\backslash
setcounter{page}{1}
\end_layout
\end_inset
\end_layout
\begin_layout Chapter
Introduction
\end_layout
\begin_layout Standard
Online gaming and computer gaming in general has become an important part
in the day-to-day lives of many people.
A few years ago, computer games were not at all as popular as they are
today.
With the advances in computer graphics and computer hardware today's games
are much more sophisticated than they were in the days of
\emph on
NetHack
\emph default
,
\emph on
Zork,
\emph default
or
\emph on
Pacman.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Zork}}{A textual computer game developed by students at MIT}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Pacman}}{An early graphical computer game developed by Namco}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{NetHack}}{An early computer game developed by the NetHack team, arguably
the oldest computer game still in development}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
The early computer games featured simple or no graphics at all
\begin_inset CommandInset citation
LatexCommand citep
key "nethack:website"
\end_inset
.
The games often took place in a textual world, leaving the task of picturing
the world up to the player.
Multiplayer games were not as common as they are today, whereas most games
today are expected to have a multiplayer mode, most early games did not.
\end_layout
\begin_layout Standard
Since these early games, the gaming industry has become much more influential
in many ways.
Many advances in computer hardware are thought to come from pressure of
the computer game industry.
More powerful games require more powerful, and more easily available hardware.
Due to the high entertainment value of modern computer games, gaming has
become a huge industry where large amounts of money are invested.
The gaming industry is today in some places even larger than the motion
picture industry.
\begin_inset CommandInset citation
LatexCommand citep
key "esa:website,thenumbers:website"
\end_inset
\end_layout
\begin_layout Standard
Due to the increasing importance of computer gaming, more focus should be
spent on improving the quality of the gaming service.
As more and more computer games are gaining multiplayer capabilities, the
demands for multiplayer networking software rises.
The challenge of this thesis is to investigate techniques to improve the
quality of this networking software.
\end_layout
\begin_layout Standard
The Generic Game Server, hereafter known as the GGS
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{GGS}}{Generic Game Server, a software for reliably hosting network
games.
The subject of this thesis.}
\end_layout
\end_inset
, is a computer program designed to
\emph on
host
\emph default
network games on one or more server computers.
Hosting, in a network software setting, means allowing client software
to connect to the server software, for the purpose of utilizing services
provided by the server.
The GGS software provides games as a service, and the clients connecting
to the GGS can play these games on the GGS.
\end_layout
\begin_layout Standard
The idea of game servers is not new, network games have been played for
decades.
Early, popular examples of network games include the
\emph on
Quake
\emph default
series, or the
\emph on
Doom
\begin_inset Note Note
status collapsed
\begin_layout Plain Layout
\emph on
Come up w/ better game
\end_layout
\end_inset
\emph default
games.
Newer examples of network games include
\emph on
World of Warcraft
\emph default
, and
\emph on
Counter-Strike
\emph default
.
The difference between the GGS and the servers for these games is that
the servers for Doom, Quake, and the others listed, were designed with
these specific games in mind.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Quake}}{A first person shooter series developed by ID software.
The series consists of four games.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Doom}}{A first person shooter series developed by ID software.
The series consists of three games.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Counter-Strike}}{A multiplayer first person shooter game, popular
in E-Sports.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{World of Warcraft}}{A MMORPG game developed by Blizzard.
The world's most popular MMORPG by subscriber count.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Framework}}{A supporting structure, the GGS is a framework for developing
network games.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{First-person shooter}}{A game which centers around gun combat from
the first person perspective.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{MMORPG}}{Massively multiplayer online role playing game.
An online game with several thousand participants.}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
What GGS does is to provide a
\emph on
generic
\emph default
framework for developing network games.
The framework is generic in the sense that it is not bound to a specific
game.
The generic nature of the GGS allows the creation of many different types
of games, the motivation behind this is to remove the necessity of writing
new game servers when developing new games.
\end_layout
\begin_layout Standard
The GGS is in addition to being generic, also
\emph on
reliable
\emph default
in the sense that the gaming service provided is consistent and available.
A consistent and available server is a server that handles hardware failures
and software failures gracefully.
In the event of a component breaking within the GGS, the error is handled
by fault recovery processes, thereby creating a more reliable system.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Hardware failure}}{A failure in hardware (hard drive, memory, processor,
etc.) which causes a system to function in a different way than originally
intended, or crash}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Software failure}}{A failure in software (the GGS, the operating
system, etc.) which causes a system to function in a different way than
what was originally intended, or crash}
\end_layout
\end_inset
\end_layout
\begin_layout Section
Background
\begin_inset CommandInset label
LatexCommand label
name "sec:Background"
\end_inset
\end_layout
\begin_layout Standard
The gaming industry is a quickly growing industry with high revenues and
many clever computer scientists.
Strangely enough gamers often experience long downtimes due to maintainance
or because of problems with the servers
\begin_inset CommandInset citation
LatexCommand citep
key "news/cnet/com/WoWProblems"
\end_inset
.
This is a problem that has existed and been resolved in other industries
before.
The telecom industry, for instance, has already found solutions to similar
problems.
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{The nine nines}}{A common goal for availability in the telecom business.
A system with nine nines of availability is available 99.999999999% of the
time.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Downtime}}{The amount of time a system is unavailable and does not
function.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Uptime}}{The amount of time a system is available and functions.}
\end_layout
\end_inset
A common figure often used in telecoms is that of
\emph on
the nine nines
\emph default
, referring to
\begin_inset Formula $99.999999999\%$
\end_inset
of availability
\begin_inset CommandInset citation
LatexCommand citep
key "Armstrong03"
\end_inset
, or roughly
\begin_inset Formula $15ms$
\end_inset
downtime in a year.
The level of instability and bad fault tolerance seen in the game server
industry would not have been accepted in the telecom industry.
This level of instability should not be accepted in the game server industry
either.
An unavailable phone system could potentially have life threatening consequence
s, leaving the public unable to contact emergency services.
The same cannot be said about an unavailable game server.
The statement that game servers are less important than phone systems is
not a reason not to draw wisdom from what the telecoms have already learned.
\end_layout
\begin_layout Standard
Moving back to the gaming industry.
The main reason to develop reliable servers is higher revenue for game
companies, to achieve this it is important for game companies to expand
their customer base.
Reliable game servers will create a good image of the company.
In general the downtime of game servers is much higher than the downtime
of telecom systems even though the overall structure of the systems is
similar in many ways.
It should be possible to learn and reuse solutions from the telecom systems
to improve game servers.
\end_layout
\begin_layout Standard
In the current state game servers are developed on a per-game basis, often
this seems like bad practice.
A way to help game developers in developing servers more efficiently would
be to offer a generic game server which gives developers an environment
in which developers can implement their game.
This approach would not only make it easier to develop network games, it
would also allow games in different programming languages to be implemented
using the same server.
\end_layout
\begin_layout Standard
Some key factors to the development of the GGS have been isolated.
Many of these are also found in the telecom sector.
The factors are
\emph on
scalability, fault tolerance
\emph default
and a
\emph on
generic
\emph default
nature.
These terms are defined below.
\end_layout
\begin_layout Standard
Scalability (see
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Scalability"
\end_inset
) in computer science is a large topic and is commonly divided into sub-fields,
two of which are
\emph on
structural scalability
\emph default
and
\emph on
load scalability
\emph default
\begin_inset CommandInset citation
LatexCommand citep
key "Bondi:2000:CSI:350391.350432"
\end_inset
.
These two issues are addressed in this thesis.
Structural scalability means expanding architecture, e.g.
adding nodes to a system without requiring modification of the system.
Load scalability means using the available resources in a way which allows
handling increasing load, e.g.
more users, gracefully.
\end_layout
\begin_layout Standard
Fault tolerance (see
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Fault-Tolerance"
\end_inset
) is used to raise the level of
\emph on
dependability
\emph default
in a system, so that the dependability is high even in presence of errors.
Dependability is the statistical probability of the system functioning
as intended at a given point in time.
Fault tolerance is the characteristic of a system always to follow a specificat
ion, even in the presence of errors.
The specification could define error handling procedures which activate
when an error occurs.
This means that a fault tolerant, dependable system will have a very high
probability of functioning at any given point in time, and this is exactly
what is desired.
\begin_inset CommandInset citation
LatexCommand citep
key "Gartner:1999:FFD:311531.311532"
\end_inset
\end_layout
\begin_layout Standard
A generic (see
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Generic"
\end_inset
) game server has to be able to run different client-server network games
regardless of the platform the clients are running on.
It runs network games of different types.
A very rough separation of games is real time games and turn based games.
\end_layout
\begin_layout Standard
The server behaves in a way similar to an application server, but is designed
to help running games instead of typical applications.
An application server provides processing ability and time; therefore it
is different from a file- or print-server, which only serves resources
to the clients.
In order to more easily understand the purpose of the GGS, it can be of
use to briefly think of application servers, thereafter viewing the differences
between the GGS and regular application servers.
\end_layout
\begin_layout Standard
The most common type of application servers are web servers, where you run
a web application within the server.
The application server provides an environment and interfaces to the outer
world, in which applications run.
Hooks and helpers are provided to use the resources of the server.
Some examples for web application servers are the
\emph on
Glassfish
\emph default
server which allows running applications written in Java or the
\emph on
Google App Engine
\emph default
where you can run applications written in Python or any language which
runs in the
\emph on
Java Virtual Machine
\emph default
\begin_inset Note Note
status open
\begin_layout Plain Layout
Reference to app engine
\end_layout
\end_inset
.
An example of an application server not powering web applications, but
instead regular business logic, is Oracles
\emph on
TUXEDO
\emph default
application server, which can be used to run applications written in COBOL,
C++ and other languages.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{SQL}}{Structured Query Language, a computer language common in querying
certain databases.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{JavaScript}}{A programming language originally developed by Netscape,
common in web programming.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{COBOL}}{Originally a procedural programming language.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{C++}}{An object-oriented programming language.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Java}}{An object-oriented programming language.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{AXD301}}{Telephone switch developed by Ericsson.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Erlang}}{A concurrent programming language, often used for telecom
applications.
The main language of the GGS.}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
A database server can also be seen as an application server.
Scripts, for example SQL queries or JavaScript, are sent to the server,
which runs them and returns the evaluated data to the clients.
\end_layout
\begin_layout Standard
Application servers were developed to run applications, often web applications.
The application servers offer appealing features for application developers,
which assist them in writing applications.
Database servers were developed in order to provide access to and allow
programming of databases, thus having features specifically tailored for
database development.
\end_layout
\begin_layout Standard
The GGS on the other hand offers features appealing to game developers.
While it would be technically possible to write both regular applications
and database software using the GGS, this is not the intended use of the
server, and this is how the GGS differs from other kinds of application
servers.
\end_layout
\begin_layout Standard
To allow the development of different games, the game server developed needs
to be generic, therefore one purpose of this thesis is to investigate how
one could make a game server as generic as possible.
Some important helpers for game developers are discussed, such as abstraction
of the network layer, data store and game specific features.
\end_layout
\begin_layout Standard
A prototype has been developed in order to support the discussion of the
theoretical parts of the GGS.
The prototype does not feature all the characteristics described in this
thesis.
A selection has been made among the features and the most important ones
have been implemented either full or in part in the prototype.
\end_layout
\begin_layout Standard
The choice of the implementation language for the prototype of the GGS was
made with inspiration from the telecom industry.
The Erlang language was developed by the Swedish telecom company Ericsson
to develop highly available and dependable telecom switches.
One of the most reliable systems ever developed by Ericsson, the AXD301
was developed using Erlang.
The AXD301 has possibly the largest code base ever written in a functional
language
\begin_inset CommandInset citation
LatexCommand citep
key "Armstrong03"
\end_inset
.
The same language is used to develop the prototype of the GGS.
The usage of Erlang in the GGS is discussed in further detail in section
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:The-usage-of-erlang"
\end_inset
.
\end_layout
\begin_layout Section
Purpose
\end_layout
\begin_layout Standard
The purpose of creating a generic and fault tolerant game server is to provide
a good framework for the development of many different types of games.
Allowing the system to scale up and down is a powerful way to maximize
the usage of physical resources.
By scaling up to new machines when load increases, and scaling down from
machines when load decreases costs and energy consumption can be optimized.
\end_layout
\begin_layout Standard
Fault tolerance is important for the GGS to create a reliable service.
The purpose of a reliable game server is to provide a consistent service
to people using the server.
Going back to the telecom example, the purpose of creating a reliable telecom
system is to allow calls, possibly emergency calls, at any time.
Should the telecom network be unavailable at any time, emergency services
may become unavailable, furthermore the reputation of the telecom system
degrades.
\end_layout
\begin_layout Standard
Returning to the game industry, emergency services will not be contacted
using a game server, however an unavailable server will degrade the consumer's
image of the system.
Consider an online casino company.
The online casino company's servers must be available at all times to allow
customers to play.
If the servers are unavailable customers cannot play and the company loses
money.
In this scenario an unavailable server can be compared to a closed real-world
casino.
\end_layout
\begin_layout Standard
The generic nature of the GGS allows a multitude of different games to be
deployed on the GGS.
By deploying games on a common server less time has to be spent developing
servers for each individual game.
By supporting games developed in different languages, the features of the
GGS become available to games developed in languages which traditionally
do not exhibit these features.
\end_layout
\begin_layout Section
Challenges in developing the prototype
\end_layout
\begin_layout Standard
The word
\emph on
generic
\emph default
in the name of the GGS implies that the system is able to run a very broad
range of different code, for instance code written in different programming
languages or code written for a broad range of different game types.
To support this, a virtual machine (VM) for each
\emph on
game development language
\emph default
(hereafter GDL for brevity) is used.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{GDL}}{Game Development Language, the language used to program games
in the GGS.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{VM}}{Virtual Machine.}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
No hard limit has been set on which languages can be used for game development
on the GGS, but there are several factors which should be taken into considerat
ion when deciding the feasibility of a language:
\end_layout
\begin_layout Itemize
How well it integrates with Erlang, which is used for the core of the GGS
system?
\end_layout
\begin_layout Itemize
How easy it is to send messages from the GGS to the GDL VM?
\end_layout
\begin_layout Itemize
How easy it is to send messages from the GDL VM to the GGS?
\end_layout
\begin_layout Itemize
Is it possible to sandbox every game with a context or something comparable?
\end_layout
\begin_layout Standard
Internally the GDL VM needs to interface with the GGS to make use of the
helpers and tools that the GGS provides.
Thus an internal API has to be designed to make the GDL VM be able to interact
with the GGS.
This API is ideally completely independent of the GDL and reusable for
any GDL.
\end_layout
\begin_layout Standard
The communication with the gaming clients has to take place with help a
protocol.
Ideally a standard protocol should be used in order to shorten the learning
curve for developers and also make the system as a whole less obscure.
A major challenge during this project is to decide whether an existing
protocol can be used, and if not, how a new protocol can be designed which
performs technically as desired, while still being familiar enough to developer
s.
\end_layout
\begin_layout Standard
Work has been devoted to make the GGS
\emph on
reliable
\emph default
.
This includes ensuring that the system scales well and to make sure it
is fault tolerant.
In order to facilitate scalability the GGS needs a storage platform which
is accessible and consistent.
The scalability aspects of the GGS are discussed from a theoretical point
of view, however no practical implementations of the scalability aspects
are found in the prototype.
\end_layout
\begin_layout Section
Limitations of the prototype
\end_layout
\begin_layout Standard
The implementation of the GGS protocol together with storage possibilities,
server capacity, and game language support imposes some limitations on
the project.
To get a functional prototype, some limits must be set on the types of
games that can be played on the prototype.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{UDP}}{User Datagram Protocol, a stateless networking protocol.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{TCP}}{Transmission Control Protocol, a streaming network protocol.}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
The UDP protocol is not supported for communication between client and server.
The TCP protocol was chosen in favor of UDP, due to the fact that the implement
ation process using TCP was faster and easier than if UDP would have been
used.
UDP is generally considered to be faster than TCP for the transfer of game
(and other) related data, this is discussed in more depth in
\begin_inset CommandInset ref
LatexCommand vref
reference "sec:Choice-of-network"
\end_inset
.
In short, the decision of using TCP means that games that require a high
speed protocol will not be supported by the GGS prototype.
Another limitation necessary to set on the system is the fact that you
cannot have huge game worlds due to the implementation of the scaling mechanism
in the prototype.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Latency}}{A measure of delay, often measured in milliseconds.}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
In real-time games all players are playing together at the same time.
Latency is a huge problem in real-time games, a typical round trip time
for such games is one of
\begin_inset Formula $50$
\end_inset
to
\begin_inset Formula $150ms$
\end_inset
and everything above
\begin_inset Formula $200ms$
\end_inset
is reported to be intolerable (see
\begin_inset CommandInset citation
LatexCommand citep
key "Farber:2002:NGT:566500.566508"
\end_inset
).
Latency sensitive games include most of the first person shooters with
multiplayer ability, for example
\emph on
Counter Strike
\emph default
or massively multiplayer online role playing games (MMORPGs), for example
\emph on
World of Warcraft
\emph default
.
\end_layout
\begin_layout Standard
In turn-based games each player has to wait for their turn.
Latency is not a problem since the gameplay does not require fast interactions
among the players, long round trip times will not be noticed.
Examples of turn-based games include board and card games, as well as multiplay
er games like
\emph on
Jeopardy
\emph default
.
Both game types have varying difficulties and needs when it comes to implementi
ng them, any Generic Game Server should address all of these difficulties
in order to provide the tools necessary for the implementation of both
game types.
\end_layout
\begin_layout Standard
Due to the limited capability of threading in many GDL VMs, the GGS prototype
will not support MMORPGs.
\end_layout
\begin_layout Standard
The implementation of the GGS described in this thesis is only a small prototype
and tests will be performed on simple games like pong or chess, thus there
is no need to implement more advanced features in the system.
Note that these limitations only apply for the prototype of the project,
and that further developments of the GGS could be to implement these features.
\end_layout
\begin_layout Section
Method
\end_layout
\begin_layout Standard
A prototype was developed early on in the project to carry out experiments.
Using this prototype, the system was divided into modules.
A demand specification was created, using this specification, the modules
were easily identifiable.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Module}}{A part of a larger system with defined interfaces.}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
The first prototype of the GGS consisted of simple modules, however, due
to the separation of concerns among the modules, they were easily independently
modified and improved.
Once the basic structure of the GGS had been established, the first prototype
was removed, remaining was the structure of the modules and the internal
flow of the application.
This could be seen as an iterative workflow, with the first prototype being
the first iteration.
The second iteration later became the final result of the GGS.
\end_layout
\begin_layout Standard
The layout of the GGS is both layered and modular.
The first layer handles the most primitive data and produces a higher level
representation of the data, passing it on to different modules of the GGS.
The modular structure of the GGS plays an important role in making the
system fault-tolerant.
The approach to fault tolerance used is replication and restarting faulting
modules with the last known good data.
\end_layout
\begin_layout Standard
An informal specification and list of requirements of the system was outlined
early on in the project.
Usability goals for developers were set.
During the project several demo applications were constructed, by constructing
these applications, the usability goals were enforced.
\end_layout
\begin_layout Chapter
Theory behind the GGS
\begin_inset CommandInset label
LatexCommand label
name "cha:Theory"
\end_inset
\end_layout
\begin_layout Standard
In this chapter, the theory behind the techniques used in the GGS are discussed.
Performance issues, performance measurement, and benchmarking techniques
are covered in the following.
The options when choosing network protocols are given, along with a discussion
of each alternative.
Finally, an overview of scalability, fault tolerance and availability is
presented.
\end_layout
\begin_layout Section
Design of the GGS system
\begin_inset CommandInset label
LatexCommand label
name "sec:Design-of-the"
\end_inset
\end_layout
\begin_layout Standard
The GGS is modeled after a real-world system performing much of the same
duties as the GGS.
This is common practice
\begin_inset CommandInset citation
LatexCommand citep
key "armstrong2011"
\end_inset
in the computer software world to understand complex problems more easily.
While there may not always be a real world example of a system performing
the exact duties of the system being modeled in the computer, it is often
easier to create and analyze requirements for real world systems and processes
than systems existing solely in virtual form in a computer.
The requirements and limitations imposed on the real-world system can be
transferred to the software model with help of proper tools.
\end_layout
\begin_layout Standard
The real-world system chosen to represent the GGS is a
\begin_inset Quotes eld
\end_inset
chess club
\begin_inset Quotes erd
\end_inset
- a building where chess players can meet and play chess.
In the following text the choice of using a chess club for modeling the
GGS is discussed.
The chess club is described in greater detail, furthermore the corresponding
parts of the chess club in the GGS are described.
Since a real-world scenario is readily available, and to such a large extent
resembles the computer software required for the GGS, the next step in
developing the GGS system is to duplicate this real world scenario in a
software setting.
\end_layout
\begin_layout Standard
Some requirements, limitations and additions were made to the chess club
system, so that the system would more easily and efficiently be replicated
in a software setting.
\end_layout
\begin_layout Standard
In the text below, two examples will be presented.
One example is that of a real-world chess club, in which players meet to
play chess against each other, the other example is the GGS and how it
corresponds to this chess club.
\begin_inset Float figure
wide false
sideways false
status collapsed
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
begin{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Graphics
filename graphics/theory_layout.eps
scale 40
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
end{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption
\begin_layout Plain Layout
\begin_inset CommandInset label
LatexCommand label
name "fig:theory-layout"
\end_inset
The layout of a physical
\begin_inset Quotes eld
\end_inset
Chess club
\begin_inset Quotes erd
\end_inset
with two players (P) sitting by each chess table (Table), a coordinator
keeps track of all movements of players in the building.
A player has to pass by the entrance to enter or exit the building.
The building is represented by the outermost box.
\end_layout
\end_inset
\end_layout
\end_inset
In figure
\begin_inset CommandInset ref
LatexCommand vref
reference "fig:theory-layout"
\end_inset
a graphical representation of the chess club is given.
The club is seen from above.
The outermost box represents the building.
In the GGS setting, the building would represent one instance of the GGS.
Several buildings linked together would represent a cluster of GGS instances.
In order for a player (the P symbol in the graphic) to enter the theoretical
chess club, the player must pass by the entrance.
By having each player pass by the entrance, a tally can be kept, ensuring
that there are not too many players within the building.
In the GGS setting, too many players entering would mean too many connections
have been accepted by the GGS system, and that the structure of the system
thus must be modified, for example by adding more servers.
\end_layout
\begin_layout Standard
Once a player has been allowed in to the chess club the player is greeted
by the host of the chess club, in the GGS setting represented by the
\emph on
Coordinator
\emph default
, and is seated by a table.
The coordinator keeps track of all the players in the building, and all
moves made by the players.
The information available to the coordinator means that cheating can be
monitored and bookkeeping can be performed by this entity.
\end_layout
\begin_layout Standard
A player can only move the figures on her table in the chess club thus every
game is isolated to a table, just as expected.
This means that all communication during a game has to pass by the players
of that particular game and the coordinator only, making sure that no cheating
takes place.
\end_layout
\begin_layout Standard
This isolation of the games plays an important part in many properties of
the GGS; the isolation means that games can for example be transferred
among different chess clubs.
Furthermore, if cheating takes place, corruption can only occur in the
particular match where it was found and cannot spread.
\end_layout
\begin_layout Standard
Moving chess players from one location to another is one alteration made
to the real-world chess club system to make the system more appropriate
for a software setting.
Allowing games to be transferred is not an attribute usually desired in
a real-world chess club, where transferring players would mean moving the
players from one building to another.
In the software setting, moving players means moving the game processes
from one system to another, perhaps to balance the system load.
This transfer of players can occur transparently, without notifying the
players.
\end_layout
\begin_layout Standard
The simplified life cycle of a game in the GGS can be viewed using algorithm
\begin_inset CommandInset ref
LatexCommand vref
reference "alg:game-lifecycle"
\end_inset
.
To make this life cycle as efficient and useful as possible the scalability,
fault tolerance and generic traits are being added to the GGS.
These are not shown in the algorithm since these traits are tools in making
the algorithm behave as efficient as possible and are not the main focus
when studying the life cycle of a game.
\end_layout
\begin_layout Standard
The limits imposed in
\begin_inset CommandInset ref
LatexCommand vref
reference "alg:game-lifecycle"
\end_inset
are arbitrary for this example, there are for example no limits in the
GGS on the number of players connecting.
\end_layout
\begin_layout Standard
\begin_inset Float algorithm
wide false
sideways false
status open
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
begin{algorithmic}[1]
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
newcommand{
\backslash
INDSTATE}[1][1]{
\backslash
STATE
\backslash
hspace{#1
\backslash
algorithmicindent}}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
STATE
\end_layout
\end_inset
\series bold
while
\series default
\begin_inset Formula $players<2$
\end_inset
:
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
INDSTATE
\end_layout
\end_inset
\series bold
if
\series default
a player connects, call
\emph on
connected
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
STATE
\end_layout
\end_inset
\series bold
while
\series default
the game commences:
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
INDSTATE
\end_layout
\end_inset
call the function
\emph on
game
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
STATE
\end_layout
\end_inset
\series bold
when
\series default
the game has stopped
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
INDSTATE
\end_layout
\end_inset
call the function
\emph on
endGame
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
STATE
\end_layout
\end_inset
\series bold
function
\series default
connected:
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
INDSTATE
\end_layout
\end_inset
assign the new player an id
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
INDSTATE
\end_layout
\end_inset
alert the coordinator of the new player
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
INDSTATE
\end_layout
\end_inset
\series bold
if
\series default
a free table does not exist:
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
INDSTATE[2]
\end_layout
\end_inset
the coordinator creates a new table
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
INDSTATE
\end_layout
\end_inset
the coordinator places the player by the table, and begins watching the
player
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
STATE
\end_layout
\end_inset
\series bold
function
\series default
game
\series bold
:
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
INDSTATE
\end_layout
\end_inset
perform game-specific functions.
In chess, the rules of chess are placed here
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
STATE
\end_layout
\end_inset
\series bold
function
\series default
endGame:
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
INDSTATE
\end_layout
\end_inset
alert the coordinator, unregistering the players
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
INDSTATE
\end_layout
\end_inset
disconnect the players from the system, freeing system resources
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
end{algorithmic}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption
\begin_layout Plain Layout
\begin_inset CommandInset label
LatexCommand label
name "alg:game-lifecycle"
\end_inset
A very simple example of the flow through the GGS system when a game is
played.
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Section
Performance
\end_layout
\begin_layout Standard
There are many ways in which performance could be measured.
For the clients, time and response times are useful measurements in time-critic
al settings.
In not time-critical settings, the reliability of message delivery may
be an even more important factor than speed.
\end_layout
\begin_layout Standard
In a first person shooter game, the speed of delivery of messages with informati
on about the current positions of all players is essential.
The failure to deliver messages in time results in choppy gameplay for
the players.
In strategy games, the reliability of delivery may be more important than
the speed, since the game is not perceived as choppy even if the messages
are delayed.
\end_layout
\begin_layout Standard
For someone operating a GGS, it is perhaps more interesting to measure the
system load, memory consumption, energy consumption and network saturation.
These topics are discussed in theory in this section.
The implementation for the prototype is discussed in chapter
\begin_inset CommandInset ref
LatexCommand vref
reference "cha:Implementation-of-a"
\end_inset
.
For test results, refer to chapter
\begin_inset CommandInset ref
LatexCommand ref
reference "chap:Results-and-discussion"
\end_inset
, which contains graphs and a discussion concerning the performance of the
GGS prototype.
\end_layout
\begin_layout Section
Choosing a network protocol
\begin_inset CommandInset label
LatexCommand label
name "sec:Choice-of-network"
\end_inset
\end_layout
\begin_layout Standard
There are two main types of protocols with help of which computer communication
over the Internet usually takes place; TCP and UDP which are known as the
transport layer protocols and HTTP which is the most prominent application
layer protocol.
The transport layer protocols are commonly used to transport application
layer protocols such as HTTP, FTP and IRC.
TCP and UDP cannot be used on their own without an application layer protocol
on top of them.
Application layer protocols such as HTTP on the other hand need a transport
layer protocol in order to work.
\end_layout
\begin_layout Standard
In order for the GGS to communicate with clients over a network, both an
application layer protocol and a network layer protocol must be chosen.
This section outlines some candidates for application and network layer
protocols for the GGS, along with a motivation as to why the described
protocol was or was not chosen.
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{HTTP}}{Hyper Text Transport Protocol, a network protocol commonly
used to deliver web pages}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{FTP}}{File Transfer Protocol}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{IRC}}{Internet Relay Chat}
\end_layout
\end_inset
\end_layout
\begin_layout Subsection
UDP
\end_layout
\begin_layout Standard
Many online games use UDP as the carrier for their application layer protocol.
UDP moves data across a network very quickly, however it does not ensure
that the data transferred arrives in consistent manner.
Data sent via UDP may be repeated, lost or out of order.
To ensure that the transferred data is in good shape, some sort of error
checking mechanisms must be implemented.
UDP is a good choice for applications where it is more important that data
arrives in a timely manner than that all data arrives undamaged, it is
thus very suitable for media streaming for example.
\end_layout
\begin_layout Standard
The need to implement custom error checking, and possibly correction makes
UDP a bad candidate for the GGS.
If error checking and correction were to be implemented in the GGS project,
UDP would be a good candidate, however the time necessary to implement
these features makes this option unfeasible.
\end_layout
\begin_layout Subsection
TCP
\end_layout
\begin_layout Standard
For reliable transfers TCP is often used on the Internet.
Built in to the protocol are the error checking and correction mechanisms
missing in UDP.
This ensures the consistency of data, but also makes the transfer slower
than if UDP had been used.
TCP was chosen for the GGS as the network layer protocol even though TCP
can be considerably slower than UDP.
The error checking mechanisms in TCP are reason enough to use TCP instead
of UDP in the GGS prototype.
The implementation on top of UDP is still possible, it will however not
appear in the prototype.
\end_layout
\begin_layout Subsection
HTTP
\end_layout
\begin_layout Standard
Since HTTP is so widely used in web servers on the Internet today, it is
available on most Internet connected devices.
This means that if HTTP is used in the GGS, firewalls will not be a problem,
which is a great benefit.
However, due to the intended usage of HTTP in web servers, the protocol
was designed to be stateless and client-initiated.
In order to maintain a state during a game session using HTTP, some sort
of token would have to be passed between client and server at all times,
much like how a web server works.
These facts combined make HTTP inappropriate for use in the GGS, since
the GGS requires a state to be maintained throughout a session and also
needs to push data from the server to clients without the clients requesting
data.
It should also be mentioned that HTTP uses the TCP protocol for transport.
\end_layout
\begin_layout Subsection
The GGS Protocol
\end_layout
\begin_layout Standard
HTTP was designed to be a stateless protocol, which by adding some overhead
is able to remove the need of a permanent connection and a state for each
client.
The GGS however already has a permanent connection to each client because
it needs to push information to the clients.
Therefore it is able to use the state to minimize the overhead in the communica
tion between server and client.
Based on that it was decided to invent a new protocol which was human readable
like HTTP but customized for this special use.
The GGS protocol is described in more detail in section
\begin_inset CommandInset ref
LatexCommand ref
reference "sub:The-protocol-parser"
\end_inset
.
\end_layout
\begin_layout Section
Generic structure of the GGS
\begin_inset CommandInset label
LatexCommand label
name "sec:Generic"
\end_inset
\end_layout
\begin_layout Standard
The GGS is a game server.
It was made with a desire to be suitable for many kinds of games.
A game should not only be able to vary in terms of genre, graphics, gameplay
etc., but also in the way the game is implemented for example in different
programming languages.
The GGS should be operating system independent and run on Windows, OS X
and Linux.
The GGS can be run as a listen server on the computers of the players and
host games locally, it could also be a dedicated server running on dedicated
independent hardware.
The GGS is meant to run any game in any environment in any way desired,
therefore being as generic as possible.
\end_layout
\begin_layout Standard
Clients upload the source code of the game they would like to play on the
GGS, this way any client can connect to the server and install the game
through an API without the need of installation through the server provider
or maintainer.
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{API}}{Application programming interface.}
\end_layout
\end_inset
\end_layout
\begin_layout Section
Fault tolerance
\begin_inset CommandInset label
LatexCommand label
name "sec:Fault-Tolerance"
\end_inset
\end_layout
\begin_layout Standard
Merriam-Websters dictionary
\begin_inset CommandInset citation
LatexCommand citeyearpar
key "Dictionary.com2011"
\end_inset
defines fault tolerance as:
\end_layout
\begin_layout Quotation
1.
The ability of a system or component to continue normal operation despite
the presence of hardware or software faults.
This often involves some degree of redundancy.
\end_layout
\begin_layout Quotation
2.
The number of faults a system or component can withstand before normal
operation is impaired.
\end_layout
\begin_layout Standard
Fault tolerance is an important factor in servers, a server that is fault
tolerant should be able to follow a given specification when parts of the
system fail.
This means that fault tolerance is implemented differently in each system
depending on what specification it has.
It should be noted that it is not possible to achieve complete fault tolerance,
a system will always have a certain risk of failure.
With this in mind the goal is to make the GGS prototype as fault tolerant
as possible.
\end_layout
\begin_layout Standard
In order to make the GGS prototype fault tolerant the programming language
Erlang has been used.
Erlang will not guarantee a fault tolerant system, however it has features
that support and encourage the development of fault tolerant systems.
In the GGS it is important that the complete system is fault tolerant,
not only small parts.
Crashes of the whole system should be avoided as this would make the system
unusable for a time.
By using supervisor structures, as explained in section
\begin_inset CommandInset ref
LatexCommand ref
reference "sub:Supervisor-structure"
\end_inset
, it is possible to crash and restart small parts of the system, this is
convenient as faults can be handled within small modules thus never forcing
a crash of the system.
\end_layout
\begin_layout Standard
The need for fault tolerance in game servers is not as obvious as it may
be for other types of servers.
In general all servers strive to be fault tolerant as fault tolerance means
more uptime and a safer system.
This applies to game servers as well, good fault tolerance is a way of
satisfying customers.
In general, game servers differ from many other fault tolerant systems
in that high-availability is more important than the safety of the system.
For example a simple calculation error will not be critical for a game
server but it may be in a life-critical system and then it is better that
the system crashes than works with the faulty data.
There are cases where safety may be critical in game servers, one example
is in games where in-game money exists.
\begin_inset CommandInset citation
LatexCommand citep
key "Gartner:1999:FFD:311531.311532"
\end_inset
\end_layout
\begin_layout Section
Availability
\begin_inset CommandInset label
LatexCommand label
name "sec:Availability"
\end_inset
\end_layout
\begin_layout Standard
One important factor of any server is the availability.
A server which is unreachable is a useless server.
\end_layout
\begin_layout Standard
Within the telecom sector high-availability has been achieved
\begin_inset CommandInset citation
LatexCommand citep
key "armstrong2011"
\end_inset
.
In the game development sector however the lack of high-availability problem
has not yet been solved.
\end_layout
\begin_layout Standard
There are several good papers (e.g.
\begin_inset CommandInset citation
LatexCommand citep
key "VM:Jin2010,VM:Polze"
\end_inset
) on how to migrate whole virtual machines between nodes to replicate them
but for the GGS a different approach has been chosen.
Instead of duplicating a virtual machine, an attempt to lift the state
of the VM to a data storage external to the VM is made.
The state is stored in a fast, fault tolerant data store instead of inside
the VM.
The GGS uses several tools from the OTP, some of them are
\emph on
hot code replacement
\emph default
, where code can be updated while the application is running and without
the need to restart it, as well as the
\emph on
supervisor structure
\emph default
provided by
\emph on
OTP
\emph default
and the inter node and process communication via
\emph on
messages
\emph default
instead of shared memory.
We will discuss each of them later on.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Supervisor}}{A process monitoring and handling crashes in other processes.
}
\end_layout
\end_inset
\end_layout
\begin_layout Section
Scalability
\begin_inset CommandInset label
LatexCommand label
name "sec:Scalability"
\end_inset
\end_layout
\begin_layout Standard
Each instance of the GGS contains several so called tables.
Each table is an isolated instance of a game, for instance a chess game
or a poker game.
A possible way for the GGS to scale up is to distribute these tables to
different servers.
In many games it is not necessary for a player to move between tables during
games.
This is for example not a common occurrence in chess, where it would be
represented as a player standing up from her current table and sitting
down at a new table, all within the same game session.
Therefore the main focus of the GGS is not to move players between tables,
but to keep a player seated by a table and to start new tables if needed
instead.
When a server reaches a certain number of players the performance will
start to decrease, or worse, the server may even crash.
To avoid this the GGS will start new tables on another server, using this
technique the players will be close to evenly distributed among the servers.
It is important to investigate the amount of players which is optimal for
each server.
This approach makes it possible to use all resources with a moderate load,
instead of having some resources with heavy load and others with almost
no load.
\end_layout
\begin_layout Standard
As mentioned in section
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Background"
\end_inset
there are two different types of scalability, structural scalability and
load scalability.
To make the GGS scalable both types of scalability have to be considered.
Structural scalability means - in this case - that it should be possible
to add more servers to an existing cluster of servers.
By adding more servers the number of users can be increased.
Load scalability, in contrast to structural scalability, is not about how
to increase the actual limits of the system, rather it means how good the
system handles increased load.
The GGS should be able to scale well in both categories.
\end_layout
\begin_layout Subsection
Load balancing
\end_layout
\begin_layout Standard
The need for load balancing varies among different kinds of systems.
Small systems that only use one or a couple of servers can cope with a
simple implementation of a load balancer, while in large systems it is
useful to have extensive and well working load balancing implementations.
The need also depends on what kind of server structure the system is working
on; a static structure where the number of servers is predefined or a dynamic
structure where this number varies.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Amazon EC2}}{Amazon Elastic Compute Cloud, a cloud computation service
provided by Amazon.}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
Load balancing and scaling are difficult in certain scenarios.
When running in a server park, there is a set number of servers available,
this means that an even distribution across all servers is preferable.
When running the GGS in a cloud, such as Amazon EC2, it is possible to
add an almost infinite number of servers as execution goes on and the load
increases.
In this cloud setting it may be more important to evenly distribute load
on newly added servers.
\end_layout
\begin_layout Standard
Two methods of balancing load (increasing structure):
\end_layout
\begin_layout Itemize
Fill up the capacity of one server completely, and then move over to the
next server
\end_layout
\begin_layout Itemize
Evenly distribute all clients to all servers from the beginning.
When the load becomes too high on all of them a new problem arises: How
do we distribute the load on the new servers?
\end_layout
\begin_layout Standard
Load balancing is a key component to achieve scalability in network systems.
The GGS is a good example of a system that needs to be scalable and to
attain this, load balancing is necessary.
Optimization of the load balancing for a system is an important task to
provide a stable and fast load balancer.
There are certain persistence problems that can occur with load balancing,
if a player moves from a server to another data loss may occur.
This is an important aspect to consider when a load balancer is designed
and implemented.
\end_layout
\begin_layout Standard
Load balancing can often be implemented using dedicated software, this means
that in many applications load balancing may not be implemented internally
because better external solutions exist already.
This depends on what specific needs the system has.
A minor goal of this thesis is to analyze whether the GGS can use existing
load balancing tools or if it is necessary, how to implement load balancing
in the project.
\end_layout
\begin_layout Standard
\begin_inset Note Note
status open
\begin_layout Plain Layout
Because P2P game architectures are a constant goal for cheaters and because
“Cheating is a major concern in network games as it degrades the experience
of the majority of players who are honest” and preventing cheating in P2P
game architectures is very difficult game developers try to use Client
- Server architectures which have a natural problem to scale.
In this paper we want to show some strategies to achieve scalability.
\end_layout
\end_inset
\end_layout
\begin_layout Subsection
UUID
\begin_inset CommandInset label
LatexCommand label
name "sub:UUID"
\end_inset
\end_layout
\begin_layout Standard
\begin_inset Float algorithm
wide false
sideways false
status open
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
begin{algorithmic}[1]
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
newcommand{
\backslash
INDSTATE}[1][1]{
\backslash
STATE
\backslash
hspace{#1
\backslash
algorithmicindent}}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
STATE
\end_layout
\end_inset
global variable
\begin_inset Formula $state:=0$
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
STATE
\end_layout
\end_inset
\series bold
function
\series default
unique
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
INDSTATE
\end_layout
\end_inset
\begin_inset Formula $state:=state+1$
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
INDSTATE
\end_layout
\end_inset
\series bold
return
\begin_inset Formula $state$
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
end{algorithmic}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption
\begin_layout Plain Layout
\begin_inset CommandInset label
LatexCommand label
name "alg:A-simple-generator"
\end_inset
A simple (insufficient) generator for identifiers
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{UUID}}{Universally Unique Identifier.}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
Inside the GGS everything needs a unique identifier.
There are identifiers for players, tables and other resources.
When players communicate among each other or with their table, they need
to be able to uniquely identify all of these resources.
Within one machine, this is mostly not a problem.
A simple system with a counter can be imagined, where each request for
a new Identification Number increments the previous identifier and returns
the new identifier based on the old one; see algorithm
\begin_inset CommandInset ref
LatexCommand ref
reference "alg:A-simple-generator"
\end_inset
.
This solution poses problems when dealing with concurrent and distributed
systems.
In concurrent systems, the simple solution in algorithm
\begin_inset CommandInset ref
LatexCommand ref
reference "alg:A-simple-generator"
\end_inset
may yield non-unique identifiers due to the lack of mutual exclusion.
\end_layout
\begin_layout Standard
The obvious solution to this problem is to ensure mutual exclusion by using
some sort of locking, which may work well in many concurrent systems.
In a distributed system such as the GGS however, this locking, along with
the state, would have to be distributed.
If the lock is not distributed, no guaranties can be made that two nodes
in the distributed system do not generate the same identifier.
\end_layout
\begin_layout Standard
A different approach is to give each node the ability to generate Universally
Unique Identifiers (UUID), where the state of one machine does not interfere
with the state of another.
According to
\begin_inset CommandInset citation
LatexCommand citep
key "Leach98uuidsand"
\end_inset
:
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{MAC Address}}{Media Access Control address, used to identify network
cards.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{SHA-1}}{Stands for Secure Hash Algorithm, a cryptographic hash function,
designed by the National Security Agency (NSA).}
\end_layout
\end_inset
\end_layout
\begin_layout Quote
A UUID is 128 bits long, and if generated according to the one of the mechanisms
in this document, is either guaranteed to be different from all other UUIDs/GUI
Ds generated until 3400 A.D.
or extremely likely to be different.
\end_layout
\begin_layout Standard
The generation of a UUID is accomplished by gathering several different
sources of information, such as: time, MAC addresses of network cards;
and operating system data such as; percentage of memory in use, mouse cursor
position and process IDs.
The gathered data is then
\emph on
hashed
\emph default
\begin_inset space ~
\end_inset
using an algorithm such as SHA-1.
\end_layout
\begin_layout Standard
When using system wide unique identifiers it is extremely unlikely to have
identifier collisions when recovering from network splits between GGS clusters.
Consider figure
\begin_inset CommandInset ref
LatexCommand ref
reference "fig:network-split"
\end_inset
, where an example of a network split is shown.
When
\emph on
\emph default
the decoupled node
\emph on
\emph default
and
\emph on
\emph default
the rest of the network later re-establish communication, they may have
generated the same IDs if using algorithm
\begin_inset CommandInset ref
LatexCommand ref
reference "alg:A-simple-generator"
\end_inset
, even when mutual system-wide exclusion is implemented.
This is exactly the problem UUIDs solve.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Network split}}{Separation of two networks, occurs when two networks
cannot communicate, commonly because of a hardware or software failure.}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
begin{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Graphics
filename graphics/netsplit2.eps
scale 40
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
end{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption
\begin_layout Plain Layout
\begin_inset CommandInset label
LatexCommand label
name "fig:network-split"
\end_inset
An example of a network split
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Section
Security
\end_layout
\begin_layout Standard
The GGS only supports languages running in a sandboxed environment.
Each game session is started in its own sandbox.
The sandboxing isolates the games in such a way that they cannot interfere
with each other.
If sandboxing was not in place, one game could potentially modify the contents
of a different game.
A similar approach is taken with the persistent storage provided by the
GGS.
In the storage each game has its own namespace, much like a table in a
relational database.
A game is not allowed to venture outside this namespace, and can because
this not modify the persistent data of other games.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Sandbox}}{A protected environment in which computer software can
be run safely.}
\end_layout
\end_inset
\end_layout
\begin_layout Section
Game Development Language in a Virtual Machine
\begin_inset CommandInset label
LatexCommand label
name "sec:Game-Development-Language"
\end_inset
\end_layout
\begin_layout Standard
Erlang is not a very popular language for game development, therefore the
GGS needs to be able to run games written in different languages.
The main idea is to offer a replaceable module which would introduce an
interface to different virtual machines which would run the game code.
This way a game developer can write the game in his favorite language while
the server part still is written in Erlang and can benefit from all the
advantages the Erlang language provides.
\end_layout
\begin_layout Subsection
JavaScript
\end_layout
\begin_layout Standard
JavaScript is a prime GDL candidate for the GGS.
The language is very flexible, and a large base of developers within the
web community is using this language on the client side within the browser
and therefore are used to it.
\end_layout
\begin_layout Standard
JavaScript, as a interpreted scripting language, has gained a lot of popularity
in other fields of computer science lately.
It is used as a server side language in large projects such as
\emph on
Riak
\emph default
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
\begin_inset Flex URL
status collapsed
\begin_layout Plain Layout
http://wiki.basho.com/An-Introduction-to-Riak.html
\end_layout
\end_inset
\end_layout
\end_inset
or
\emph on
CouchDB
\emph default
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
\begin_inset Flex URL
status collapsed
\begin_layout Plain Layout
http://couchdb.apache.org
\end_layout
\end_inset
\end_layout
\end_inset
.
On the popular social coding site
\emph on
GitHub.com
\emph default
, 18%
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
during the writing of the thesis the percentage went up to 19%
\begin_inset Flex URL
status collapsed
\begin_layout Plain Layout
https://github.com/languages/
\end_layout
\end_inset
\end_layout
\end_inset
of all code is written in JavaScript.
\end_layout
\begin_layout Standard
Apart from that there are virtual machines with bindings to Erlang readily
available for JavaScript which are provided by organizations like Mozilla
and companies like Google.
In the end this choice was more or less arbitrary since the GGS is intended
to be able to run several different GDL VMs, and one had to be the first.
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{CouchDB}}{Database server}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Riak}}{Database server}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{GitHub.com}}{Social coding website}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{ActionScript}}{Programming language}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Lua}}{Programming language}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{.NET}}{Software platform}
\end_layout
\end_inset
\end_layout
\begin_layout Subsection
Other languages
\end_layout
\begin_layout Standard
Other languages like
\emph on
Lua
\emph default
or
\emph on
ActionScript
\emph default
are suitable as well since there is a virtual machine for each of them
which can be
\begin_inset Quotes eld
\end_inset
plugged in
\begin_inset Quotes erd
\end_inset
into the GDL VM interface.
With help of the
\emph on
Java Virtual Machine
\emph default
or the
\emph on
.NET
\emph default
environment it is even possible to run nearly every available programming
language in a sandbox as a GDL, however only a VM for JavaScript will be
included
\begin_inset Note Note
status open
\begin_layout Plain Layout
You did not implement the VM, you just implemented the inclusion of the
VM ...
so I would not use
\begin_inset Quotes eld
\end_inset
implement
\begin_inset Quotes erd
\end_inset
here.
\end_layout
\end_inset
in the GGS prototype.
\end_layout
\begin_layout Section
Testing
\end_layout
\begin_layout Standard
There are several ways in which the GGS can be tested.
The most important aspect is deemed to be the experience players have when
using the GGS.
To test the user experience of the GGS, a realistic usage scenario has
to be set up.
\end_layout
\begin_layout Standard
The GGS is intended to be used for powering games which have many concurrent
players.
The players do not need to participate in the same instance of the game,
games such as chess are possible candidates for the testing sessions.
\end_layout
\begin_layout Standard
When developing the GGS, two main categories of games exhibiting different
performance requirements were identified; real-time games and turn-based
games.
The real-time games are deemed more demanding than the turn-based games.
Tests are carried out using a real-time game, since this is the more demanding
type of games.
\end_layout
\begin_layout Standard
The real-time game chosen for testing of the GGS is
\emph on
Pong
\emph default
, a game in which two players play a game involving a ball and two paddles.
The goal for each player is to shoot beside the other players paddle while
not allowing the ball to pass by her own paddle.
The game requires real-time updates and is demanding when played in several
instances concurrently.
\end_layout
\begin_layout Standard
There has been some work on the area of testing game servers, see
\begin_inset CommandInset citation
LatexCommand citep
key "Lidholt02designand"
\end_inset
, who describes a test bench using
\emph on
bots
\emph default
for testing his generic hazard-gaming server.
Lidholt describes how his server, capable of running several different
casino games, is tested using artificial players, so called bots.
Performance is measured in
\begin_inset Quotes eld
\end_inset
number of clients
\begin_inset Quotes erd
\end_inset
able to connect to the server, and the system load.
\end_layout
\begin_layout Standard
Similar tests have been performed on the GGS, and the results of these tests
are presented in chapter
\begin_inset CommandInset ref
LatexCommand ref
reference "chap:Results-and-discussion"
\end_inset
.
The tests were initially performed by starting an operating system process
for each player.
Due to lack of hardware, not enough player processes could be started in
this way.
The bots were rewritten in Erlang, and due to Erlang's light weight threads,
enough processes could have been created to test the server successfully.
\end_layout
\begin_layout Chapter
Implementation of a prototype
\begin_inset CommandInset label
LatexCommand label
name "cha:Implementation-of-a"
\end_inset
\end_layout
\begin_layout Standard
As mentioned earlier in the thesis, a prototype of the GGS has been developed
in order to test hypotheses and provide concrete examples.
\end_layout
\begin_layout Standard
This chapter contains the implementation of many of the principles and technique
s described in chapter
\begin_inset CommandInset ref
LatexCommand vref
reference "cha:Theory"
\end_inset
.
Here the problems and their solutions are discussed in greater detail,
and at times the text becomes more specific to the GGS.
\end_layout
\begin_layout Standard
Much of what is discussed in this chapter has been implemented in the GGS
prototype.
The different means of communications within the GGS and outside the GGS
with third parties are also discussed here.
\end_layout
\begin_layout Standard
The chapter ends with case studies and code examples of particular features
of the GGS.
The case studies and the code serve as concrete examples of the implementations
outlined in the rest of this chapter.
\end_layout
\begin_layout Section
Overview of the prototype
\end_layout
\begin_layout Standard
The prototype of the GGS was developed using the Erlang programming language.
In Erlang, most things are processes.
The software running the Erlang code is known as the Erlang machine, or
an Erlang node.
Each Erlang node is capable of running several
\emph on
threads
\emph default
(also known as
\emph on
Light Weight Processes; LWP
\emph default
)
\emph on
,
\emph default
much like the threads in an operating system.
There are however differences between operating system threads and LWPs
in Erlang.
Threads in a Linux system, for example, are treated much like operating
system processes in different systems.
Due to the size of the data structures related to each process swapping
one process for another (known as
\emph on
context switching
\emph default
) is an expensive task in many systems
\begin_inset CommandInset citation
LatexCommand citep
after "pg 80"
key "McKusick:2004:DIF:1014910"
\end_inset
.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{LWP}}{Light Weight Process.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Context switch}}{The act of switching from one context, commonly
a process, to another.
Used by operating systems to achieve multi tasking.}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
The cost of swapping operating system processes becomes a problem when many
processes are involved.
If the GGS prototype had been developed using regular operating system
processes, it would have had to be designed in a way to minimize the number
of processes.
Using Erlang, which is capable of running very many processes in parallel
\begin_inset Note Note
status open
\begin_layout Plain Layout
or
\begin_inset Quotes eld
\end_inset
concurrently
\begin_inset Quotes erd
\end_inset
\end_layout
\end_inset
, several times more than an operating system, the relation between the
real world and the GGS (described in
\begin_inset CommandInset ref
LatexCommand vref
reference "sec:Design-of-the"
\end_inset
) becomes clearer.
\end_layout
\begin_layout Standard
Erlang allows the GGS to create several processes for each player connecting,
these processes can handle a multitude of different tasks, parsing data
for example.
Since each task is handled by a different process, the tasks are clearly
separated and the failure of one is easily recovered without affecting
others.
\end_layout
\begin_layout Standard
In addition to creating (or
\emph on
spawning
\emph default
) processes specifically to handle new players connecting, the GGS has permanent
processes running at all times.
The constantly running processes in the GGS prototype are called
\emph on
modules
\emph default
.
An example of a module in the GGS is the
\emph on
dispatcher module
\emph default
, which handles the initial connection made by a client, passing the connection
along further in to the system.
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status collapsed
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
begin{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Graphics
filename graphics/Chess_no_text.eps
width 100text%
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
end{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption
\begin_layout Plain Layout
\begin_inset CommandInset label
LatexCommand label
name "fig:The-layout-of"
\end_inset
The layout of the GGS.
The circles marked with 'C' topmost in the picture represent clients.
The cloud marked 'network' pictured directly below the clients can be any
network, for example the Internet.
The barell figure marked 'backup' is a process being fed backup data from
the coordinator.
The barrel marked 'State' contains the state of a table, and this is fed
into the box marked 'Mnesia' which is database.
Finally the figure shaped as a shield marked 'GameVM' contains the actual
game process.
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Standard
In figure
\begin_inset CommandInset ref
LatexCommand vref
reference "fig:The-layout-of"
\end_inset
the entire GGS system is represented graphically.
The circles marked with 'C' topmost in the picture represent game clients.
These circles represent processes running on the computers of the gamers,
and not on the GGS machine.
If a game of chess is to be played on the server, the clients on the machines
of the gamers will be chess game clients.
Clients connect through a network, pictured as a cloud, to the dispatcher
process in the GGS.
The dispatcher process and all other modules are discussed in
\begin_inset CommandInset ref
LatexCommand vref
reference "sec:The-modular-structure"
\end_inset
.
For each connection, a new player process is spawned, which immediately
after spawning is integrated into the GGS by the coordinator process.
\end_layout
\begin_layout Section
The usage of Erlang in the GGS
\begin_inset CommandInset label
LatexCommand label
name "sec:The-usage-of-erlang"
\end_inset
\end_layout
\begin_layout Standard
As mentioned earlier, the GGS prototype is implemented in Erlang.
The current section and the subsequent section function as a short introduction
to Erlang, focusing on the parts of the language necessary to understand
the material regarding Erlang presented in this thesis.
\end_layout
\begin_layout Standard
Erlang was designed by Ericsson, beginning in 1986, for the purpose of creating
concurrent applications and improving telecom software.
Features essential for the telecom industry to achieve high-availability
in telecom switches were added to the language.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Mutex}}{A construct for achieving mutual exclusion, used to avoid
simultaneous access to shared resources in computer systems.}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
Erlang uses message passing in favor of shared memory, mutexes and locks,
something which at the time was controversial among fellow developers
\begin_inset CommandInset citation
LatexCommand citep
key "Armstrong:2010:ERL:1810891.1810910"
\end_inset
(Armstrong is one of the inventors of the programming language Erlang).
The reason for using message passing, according to Armstrong, was that
applications should operate correctly before optimizations are done, where
efficient internal communication within the Erlang machine was considered
a later optimization.
\end_layout
\begin_layout Standard
In using message passing in favor of the methods commonly used at the time,
the issues commonly associated with shared memory and locking were avoided.
\end_layout
\begin_layout Standard
In Erlang, everything is a process, and everything operates in its own memory
space.
Memory cannot be shared among processes, which prohibits a process from
corrupting the memory of a different process.
\end_layout
\begin_layout Standard
Messages are sent between the processes in an asynchronous manner, and each
process has a mailbox from which these messages can be retrieved.
\end_layout
\begin_layout Standard
Processes in Erlang are also called
\emph on
Light Weight Processes
\emph default
because they are inexpensive to create.
Processes exist within an Erlang machine, or Erlang node.
The Erlang machine has its own scheduler and does not rely on the scheduler
of the operating system, this is a main reason of Erlang's capability of
running many concurrent processes
\begin_inset CommandInset citation
LatexCommand citep
key "Armstrong03"
\end_inset
.
\end_layout
\begin_layout Standard
The strong isolation of Erlang processes makes them ideal for multi-core
and distributed systems.
Distribution of software is included as a fundamental part in the Erlang
language.
The 'physical' location of a process, e.g.
which computer the process runs on, is not important when communicating
with the process.
Processes can communicate transparently regardless of whether they run
on the same system or not.
\end_layout
\begin_layout Standard
The distributed nature of Erlang is something the GGS can make use of when
scaling across several computers in order to achieve higher performance.
The distribution is also important in creating redundancy.
The GGS prototype does not make use of the distributed nature of Erlang,
however the GGS prototype is constructed in such a way that making use
of the distributed nature should not pose a big problem.
\end_layout
\begin_layout Standard
Erlang promotes a non-defensive programming style in which processes are
allowed to crash and be restarted in favor of having the processes recover
from errors.
The distributed nature of Erlang means supervisor processes (discussed
in section
\begin_inset CommandInset ref
LatexCommand ref
reference "sub:Supervisor-structure"
\end_inset
) can reside on remote systems, thereby increasing the reliability of the
system as a whole.
\end_layout
\begin_layout Standard
A very important feature of Erlang, used in the GGS, is the ability to interface
with external hardware and software.
Erlang allows communication with external resources through
\emph on
ports
\emph default
and
\emph on
NIF
\emph default
s (Native implemented functions)
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{NIF}}{Native implemented functions.}
\end_layout
\end_inset
\emph on
.
\emph default
Through ports communication can take place in a similar way as communication
is performed over sockets.
NIFs are called like any other functions without any difference to the
caller but are implemented in C, this implementation makes NIFs a very
efficient way to interface with the outside world
\begin_inset CommandInset citation
LatexCommand citep
key "NIF:website"
\end_inset
.
\end_layout
\begin_layout Standard
The GGS uses Erlang ports for generating UUIDs
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
UUIDs are discussed in section
\begin_inset CommandInset ref
LatexCommand ref
reference "sub:UUID"
\end_inset
\end_layout
\end_inset
and NIFs for interfacing with the GDL VMs
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
Virtual machines of games are discussed in section
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Game-Development-Language"
\end_inset
\end_layout
\end_inset
.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{OTP}}{Open Telecom Platform, a software suite for Erlang.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Behaviour}}{A design pattern in OTP.}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
Development of the GGS would have been hard if not impossible had it not
been for the
\emph on
OTP
\emph default
supplied with the standard Erlang distribution.
The OTP (Open Telecom Platform) is a set of standard libraries and design
patterns, called
\emph on
behaviors
\emph default
, which are used when developing Erlang systems.
\end_layout
\begin_layout Standard
The GGS makes heavy use of the behaviors supplied in the OTP.
The behaviors impose a programming style suitable for distributed and concurren
t applications.
In particular, the GGS uses the following behaviors:
\end_layout
\begin_layout Itemize
The
\emph on
supervisor
\emph default
behavior, which is used when creating a supervisor.
Supervisors are used when monitoring processes in Erlang systems.
When a process exits wrongfully, the supervisor monitoring the process
in question decides which action to take.
In the GGS, the most common action is to restart the faulting process.
A more thorough discussion on supervisors can be found in section
\begin_inset CommandInset ref
LatexCommand ref
reference "sub:Supervisor-structure"
\end_inset
.
\end_layout
\begin_layout Itemize
The
\emph on
gen_tcp
\emph default
behavior, which is used to interact with TCP sockets for network communication.
Using the gen_tcp behavior, network messages are converted to internal
Erlang messages and passed to a protocol parser, where the messages are
processed further.
\end_layout
\begin_layout Itemize
The
\emph on
gen_server
\emph default
behavior, which is used when constructing OTP servers in Erlang.
Using this behavior, a state can easily be kept in a server process, greatly
increasing the usefulness of the server process.
This behavior is the most widely used one in the GGS prototype.
In addition to introducing a state to the server, the gen_server behavior
also imposes patterns for synchronous and asynchronous communication between
other gen_servers and other OTP behaviors.
\end_layout
\begin_layout Itemize
The
\emph on
gen_fsm
\emph default
behavior is used in the protocol parser module in the GGS.
Using the gen_fsm behavior, finite state machines are easily developed.
Protocol parsers are an ideal example of where to use finite state machines,
which are widely used for parsing strings of text.
\end_layout
\begin_layout Standard
In addition to supplying behaviors, the OTP also has a style for packaging
and running Erlang applications.
By packaging the GGS as an
\emph on
application
\emph default
the GGS can be started in a way uniform to most Erlang software, providing
familiarity for other Erlang users, and eases the incorporation of the
GGS in other applications.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Application}}{A way of packaging Erlang software in a uniform way.}
\end_layout
\end_inset
\end_layout
\begin_layout Subsection
Short introduction to the Erlang syntax
\end_layout
\begin_layout Standard
In order to understand the examples in this thesis, a small subset of Erlang
must be understood.
In this section, the very syntactic basics of Erlang are given.
\end_layout
\begin_layout Itemize
\series bold
Variables
\series default
start with an uppercase letter, examples include
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt X, Var}, and {
\backslash
tt Global}
\end_layout
\end_inset
.
A variable can only be assigned once.
\end_layout
\begin_layout Itemize
\series bold
Atoms
\emph on
\series default
\emph default
start with lower case letters, for example:
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt atom, a}
\end_layout
\end_inset
.
\end_layout
\begin_layout Itemize
\series bold
Functions
\series default
are defined starting with an atom for the name, parenthesis containing
parameters, an arrow, a function body and finally a dot marking the end
of the function.
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt square(X) -> X*X.}
\end_layout
\end_inset
is an example of a function producing the square of X.
\end_layout
\begin_layout Itemize
Functions are
\series bold
called
\series default
by suffixing an atom with the function name with parenthesis, for example
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt square(10)}
\end_layout
\end_inset
.
Qualified names can be specified using ':', for example:
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt math:square(10)}
\end_layout
\end_inset
.
\end_layout
\begin_layout Itemize
\series bold
Tuples
\series default
are containers of fixed type for Erlang data types.
They are constructed using curly brackets, for example:
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt
\backslash
{atom1, atom2, atom3
\backslash
}}.
\end_layout
\end_inset
\end_layout
\begin_layout Itemize
\series bold
Lists
\series default
are constructed using [ and ], for example:
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt [1,2,3]}
\end_layout
\end_inset
.
\end_layout
\begin_layout Itemize
\series bold
Strings
\series default
are double-quoted lists of characters, for example
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt "Hello world"}
\end_layout
\end_inset
.
\end_layout
\begin_layout Itemize
\series bold
Records
\series default
are Erlang tuples coupled with a tag for each tuple element.
This allows referring to elements by name instead of by position.
An example of a record looks like this:
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt
\backslash
#myRecord{}}
\end_layout
\end_inset
.
\end_layout
\begin_layout Section
The modular structure of the GGS prototype
\begin_inset CommandInset label
LatexCommand label
name "sec:The-modular-structure"
\end_inset
\end_layout
\begin_layout Standard
The separation of concerns and the principle of single responsibility
\begin_inset Foot
status open
\begin_layout Plain Layout
More information on the SRP is available at:
\begin_inset CommandInset href
LatexCommand href
target "http://www.objectmentor.com/resources/articles/srp.pdf"
\end_inset
\end_layout
\end_inset
are widely respected as good practices in the world of software engineering
and development.
By dividing the GGS into modules each part of the GGS can be modified without
damaging or requiring changes in the rest of the system.
Due to the hot code update feature in Erlang, it is theoretically possible
to update parts of the GGS while the system is running, this has however
not been implemented in the prototype.
The modular composition of the GGS prototype should make a transition to
a fully hot code swappable system relatively easy.
Hot code replacements are discussed in more detail in section
\begin_inset CommandInset ref
LatexCommand ref
reference "sub:Hot-code-replacement"
\end_inset
.
\end_layout
\begin_layout Standard
The responsibility and concern of each module comes from the responsibility
and concern of the real-world entity the model represents.
The modeling of the GGS after a real-world system was discussed in chapter
\begin_inset CommandInset ref
LatexCommand vref
reference "cha:Theory"
\end_inset
.
\end_layout
\begin_layout Standard
In the text below the different modules of the GGS are presented.
In the text the word 'module' refers to the actual code of the discussed
feature, while the word 'process' is used when referring to a running instance
of the code.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{SRP}}{Single Responsibility Principle.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Object Oriented Programming}}{A programming paradigm focusing on
objects.}
\end_layout
\end_inset
\end_layout
\begin_layout Subsection
The dispatcher module
\end_layout
\begin_layout Standard
The dispatcher module is the first module to have contact with a player.
When a player connects to the GGS, the player is first greeted by the dispatche
r module, which sets up an accepting socket for each player.
The dispatcher is the module which handles the interaction with the operating
system when obtaining new sockets.
Operating system limits concerning the number of open files, or number
of open sockets are handled here.
The operating system limits can impose problems in the GGS, this is discussed
more in detail in chapter
\begin_inset CommandInset ref
LatexCommand vref
reference "sec:Operating-system-limitations"
\end_inset
.
\end_layout
\begin_layout Standard
Should the dispatcher module fail to function, no new connections to the
GGS can be made.
In the event of a crash in the dispatcher module, a supervisor process
immediately restarts the dispatcher.
There exists a window of time between the crashing of the dispatcher and
the restarting of the dispatcher, but this window is very short, and only
during this window is the GGS unable to process new connection requests.
Due to the modular structure of the GGS, the rest of the system is not
harmed by the dispatcher process not functioning.
The dispatcher process does not contain any kind of a state, therefore
a simple restart of the process is sufficient in restoring the GGS to a
pristine state after a dispatcher crash.
\end_layout
\begin_layout Standard
Returning to the scenario of the chess club, the dispatcher module is the
doorman of the club.
When a player enters the chess club, the player is greeted by the doorman,
letting the player into the club.
The actual admittance to the club is in the GGS represented by the creation
of a player process discussed in section
\begin_inset CommandInset ref
LatexCommand vref
reference "sub:The-player-module"
\end_inset
.
The newly created player process is handed the control over its own socket
connection.
\end_layout
\begin_layout Subsection
The player module
\begin_inset CommandInset label
LatexCommand label
name "sub:The-player-module"
\end_inset
\end_layout
\begin_layout Standard
The player module is responsible for representing a player in the system.
Each connected player has its own player process.
The player process has access to the connection of the client it represents,
and can communicate with this client.
In order to communicate with a client, the data to and from the player
object must pass through a protocol parser module, discussed in
\begin_inset CommandInset ref
LatexCommand vref
reference "sub:The-protocol-parser"
\end_inset
.
Raw communication, without passing the data through a protocol parser is
in theory possible, however it is not useful.
\end_layout
\begin_layout Standard
During the creation of a player process, the coordinator process, discussed
in
\begin_inset CommandInset ref
LatexCommand vref
reference "sub:The-coordinator-module"
\end_inset
, is notified by the newly created process in order to get access to the
lobby.
\end_layout
\begin_layout Standard
In the event of a crash in a player process, several things happen.
\end_layout
\begin_layout Enumerate
The player process, which is the only process with a reference to the socket
leading to the remote client software, passes this reference of the socket
to the coordinator process temporarily.
\end_layout
\begin_layout Enumerate
The player process exits.
\end_layout
\begin_layout Enumerate
The coordinator spawns a new player process with the same socket reference
as the old player process had.
\end_layout
\begin_layout Enumerate
The player process resumes operation, immediately starting a new protocol
parser process, and begins to receive and send network messages again.
\end_layout
\begin_layout Standard
The window of time between the crash of the player process and the starting
of a new player process is, as with the dispatcher, very short.
Since the connection changes owners for a short period of time, but is
never dropped, the implications of a crash are only noticed, at worst,
as choppy gameplay for the client.
Note however that this crash recovery scheme is only partly implemented
in the GGS prototype.
\end_layout
\begin_layout Standard
Moving back to the real-world example, the player process represents an
actual person in the chess club.
When a person sits down at a table in the chess club, the person does so
by requesting a seat from some coordinating person, and is then seated
by the same coordinator.
Once seated, the player may make moves on the table he or she is seated
by, this corresponds clearly to how the GGS is structured, as can be seen
in the following sections.
\end_layout
\begin_layout Subsection
The protocol parser module
\begin_inset CommandInset label
LatexCommand label
name "sub:The-protocol-parser"
\end_inset
\end_layout
\begin_layout Standard
The protocol parser is an easily interchangeable module in the GGS, handling
the client-to-server, and server-to-client protocol parsing.
In the GGS prototype, there is only one protocol supported, namely the
\emph on
GGS Protocol
\emph default
.
The role of the protocol parser is to translate the meaning of packets
sent using the protocol in use to internal messages of the GGS system.
The GGS protocol, discussed below is used as a sample protocol in order
to explain how protocol parsers can be built for the GGS.
\end_layout
\begin_layout Subsubsection
The structure of the GGS Protocol
\begin_inset CommandInset label
LatexCommand label
name "sub:The-structure-of"
\end_inset
\end_layout
\begin_layout Standard
The GGS protocol is modeled after the HTTP protocol.
The main reason for this is the familiarity many developers already have
with HTTP due to its presence in internet software.
Each GGS protocol packet contains a headers section.
The headers section is followed by a data section.
In the headers section, parameters concerning the packet are placed.
In the data section, the actual data payload of the packet is placed.
\end_layout
\begin_layout Standard
There is no requirement of any specific order of the parameters in the headers
section, however the data section must always follow directly after the
headers section separated by an empty new line.
\end_layout
\begin_layout Standard
In the example below, line 1 contains the Game-Command parameter.
This parameter is used to determine which game-specific command the client
is trying to perform.
The handling of this parameter is specific to each game, and can be anything.
\end_layout
\begin_layout Standard
Line 2 specifies the content type of the payload of this particular packet.
This parameter allows the GGS to invoke special parsers, should the data
be encoded or encrypted.
When encryption is applied, only the payload is encrypted, not the header
section.
This is a scheme which does not allow for strong encryption, but is deemed
feasible for gaming purposes.
\end_layout
\begin_layout Standard
Line 3 specifies the content length of the payload following immediately
after the headers section.
\end_layout
\begin_layout Standard
The parser of the GGS protocol implemented in the GGS prototype is designed
as a finite state machine using the gen_fsm behavior.
When a full message has been parsed by the parser, the message is converted
into the internal structure of the GGS messages, and sent to the system
from the protocol parser using the message passing functionality.
\end_layout
\begin_layout Standard
Line 4 is an empty line which is, like in the HTTP protocol, the separator
between the head and body or payload section.
\end_layout
\begin_layout Standard
Line 5 is the actual payload which is transported to the game as a parameter
of the playerCommand() function call.
\end_layout
\begin_layout Standard
\begin_inset Note Note
status open
\begin_layout Plain Layout
Packet below is not an algorithm, but I don't know how to change that label..
\end_layout
\end_inset
\end_layout
\begin_layout Standard
\begin_inset Float algorithm
wide false
sideways false
status open
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
lstset{
\end_layout
\begin_layout Plain Layout
backgroundcolor=
\backslash
color{white},
\end_layout
\begin_layout Plain Layout
extendedchars=true,
\end_layout
\begin_layout Plain Layout
basicstyle=
\backslash
footnotesize
\backslash
ttfamily,
\end_layout
\begin_layout Plain Layout
showstringspaces=false,
\end_layout
\begin_layout Plain Layout
showspaces=false,
\end_layout
\begin_layout Plain Layout
numbers=left,
\end_layout
\begin_layout Plain Layout
numberstyle=
\backslash
footnotesize,
\end_layout
\begin_layout Plain Layout
numbersep=9pt,
\end_layout
\begin_layout Plain Layout
tabsize=2,
\end_layout
\begin_layout Plain Layout
breaklines=true,
\end_layout
\begin_layout Plain Layout
showtabs=false,
\end_layout
\begin_layout Plain Layout
captionpos=b
\end_layout
\begin_layout Plain Layout
}
\end_layout
\begin_layout Plain Layout
\backslash
begin{lstlisting}
\end_layout
\begin_layout Plain Layout
Game-Command: chat
\end_layout
\begin_layout Plain Layout
Content-Type: text
\end_layout
\begin_layout Plain Layout
Content-Length: 18
\end_layout
\begin_layout Plain Layout
\end_layout
\begin_layout Plain Layout
Hello world, guys!
\end_layout
\begin_layout Plain Layout
\backslash
end{lstlisting}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption
\begin_layout Plain Layout
\begin_inset CommandInset label
LatexCommand label
name "alg:A-sample-packet"
\end_inset
A sample packet sent from a client to the GGS during a chat session
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Subsection
The coordinator module
\begin_inset CommandInset label
LatexCommand label
name "sub:The-coordinator-module"
\end_inset
\end_layout
\begin_layout Standard
The coordinator module is responsible for keeping track of all players,
their seats and tables.
Players register with the coordinator process when first connecting to
the server.
The coordinator places each player by their respective table.
\end_layout
\begin_layout Standard
The coordinator keeps relations between each player and table, therefore
it is used to perform lookups on tables and players to find out which ones
that are connected.
The connectivity of players and tables is important when sending messages
to all participants in a game.
A lookup in the coordinator process is performed before notifying all players
in a game to ensure the message reaches all players.
The lookup can be performed either using internal identification codes
or using the UUID associated with each client and table.
\end_layout
\begin_layout Standard
The coordinator process contains an important state, therefore a backup
process is kept at all times.
All good data processed by the coordinator is stored for safekeeping in
the backup process as well.
Data which is potentially harmful is not stored in the backup process.
\end_layout
\begin_layout Standard
In the event of a crash, the coordinator process recovers the prior good
state from the backup process and continues where it left off.
A supervisor process monitors the coordinator process and restarts the
process when it malfunctions.
There is a window of time between the crash of the coordinator and the
restart of a new coordinator process.
During this time, players cannot be seated by new tables and cannot disconnect
from the server.
This window of time is very small, and the unavailability of the coordinator
process should not be noticed by more than a short time lag for the clients.
\end_layout
\begin_layout Standard
Moving back to the example of the chess club, the coordinator process can
be seen as a host in the chess club, seating players by their tables and
offering services to the players.
\end_layout
\begin_layout Subsection
The table module
\end_layout
\begin_layout Standard
The table module is mostly a hub used for communication.
New table processes are created by the coordinator on demand.
The table module does not contain any business logic, however each process
contains information concerning which players are seated by that particular
table.
\end_layout
\begin_layout Standard
The information about which players are seated by each table is used when
notifying all players by a table of an action.
Consider a game of chess, each player notifies the table of its actions,
the table then notifies the rest of the participants of these actions after
having had the actions processed by the game VM, where an action could
be moving a playing piece in the game.
\end_layout
\begin_layout Standard
Each table is associated with a game VM.
The actions sent to a table are processed by the game VM, this is where
the game logic is implemented.
\end_layout
\begin_layout Standard
After a crash in a table process, the entire table must be rebuilt and the
players must be re-associated with the table.
Data concerning players is kept in the coordinator process and is restored
from there.
Data kept in the actual game is not automatically corrupted by the crash
in a table, however the table must be re-associated with the game VM it
was associated with before the crash of the table.
The table process maps well to the setting of the real-world chess club
scenario previously discussed.
A table works in the same way in a real-world setting as in the GGS setting.
\end_layout
\begin_layout Subsection
The game virtual machine module
\end_layout
\begin_layout Standard
This module is responsible for the VM associated with each game.
\end_layout
\begin_layout Standard
The game VM contains a connection to the GDL VM and a table token associated
with a running game.
The game VM is started by the table module during its initialization.
The table module hands over a token used for identification to the game
VM during the initialization.
During the initialization a new GDL VM instance and various objects associated
to the GDL VM instance are created.
Callbacks to Erlang are registered into the GDL VM and the source code
of a game is loaded into the GDL VM, finally the game is ready for startup.
The only means for a game to communicate with the GGS is through usage
of a provided interface.
\end_layout
\begin_layout Standard
The GDL VM itself makes it possible for the game developer to program in
the programming language covered by the GDL VM.
In future releases, more GDL VMs will be added to support more programming
languages.
Since the game VM keeps track of the correct table, the game developer
does not need to take this into consideration when programming a game.
If a method within the game sends data to a player, the data is delivered
to the player in the correct game.
The same game token is used to store the game state in the database.
Therefore, no game states can be mixed up.
\end_layout
\begin_layout Standard
This module does not affect game runtime but evaluates a new game state
and handles communication between the game and the players.
A closer look at the structure of this model is given in
\begin_inset CommandInset ref
LatexCommand vref
reference "sec:Communication-with-the-GDL-VM"
\end_inset
.
\end_layout
\begin_layout Standard
The code which is run in the GDL VM is uploaded to the GGS prior to each
game.
Allowing the clients to upload code allows clients to run any game.
\end_layout
\begin_layout Subsection
The database module
\begin_inset CommandInset label
LatexCommand label
name "sub:The-database-module"
\end_inset
\end_layout
\begin_layout Standard
Game data from all games on the GGS is stored in the database backend of
the database module.
\end_layout
\begin_layout Standard
In the GGS prototype the database module is using a database management
system called Mnesia.
Mnesia ships with the standard Erlang distribution and is a key-value store
type of database.
Mnesia is designed to handle the stress of telecoms systems
\begin_inset CommandInset citation
LatexCommand citep
key "667766"
\end_inset
, therefore it has some features specifically tailored for telecoms which
are not commonly found in other databases.
Key features of the Mnesia database are:
\end_layout
\begin_layout Itemize
Fast key/value lookups
\end_layout
\begin_layout Itemize
Distribution of the database system
\end_layout
\begin_layout Itemize
Fault tolerance
\end_layout
\begin_layout Standard
The features of Mnesia originally intended for telecoms prove very useful
for the GGS as well.
The fault tolerance and speed of Mnesia are valuable tools, the fast key/value
lookups permit many lookups per second from the database.
\end_layout
\begin_layout Standard
Game data will not be lost when a game is stopped or has gone down for any
reason.
This makes it possible to continue a game from the point just before the
failure without having to restart the complete game.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Mnesia}}{Database server used in the GGS.}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
The GGS stores the game states in the distributed database Mnesia, from
which the state can be restored in an event of a crash.
\end_layout
\begin_layout Standard
Each game is uniquely identified by a table token and the data of each game
is stored within two different namespaces.
The namespaces are named
\noun on
world
\noun default
and
\noun on
localStorage
\noun default
.
The
\noun on
World
\noun default
is used contain all game data related to the game state.
This sort of game data may change during the runtime of the game.
The
\noun on
localStorage
\noun default
contains data independent of the game state.
Game resources, constants and global variables are all examples of data
that reside within the
\noun on
localStorage
\noun default
.
To store a value within the database, not only are the table token and
the name of the namespace required, but a unique key so that the value
can be successfully retrieved or modified later.
The key is decidable by the game developer.
\end_layout
\begin_layout Standard
The interface of the database module is an implementation of the upcoming
W3C Web Storage specification.
Web Storage is intended for use in web browsers, providing a persistent
storage on the local machine for web applications.
The storage can be used to communicate among browser windows (which is
difficult when using cookies), and to store larger chunks of data
\begin_inset CommandInset citation
LatexCommand citep
key "webstorage:website"
\end_inset
.
Usage of the Web Storage standard in the GGS provides a well documented
interface to the database backend.
\end_layout
\begin_layout Section
Communication with the GDL VM
\begin_inset CommandInset label
LatexCommand label
name "sec:Communication-with-the-GDL-VM"
\end_inset
\end_layout
\begin_layout Standard
A game launched on the GGS is run within a virtual machine.
For each programming language supported, there is a virtual machine which
interprets the game.
Furthermore an interface for communication among the GGS, the game and
the players playing the game is present.
\end_layout
\begin_layout Standard
Callbacks written in Erlang are registered to the VM for the interface to
work.
It is only with the help of the interface that the game developer can access
the game state and send messages to the clients.
The interface provides access to three objects called
\emph on
\noun on
world
\noun default
,
\noun on
players
\emph default
\noun default
and
\emph on
\noun on
localStorage
\emph default
\noun default
.
The game state is safely stored in a database and retrieved for manipulation
by a call for the world object.
Interaction with the players is done by using the
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt GGS.sendCommand(player
\backslash
_id, command, args)}
\end_layout
\end_inset
\emph default
and
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt GGS.sendCommandToAll(command, args)}
\end_layout
\end_inset
\emph default
.
The
\noun on
localStorage
\noun default
is a convenient way to store global data and other variables separated
from the game state.
Unique IDs called game tokens are generated for hosted games so that they
are not mixed up.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Web Storage}}{A new standard for letting websites store data on visitors'
computers.}
\end_layout
\end_inset
\end_layout
\begin_layout Subsection
Exposing Erlang functionality to the GDL VM
\begin_inset CommandInset label
LatexCommand label
name "sub:Exposing-Erlang-functionality"
\end_inset
\end_layout
\begin_layout Standard
This section contains a concrete example of how the
\noun on
localStorage
\noun default
and
\noun on
world
\noun default
objects are exposed to a GDL VM.
The example comes from the GGS prototype, which uses JavaScript powered
by Google V8 as its GDL VM.
\end_layout
\begin_layout Standard
The code given in
\begin_inset CommandInset ref
LatexCommand ref
reference "alg:exposing-erlang"
\end_inset
is specific to V8 and JavaScript, however implementations for different
GDLs, or different VMs should be similar.
\end_layout
\begin_layout Standard
In JavaScript it is common to use a top level object, called a global object,
to establish a global scope.
This allows the declaration of global variables and functions.
To gain access to the global object in the GGS, the
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt erlv8
\backslash
_vm:global(..)}
\end_layout
\end_inset
function on line 2 of the example is used.
Using the global object, declarations of the world and GGS object can be
placed in the global scope.
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt Global:set
\backslash
_value(..)}
\end_layout
\end_inset
is a call to the global object, declaring new objects in the global scope.
On line 4 the GGS object is declared.
By accessing
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt GGS.localStorage }
\end_layout
\end_inset
from within the GDL, access to the
\noun on
localStorage
\noun default
is provided, thus the
\noun on
localStorage
\noun default
must be connected to the GGS object, this can be seen in line 5.
\end_layout
\begin_layout Standard
Both the
\noun on
GGS
\noun default
and
\noun on
localStorage
\noun default
objects are dummy objects, which provide no functionality, these two objects
are simply placed in the GDL for the purpose of clearing up the code.
To perform an action using the GGS and
\noun on
localStorage
\noun default
objects, the
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt getItem} and {
\backslash
tt setItem}
\end_layout
\end_inset
functions must be used.
These items are directly connected to the database module of the GGS, which
is discussed in more detail in
\begin_inset CommandInset ref
LatexCommand ref
reference "sub:The-database-module"
\end_inset
.
\end_layout
\begin_layout Standard
Similarly the functions
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt sendCommand, sendCommandToAll} and {
\backslash
tt setTimeout}
\end_layout
\end_inset
are directly connected to a piece of code in the GGS which performs the
desired action.
The
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt sendCommand}
\end_layout
\end_inset
functions are used to send commands or text to participants of the table.
The
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt setTimeout}
\end_layout
\end_inset
function introduces timeouts to the V8 engine, which are not available
per default.
\end_layout
\begin_layout Standard
\begin_inset Float algorithm
wide false
sideways false
status open
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
lstset{
\end_layout
\begin_layout Plain Layout
language=Erlang,
\end_layout
\begin_layout Plain Layout
backgroundcolor=
\backslash
color{white},
\end_layout
\begin_layout Plain Layout
extendedchars=true,
\end_layout
\begin_layout Plain Layout
basicstyle=
\backslash
footnotesize
\backslash
ttfamily,
\end_layout
\begin_layout Plain Layout
showstringspaces=false,
\end_layout
\begin_layout Plain Layout
showspaces=false,
\end_layout
\begin_layout Plain Layout
numbers=left,
\end_layout
\begin_layout Plain Layout
numberstyle=
\backslash
footnotesize,
\end_layout
\begin_layout Plain Layout
numbersep=9pt,
\end_layout
\begin_layout Plain Layout
tabsize=2,
\end_layout
\begin_layout Plain Layout
breaklines=true,
\end_layout
\begin_layout Plain Layout
showtabs=false,
\end_layout
\begin_layout Plain Layout
captionpos=b
\end_layout
\begin_layout Plain Layout
}
\end_layout
\begin_layout Plain Layout
\backslash
begin{lstlisting}[language=Erlang]
\end_layout
\begin_layout Plain Layout
% @doc Exposes some GGS functions to JavaScript
\end_layout
\begin_layout Plain Layout
expose(GameVM, Table) ->
\end_layout
\begin_layout Plain Layout
Global = erlv8_vm:global(GameVM),
\end_layout
\begin_layout Plain Layout
Global:set_value("GGS", erlv8_object:new([
\end_layout
\begin_layout Plain Layout
{"localStorage", erlv8_object:new([
\end_layout
\begin_layout Plain Layout
{"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])->
\end_layout
\begin_layout Plain Layout
ggs_db:setItem(Table, local_storage, Key, Val)
\end_layout
\begin_layout Plain Layout
end},
\end_layout
\begin_layout Plain Layout
{"getItem", fun(#erlv8_fun_invocation{}, [Key])->
\end_layout
\begin_layout Plain Layout
ggs_db:getItem(Table, local_storage, Key)
\end_layout
\begin_layout Plain Layout
end}
\end_layout
\begin_layout Plain Layout
% more functions ...
\end_layout
\begin_layout Plain Layout
])},
\end_layout
\begin_layout Plain Layout
{"world", erlv8_object:new([
\end_layout
\begin_layout Plain Layout
{"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])->
\end_layout
\begin_layout Plain Layout
ggs_db:setItem(Table, world, Key, Val),
\end_layout
\begin_layout Plain Layout
ggs_table:send_command_to_all(
\end_layout
\begin_layout Plain Layout
Table, {"world_set", Key ++ "=" ++ Val}
\end_layout
\begin_layout Plain Layout
)
\end_layout
\begin_layout Plain Layout
end},
\end_layout
\begin_layout Plain Layout
{"getItem", fun(#erlv8_fun_invocation{}, [Key])->
\end_layout
\begin_layout Plain Layout
ggs_db:getItem(Table, world, Key),
\end_layout
\begin_layout Plain Layout
end}
\end_layout
\begin_layout Plain Layout
% more functions ...
\end_layout
\begin_layout Plain Layout
])},
\end_layout
\begin_layout Plain Layout
{"sendCommand", fun(#erlv8_fun_invocation{}, [Player, Command, Args])->
\end_layout
\begin_layout Plain Layout
ggs_table:send_command(Table, Player, {Command, Args})
\end_layout
\begin_layout Plain Layout
end},
\end_layout
\begin_layout Plain Layout
{"sendCommandToAll", fun(#erlv8_fun_invocation{}, [Command, Args])->
\end_layout
\begin_layout Plain Layout
ggs_table:send_command_to_all(Table, {Command, Args})
\end_layout
\begin_layout Plain Layout
end}
\end_layout
\begin_layout Plain Layout
{"setTimeout", fun(#erlv8_fun_invocation{}, [Time, Function])->
\end_layout
\begin_layout Plain Layout
timer:apply_after(Time, ?MODULE, call_js, [GameVM, Function])
\end_layout
\begin_layout Plain Layout
end}
\end_layout
\begin_layout Plain Layout
% more functions ...
\end_layout
\begin_layout Plain Layout
])).
\end_layout
\begin_layout Plain Layout
\backslash
end{lstlisting}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption
\begin_layout Plain Layout
\begin_inset CommandInset label
LatexCommand label
name "alg:exposing-erlang"
\end_inset
An example of how Erlang functionality is exposed to a JavaScript GDL VM.
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Standard
\begin_inset Note Note
status open
\begin_layout Plain Layout
TODO: Go in to more detail about how the world, player and localstorage
objects are implemented.
Also discuss localstorage and how it derives from the webstorage standard
in detail.
This is a great point on how we try to follow standards.
\end_layout
\end_inset
\end_layout
\begin_layout Section
Techniques for ensuring reliability
\end_layout
\begin_layout Standard
One main goal of the project is to achieve high reliability.
The term 'reliable system' is defined by the IEEE as
\end_layout
\begin_layout Quotation
A system with the ability of a system or component to perform its required
functions under stated conditions for a specified period of time
\begin_inset CommandInset citation
LatexCommand citep
key "ieee_90"
\end_inset
.
\end_layout
\begin_layout Standard
There are some tools built into Erlang that help creating reliable applications
:
\begin_inset ERT
status collapsed
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{Reliability}}{The ability of a system or component to perform its
required functions under stated conditions for a specified period of time}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{IEEE}}{Institute of Electrical and Electronics Engineers, read "I-triple-
E"}
\end_layout
\end_inset
\end_layout
\begin_layout Itemize
\series bold
Links between processes
\series default
.
When a process spawns a new child process, and the child process later
exits, the parent process is notified of the exit.
\end_layout
\begin_layout Itemize
\series bold
Transparent distribution over a network of processors
\series default
.
When several nodes participate in a network, it does not matter on which
of these machines a process is run.
Communication between processes does not depend on the node in which each
process is run.
\end_layout
\begin_layout Itemize
\series bold
Hot code replacements
\series default
.
Two versions of the same module can reside in the memory of Erlang at any
time.
This means that a simple swap between these versions can take place very
quickly, and without stopping the machine.
\end_layout
\begin_layout Standard
These three features are some of the basic building blocks for more sophisticate
d reliable systems in Erlang.
Often it is not necessary to use these features directly, but rather through
the design patterns described below.
\end_layout
\begin_layout Subsection
Supervisor structure
\begin_inset CommandInset label
LatexCommand label
name "sub:Supervisor-structure"
\end_inset
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
begin{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Graphics
filename graphics/Supervisor_tree_GGS.eps
scale 40
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
end{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption
\begin_layout Plain Layout
\begin_inset CommandInset label
LatexCommand label
name "fig:The-supervisor-structure"
\end_inset
The supervisor structure of the GGS
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Standard
By linking processes together and notifying parents when children exit,
supervisors are created.
A supervisor is a common approach in ensuring that an application functions
in the way it was intended to
\begin_inset CommandInset citation
LatexCommand citep
key "Savor:1997:HSA:851010.856089"
\end_inset
.
When a process misbehaves, the supervisor takes some action to restore
the process to a functional state.
In the case of the GGS, a process misbehaving most commonly triggers a
restart of the faulting process.
\end_layout
\begin_layout Standard
There are several approaches to a supervisor design in general.
One common approach is to have the supervisor look into the state of the
processes it supervises, and let the supervisor make decisions based on
this state.
The supervisor has a specification of how the processes it supervises should
function, this is how it makes decisions.
\end_layout
\begin_layout Standard
In Erlang, there is a simple version of supervisors.
No state of the processes being supervised is actually monitored.
There is, however a specification of how the supervised processes should
behave, but on a higher level.
The specification describes things such as how many times in a given interval
a child process may crash, which processes need restarting when crashes
occur, etc.
\end_layout
\begin_layout Standard
When the linking of processes to monitor exit behavior is coupled with the
transparent distribution of Erlang, a very powerful supervision system
is created.
For instance is it possible to restart a failing process on a different,
new node, with minimal impact on the system as a whole.
\end_layout
\begin_layout Standard
In the GGS, the system has been separated into two large supervised parts.
An attempt to restart a crashing child separately is made, if this fails
too many
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
Exactly how many
\begin_inset Quotes eld
\end_inset
too many
\begin_inset Quotes erd
\end_inset
is depends on a setting in the supervisor, ten crashes per second is a
reasonable upper limit.
\end_layout
\end_inset
times, the nearest supervisor of this child is restarted.
This ensures separation of the subsystems so that a crash is as isolated
as possible.
\end_layout
\begin_layout Standard
Figure
\begin_inset CommandInset ref
LatexCommand vref
reference "fig:The-supervisor-structure"
\end_inset
shows the two subsystems, the coordinator subsystem and the dispatcher
subsystem.
Since these two systems perform very different tasks they have been separated.
Each subsystem has one worker process, the coordinator or the dispatcher.
The worker process keeps a state which should not be lost in the event
of a crash.
\end_layout
\begin_layout Standard
The choice has been made to let faulty processes crash very easily when
they receive bad data, or something unexpected happens.
The alternative to crashing would have been to try to fix this faulty data,
or to foresee the unexpected events.
This was not chosen since it is so simple to monitor and restart processes,
and difficult to try to mend broken states.
This approach is something widely deployed in the Erlang world, and developers
are often encouraged to “Let it crash”
\begin_inset CommandInset citation
LatexCommand citep
key "Armstrong03"
\end_inset
.
\end_layout
\begin_layout Standard
To prevent any data loss, the good state of the worker processes is stored
in their respective backup processes.
When a worker process (re)starts, the backup process is queried for any
previous state, if there is any, that state is loaded into the worker and
it proceeds where it left off.
If on the other hand no state is available, a special message is delivered
instead, making the worker create a new state, this is what happens when
the workers are first created.
\end_layout
\begin_layout Subsection
Redundancy
\end_layout
\begin_layout Standard
The modules in the GGS are built to be capable of redundant operations.
By adding a backup process to sensitive processes, the state can be kept
in the event of a crash.
The coordinator of the GGS prototype has this backup feature built in.
The coordinator passes the state along to the backup process which keeps
the data safe.
If a crash occurs, the coordinator recovers the state from the backup process.
Figure
\begin_inset CommandInset ref
LatexCommand ref
reference "fig:redundancy"
\end_inset
depicts the redundancy built in to the coordinator process.
\end_layout
\begin_layout Standard
This type of redundancy is only implemented in the coordinator process,
similar configurations should however be possible for all modules of the
GGS.
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status collapsed
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
begin{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Graphics
filename graphics/redundancy.eps
scale 40
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
end{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption
\begin_layout Plain Layout
\begin_inset CommandInset label
LatexCommand label
name "fig:redundancy"
\end_inset
To the left normal execution is pictured; the server state is backed up.
To the right; the exceptional execution, where the state is retrieved from
the backup to repopulate the server.
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Subsection
Hot code replacement
\begin_inset CommandInset label
LatexCommand label
name "sub:Hot-code-replacement"
\end_inset
\end_layout
\begin_layout Standard
Hot code replacement is a technique used to update systems while they are
running.
The main use of hot code replacement is in critical systems that require
low downtime, such as telecom systems.
By using hot code replacement, systems are able to achieve much longer
uptimes and thus improving the reliability of the system.
Code replacement is a feature that exists in Erlang which means that with
some work it could be implemented into the GGS.
\end_layout
\begin_layout Section
Testing
\end_layout
\begin_layout Standard
To make sure the GGS prototype adheres to the specification set, three different
approaches to software testing are used.
For simpler testing the GGS prototype uses unit tests.
Modules are tested on a high level, making sure each function in the module
tested functions has been tested according to the specification.
\end_layout
\begin_layout Standard
Unit testing is not employed to test the system from the client side.
In order to more accurately simulate real users some randomization is needed,
as users do not always act rationally.
In order to introduce random data, the client side of the GGS is simulated
by QuickCheck tests.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{QuickCheck}}{QuickCheck is a library designed to assist in software
testing by generating test cases for test suites.}
\end_layout
\end_inset
\end_layout
\begin_layout Standard
Finally to test the robustness of the prototype virtual users, so called
bots are being used to simulate large amounts of players playing different
games simultaneously.
\end_layout
\begin_layout Subsection
Unit testing
\end_layout
\begin_layout Standard
Unit testing is a way to check if the functionality adheres to the specification
of the system by manually creating test cases for sections of code, usually
complete functions.
Unit testing is good, not only for revealing software bugs, but also to
state that a feature is working according to the specification.
\end_layout
\begin_layout Standard
Unit testing is an useful way to create regression tests.
Regression tests are used to make sure changes made to the GGS do not introduce
new bugs or break the specification.
The regression tests are optimally run very often, such as after each change
to the code.
\begin_inset Note Note
status open
\begin_layout Plain Layout
continuous testing, agile, something like that could be mentioned here!
By the way, do you know http://schneide.wordpress.com/2008/10/27/extreme-feedback
-device-xfd-the-onoz-lamp/? the whole category http://schneide.wordpress.com/categ
ory/extreme-feedback/ could be interesting ...
\end_layout
\end_inset
\end_layout
\begin_layout Standard
Erlang provides a module for unit testing called EUnit.
EUnit, being a part of OTP, is rich in functionality and well documented,
it does not however allow any means of testing of asynchronous behaviors
as opposed to other means of software testing.
\end_layout
\begin_layout Subsection
Automated test case generation
\end_layout
\begin_layout Standard
The problem of writing software tests manually is that it takes a lot of
time.
There exists other ways to test software that addresses this problem by
generating test cases with certain properties.
This allows for testing functions with a lot of different input parameters
without having to implement each specific test itself.
\end_layout
\begin_layout Standard
By having each test automatically generated, each test can be very complex
and long.
In order to generate random, complex tests the GGS uses QuickCheck.
By using QuickCheck the GGS can be tested with input which would be extremely
difficult to construct using manual testing methods.
Regression tests, such as the unit tests used by the GGS are more useful
for ensuring that the system does not diverge from a working scenario than
for finding new cases where the specification does not hold
\begin_inset CommandInset citation
LatexCommand citep
key "Arts:2006:TTS:1159789.1159792"
\end_inset
.
\end_layout
\begin_layout Standard
The entire GGS was not tested using QuickCheck, nor was the entire client
protocol for a game tested using QuickCheck, however the tests performed
using QuickCheck show that an automated testing system such as QuickCheck
is a very viable testing method for the GGS.
\end_layout
\begin_layout Standard
QuickCheck has features to generate very large and complex tests, the results
of which can be hard to analyze.
The solution to reading these complex test results is to extract a
\emph on
minimal failing test case
\emph default
which contains the smallest failing test sequence.
By applying a very large test and gradually simplifying the test to find
the smallest failing sequence, many bugs which would otherwise have been
hard to catch can be caught
\begin_inset CommandInset citation
LatexCommand citep
key "Arts:2006:TTS:1159789.1159792"
\end_inset
.
\end_layout
\begin_layout Standard
QuickCheck was originally made for the programming language Haskell.
There are a lot of implementations of QuickCheck in various programming
languages.
Erlang QuickCheck (EQC) and Triq are two variants of QuickCheck for Erlang.
EQC was chosen for testing the GGS.
Besides the standard functionality that QuickCheck provides, EQC is capable
of testing concurrency within a program.
\end_layout
\begin_layout Subsection
Bots
\end_layout
\begin_layout Standard
In order to test the robustness of the GGS several different artificial
users, so called bots, have been implemented.
Each of these bots is programmed to play a game on the GGS as similar to
a real user as possible.
For the GGS there is no difference in serving a real user or a bot.
A large amount of players can be simulated playing games on the GGS simultaneou
sly, which is a good stress and concurrency test for the overall system.
In section
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Statistics"
\end_inset
some of the statistical data retrieved with help of a whole network of
bots playing games is being presented.
\end_layout
\begin_layout Section
Case studies
\end_layout
\begin_layout Standard
This section contains three case studies.
These case studies have been written to provide examples of how the flow
through the GGS can look when performing different tasks.
The first case study outlines the flow of sending a common message to the
GDL VM and receiving a response.
The second case study provides an example of the process of connecting
to the GGS to set up a game.
The third and final case study is a section of code from a part of a game
for the GGS.
The code in the third study shows how a simple chat server can be implemented
in the GGS using JavaScript as GDL.
\end_layout
\begin_layout Subsection
Typical communication
\end_layout
\begin_layout Standard
This case study describes the flow through the GGS when a typical command
is encountered.
Below is a case study where a chat client sends a message to change the
nick name of a user.
The actual code performing the change of a nick name in JavaScript is discussed
in section
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Example-of-a-GGS-app"
\end_inset
.
All communication between modules is asynchronous, nothing is blocking,
which is very important in concurrent systems.
To follow the example more easily, looking at the graphic in section
\begin_inset CommandInset ref
LatexCommand vref
reference "fig:The-layout-of"
\end_inset
is recommended.
\end_layout
\begin_layout Enumerate
The client packages a Game-Command into a
\emph on
GGS protocol packet
\emph default
which conforms to the protocol structure the GGS is using and sends it
over the network.
\end_layout
\begin_layout Enumerate
The player process, which is coupled to the TCP process which reacts on
incoming messages, accepts the message and forwards the raw data to the
protocol parser process.
\end_layout
\begin_layout Enumerate
The protocol parser process parses the message and brings it into the format
of the internal GGS representation of such a message, which is just a specializ
ed Erlang tuple.
\end_layout
\begin_layout Enumerate
The protocol parser sends this Erlang tuple back to the player process.
\end_layout
\begin_layout Enumerate
The player process checks if the command is a Server-Command or a Game-Command.
In our example it is a Game-Command and it sends the message to the table
process.
\end_layout
\begin_layout Enumerate
The table process sends it to its own game VM process.
\end_layout
\begin_layout Enumerate
The game VM process calls the function
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt playerCommand("278d5", "nick", "Peter")}
\end_layout
\end_inset
\emph default
within the JavaScript VM (JSVM).
\end_layout
\begin_layout Enumerate
The JSVM - at this stage Googles V8 JavaScript Engine - evaluates the function
within the sandboxed game context which has been established earlier during
the setup of the game.
\end_layout
\begin_layout Enumerate
In the example in section
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Example-of-a-GGS-app"
\end_inset
we see that the GGS functions
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt GGS.localStorage.setItem(key, value)}
\end_layout
\end_inset
\emph default
and
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt GGS.localStorage(key)}
\end_layout
\end_inset
\emph default
are used.
Both are callbacks coupled to the database module functions.
\end_layout
\begin_layout Enumerate
Data is read from and written to the database and handed over to the JSVM
via the database process.
\end_layout
\begin_layout Enumerate
In the example the
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt GGS.sendCommandToAll()}
\end_layout
\end_inset
\emph default
is being called then which is a callback to a function of the table module
which iterates through its player list and sends the command to every player.
\end_layout
\begin_layout Enumerate
The table process sends every player process the message to send the message
with the change of a nickname of a particular user to its own client.
\end_layout
\begin_layout Enumerate
The player process asks the protocol process to create a message conforming
to the protocol which is being used.
\end_layout
\begin_layout Enumerate
The protocol process creates a string according to the protocol and returns
it to the player process.
\end_layout
\begin_layout Enumerate
The player process sends the message with help of the gen_tcp module to
the client.
\end_layout
\begin_layout Subsection
Initialization and life cycle of a game
\end_layout
\begin_layout Standard
This case study describes the initialization and definition of a game and
roughly its life cycle until it is removed from the GGS.
\end_layout
\begin_layout Subsubsection
Initialization
\end_layout
\begin_layout Enumerate
A client connects via TCP to the GGS.
\end_layout
\begin_layout Enumerate
The dispatcher process reacts on the incoming connection and creates a new
player process.
\end_layout
\begin_layout Enumerate
The dispatcher process couples the TCP connection to the newly created player
process, this way the new player process is responsible to react on incoming
messages.
\end_layout
\begin_layout Enumerate
The client sends a message with a
\noun on
hello
\noun default
Server-Command to initiate a handshake.
\end_layout
\begin_layout Enumerate
The player module parses the message with help of the protocol module.
\end_layout
\begin_layout Enumerate
If the message was just a plain
\noun on
hello
\noun default
, without a table token, then the player process asks the coordinator process
to create a new table process and add this player process to this newly
created table.
If the client did send a table token then the player process asks the coordinat
or to add the player process to this table.
\end_layout
\begin_layout Enumerate
During the creation of a new table the table process creates a new game
VM process which creates its own game context within the JSVM.
\end_layout
\begin_layout Enumerate
The player process answers to the client with a
\noun on
hello
\noun default
Client-Command and passes on the clients player token along with the informatio
n about whether it should define a game.
The first client to connect to this table should define the new game.
\end_layout
\begin_layout Subsubsection
Defining a game
\end_layout
\begin_layout Standard
The generic nature of the GGS leaves it up to the client to define which
game should be run.
The definition is done in the GDL, in this example the GDL is JavaScript.
It is possible to alter the GGS prototype so that only the server maintainer
is able to install new games on the server, however the current implementation
of the GGS is much more generic.
\end_layout
\begin_layout Standard
The first client which connects to a table is responsible to provide the
JavaScript server source code.
To do so there is a
\noun on
define
\noun default
Server-Command.
\end_layout
\begin_layout Enumerate
If during the handshake with the
\noun on
hello
\noun default
command the client is assigned the task of providing the server source
code then the client must send a
\noun on
define
\noun default
Server-Command message with the source code as its payload.
Only the first client will get the information about the need of defining
a game during the handshake.
\end_layout
\begin_layout Enumerate
The player process parses the message, with help of the protocol module.
\end_layout
\begin_layout Enumerate
The player process sends the source code to the table process assigned to
the player as a
\noun on
define
\noun default
message.
\end_layout
\begin_layout Enumerate
The table process forwards the source code to the game VM process.
\end_layout
\begin_layout Enumerate
The game VM process executes the source code within the JavaScript VM.
\end_layout
\begin_layout Enumerate
The JavaScript VM evaluates the source code - which has to implement the
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt playerCommand()}
\end_layout
\end_inset
function - within the context of the game.
\end_layout
\begin_layout Enumerate
The game is at this point fully initialized and can be used by all clients
with help of the
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt playerCommand()}
\end_layout
\end_inset
function.
\end_layout
\begin_layout Enumerate
The table process saves the source code in the database for backup reasons
(this is not yet implemented).
\end_layout
\begin_layout Enumerate
The player process sends a
\noun on
defined
\noun default
Client-Command to the client.
This way the client is notified that everything went well and it can start
the game.
\end_layout
\begin_layout Subsubsection
Life cycle
\end_layout
\begin_layout Enumerate
Initialization.
\end_layout
\begin_layout Enumerate
Defining a game.
\end_layout
\begin_layout Enumerate
Other clients connect and initialize but do not define anything.
\end_layout
\begin_layout Enumerate
Typical communication.
\end_layout
\begin_layout Enumerate
Clients disconnect.
\end_layout
\begin_layout Enumerate
When the last client disconnects, the table process terminates and with
it the game context and database content (not implemented in the prototype).
\end_layout
\begin_layout Subsection
A GGS server application in JavaScript
\begin_inset CommandInset label
LatexCommand label
name "sec:Example-of-a-GGS-app"
\end_inset
\end_layout
\begin_layout Standard
Below is a concrete example of part of a game, a simple in-game-chat server
application written using the GGS.
The language chosen for this chat server is JavaScript.
The GGS processes all incoming data through a protocol parser, which interprets
the data and parses it into an internal format for the GGS.
\end_layout
\begin_layout Standard
When the GGS receives a
\emph on
Game-Command
\emph default
from a client, it is passed along to the game VM through a function called
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt playerCommand()}
\end_layout
\end_inset
\emph default
which is the entry point for each game and has to be implemented by the
developer; it can be seen as the
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt main()}
\end_layout
\end_inset
\emph default
function of a C or Java program
\emph on
.
\emph default
Typically the
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt playerCommand()}
\end_layout
\end_inset
\emph default
function contains conditional constructs which decide the next action to
take.
In
\begin_inset CommandInset ref
LatexCommand ref
reference "alg:A-concrete-example"
\end_inset
an example of the
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt playerCommand()}
\end_layout
\end_inset
\emph default
function can be seen.
\end_layout
\begin_layout Standard
In
\begin_inset CommandInset ref
LatexCommand ref
reference "alg:A-concrete-example"
\end_inset
the
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt playerCommand()}
\end_layout
\end_inset
\emph default
function accepts two different commands.
The first command is a command which allows chat clients connected to the
chat server to change the nicknames, which are used when chatting.
In order to change the nickname, a client must send a Game-Command
\noun on
nick
\noun default
with the actual new nick name as its payload.
When a message arrives at the GGS which has the form corresponding to the
nick name change, the
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt playerCommand()}
\end_layout
\end_inset
\emph default
function is called with the parameters
\emph on
player_id, command,
\emph default
and
\emph on
args
\emph default
filled in appropriately.
\end_layout
\begin_layout Standard
The
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt playerCommand()}
\end_layout
\end_inset
\emph default
function is responsible for calling the helper functions responsible for
carrying out the actions of each message received.
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt changeNick()}
\end_layout
\end_inset
\emph default
is a function which is called when the
\noun on
nick
\noun default
message is received.
The
\emph on
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt changeNick()}
\end_layout
\end_inset
\emph default
function uses a feature of the GGS called
\noun on
localStorage
\noun default
(see section
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Communication-with-the-GDL-VM"
\end_inset
), which is an interface to the database backend contained in the database
module (see
\begin_inset CommandInset ref
LatexCommand ref
reference "sub:The-database-module"
\end_inset
).
The database can be used as any key-value store, however the syntax for
insertions and fetch operations is tightly integrated with the GDL of the
GGS.
\end_layout
\begin_layout Standard
Access to the
\noun on
localStorage
\noun default
is provided through the
\emph on
\noun on
GGS
\noun default
\emph default
object, which also can be used to communicate with the rest of the system
from the GDL.
Implementation specifics of the GGS object are provided in
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Communication-with-the-GDL-VM"
\end_inset
.
\end_layout
\begin_layout Standard
\begin_inset Float algorithm
wide false
sideways false
status open
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
lstset{
\end_layout
\begin_layout Plain Layout
language=JavaScript,
\end_layout
\begin_layout Plain Layout
backgroundcolor=
\backslash
color{white},
\end_layout
\begin_layout Plain Layout
extendedchars=true,
\end_layout
\begin_layout Plain Layout
basicstyle=
\backslash
footnotesize
\backslash
ttfamily,
\end_layout
\begin_layout Plain Layout
showstringspaces=false,
\end_layout
\begin_layout Plain Layout
showspaces=false,
\end_layout
\begin_layout Plain Layout
numbers=left,
\end_layout
\begin_layout Plain Layout
numberstyle=
\backslash
footnotesize,
\end_layout
\begin_layout Plain Layout
numbersep=9pt,
\end_layout
\begin_layout Plain Layout
tabsize=2,
\end_layout
\begin_layout Plain Layout
breaklines=true,
\end_layout
\begin_layout Plain Layout
showtabs=false,
\end_layout
\begin_layout Plain Layout
captionpos=b
\end_layout
\begin_layout Plain Layout
}
\end_layout
\begin_layout Plain Layout
\backslash
begin{lstlisting}[language=JavaScript]
\end_layout
\begin_layout Plain Layout
function playerCommand(player_id, command, args) {
\end_layout
\begin_layout Plain Layout
if(command == "nick") {
\end_layout
\begin_layout Plain Layout
changeNick(player_id, args);
\end_layout
\begin_layout Plain Layout
} else if(command == "message") {
\end_layout
\begin_layout Plain Layout
message(player_id, args);
\end_layout
\begin_layout Plain Layout
}
\end_layout
\begin_layout Plain Layout
}
\end_layout
\begin_layout Plain Layout
function changeNick(player_id, nick) {
\end_layout
\begin_layout Plain Layout
var old_nick = GGS.localStorage.getItem("nick_" + player_id);
\end_layout
\begin_layout Plain Layout
GGS.localStorage.setItem("nick_" + player_id, nick);
\end_layout
\begin_layout Plain Layout
if (!old_nick) {
\end_layout
\begin_layout Plain Layout
GGS.sendCommandToAll("notice", nick + " joined");
\end_layout
\begin_layout Plain Layout
} else {
\end_layout
\begin_layout Plain Layout
GGS.sendCommandToAll("notice", old_nick + " is now called " + nick);
\end_layout
\begin_layout Plain Layout
}
\end_layout
\begin_layout Plain Layout
}
\end_layout
\begin_layout Plain Layout
function message(player_id, message) {
\end_layout
\begin_layout Plain Layout
var nick = GGS.localStorage.getItem("nick_" + player_id);
\end_layout
\begin_layout Plain Layout
GGS.sendCommandToAll("message", nick + "> " + message);
\end_layout
\begin_layout Plain Layout
}
\end_layout
\begin_layout Plain Layout
\backslash
end{lstlisting}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption
\begin_layout Plain Layout
\begin_inset CommandInset label
LatexCommand label
name "alg:A-concrete-example"
\end_inset
A concrete example of a simple chat server written in JavaScript, running
on the GGS.
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Chapter
Problems of the implementation
\begin_inset CommandInset label
LatexCommand label
name "cha:Problems-of-implementation"
\end_inset
\end_layout
\begin_layout Standard
This chapter contains descriptions of specific problems encountered when
implementing the GGS prototype.
Some of the problems described have solutions attached, however some problems
were not solved, therefore only ideas for solutions have been included.
\end_layout
\begin_layout Standard
The integration of JavaScript as a GDL in the GGS prototype was particularly
difficult, and is handled in this section, so is the protocol design and
limitation in the operating systems which have been used during development
and testing.
\end_layout
\begin_layout Section
JavaScript engine
\end_layout
\begin_layout Standard
The GGS prototype uses a virtual machine to sandbox each game.
JavaScript was chosen for the prototype due to its wide-spread use in web
applications and the flexibility of the language.
Any language with the proper bindings to Erlang could have been used in
theory.
\end_layout
\begin_layout Standard
There are two JavaScript virtual machines, or
\emph on
engines,
\emph default
with suitable bindings to Erlang available at the time of the writing of
this thesis.
There is a group of machines developed by Mozilla called
\emph on
TraceMonkey, JaegerMonkey, SpiderMonkey
\emph default
and
\emph on
IonMonkey
\emph default
, and also there is Google's
\emph on
V8
\emph default
.
The members in the group of Mozilla machines are largely the same, and
are referred to as the same machine for simplicity.
\end_layout
\begin_layout Standard
For the Mozilla machines, there exists an Erlang binding called erlang_js,
and for the V8 machine a binding called erlv8 exists.
Below follows a discussion about the different bindings and machines, and
a motivation as to why erlv8 was preferred over erlang_js.
\end_layout
\begin_layout Subsection
erlang_js
\end_layout
\begin_layout Standard
erlang_js provides direct communication with the JavaScript VM, which is
exactly what is desired.
However also required is the possibility to communicate from JavaScript
to Erlang.
The ability to communicate from JavaScript to Erlang is not yet implemented
in erlang_js, due to lack of time of the erlang_js developers.
\end_layout
\begin_layout Standard
There were two possible solutions to the problem, either one would implement
the missing functionality, or a switch from erlang_js to some other JavaScript
engine with better bindings could be made.
\end_layout
\begin_layout Standard
Attempts at implementing the missing functionality were initially made but
never became stable enough for usage in the GGS and the erlang_js software
was abandoned.
\end_layout
\begin_layout Subsection
erlv8
\end_layout
\begin_layout Standard
erlv8 is powered by the V8 engine developed by Google.
The ability to communicate from JavaScript to Erlang using NIF callbacks
is present in the erlv8 bindings and can be used within the GGS.
\end_layout
\begin_layout Standard
Initial releases of the erlv8 bindings had stability issues, these however
were resolved by the erlv8 developers during the development of the GGS.
While still described to be in 'alpha' stage, the erlv8 bindings have proved
to be stable enough and at this point erlv8 is the JavaScript engine powering
JavaScript as a GDL in the GGS.
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{V8}}{JavaScript engine developed by Google.}
\end_layout
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{SpiderMonkey}}{JavaScript engine developed by Mozilla.}
\end_layout
\end_inset
\end_layout
\begin_layout Section
Protocol design
\end_layout
\begin_layout Standard
Initially the GGS protocol was planned to use the UDP protocol as a transport
layer.
Due to the lack of error checking in the UDP protocol, the UDP protocol
is faster than the TCP protocol, this was a main reason in the desire to
use UDP.
The GGS does however need error checking for some of it parts to be as
reliable as possible.
Therefore an error checking layer would have to be placed on top of UDP.
\end_layout
\begin_layout Standard
The development of an error checking layer was weighed against the implementatio
n based on TCP instead of UDP, thus losing some speed.
Even though speed was lost, TCP was chosen due to the relative ease of
implementation compared to UDP.
Due to the modularity of the GGS, a UDP extension is easily possible by
replacing the network parts of the GGS.
\end_layout
\begin_layout Standard
The Apache Thrift
\begin_inset CommandInset citation
LatexCommand citep
key "Slee2007"
\end_inset
was also an alternative.
Using Thrift would mean the GGS would feature a standard protocol for network
communication.
Before finding out about Thrift during a lecture by Joe Armstrong (one
of the inventors of Erlang), the GGS protocol had already been implemented,
moving to Thrift would have meant too much effort for a prototype during
the short amount of time.
\end_layout
\begin_layout Standard
The use of Google protocol buffers - which is a different approach to a
standard protocol framework, implemented by Google - or other protocols
can be supported quite easily by developing protocol modules for each of
the protocols.
No protocol modules for these protocols have however been developed during
the writing of this thesis.
\end_layout
\begin_layout Section
Operating system limitations
\begin_inset CommandInset label
LatexCommand label
name "sec:Operating-system-limitations"
\end_inset
\end_layout
\begin_layout Standard
The operating systems on the computers which have been used to run the bots
while testing the GGS prototype had some limitations.
The operating systems used were Linux and Mac OS X, since these systems
are quite similar on a lower level they exhibited the same limitations..
\end_layout
\begin_layout Standard
The most notable limitation was a limit set on the number of simultaneously
open files.
Due to the implementation of sockets in UNIX-like systems such as Mac OS
X and Linux, a limit on the number of open files is a limit on the number
of open sockets.
In order to simulate many connections to the GGS, many sockets needed to
be opened.
Each socket had a bot connected on one end and the GGS on the other end.
On each test machine several thousand sockets needed to be open while testing
the GGS, therefore the limit on open files had to be removed.
\end_layout
\begin_layout Standard
On the Linux machines the limit of open files is configured in
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt /etc/security/security.conf}
\end_layout
\end_inset
.
\end_layout
\begin_layout Standard
On the Mac OS X machine the limit of open files is configured in
\begin_inset ERT
status open
\begin_layout Plain Layout
{
\backslash
tt /etc/launchd.conf }
\end_layout
\end_inset
.
\end_layout
\begin_layout Chapter
Results and discussion
\begin_inset CommandInset label
LatexCommand label
name "chap:Results-and-discussion"
\end_inset
\end_layout
\begin_layout Standard
In this chapter the results of tests done on the GGS prototype are presented
and discussed.
The test results are presented with both graphical and textual content.
Finally thoughts about how future improvements to the prototype could look
like are given.
\end_layout
\begin_layout Section
Statistics
\begin_inset CommandInset label
LatexCommand label
name "sec:Statistics"
\end_inset
\end_layout
\begin_layout Standard
Testing of the GGS took place in two separate sessions.
The first session simulated a highly demanding application, the second
session simulated a less demanding application.
The highly demanding application is a real-time game which does several
asynchronous database writes each second.
The less demanding application does not perform any database reads or writes.
\end_layout
\begin_layout Standard
Each of the two simulations uses JavaScript as the GDL.
The JavaScript is run through Google V8.
The database module uses Mnesia.
\end_layout
\begin_layout Standard
During the sessions two measurements were recorded.
\end_layout
\begin_layout Itemize
\series bold
Messages per second
\series default
is used to see how many incoming and outgoing messages the server can process
each second.
The results of the messages per second testing are shown for a high demanding
application in figure
\begin_inset CommandInset ref
LatexCommand ref
reference "fig:msg-per-sec-MNESIA"
\end_inset
, and for a low demanding application in
\begin_inset CommandInset ref
LatexCommand ref
reference "fig:msg-per-sec-NOMNESIA"
\end_inset
.
\end_layout
\begin_layout Itemize
\series bold
Latency between server and client
\series default
is used to measure the round-trip time for a message sent between the client
and server.
This measurement is used to determine how many players the server can handle
while still providing a playable gaming experience.
The results of the latency test can be seen in figure
\begin_inset CommandInset ref
LatexCommand ref
reference "fig:latency-graph"
\end_inset
.
\end_layout
\begin_layout Standard
The hardware that the GGS was running on was a Thinkpad T410, with an Intel
i5 processor and 4GB RAM.
\end_layout
\begin_layout Standard
In the first test, in which Mnesia has been heavily used, the server had
a peak value of nearly 6,000 messages per second.
When this number was reached Mnesia warned that it was overloaded and shortly
after that Mnesia failed to serve requests.
This result was not unexpected as this test put the database under heavy
load.
In the next testing session, the test has been conducted with another game
that did not use Mnesia.
Without Mnesia the server peaked at 60,000 messages per second, however
this was only for a very short time.
The average throughput was around 25,000 messages per second, five times
more than what the server was able to process with Mnesia in place.
\end_layout
\begin_layout Standard
In the second testing session the delay between the server and the clients
has also been measured.
A connection can be seen between those values; as long as the server is
under moderate load the delay is low and stable.
When the load on the server increases heavily the delay does too, this
is because the server cannot process all incoming messages and therefore
messages are put in a queue within the system.
\end_layout
\begin_layout Standard
There was also a testing session where the number of clients were measured,
however this was not a good measurement of performance and therefore these
numbers will not be included in the report.
\end_layout
\begin_layout Standard
It should be noted that with distribution in place, having the GGS deployed
on several machines, test results could reveal much higher numbers.
\end_layout
\begin_layout Standard
\begin_inset Note Note
status collapsed
\begin_layout Plain Layout
Important things to note are that the number of clients is not a good way
of measuring the performance of the server because the server is possible
to have a large number of clients on the server but it cannot handle all
the information.
Instead the performance of the server should be measured in the number
of messages it can handle per second.
\end_layout
\begin_layout Plain Layout
We were able to reach 6000 messages per second on the server, which corresponds
to around 350 clients.
However soon after this mnesia printed some warnings and the clients started
to lag.
With this in mind one thing to investigate is if mnesia is the bottleneck
in the system.
Current game servers do not use databases to save their state and maybe
we can see the reason here.
Other possible bottlenecks may be the protocol, but this seems less likely
than mnesia.
\end_layout
\end_inset
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
begin{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Graphics
filename graphics/msg_per_sec.eps
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
end{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption
\begin_layout Plain Layout
\begin_inset CommandInset label
LatexCommand label
name "fig:msg-per-sec-MNESIA"
\end_inset
The graph shows messages per second for intervals of clients connected.
Each client performs at least 3 asynchronous writes to the Mnesia database
each second.
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
begin{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Graphics
filename graphics/ping.eps
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
end{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption
\begin_layout Plain Layout
\begin_inset CommandInset label
LatexCommand label
name "fig:latency-graph"
\end_inset
This graph shows the latency in a low-demand application.
The ping is measured in milliseconds for a message to make a round-trip
between client and server.
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
begin{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Graphics
filename graphics/msg_per_secoutput.eps
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
end{centering}
\end_layout
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption
\begin_layout Plain Layout
\begin_inset CommandInset label
LatexCommand label
name "fig:msg-per-sec-NOMNESIA"
\end_inset
The graph shows messages per second for intervals of clients connected.
No database is used.
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Section
Future improvements
\end_layout
\begin_layout Standard
There are several things in the GGS prototype that can be improved.
In this section the most important improvements to the GGS are described,
along with a motivation as to why these additions are not found in the
GGS prototype.
\end_layout
\begin_layout Subsection
Distribution
\end_layout
\begin_layout Standard
The GGS was originally intended to be a distributed application, running
on several machines at once.
The design of the GGS should support this, it has however not been tested.
The technologies, such as supervisor trees and the servers supplied by
the OTP which are used in the GGS all support the development of distributed
applications.
\end_layout
\begin_layout Standard
Distribution was however not implemented in the GGS.
Other parts of the GGS were prioritized.
A future improvement is therefore to implement distribution in the GGS.
A simple way to achieve this is to keep one GGS instance as a coordinating
instance, and to keep clients on other instances of the GGS, which can
be dynamically added as new clients connect.
\end_layout
\begin_layout Subsection
Performance
\end_layout
\begin_layout Standard
The GGS prototype was not developed for maximum performance.
Performance optimizations were considered, many were however not implemented
in the prototype.
There are several performance optimizations which can be included in future
versions of the GGS, below are some of the most important performance optimizat
ions identified.
\end_layout
\begin_layout Subsubsection
Protocols
\begin_inset Note Note
status open
\begin_layout Plain Layout
Need references for assertions about UDP being nicer on the CPU.
Motivate why UDP is not implemented.
\end_layout
\end_inset
\end_layout
\begin_layout Standard
Because of TCP being a connection oriented protocol, it is not suited for
all types of game data transfers.
Each transmission will consume more network bandwidth than connectionless
protocols like UDP and cause unnecessary load on the processor while performing
, in some cases unnecessary, tests to assure the correctness of the data.
Therefore support for UDP would mean that more games could be run simultaneousl
y on the GGS.
Another advantage of UDP is that latency is being reduced.
Without having to set up a connection for each group of packets of data
being sent, they will be sent instantly and therefore arrive earlier.
Latency is of highest importance in real-time games as it improves realism
and fairness in gameplay and many game developers require the freedom to
take care of safety issues as packet losses themselves.
This concludes that UDP would be a benefit for the GGS, game developers
and players alike.
\end_layout
\begin_layout Subsubsection
Database
\end_layout
\begin_layout Standard
Currently Mnesia is used for game data storage.
During stress tests, Mnesia has turned out to be the bottleneck due to
data losses when too many games are played on the GGS simultaneously.
\end_layout
\begin_layout Standard
The usage of Mnesia in the GGS is not the usage originally intended.
Originally a cache was to be placed before Mnesia.
The cache could be either Erlang Term Storage (ETS) or a Erlang process
which keeps track of all database actions.
The cache periodically flushes its contents to Mnesia, thereby reducing
the Mnesia transactions overall.
\end_layout
\begin_layout Standard
The cache was never implemented in the prototype due to other parts of the
GGS being prioritized.
The current implementation of the database backend is not optimal, however
it functions reliably, therefore it was deemed sufficient for the prototype.
\end_layout
\begin_layout Standard
A possible future addition to the GGS could be to add this cache in the
database module.
The API would not need any changes, as this could be implemented internally
in the database module.
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
nomenclature{
\backslash
textbf{ETS}}{Erlang Term Storage.}
\end_layout
\end_inset
\end_layout
\begin_layout Subsubsection
Integration with existing games
\end_layout
\begin_layout Standard
It should be possible to integrate the GGS with existing network games.
In order to integrate the GGS with an existing game it is neccessary to
1) rewrite the entire server logic in a GDL and deploy this implementation
on the GGS, and 2) write a protocol parser for the protocol of the game
at hand.
\end_layout
\begin_layout Standard
No implementation of a game server for an existing game has been done, however
preliminary investigations on running an early version of Quake on he GGS
have been made.
An interesting future improvement of the GGS would be to develop an implementat
ion of a game server for an existing game for the GGS.
\end_layout
\begin_layout Chapter
Conclusion
\end_layout
\begin_layout Standard
This thesis describes a method to create a reliable and generic game server
with help of the techniques used in the telecom industry.
\end_layout
\begin_layout Standard
To make the GGS as generic as possible separation of game and server logic
is necessary.
Designing a good API is vital in order to allow game developers to interact
with the server in a simple manner and with minimal overhead.
Furthermore every game should be isolated so that games cannot interfere
with each other.
Isolation can be achieved by introducing a context for each game which
leads to the fact that each game runs in its own sandbox.
To be able to use different game development languages virtual machines
should be used.
Each virtual machine instance evaluates game source code safely.
\end_layout
\begin_layout Standard
In the current state, the GGS prototype is not scalable.
The GGS is however prepared for scaling due to its overall structure.
The implementation of scalability could be performed in two different ways,
either to scale one instance of the GGS or to scale by creating new instances
and support communication among them.
\end_layout
\begin_layout Standard
This thesis concludes that it is reasonable to use the same tools as those
used by the telecom industry for creating reliable systems when developing
games for computers.
A typical game can be split up in to several parts, and using the GGS,
the parts not directly related to the actual gameplay can be implemented
in Erlang, while keeping the actual game software in a virtual machine.
It has been demonstrated in this thesis that games can be developed for
the GGS in JavaScript, while still benefiting from the features offered
by Erlang and the OTP.
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
addcontentsline{toc}{section}{Glossary}
\end_layout
\begin_layout Plain Layout
\backslash
printnomenclature
\end_layout
\end_inset
\end_layout
\begin_layout Standard
\begin_inset CommandInset bibtex
LatexCommand bibtex
bibfiles "bibliography"
options "plainnat"
\end_inset
\end_layout
\end_body
\end_document