jeena/GGS-report
1
0
Fork 0
Code Issues Pull requests Projects Packages Wiki Activity Actions

Added report

Browse source
This commit is contained in:
Jonatan Pålsson 2011-03-22 18:37:09 +01:00
commit 5b2ee9f22f
10 changed files with 5176 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

786
#report.lyx# Normal file
View 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
View file

Binary file not shown.

352
Thesis_Template.lyx Normal file
View 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
View file

File diff suppressed because it is too large Load diff

BIN
gu_logo.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 15 KiB

984
report.lyx Normal file
View 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
View 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
View file

Binary file not shown.

BIN
supervisors.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 24 KiB

BIN
system_structure.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 55 KiB