1788 lines
41 KiB
Text
1788 lines
41 KiB
Text
#LyX 1.6.7 created this file. For more info see http://www.lyx.org/
|
||
\lyxformat 345
|
||
\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}
|
||
\end_preamble
|
||
\use_default_options true
|
||
\language english
|
||
\inputencoding auto
|
||
\font_roman lmodern
|
||
\font_sans default
|
||
\font_typewriter default
|
||
\font_default_family rmdefault
|
||
\font_sc false
|
||
\font_osf false
|
||
\font_sf_scale 100
|
||
\font_tt_scale 100
|
||
|
||
\graphics default
|
||
\paperfontsize default
|
||
\spacing onehalf
|
||
\use_hyperref false
|
||
\papersize a4paper
|
||
\use_geometry false
|
||
\use_amsmath 1
|
||
\use_esint 1
|
||
\cite_engine natbib_authoryear
|
||
\use_bibtopic false
|
||
\paperorientation portrait
|
||
\paperwidth 11in
|
||
\paperheight 8.5in
|
||
\leftmargin 1.25in
|
||
\topmargin 0in
|
||
\rightmargin 1in
|
||
\bottommargin 1.7in
|
||
\secnumdepth 2
|
||
\tocdepth 2
|
||
\paragraph_separation indent
|
||
\defskip medskip
|
||
\quotes_language english
|
||
\papercolumns 1
|
||
\papersides 1
|
||
\paperpagestyle empty
|
||
\tracking_changes false
|
||
\output_changes false
|
||
\author ""
|
||
\author ""
|
||
\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/2]{graphics/logo}
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
end{center}
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
end{textblock*}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Title
|
||
Generic Game Server
|
||
\end_layout
|
||
|
||
\begin_layout Author
|
||
Niklas Landin
|
||
\begin_inset Newline newline
|
||
\end_inset
|
||
|
||
Richard Pannek
|
||
\begin_inset Newline newline
|
||
\end_inset
|
||
|
||
Matias Petterson
|
||
\begin_inset Newline newline
|
||
\end_inset
|
||
|
||
Jonatan Pålsson
|
||
\end_layout
|
||
|
||
\begin_layout Abstract
|
||
This is the abstract!
|
||
\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
|
||
The introduction aims to give the reader a good base to stand on when taking
|
||
on the rest of this thesis.
|
||
A background and motivation of why this topic is interesting is given,
|
||
and some basic terminoligy is defined and explained.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
We draw some parallels to existing solutions which solve similar problems
|
||
in different sectors.
|
||
The main challenges of the project are outlined, with the solutions thereof
|
||
following later on in the paper.
|
||
Some boundaries are placed on the project, since it is not possible to
|
||
cover everything at once.
|
||
By placing these boundaries, the purpose of the GGS is further refined.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
\begin_inset Note Note
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
Also cover the final topics; method (development process, etc).
|
||
As of this eriting, the contents of method are unknown.
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Background
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The game industry is a quickly growing industry where the need for new technique
|
||
s is large.
|
||
One specific section where the development has stalled is the game server
|
||
section.
|
||
The existing game servers are functional but they lack good fault tolerance
|
||
and the ability to scale well.
|
||
Users will notice this in low uptime and many crashes.
|
||
This is a problem that has existed and been resolved in other industries.
|
||
One good example is the telecom industry which have managed to develop
|
||
a solution to similar problems.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The main reason to develop reliable servers are monetary, it is important
|
||
for game companies to expand its customer base.
|
||
Reliable game servers are one improvement that will create a good image
|
||
of a company.
|
||
In general the downtime of game servers are much higher than the downtime
|
||
of telecom system.
|
||
The structure of the system is similar and it should be possible to reuse
|
||
solutions from the telecom system to improve game servers.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
In the current state game servers is coded for each game that needs it,
|
||
in many cases this seems like a bad solution.
|
||
Developers that want to make a network game need to understand network
|
||
programming.
|
||
A way to change this is a generic game server which give the game developers
|
||
a server which they implement their game towards.
|
||
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 Section
|
||
Purpose
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The purpose of the GGS project is to create a
|
||
\emph on
|
||
scalable
|
||
\emph default
|
||
and
|
||
\emph on
|
||
fault tolerant
|
||
\emph default
|
||
server, while still allowing the server to be as
|
||
\emph on
|
||
generic
|
||
\emph default
|
||
as possible.
|
||
These three italicised terms need some explanation.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Scalability 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 citet
|
||
key "Bondi:2000:CSI:350391.350432"
|
||
|
||
\end_inset
|
||
|
||
.
|
||
These two issues are addressed in this thesis.
|
||
Structural scalability means expanding an 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 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 defined as the statistical probability of the system functioni
|
||
ng as intended at a given point in time.
|
||
Fault tolerance is defined as the property of a system to always follow
|
||
a specification, even in the presence of errors.
|
||
The specification could take the form of 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 a given point in time, and is exactly what
|
||
is desired.
|
||
|
||
\begin_inset CommandInset citation
|
||
LatexCommand citet
|
||
key "Gartner:1999:FFD:311531.311532"
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
A generic 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 type.
|
||
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.
|
||
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.
|
||
\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 some language which
|
||
runs in the
|
||
\emph on
|
||
Java Virtual Machine
|
||
\emph default
|
||
.
|
||
An example of an application server not powering web applications, but
|
||
instead regular business logic, is Oracle’s
|
||
\emph on
|
||
TUXEDO
|
||
\emph default
|
||
application server, which can be used to run applications written in COBOL,
|
||
C++ and others.
|
||
\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
|
||
One of the purposes of this thesis is to investigate how we can make a game
|
||
server as generic as possible.
|
||
Some important helpers are discussed, such as abstraction of the network
|
||
layer, data store and game specific features.
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Challenges
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The word
|
||
\emph on
|
||
generic
|
||
\emph default
|
||
in GGS implies that the system is able to run a very broad range of different
|
||
code, for instance code written in different programming languages, in
|
||
addition to a broad range of different game types.
|
||
In order to support this, a virtual machine (VM) for each
|
||
\emph on
|
||
game development language
|
||
\emph default
|
||
(hereafter GDL for brevity) is used.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
No hard limit has been set on which languages can be used for game development
|
||
on GGS, but there are several factors which decide the feasibility of a
|
||
language;
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
How well it integrates with Erlang, which is used in the core GGS system
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
How easy it is to send messages to the virtual machine of the GDL from GGS
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
How easy it is to send messages from the GDL VM to GGS
|
||
\begin_inset Note Note
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
Add more like threads, events, etc.
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Internally, the GDL VM needs to interface with GGS to make use of the helpers
|
||
and tools that GGS provides.
|
||
Thus an internal API has to be designed for use in interacting with GGS.
|
||
This API is ideally completely independent of the GDL, and reusable for
|
||
any GDL.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The communication with gaming clients has to take place over 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 large 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 existing
|
||
developers.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
A great deal of work is devoted to make 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, we need a storage platform which is
|
||
accessible and consistent among all of GGS, this is also investigated.
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Delimitations
|
||
\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 games
|
||
that can be played on the prototype.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The UDP protocol will not be implemented, only TCP, the main reason behind
|
||
this is a strict timetable.
|
||
This decision means that games that requires a high speed protocol will
|
||
not be supported by the GGS prototype.
|
||
Another limitation necessary to set on the system is the possibility to
|
||
have huge game worlds.
|
||
|
||
\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 50 to 150 ms and everything above 200 ms is reported
|
||
to be intolerable
|
||
\begin_inset CommandInset citation
|
||
LatexCommand citet
|
||
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 (MMORPG:s), for example
|
||
|
||
\emph on
|
||
World of Warcraft
|
||
\emph default
|
||
.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
In turn based games each player has to wait for her turn.
|
||
Latency is not a problem since the gameplay does not require fast interactions
|
||
between 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, a Generic Game Server should address all of them and help the developer
|
||
to accomplish his goal.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Due to the limited capability of threading in many GDL VM:s, the GGS prototype
|
||
will not support MMORPG:s as it is not possible to implement and test something
|
||
that complex within the projects timetable.
|
||
\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
|
||
are no need to implement more advanced features in the system.
|
||
It is important to note that these limitations only apply for the prototype
|
||
of the project, and that further developments to GGS could be to implement
|
||
these features.
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Method
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
Development process
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
May be Extreme Programming(XP), need to check this out further.
|
||
Maybe adapt so we can say that we use a standardized software development
|
||
method.
|
||
\end_layout
|
||
|
||
\begin_layout Subsubsection
|
||
Demand specification
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
Design
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
Testing and evaluation
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Can we use quickcheck?
|
||
\end_layout
|
||
|
||
\begin_layout Chapter
|
||
Theory
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Performance
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
How many players can we have on a server? Performance differences between
|
||
games? e.g can one game have thousands players on a server and another only
|
||
have hundreds? Questions to be discussed here.
|
||
|
||
\begin_inset Note Note
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
Create a game with several thousand players, see how our server scales,
|
||
how can we improve the performance? Sharding isn’t very nice..
|
||
alternatives? Improve the speed of sharding?
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Choice of network protocol
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
There are three main ways in which computer communication over the Internet
|
||
usually takes place; TCP, UDP and HTTP.
|
||
The first two are transport layer protocols, which are commonly used to
|
||
transport application layer protocols, such as HTTP.
|
||
TCP and UDP can not be used on their own, without an application layer
|
||
protocol on top.
|
||
Application layer protocols such as HTTP on the other hand needs a transport
|
||
layer protocol in order to work.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
HTTP
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Since HTTP is so widely used on the Internet today in web servers, it is
|
||
available on most Internet connected devices.
|
||
This means that if HTTP is used in GGS, firewalls will not pose problems,
|
||
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 makes HTTP unsuitable for our purposes, since 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,
|
||
and what is said about TCP also applies to HTTP.
|
||
|
||
\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 the data transferred 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.
|
||
In GGS reliability of transfer was chosen before the speed of the transfer,
|
||
ruling out UDP as the transport later protocol.
|
||
|
||
\begin_inset Note Note
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
Perhaps we should only say that we chose TCP just for our GGS prototype
|
||
and why.
|
||
If we leave it like that it seems that we think it is not suitable.
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\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.
|
||
In GGS, data consistency is more important than transfer speeds, and thus
|
||
TCP is a better alternative than UDP.
|
||
|
||
\begin_inset Note Note
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
Same here it is simply not true for a generic server to chose one or the
|
||
other.
|
||
We should rephrase it so it is clear that we only state it about the GGS
|
||
prototype.
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Fault Tolerant
|
||
\end_layout
|
||
|
||
\begin_layout Subsubsection
|
||
Performance penalties
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Availability
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
One important factor of any server is the availability.
|
||
A server to which you are unable to connect to is a useless server.
|
||
Other then within telecomunication, their uptime is of about 99,99%, the
|
||
game developer community hasn't approched this problem very genuinely yet
|
||
so there is much room for improvement.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
There are several good papers on how to migrate whole virtual machines between
|
||
nodes to replicate them but for the GGS a different approche has been chosen.
|
||
Instead of just duplicating a virtual machine, the programming language
|
||
Erlang has been used which offers several features to increase the availability.
|
||
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, 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.
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Scalability
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Each instance of GGS contains several tables.
|
||
Each table is an isolated instance of a game, for example a chess game
|
||
or a poker game.
|
||
The way that GGS scales is to distribute these tables on 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.
|
||
With this in mind, the main focus of GGS is not to move players between
|
||
tables, but to keep a player in a table, and to start new tables instead.
|
||
When a server has reached a certain amount of players the performance will
|
||
start to decrease.
|
||
To avoid this GGS will start new tables on another server, using this technique
|
||
the players will be close to evenly distributed between the servers.
|
||
It is important to investigate and find out how many players that are optimal
|
||
for each server.
|
||
This approach makes it possible to utilize all resources with moderate
|
||
load, instead of having some resources with heavy load and some with almost
|
||
no load.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
As mentioned in the purpose section there are two different types of scalability
|
||
, structural scalability and load scalability.
|
||
To make GGS scalable both types of scalability are needed.
|
||
Structural scalability means in our case that it should be possible to
|
||
add more servers to an existing cluster of servers.
|
||
By adding more servers the limits of how many users a system can have is
|
||
increased.
|
||
Load scalability in contrast to structural scalability is not about how
|
||
to increase the actual limits of the system.
|
||
Instead it means how good the system handles increased load.
|
||
GGS should be able to scale well in both categories.
|
||
\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
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
\begin_inset Float algorithm
|
||
wide false
|
||
sideways false
|
||
status collapsed
|
||
|
||
\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
|
||
Inside the GGS, everything has a unique identifier.
|
||
There are identifiers for players, tables and other resources.
|
||
When players communicate amongst each other, or communicate with tables,
|
||
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 ID increments the previous identifier and returns the new identifier
|
||
based off 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 exclution.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The obvious solution to this problem is to ensure mutual exclusion by using
|
||
some sort of lock, which may work well in many concurrent systems.
|
||
In a distributed system, this lock, along with the state, would have to
|
||
be distributed.
|
||
If the lock is not distributed, no guarantee can be made that two nodes
|
||
in the distributed system do not generate the same number.
|
||
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.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
According to
|
||
\begin_inset CommandInset citation
|
||
LatexCommand citet
|
||
key "Leach98uuidsand"
|
||
|
||
\end_inset
|
||
|
||
,
|
||
\begin_inset Quotes eld
|
||
\end_inset
|
||
|
||
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
|
||
\begin_inset Quotes erd
|
||
\end_inset
|
||
|
||
.
|
||
This 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
|
||
ID:s.
|
||
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, such as the ones generated by
|
||
algorithm
|
||
\begin_inset CommandInset ref
|
||
LatexCommand ref
|
||
reference "alg:A-simple-generator"
|
||
|
||
\end_inset
|
||
|
||
with mutual exclusion, it is not possible 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
|
||
\emph on
|
||
Site A
|
||
\emph default
|
||
is separated from
|
||
\emph on
|
||
Site B
|
||
\emph default
|
||
by a faulty network (illustrated by the cloud and lightening bolt).
|
||
When
|
||
\emph on
|
||
Site A
|
||
\emph default
|
||
and
|
||
\emph on
|
||
Site B
|
||
\emph default
|
||
later re-establish communications, they may have generated the same ID:s
|
||
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 UUID:s solve.
|
||
\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/NetworkSPlit.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
|
||
We only support 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 can not 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 we provide.
|
||
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
|
||
of this not modify the persistent data of other games.
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
Encryption
|
||
\end_layout
|
||
|
||
\begin_layout Chapter
|
||
Practice
|
||
\begin_inset Note Note
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
Perhaps call this
|
||
\begin_inset Quotes eld
|
||
\end_inset
|
||
|
||
realization
|
||
\begin_inset Quotes erd
|
||
\end_inset
|
||
|
||
or
|
||
\begin_inset Quotes eld
|
||
\end_inset
|
||
|
||
implementation
|
||
\begin_inset Quotes erd
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Techniques for ensuring reliability
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
One of the main goals of the project is to achieve high reliability.
|
||
A highly reliable application is one crashes very, very rarely
|
||
\begin_inset Note Note
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
CITATION NEEDED
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
.
|
||
There are some tools for creating reliable applications built in to Erlang.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
Links between processes.
|
||
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
|
||
Transparent distribution over a network of processors.
|
||
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
|
||
Hot code replacements.
|
||
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 reliability systems in Erlang.
|
||
Many times it is not necessary to use these features directly, but rather
|
||
through the design patterns described below.
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
Supervisor structure
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
By linking processes together and notifying parents when children exit,
|
||
we can create supervisors.
|
||
A supervisor is a common approach in ensuring that an application functions
|
||
in the way it was intended.
|
||
When a process misbehaves, the supervisor takes some action to restore
|
||
the process to a functional state.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
There are several approaches to supervisor design in general (when not just
|
||
considering how they work in Erlang).
|
||
One common approach is to have the supervisor look in to the state of the
|
||
process(es) it supervises, and let the supervisor make decisions based
|
||
on this state.
|
||
The supervisor has a specification of how the process it supervises should
|
||
function, and this is how it makes decisions.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
In Erlang, we have a simple version of supervisors.
|
||
We do not inspect the state of the processes being supervised.
|
||
We do have 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 time
|
||
interval a child process may crash, which processes need restarting when
|
||
crashes occur, and so forth.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
When the linking of processes in order to monitor exit behaviour is coupled
|
||
with the transparent distribution of Erlang, a very powerful supervision
|
||
system is created.
|
||
For instance, we can restart a failing process on a different, new node,
|
||
with minimal impact on the system as a whole.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
In GGS, we have separated the system in to two large supervised parts.
|
||
We try to restart a crashing child separately, if this fails too many
|
||
\begin_inset Foot
|
||
status open
|
||
|
||
\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, we restart the nearest supervisor of this child.
|
||
This ensures separation of the subsystems so that a crash is as isolated
|
||
as possible.
|
||
\begin_inset Float figure
|
||
wide false
|
||
sideways false
|
||
status collapsed
|
||
|
||
\begin_layout Plain Layout
|
||
\begin_inset Note Note
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
We should really do this graphic in EPS instead of PNG
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\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
|
||
The supervisor structure of GGS
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The graphic above shows our 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 upon a crash.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
We have chosen 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 and fix this faulty
|
||
data, or to foresee the unexpected events.
|
||
We chose not to do this because it is so simple to monitor and restart
|
||
processes, and so difficult to try and mend broken states.
|
||
This approach is something widely deployed in the Erlang world, and developers
|
||
are often encouraged to “Let it crash”.
|
||
\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, it asks the backup process for any previous
|
||
state, if there is any that state is loaded in to 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
|
||
Distribution
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
Hot code replacement
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Implementation
|
||
\end_layout
|
||
|
||
\begin_layout Subsubsection
|
||
User interface
|
||
\end_layout
|
||
|
||
\begin_layout Chapter
|
||
Problems
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
erlang_js
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
To be able to run JavaScript on our server we needed to embed a JavaScript
|
||
engine within the server.
|
||
After a thorough investigation erlang_js became our choice.
|
||
erlang_js provides direct communication with a JavaScript VM (Virtual Machine).
|
||
This was exactly what we wanted, but we also needed the possibility to
|
||
communicate from erlang_js to Erlang.
|
||
This functionality was not yet implemented in erlang_js, due to lack of
|
||
time.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
There were two possible solutions to the problem.
|
||
We could rewrite some part of erlang_js, or we could switch erlang_js for
|
||
some other JavaScript engine.
|
||
Searching for other engines we found erlv8 and beam.js which provided the
|
||
functionality that we wanted.
|
||
As we tested beam.js it occurred random crashes of the whole Erlang environment.
|
||
These crashes were related to the use of erlv8 in beam.js and we decided
|
||
that the use of erlv8 was not an alternative due to the stability issues.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
To get the functionality needed we decided to implement this in erlang_js.
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
UUID
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Erlang identifies processes uniquely throughout the entire Erlang network
|
||
using process IDs (PID).
|
||
When we wish to refer to erlang processes from outside our erlang system,
|
||
for example in a virtual machine for a different language, possibly on
|
||
a different machine, these PID:s are no longer useful.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
This problem is not new, and a common solution is to use a Universally Unique
|
||
Identifier, a UUID.
|
||
These identifiers are generated both using randomization and using time.
|
||
A reasonably large number of UUID:s can be generated before a collision
|
||
should occur.
|
||
There are standard tools in many UNIX systems to generate UUID:s, we chose
|
||
to use the uuidgen command, which employs an equidistributed combined Tausworth
|
||
e generator.
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Design choices
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
When designing concurrent applications, it is useful to picture them as
|
||
real world scenarios, and to model each actor# as a real world process.
|
||
A real world process is a process which performs some action in the real
|
||
world, such as a mailbox receiving a letter, a door being opened, a person
|
||
translating a text, a soccer player kicking the ball, just to name a few
|
||
examples.
|
||
Since we focus on games in this project, it is suitable to model our system
|
||
as a place where games take place.
|
||
We imagined a chess club.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The clients pictured as green circles can be thought of as the physical
|
||
chess players.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
When a player wants to enter the our particular chess club, he must first
|
||
be let in by the doorman, called the Dispatcher in GGS.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
He then gets a name badge, and thus becomes a Player process in the system.
|
||
He is also guided in to the lobby by the Coordinator, which has the role
|
||
of the host of the chess club.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
When players wish to play against each other, they talk to the Coordinator
|
||
who pairs them up, and places them at a table.
|
||
Once they have sat down at the table, they no longer need the assistance
|
||
of the Coordinator, all further communication takes place via the table.
|
||
This can be thought of as the actual chess game commencing.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
All the moves made in the game are recorded by the table, such that the
|
||
table can restore the game in case something would happen, such as the
|
||
table tipping over, which would represent the table process crashing.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Once a player wishes to leave a game, or the entire facility, he should
|
||
contact the Coordinator, who revokes his name badge and the Dispatcher
|
||
will let the player out.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
With the information kept in the tables and the Coordinator combined, we
|
||
can rebuild the entire state of the server at a different location.
|
||
This can be thought of the chess club catching fire, and the Coordinator
|
||
rounding up all the tables, running to a new location and building the
|
||
club up in the exact state it was prior to the fire.
|
||
\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/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
|
||
The layout of GGS
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Understanding OTP
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Usability
|
||
\end_layout
|
||
|
||
\begin_layout Chapter
|
||
Results and discussion
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Software development methodology
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Statistics
|
||
\end_layout
|
||
|
||
\begin_layout Chapter
|
||
Conclusion
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
\begin_inset CommandInset bibtex
|
||
LatexCommand bibtex
|
||
bibfiles "bibliography"
|
||
options "plainnat"
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\end_body
|
||
\end_document
|