8216 lines
179 KiB
Text
8216 lines
179 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-200px]{graphics/logo}
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
end{center}
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
end{textblock*}
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
begin{textblock*}{
|
||
\backslash
|
||
paperwidth}(21mm,240mm)
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
University of Gothenburg
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
Department of Computer Science and Engineering
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
Gothenburg, Sweden 2011
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
Bachelor's thesis 2011:44
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
end{textblock*}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
author{
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
Jonatan Pålsson
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
|
||
\backslash
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
Richard Pannek
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
|
||
\backslash
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
Niklas Landin
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
|
||
\backslash
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
Mattias Petterson
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
}
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
title{
|
||
\backslash
|
||
Huge{A Generic Game Server}}
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
maketitle{ }
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Abstract
|
||
Today users of network games often experience failures of the servers while
|
||
playing or downtime due to maintenance.
|
||
Additionally game developers often perform the difficult task of reinventing
|
||
a game server to meet their needs.
|
||
The purpose of this thesis is to design a reliable game server which supports
|
||
different types of games simultaneously.
|
||
\end_layout
|
||
|
||
\begin_layout Abstract
|
||
It is investigated if the techniques and tools used in the telecom industry,
|
||
specifically the programming language Erlang and the Open Telecom Platform
|
||
(OTP) framework, can be used to create a highly reliable game server.
|
||
To make the server generic, it is investigated if virtual machines can
|
||
be used to run the actual games, thereby allowing the games to be developed
|
||
in different programming languages.
|
||
\end_layout
|
||
|
||
\begin_layout Abstract
|
||
A prototype is developed in Erlang using OTP.
|
||
The prototype features basic fault tolerance and is connected to the Google
|
||
V8 JavaScript virtual machine to run games written in JavaScript.
|
||
\end_layout
|
||
|
||
\begin_layout Abstract
|
||
The test results show that it is possible to design a server using the tools
|
||
originally intended for telecom software and it is indeed possible to create
|
||
a generic game server, capable of running different games, written in different
|
||
languages.
|
||
\end_layout
|
||
|
||
\begin_layout Abstract
|
||
This thesis concludes that simple games can easily be developed to work
|
||
reliably by making use of a generic server.
|
||
It should be worthwhile attempting to develop more advanced games using
|
||
the techniques described in this thesis.
|
||
\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 the day-to-day lives of many people.
|
||
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 than 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 citep
|
||
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 has become much more influential
|
||
in many ways.
|
||
Many advances in computer hardware are thought to come from pressure of
|
||
the computer game industry.
|
||
More powerful games require more powerful, and more easily available hardware.
|
||
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 citep
|
||
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 challenge of this thesis is to investigate techniques to improve the
|
||
quality of this networking software.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The 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
|
||
to 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 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.
|
||
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 failure}}{A failure in hardware (hard drive, memory, processor,
|
||
etc.) which causes a system to function in a different way than originally
|
||
intended, or crash}
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
nomenclature{
|
||
\backslash
|
||
textbf{Software failure}}{A failure in software (the GGS, the operating
|
||
system, etc.) which causes a system to function in a different way than
|
||
what was originally intended, or crash}
|
||
\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 gaming industry is a quickly growing industry with high revenues and
|
||
many clever computer scientists.
|
||
Strangely enough gamers often experience long downtimes due to maintainance
|
||
or because of problems with the servers
|
||
\begin_inset CommandInset citation
|
||
LatexCommand citep
|
||
key "news/cnet/com/WoWProblems"
|
||
|
||
\end_inset
|
||
|
||
.
|
||
This is a problem that has existed and been resolved in other industries
|
||
before.
|
||
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 citep
|
||
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 higher revenue for game
|
||
companies, to achieve 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 though 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.
|
||
A way to help game developers in developing servers more efficiently would
|
||
be to offer a generic game server which gives developers an environment
|
||
in which developers 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 citep
|
||
key "Bondi:2000:CSI:350391.350432"
|
||
|
||
\end_inset
|
||
|
||
.
|
||
These two issues are addressed in this thesis.
|
||
Structural scalability means expanding 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 characteristic of a system always to follow a specificat
|
||
ion, 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 any given point in time, and this is exactly
|
||
what is desired.
|
||
|
||
\begin_inset CommandInset citation
|
||
LatexCommand citep
|
||
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 types.
|
||
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 of 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 regular 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 any language which
|
||
runs in the
|
||
\emph on
|
||
Java Virtual Machine
|
||
\emph default
|
||
|
||
\begin_inset Note Note
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
Reference to app engine
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
.
|
||
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}}{Originally a procedural programming language.}
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
nomenclature{
|
||
\backslash
|
||
textbf{C++}}{An object-oriented programming language.}
|
||
\end_layout
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
nomenclature{
|
||
\backslash
|
||
textbf{Java}}{An object-oriented 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
|
||
Application servers were developed to run applications, often web applications.
|
||
The application servers offer appealing features for application developers,
|
||
which assist them 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 use 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 needs
|
||
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 support 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 ever 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 reputation 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 Standard
|
||
The generic nature of the GGS allows a multitude of different games to be
|
||
deployed on the GGS.
|
||
By deploying games on a common server less time has to be spent developing
|
||
servers for each individual game.
|
||
By supporting games developed in different languages, the features of the
|
||
GGS become available to games developed in languages which traditionally
|
||
do not exhibit these features.
|
||
\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 for the core of 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 developer
|
||
s.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Work has been 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 scalability aspects of the GGS are discussed from a theoretical point
|
||
of view, however no practical implementations 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 of
|
||
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 stateless 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 require a high
|
||
speed protocol will not be supported by the GGS prototype.
|
||
Another limitation necessary to set on the system is the fact that you
|
||
cannot 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 is 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 citep
|
||
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, any Generic Game Server should address all of these difficulties
|
||
in order to provide the tools necessary 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 of 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 with defined interfaces.}
|
||
\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 on 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 used is replication and restarting 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, performance measurement, and benchmarking techniques
|
||
are covered in the following.
|
||
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 be
|
||
transferred to the software model with help of proper tools.
|
||
\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 modeling 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.
|
||
One 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 of the chess club is given.
|
||
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 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, for example by adding more 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 bookkeeping 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 all communication during a game has to pass by the players
|
||
of that particular game and the coordinator only, making sure that no cheating
|
||
takes place.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
This isolation of the games plays 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 match 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-critic
|
||
al settings.
|
||
In not 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 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
|
||
transport 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 transferred data 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 necessary to implement
|
||
these features makes this option unfeasible.
|
||
\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 on top 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.
|
||
Based on that 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 operating system independent and run on Windows, OS X
|
||
and Linux.
|
||
The GGS can be run as a listen server on the computers of the players and
|
||
host games locally, it could also be a dedicated server running on dedicated
|
||
independent hardware.
|
||
The GGS 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 they would like to play on the
|
||
GGS, this way any client can connect to the server and install the game
|
||
through an 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 implemented differently 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, as explained in section
|
||
\begin_inset CommandInset ref
|
||
LatexCommand ref
|
||
reference "sub:Supervisor-structure"
|
||
|
||
\end_inset
|
||
|
||
, 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 types 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 exists.
|
||
\begin_inset CommandInset citation
|
||
LatexCommand citep
|
||
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 a useless server.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Within the telecom sector high-availability has been achieved
|
||
\begin_inset CommandInset citation
|
||
LatexCommand citep
|
||
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 citep
|
||
key "VM:Jin2010,VM:Polze"
|
||
|
||
\end_inset
|
||
|
||
) on how to migrate whole virtual machines between 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 data storage external to the VM is made.
|
||
The state is stored in a fast, fault tolerant data store instead of inside
|
||
the VM.
|
||
The GGS uses several 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, as well as 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 handling 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 to
|
||
different servers.
|
||
In many games it is not necessary for a player to move between tables during
|
||
games.
|
||
This is for example not a common occurrence in chess, where it would be
|
||
represented as a player standing up from her current table and sitting
|
||
down at a new table, all within the same game session.
|
||
Therefore the main focus of the GGS is not to move players between tables,
|
||
but to keep a player seated by a table and to start new tables if needed
|
||
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 number of users can be 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 kinds 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}}{Amazon Elastic Compute Cloud, a cloud computation service
|
||
provided by Amazon.}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Load balancing and scaling are difficult in certain scenarios.
|
||
When running in a server park, there is a set number of servers available,
|
||
this means that an even distribution across 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 the load on the 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 and 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 internally
|
||
because better external solutions exist already.
|
||
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 among each other or with their table, 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 Identification Number 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 locking, which may work well in many concurrent systems.
|
||
In a distributed system such as the GGS however, this locking, 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 citep
|
||
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}}{Stands for Secure Hash Algorithm, a cryptographic 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 it is extremely unlikely to have
|
||
identifier collisions when recovering from network splits between GGS clusters.
|
||
Consider figure
|
||
\begin_inset CommandInset ref
|
||
LatexCommand ref
|
||
reference "fig:network-split"
|
||
|
||
\end_inset
|
||
|
||
, where an example of a network split is shown.
|
||
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 failure.}
|
||
\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 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 the Erlang language provides.
|
||
\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, and a large base of developers within the
|
||
web community is using this language on the client side within the browser
|
||
and therefore are used to it.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
JavaScript, as a interpreted scripting language, has gained a lot of popularity
|
||
in other fields of computer science lately.
|
||
It is used as a server side language in large projects such as
|
||
\emph on
|
||
Riak
|
||
\emph default
|
||
|
||
\begin_inset Foot
|
||
status collapsed
|
||
|
||
\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
|
||
|
||
or
|
||
\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
|
||
Apart from that there are virtual machines with bindings to Erlang readily
|
||
available for JavaScript which are provided by organizations like Mozilla
|
||
and companies like Google.
|
||
In the end this choice was more or less arbitrary since the GGS is intended
|
||
to be able to run several different GDL VMs, and one had to be the first.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\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
|
||
included
|
||
\begin_inset Note Note
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
You did not implement the VM, you just implemented the inclusion of the
|
||
VM ...
|
||
so I would not use
|
||
\begin_inset Quotes eld
|
||
\end_inset
|
||
|
||
implement
|
||
\begin_inset Quotes erd
|
||
\end_inset
|
||
|
||
here.
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
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 is 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 do not need to participate in the same instance of the game,
|
||
games such as chess are possible candidates for the testing sessions.
|
||
\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 are deemed more demanding than the turn-based games.
|
||
Tests are 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 of 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 citep
|
||
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, is 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 have been performed on the GGS, and the results of these tests
|
||
are presented 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 weight threads,
|
||
enough processes could have been created to test the server successfully.
|
||
\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 implementation of many of the principles and technique
|
||
s 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 the GGS.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Much of what is discussed in this chapter has been implemented in the 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 programming language.
|
||
In Erlang, most things are processes.
|
||
The software running the Erlang code is known as the Erlang machine, or
|
||
an 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 LWPs
|
||
in Erlang.
|
||
Threads in a Linux system, for example, are treated much like operating
|
||
system processes in different systems.
|
||
Due to the size of the 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 prototype 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 in parallel
|
||
\begin_inset Note Note
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
or
|
||
\begin_inset Quotes eld
|
||
\end_inset
|
||
|
||
concurrently
|
||
\begin_inset Quotes erd
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
, several times more than an operating system, the relation between the
|
||
real world and the GGS (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 processes 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
|
||
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 permanent
|
||
processes running at all times.
|
||
The constantly running processes in the GGS prototype 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 the computers of the gamers,
|
||
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 into 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 necessary 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 mutual 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 citep
|
||
key "Armstrong:2010:ERL:1810891.1810910"
|
||
|
||
\end_inset
|
||
|
||
(Armstrong is one of the inventors of the programming language Erlang).
|
||
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 from which these messages can be retrieved.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Processes in Erlang are also called
|
||
\emph on
|
||
Light Weight Processes
|
||
\emph default
|
||
because they are inexpensive to create.
|
||
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 citep
|
||
key "Armstrong03"
|
||
|
||
\end_inset
|
||
|
||
.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The strong isolation of Erlang processes makes 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 transparently regardless of whether they run
|
||
on the same system or not.
|
||
\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 not pose a big problem.
|
||
\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)
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
nomenclature{
|
||
\backslash
|
||
textbf{NIF}}{Native implemented functions.}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\emph on
|
||
.
|
||
|
||
\emph default
|
||
Through ports communication can take place in a similar way as 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 citep
|
||
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 GDL VMs
|
||
\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.
|
||
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 Erlang systems.
|
||
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 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 interact 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.
|
||
This behavior is the most widely used one in the GGS prototype.
|
||
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 the 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 the 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
|
||
are double-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 the 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 into modules each part of the GGS can be modified without
|
||
damaging or requiring changes in the rest of the system.
|
||
Due to the hot code update feature in Erlang, it is theoretically possible
|
||
to update parts of the GGS while the system is running, this has however
|
||
not been implemented in the prototype.
|
||
The modular composition of the GGS prototype should make a transition to
|
||
a fully hot code swappable system relatively easy.
|
||
Hot code replacements are discussed in more detail in section
|
||
\begin_inset CommandInset ref
|
||
LatexCommand ref
|
||
reference "sub:Hot-code-replacement"
|
||
|
||
\end_inset
|
||
|
||
.
|
||
\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 different modules of the GGS are presented.
|
||
In the text 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
|
||
The dispatcher module is the first module to have contact with a player.
|
||
When a player connects to the GGS, the player is first greeted by the dispatche
|
||
r module, which sets up an accepting socket for each player.
|
||
The dispatcher is the module which handles the interaction with the operating
|
||
system when obtaining new 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 in the GGS, this is discussed
|
||
more in detail in chapter
|
||
\begin_inset CommandInset ref
|
||
LatexCommand vref
|
||
reference "sec:Operating-system-limitations"
|
||
|
||
\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, but 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 dispatcher process does not contain any kind of a state, therefore
|
||
a simple restart of the process is sufficient in restoring the GGS to a
|
||
pristine state after a dispatcher crash.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Returning to the 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 into the club.
|
||
The actual admittance to the club is in the GGS represented by the creation
|
||
of a player process discussed in section
|
||
\begin_inset CommandInset ref
|
||
LatexCommand vref
|
||
reference "sub:The-player-module"
|
||
|
||
\end_inset
|
||
|
||
.
|
||
The newly created player process is handed the control over its own socket
|
||
connection.
|
||
\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 client it represents,
|
||
and can communicate with this client.
|
||
In order to communicate with a client, 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, however it is not useful.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
During 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 created process in order to get access to the
|
||
lobby.
|
||
\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 only partly implemented
|
||
in the GGS prototype.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Moving back to the real-world example, the player process represents 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 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 are 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 separated by an empty new line.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
In the example below, line 1 contains the 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 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 applied, 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 3 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 to the system
|
||
from the protocol parser using the message passing functionality.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Line 4 is an empty line which is, like in the HTTP protocol, the separator
|
||
between the head and body or payload section.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Line 5 is the actual payload which is transported to the game as a parameter
|
||
of the playerCommand() function call.
|
||
\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
|
||
|
||
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 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.
|
||
The coordinator places each player by their respective table.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The coordinator keeps relations between each player and table, therefore
|
||
it is used to perform lookups on tables and players to find out which ones
|
||
that 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 before 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 an 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
|
||
In the event of 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
|
||
restart of a new coordinator process.
|
||
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 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 in the game.
|
||
\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 it
|
||
was associated with before the crash of the table.
|
||
The table process maps well to 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 is responsible for the VM associated with each game.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The game VM contains a connection to the GDL VM and a table token associated
|
||
with a running game.
|
||
The game VM is started by the table module during its initialization.
|
||
The table module hands over a token used for identification to the game
|
||
VM during the initialization.
|
||
During the initialization a new GDL VM instance and various objects associated
|
||
to the GDL VM instance are created.
|
||
Callbacks to Erlang are registered into the GDL VM and the source code
|
||
of a game is loaded into the GDL VM, finally the game is ready for startup.
|
||
The only means for a game to communicate with the GGS is through usage
|
||
of a provided interface.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The GDL VM itself makes it possible for the game developer to program in
|
||
the programming language covered by the GDL VM.
|
||
In future releases, more GDL VMs will be added to support more programming
|
||
languages.
|
||
Since 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, the data is delivered
|
||
to the player in the correct game.
|
||
The same game token is used to store the game state in the database.
|
||
Therefore, no game states can be mixed up.
|
||
\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 GDL 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 is 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 of database.
|
||
Mnesia is designed to handle the stress of telecoms systems
|
||
\begin_inset CommandInset citation
|
||
LatexCommand citep
|
||
key "667766"
|
||
|
||
\end_inset
|
||
|
||
, therefore it 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
|
||
The features of Mnesia originally intended for telecoms prove very useful
|
||
for the GGS as well.
|
||
The fault tolerance and speed of Mnesia are valuable tools, the fast key/value
|
||
lookups permit many lookups per second from the database.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Game data will not be lost when a game is stopped or has gone down for any
|
||
reason.
|
||
This makes it possible to continue a game from the point just before the
|
||
failure without having to restart the complete game.
|
||
|
||
\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 states in the distributed database Mnesia, from
|
||
which the state can be restored in an 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
|
||
\noun on
|
||
world
|
||
\noun default
|
||
and
|
||
\noun on
|
||
localStorage
|
||
\noun default
|
||
.
|
||
The
|
||
\noun on
|
||
World
|
||
\noun default
|
||
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
|
||
\noun on
|
||
localStorage
|
||
\noun default
|
||
contains data independent of the game state.
|
||
Game resources, constants and global variables are all examples of data
|
||
that reside within the
|
||
\noun on
|
||
localStorage
|
||
\noun default
|
||
.
|
||
To store a value within the database, not only are 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 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 among browser windows (which is
|
||
difficult when using cookies), and to store larger chunks of data
|
||
\begin_inset CommandInset citation
|
||
LatexCommand citep
|
||
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 which
|
||
interprets the game.
|
||
Furthermore an interface for communication among 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
|
||
\noun on
|
||
world
|
||
\noun default
|
||
,
|
||
\noun on
|
||
players
|
||
\emph default
|
||
\noun default
|
||
and
|
||
\emph on
|
||
\noun on
|
||
localStorage
|
||
\emph default
|
||
\noun 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
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt GGS.sendCommand(player
|
||
\backslash
|
||
_id, command, args)}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\emph default
|
||
and
|
||
\emph on
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt GGS.sendCommandToAll(command, args)}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\emph default
|
||
.
|
||
The
|
||
\noun on
|
||
localStorage
|
||
\noun default
|
||
is a convenient way to store global data and other variables separated
|
||
from the game state.
|
||
Unique IDs called game tokens are generated for hosted games so that they
|
||
are not mixed up.
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
nomenclature{
|
||
\backslash
|
||
textbf{Web Storage}}{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
|
||
\noun on
|
||
localStorage
|
||
\noun default
|
||
and
|
||
\noun on
|
||
world
|
||
\noun default
|
||
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 it 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
|
||
\noun on
|
||
localStorage
|
||
\noun default
|
||
is provided, thus the
|
||
\noun on
|
||
localStorage
|
||
\noun default
|
||
must be connected to the GGS object, this can be seen in line 5.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Both the
|
||
\noun on
|
||
GGS
|
||
\noun default
|
||
and
|
||
\noun on
|
||
localStorage
|
||
\noun default
|
||
objects are dummy objects, which provide no functionality, these two objects
|
||
are simply placed in the GDL for the purpose of clearing up the code.
|
||
To perform an action using the GGS and
|
||
\noun on
|
||
localStorage
|
||
\noun default
|
||
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 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 VM.
|
||
\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 Section
|
||
Techniques for ensuring reliability
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
One main goal of the project is to achieve high reliability.
|
||
The term 'reliable system' is defined by the IEEE as
|
||
\end_layout
|
||
|
||
\begin_layout Quotation
|
||
A system with the ability of a system or component to perform its required
|
||
functions under stated conditions for a specified period of time
|
||
\begin_inset CommandInset citation
|
||
LatexCommand citep
|
||
key "ieee_90"
|
||
|
||
\end_inset
|
||
|
||
.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
There are some tools built into Erlang that help creating reliable applications
|
||
:
|
||
\begin_inset ERT
|
||
status collapsed
|
||
|
||
\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
|
||
|
||
\series bold
|
||
Links between processes
|
||
\series default
|
||
.
|
||
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
|
||
|
||
\series bold
|
||
Transparent distribution over a network of processors
|
||
\series default
|
||
.
|
||
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
|
||
|
||
\series bold
|
||
Hot code replacements
|
||
\series default
|
||
.
|
||
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 reliable systems in Erlang.
|
||
Often 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 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/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
|
||
\begin_inset CommandInset label
|
||
LatexCommand label
|
||
name "fig:The-supervisor-structure"
|
||
|
||
\end_inset
|
||
|
||
The supervisor structure of the 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 to
|
||
\begin_inset CommandInset citation
|
||
LatexCommand citep
|
||
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.
|
||
In the case of the GGS, a process misbehaving most commonly triggers a
|
||
restart of the faulting process.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
There are several approaches to a supervisor design in general.
|
||
One common approach is to have the supervisor look into the state of the
|
||
processes it supervises, and let the supervisor make decisions based on
|
||
this state.
|
||
The supervisor has a specification of how the processes it supervises should
|
||
function, this is how it makes decisions.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
In Erlang, there is a simple version of supervisors.
|
||
No state of the processes being supervised is actually monitored.
|
||
There is, however 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 interval
|
||
a child process may crash, which processes need restarting when crashes
|
||
occur, etc.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
When the linking of processes to monitor exit behavior is coupled with the
|
||
transparent distribution of Erlang, a very powerful supervision system
|
||
is created.
|
||
For instance is it possible to 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, the system has been separated into two large supervised parts.
|
||
An attempt to restart a crashing child separately is made, 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, the nearest supervisor of this child is restarted.
|
||
This ensures separation of the subsystems so that a crash is as isolated
|
||
as possible.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Figure
|
||
\begin_inset CommandInset ref
|
||
LatexCommand vref
|
||
reference "fig:The-supervisor-structure"
|
||
|
||
\end_inset
|
||
|
||
shows the 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 in the event
|
||
of a crash.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The choice has been made 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 to fix this faulty data,
|
||
or to foresee the unexpected events.
|
||
This was not chosen since it is so simple to monitor and restart processes,
|
||
and difficult to try to mend broken states.
|
||
This approach is something widely deployed in the Erlang world, and developers
|
||
are often encouraged to “Let it crash”
|
||
\begin_inset CommandInset citation
|
||
LatexCommand citep
|
||
key "Armstrong03"
|
||
|
||
\end_inset
|
||
|
||
.
|
||
\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, the backup process is queried for any
|
||
previous state, if there is any, that state is loaded into 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 operations.
|
||
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 the state along to the backup process which keeps
|
||
the data safe.
|
||
If a crash occurs, 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
|
||
This type of redundancy is only implemented in the coordinator process,
|
||
similar configurations should however be possible for all modules of the
|
||
GGS.
|
||
\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
|
||
\begin_inset CommandInset label
|
||
LatexCommand label
|
||
name "sub:Hot-code-replacement"
|
||
|
||
\end_inset
|
||
|
||
|
||
\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 is in critical systems that require
|
||
low downtime, such as telecom systems.
|
||
By using hot code replacement, systems are able to achieve much longer
|
||
uptimes and thus improving the reliability of the system.
|
||
Code replacement is a feature that exists in Erlang which means that with
|
||
some work it could be implemented into the GGS.
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Testing
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
To make sure the GGS prototype adheres to the specification set, three 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 functions has been tested according to the 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,
|
||
as users do not always act rationally.
|
||
In order to introduce random data, the client side of the GGS is simulated
|
||
by QuickCheck tests.
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
nomenclature{
|
||
\backslash
|
||
textbf{QuickCheck}}{QuickCheck is a library designed to assist in software
|
||
testing by generating test cases for test suites.}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Finally to test the robustness of the prototype virtual users, so called
|
||
bots are being used to simulate large amounts of players playing different
|
||
games simultaneously.
|
||
\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, usually
|
||
complete functions.
|
||
Unit testing is good, not only for revealing software bugs, but also to
|
||
state that a feature is working according to the specification.
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Unit testing is an 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.
|
||
\begin_inset Note Note
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
continuous testing, agile, something like that could be mentioned here!
|
||
By the way, do you know http://schneide.wordpress.com/2008/10/27/extreme-feedback
|
||
-device-xfd-the-onoz-lamp/? the whole category http://schneide.wordpress.com/categ
|
||
ory/extreme-feedback/ could be interesting ...
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Erlang provides a module for unit testing called EUnit.
|
||
EUnit, being a part of OTP, is rich in functionality and well documented,
|
||
it does not however allow any means of testing of asynchronous behaviors
|
||
as opposed to other means of software testing.
|
||
\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 addresses this problem by
|
||
generating 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 that 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 citep
|
||
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 results is to extract a
|
||
\emph on
|
||
minimal failing test case
|
||
\emph default
|
||
which contains the smallest failing test sequence.
|
||
By applying a very large test and gradually simplifying the test to find
|
||
the smallest failing sequence, many bugs which would otherwise have been
|
||
hard to catch can be caught
|
||
\begin_inset CommandInset citation
|
||
LatexCommand citep
|
||
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 implementations 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 Subsection
|
||
Bots
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
In order to test the robustness of the GGS several different artificial
|
||
users, so called bots, have been implemented.
|
||
Each of these bots is programmed to play a game on the GGS as similar to
|
||
a real user as possible.
|
||
For the GGS there is no difference in serving a real user or a bot.
|
||
A large amount of players can be simulated playing games on the GGS simultaneou
|
||
sly, which is a good stress and concurrency test for the overall system.
|
||
In section
|
||
\begin_inset CommandInset ref
|
||
LatexCommand ref
|
||
reference "sec:Statistics"
|
||
|
||
\end_inset
|
||
|
||
some of the statistical data retrieved with help of a whole network of
|
||
bots playing games is being presented.
|
||
\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 name of a user.
|
||
The actual code performing the change of a nick name 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 representation of such a message, which is just a specializ
|
||
ed Erlang tuple.
|
||
\end_layout
|
||
|
||
\begin_layout Enumerate
|
||
The protocol parser sends this Erlang tuple back to the player process.
|
||
\end_layout
|
||
|
||
\begin_layout Enumerate
|
||
The player process checks if the command 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
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt playerCommand("278d5", "nick", "Peter")}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\emph default
|
||
within the JavaScript VM (JSVM).
|
||
\end_layout
|
||
|
||
\begin_layout Enumerate
|
||
The 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
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt GGS.localStorage.setItem(key, value)}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\emph default
|
||
and
|
||
\emph on
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt GGS.localStorage(key)}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\emph default
|
||
are used.
|
||
Both are callbacks coupled to the database module functions.
|
||
\end_layout
|
||
|
||
\begin_layout Enumerate
|
||
Data is 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
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt GGS.sendCommandToAll()}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\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
|
||
roughly its life cycle until 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 incoming connection 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 add 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 JSVM.
|
||
\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 whether it should define a game.
|
||
The first client to connect to this table should define the new game.
|
||
\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 payload.
|
||
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
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt playerCommand()}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
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
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt playerCommand()}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
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 part of a game, a simple in-game-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
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt playerCommand()}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\emph default
|
||
which is the entry point for each game and has to be implemented by the
|
||
developer; it can be seen as the
|
||
\emph on
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt main()}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\emph default
|
||
function of a C or Java program
|
||
\emph on
|
||
.
|
||
|
||
\emph default
|
||
Typically the
|
||
\emph on
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt playerCommand()}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\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
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt playerCommand()}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\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
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt playerCommand()}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\emph default
|
||
function accepts two different commands.
|
||
The first command is a command which allows chat clients connected to the
|
||
chat server to change the nicknames, which are used when chatting.
|
||
In order to change the nickname, a client must send a Game-Command
|
||
\noun on
|
||
nick
|
||
\noun default
|
||
with the actual new nick name as its payload.
|
||
When a message arrives at the GGS which has the form corresponding to the
|
||
nick name change, the
|
||
\emph on
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt playerCommand()}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\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
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt playerCommand()}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\emph default
|
||
function is responsible for calling the helper functions responsible for
|
||
carrying out the actions of each message received.
|
||
|
||
\emph on
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt changeNick()}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\emph default
|
||
is a function which is called when the
|
||
\noun on
|
||
nick
|
||
\noun default
|
||
message is received.
|
||
The
|
||
\emph on
|
||
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt changeNick()}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\emph default
|
||
function uses a feature of the GGS called
|
||
\noun on
|
||
localStorage
|
||
\noun default
|
||
(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 with the GDL of the
|
||
GGS.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Access to the
|
||
\noun on
|
||
localStorage
|
||
\noun default
|
||
is provided through the
|
||
\emph on
|
||
\noun on
|
||
GGS
|
||
\noun default
|
||
|
||
\emph default
|
||
object, 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 the implementation
|
||
\begin_inset CommandInset label
|
||
LatexCommand label
|
||
name "cha:Problems-of-implementation"
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
This chapter contains descriptions of 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 included.
|
||
\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, so is the protocol design and
|
||
limitation in the operating systems which have been used during development
|
||
and testing.
|
||
\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 wide-spread use in web
|
||
applications 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 Google's
|
||
\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 an Erlang binding called erlang_js,
|
||
and for the V8 machine a binding called erlv8 exists.
|
||
Below follows a discussion about the different bindings and machines, and
|
||
a motivation as to why erlv8 was preferred over erlang_js.
|
||
\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 NIF callbacks
|
||
is present 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 of the GGS.
|
||
While still described to be in 'alpha' stage, the erlv8 bindings have proved
|
||
to be stable enough and 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 planned to use the UDP protocol as a transport
|
||
layer.
|
||
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 based on 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 by Joe Armstrong (one
|
||
of the inventors of Erlang), the GGS protocol had already been implemented,
|
||
moving to Thrift would have meant too much effort for a prototype during
|
||
the short amount of time.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The use of Google protocol buffers - which is a different approach to a
|
||
standard protocol framework, implemented by Google - or other protocols
|
||
can be supported quite easily by developing protocol modules for each of
|
||
the protocols.
|
||
No protocol modules for these protocols have however been developed during
|
||
the writing of this thesis.
|
||
\end_layout
|
||
|
||
\begin_layout Section
|
||
Operating system limitations
|
||
\begin_inset CommandInset label
|
||
LatexCommand label
|
||
name "sec:Operating-system-limitations"
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The operating systems on the computers which have been used to run the bots
|
||
while testing the GGS prototype had some limitations.
|
||
The operating systems used were Linux and Mac OS X, since these systems
|
||
are quite similar on a lower level they exhibited the same limitations..
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The most notable limitation was a limit set on the number of simultaneously
|
||
open files.
|
||
Due to the implementation of sockets in UNIX-like systems such as Mac OS
|
||
X and Linux, a limit on the number of open files is a limit on the number
|
||
of open sockets.
|
||
In order to simulate many connections to the GGS, many sockets needed to
|
||
be opened.
|
||
Each socket had a bot connected on one end and the GGS on the other end.
|
||
On each test machine several thousand sockets needed to be open while testing
|
||
the GGS, therefore the limit on open files had to be removed.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
On the Linux machines the limit of open files is configured in
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt /etc/security/security.conf}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
On the Mac OS X machine the limit of open files is configured in
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
{
|
||
\backslash
|
||
tt /etc/launchd.conf }
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
.
|
||
\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 tests done on the GGS prototype are presented
|
||
and discussed.
|
||
The test results 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 CommandInset label
|
||
LatexCommand label
|
||
name "sec:Statistics"
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Testing of the GGS took place in two separate sessions.
|
||
The first session simulated 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 uses 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 sent 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
|
||
The hardware that the GGS was running on was a Thinkpad T410, with an Intel
|
||
i5 processor and 4GB RAM.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
In the first test, in which Mnesia has been heavily used, the server had
|
||
a peak value of nearly 6,000 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 has been conducted with another game
|
||
that did not use Mnesia.
|
||
Without Mnesia the server peaked at 60,000 messages per second, however
|
||
this was only for a very short time.
|
||
The average throughput was around 25,000 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 the clients
|
||
has also been 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 too, 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
|
||
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.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
It should be noted that with distribution in place, having the GGS deployed
|
||
on several machines, test results could reveal much higher numbers.
|
||
\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 at least 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 used.
|
||
\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 prototype that can be improved.
|
||
In this section the most important improvements 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 future 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 prototype.
|
||
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 while performing
|
||
, in some cases unnecessary, tests to assure the correctness of the data.
|
||
Therefore support for UDP would mean that more games could be run simultaneousl
|
||
y on the GGS.
|
||
Another advantage of UDP is that latency is being reduced.
|
||
Without having to set up a connection for each group of 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 any changes, 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 Subsubsection
|
||
Integration with existing games
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
It should be possible to integrate the GGS with existing network games.
|
||
In order to integrate the GGS with an existing game it is neccessary to
|
||
1) rewrite the entire server logic in a GDL and deploy this implementation
|
||
on the GGS, and 2) write a protocol parser for the protocol of the game
|
||
at hand.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
No implementation of a game server for an existing game has been done, however
|
||
preliminary investigations on running an early version of Quake on he GGS
|
||
have been made.
|
||
An interesting future improvement of the GGS would be to develop an implementat
|
||
ion of a game server for an existing game for the GGS.
|
||
\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 separation 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 simple manner and with minimal overhead.
|
||
Furthermore every game should be isolated so that games cannot interfere
|
||
with each other.
|
||
Isolation can be achieved 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
|
||
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
|
||
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
|
||
\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
|