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