Added report
This commit is contained in:
Jonatan Pålsson
commit
5b2ee9f22f
10 changed files with 5176 additions and 0 deletions
786
#report.lyx#
Normal file
786
#report.lyx#
Normal file
|
|
@ -0,0 +1,786 @@
|
||||||
|
#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
|
||||||
|
|
||||||
|
\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 Subsubsection
|
||||||
|
UUID
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Section
|
||||||
|
Design choices
|
||||||
|
\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 Section
|
||||||
|
Objectives
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
\begin_inset Newpage newpage
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
Figures go here...
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Chapter
|
||||||
|
Methodology
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Section
|
||||||
|
Overview
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
Text goes here...
|
||||||
|
\begin_inset Newpage newpage
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
Figures go here...
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\end_body
|
||||||
|
\end_document
|
||||||
BIN
LO_CHGU_cen2rCMYK.eps
Normal file
BIN
LO_CHGU_cen2rCMYK.eps
Normal file
Binary file not shown.
352
Thesis_Template.lyx
Normal file
352
Thesis_Template.lyx
Normal file
|
|
@ -0,0 +1,352 @@
|
||||||
|
#LyX 1.6.3 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 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 Standard
|
||||||
|
Text goes here...
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Section
|
||||||
|
Objectives
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
\begin_inset Newpage newpage
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
Figures go here...
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Chapter
|
||||||
|
Methodology
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Section
|
||||||
|
Overview
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
Text goes here...
|
||||||
|
\begin_inset Newpage newpage
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
Figures go here...
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\end_body
|
||||||
|
\end_document
|
||||||
2262
UTHM-Thesis-Classic-authoryear-V-05.lyx
Normal file
2262
UTHM-Thesis-Classic-authoryear-V-05.lyx
Normal file
File diff suppressed because it is too large
Load diff
BIN
gu_logo.png
Normal file
BIN
gu_logo.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
984
report.lyx
Normal file
984
report.lyx
Normal file
|
|
@ -0,0 +1,984 @@
|
||||||
|
#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
|
||||||
792
report.lyx~
Normal file
792
report.lyx~
Normal file
|
|
@ -0,0 +1,792 @@
|
||||||
|
#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 50
|
||||||
|
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
|
||||||
|
\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 Subsubsection
|
||||||
|
UUID
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Section
|
||||||
|
Design choices
|
||||||
|
\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 Section
|
||||||
|
Objectives
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
\begin_inset Newpage newpage
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
Figures go here...
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Chapter
|
||||||
|
Methodology
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Section
|
||||||
|
Overview
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
Text goes here...
|
||||||
|
\begin_inset Newpage newpage
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
Figures go here...
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\end_body
|
||||||
|
\end_document
|
||||||
BIN
report.pdf
Normal file
BIN
report.pdf
Normal file
Binary file not shown.
BIN
supervisors.png
Normal file
BIN
supervisors.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
BIN
system_structure.png
Normal file
BIN
system_structure.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 55 KiB |
Loading…
Add table
Add a link
Reference in a new issue