984 lines
23 KiB
Text
984 lines
23 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
|
||
\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 double
|
||
\use_hyperref false
|
||
\papersize default
|
||
\use_geometry true
|
||
\use_amsmath 1
|
||
\use_esint 1
|
||
\cite_engine natbib_authoryear
|
||
\use_bibtopic false
|
||
\paperorientation portrait
|
||
\paperwidth 11in
|
||
\paperheight 8.5in
|
||
\leftmargin 1.25in
|
||
\topmargin 1in
|
||
\rightmargin 1in
|
||
\bottommargin 1.7in
|
||
\secnumdepth 3
|
||
\tocdepth 3
|
||
\paragraph_separation indent
|
||
\defskip medskip
|
||
\quotes_language english
|
||
\papercolumns 1
|
||
\papersides 1
|
||
\paperpagestyle default
|
||
\tracking_changes false
|
||
\output_changes false
|
||
\author ""
|
||
\author ""
|
||
\end_header
|
||
|
||
\begin_body
|
||
|
||
\begin_layout Title
|
||
Generic Game Server
|
||
\end_layout
|
||
|
||
\begin_layout Author
|
||
Jonatan Pålsson
|
||
\begin_inset Newline newline
|
||
\end_inset
|
||
|
||
Niklas Landin
|
||
\begin_inset Newline newline
|
||
\end_inset
|
||
|
||
Richard Pannek
|
||
\begin_inset Newline newline
|
||
\end_inset
|
||
|
||
Matias Petterson
|
||
\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}{5}
|
||
\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
|
||
addcontentsline{toc}{chapter}{List of Tables}
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
renewcommand{
|
||
\backslash
|
||
cftlottitlefont}{
|
||
\backslash
|
||
hfill
|
||
\backslash
|
||
Large}
|
||
\backslash
|
||
renewcommand{
|
||
\backslash
|
||
cftafterlottitle}{
|
||
\backslash
|
||
hfill}
|
||
\backslash
|
||
renewcommand{
|
||
\backslash
|
||
cfttabpresnum}{Table~}
|
||
\backslash
|
||
setlength
|
||
\backslash
|
||
cfttabnumwidth{60pt}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
\begin_inset FloatList table
|
||
|
||
\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
|
||
addcontentsline{toc}{chapter}{List of Figures}
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
renewcommand{
|
||
\backslash
|
||
cftloftitlefont}{
|
||
\backslash
|
||
hfill
|
||
\backslash
|
||
Large}
|
||
\backslash
|
||
renewcommand{
|
||
\backslash
|
||
cftafterloftitle}{
|
||
\backslash
|
||
hfill}
|
||
\backslash
|
||
renewcommand{
|
||
\backslash
|
||
cftfigpresnum}{Figure~}
|
||
\backslash
|
||
setlength
|
||
\backslash
|
||
cftfignumwidth{60pt}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
\begin_inset FloatList figure
|
||
|
||
\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 Section
|
||
Background
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Purpose
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Challenges
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Challenges lies mainly in providing a reliable, high-performing server and
|
||
at the same time make it easy to use for game developers.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
Basis
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Delimitations
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
Types of games
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
In theory no limitations, but in reality it will be limitations.
|
||
Many factors are involved here.
|
||
Implementation of protocol, storage possibilities, server capacity, language
|
||
support.
|
||
In real time games a low latency is very important not a high bandwidth
|
||
because the games already send very little data, ~ 80 bytes.
|
||
Lag of below 250 ms is good, lag up to 500 ms payable and beyond that the
|
||
lag is noticeable.
|
||
\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 Subsection
|
||
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 Subsection
|
||
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 Subsubsection
|
||
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 Subsubsection
|
||
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.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Subsubsection
|
||
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.
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
Encryption
|
||
\end_layout
|
||
|
||
\begin_layout Subsubsection
|
||
Performance penalties
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
Availability
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
One important factor of a server is the availability, a server that you
|
||
can not connect to is a bad server.
|
||
Erlang has several features to increase the availability, for example hot
|
||
code replacement.
|
||
It is also critical to have a good design, we want to separate each part
|
||
of the server and thus avoiding that the whole server will crash.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
\begin_inset Note Note
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
Players are unsatisfied with the service of WoW Telecoms have the same problem
|
||
of having to migrate users from one node to another, this is called handover
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
Scalability
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
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
|
||
|
||
\begin_layout Subsubsection
|
||
UUID
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
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 Chapter
|
||
Overview
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
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 Subsubsection
|
||
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 times,
|
||
we restart the nearest supervisor of this child.
|
||
This ensures separation of the subsystems so that a crash is as isolated
|
||
as possible.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
\begin_inset Graphics
|
||
filename supervisors.png
|
||
scale 40
|
||
|
||
\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 Subsubsection
|
||
Hot code replacement
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
Implementation
|
||
\end_layout
|
||
|
||
\begin_layout Subsubsection
|
||
User interface
|
||
\end_layout
|
||
|
||
\begin_layout Chapter
|
||
Problems
|
||
\end_layout
|
||
|
||
\begin_layout Subsection
|
||
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 Subsubsection
|
||
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 PIDs 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 UUIDs can be generated before a collision
|
||
should occur.
|
||
There are standard tools in many UNIX systems to generate UUIDs, 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.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
\begin_inset Graphics
|
||
filename system_structure.png
|
||
scale 40
|
||
|
||
\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 Chapter
|
||
References
|
||
\end_layout
|
||
|
||
\begin_layout Chapter
|
||
Appendix
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Text goes here..
|
||
\end_layout
|
||
|
||
\begin_layout Bibliography
|
||
\begin_inset CommandInset bibitem
|
||
LatexCommand bibitem
|
||
key "key-1"
|
||
|
||
\end_inset
|
||
|
||
Savor, T.; Seviora, R.E.; , "Hierarchical supervisors for automatic detection
|
||
of software failures," PROCEEDINGS The Eighth International Symposium On
|
||
Software Reliability Engineering , vol., no., pp.48-59, 2-5 Nov1997 doi: 10.1109/IS
|
||
SRE.1997.630847 URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=630847&i
|
||
snumber=13710
|
||
\end_layout
|
||
|
||
\begin_layout Bibliography
|
||
\begin_inset CommandInset bibitem
|
||
LatexCommand bibitem
|
||
key "key-6"
|
||
|
||
\end_inset
|
||
|
||
Vinoski, S.; , "Reliability with Erlang," Internet Computing, IEEE , vol.11,
|
||
no.6, pp.79-81, Nov.-Dec.
|
||
2007 doi: 10.1109/MIC.2007.132 URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&ar
|
||
number=4376232&isnumber=4376216
|
||
\end_layout
|
||
|
||
\begin_layout Bibliography
|
||
\begin_inset CommandInset bibitem
|
||
LatexCommand bibitem
|
||
key "key-5"
|
||
|
||
\end_inset
|
||
|
||
CESARINI, F., & THOMPSON, S.
|
||
(2009).
|
||
Erlang programming.
|
||
Beijing, O'Reilly.
|
||
pp.139
|
||
\end_layout
|
||
|
||
\begin_layout Bibliography
|
||
\begin_inset CommandInset bibitem
|
||
LatexCommand bibitem
|
||
key "key-4"
|
||
|
||
\end_inset
|
||
|
||
"Erlang/OTP Product Information: Technical Description of Erlang." Home of
|
||
Erlang/OTP.
|
||
Web.
|
||
01 Mar.
|
||
2011.
|
||
<http://www.erlang.se/productinfo/erlang_tech.shtml>.
|
||
\end_layout
|
||
|
||
\begin_layout Bibliography
|
||
\begin_inset CommandInset bibitem
|
||
LatexCommand bibitem
|
||
key "key-3"
|
||
|
||
\end_inset
|
||
|
||
Joe Armstrong – Armstrong, J.
|
||
[2011].
|
||
If Erlang is the answer, then what is the question?.
|
||
[1].
|
||
IT University.
|
||
Computer Science and Engineering, 15/2/2011
|
||
\end_layout
|
||
|
||
\begin_layout Bibliography
|
||
\begin_inset CommandInset bibitem
|
||
LatexCommand bibitem
|
||
key "key-2"
|
||
|
||
\end_inset
|
||
|
||
Gul Abdulnabi Agha (1985).
|
||
ACTORS: A MODEL OF CONCURRENT COMPUTATION IN DISTRIBUTED SYSTEMS.
|
||
Ph.D thesis, Artificial Intelligence Laboratory, MIT.
|
||
\end_layout
|
||
|
||
\end_body
|
||
\end_document
|