diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000..5008ddf Binary files /dev/null and b/.DS_Store differ diff --git a/opposition.lyx b/opposition.lyx index 8f640c6..bf934a4 100644 --- a/opposition.lyx +++ b/opposition.lyx @@ -147,15 +147,7 @@ Why is recording favoured over emulation, for example? How can recorded \end_layout \begin_layout Standard -Section 7.1 mentions a generic module to support the development of simulators. - Furthermore the section describes some simulators developed using the gen_fsm - behaviour. - Which additional features are provided by the software described in this - thesis, which are not already present in the gen_fsm behaviour? -\end_layout - -\begin_layout Standard -In the thesis there are some unclear points: +Specifically: \end_layout \begin_layout Itemize @@ -167,6 +159,12 @@ In the thesis there are some unclear points: ? Also, what is the “old work flow” in this context? \end_layout +\begin_layout Itemize +4.2: This section states a simulation library and support for creating new + simulators. + Yet these are not explained like for example the convenience scripts. +\end_layout + \begin_layout Itemize 5.2: Exactly how is the quality of the simulators measured? Which metrics are used? Some metrics are presented here, but not motivated, also results @@ -174,9 +172,21 @@ In the thesis there are some unclear points: \end_layout \begin_layout Itemize -4.2: This section states a simulation library and support for creating new - simulators. - Yet these are not explained like for example the convenience scripts. +7.1: mentions a generic module to support the development of simulators. + Furthermore the section describes some simulators developed using the gen_fsm + behaviour. + Which additional features are provided by the software described in this + thesis, which are not already present in the gen_fsm behaviour? +\end_layout + +\begin_layout Itemize +According to 7.4, API:s and simulators must be created when they don't already + exist, why is this not represented in the first flow chart? Does your applicati +on provide any ways to reduce development time of simulators? The quality + of a simulator may vary.. + You created three simple device simulators. + How long did it take to create them? Case studies of developing these could + motivate the usage of simulators over hardware. \end_layout \begin_layout Standard @@ -185,13 +195,6 @@ A future improvement to the project is creating a finite state machine from It is unclear to us how this improves the system. \end_layout -\begin_layout Standard -A future improvement of the system is to implement “runtime function call - replacement”, this directly contradicts the purpose of the thesis, which - is to run the same code on both the simulator and the real hardware. - Why is this considered to be an improvement? -\end_layout - \begin_layout Standard Also, there are some factual errors; processes do share data, and data is shared through message passing. @@ -200,11 +203,6 @@ Also, there are some factual errors; processes do share data, and data is PIDs can indeed be converted to lists, using the pid_to_list/1 function. \end_layout -\begin_layout Standard -7.5.1 says that ember can automate the process of deploying code. - How is this useful? What sort of code? -\end_layout - \begin_layout Section* Results \end_layout @@ -233,18 +231,28 @@ How long does it take to upload the code to the hardware and how often is \end_layout \begin_layout Itemize -How long, on the other hand, does it take to get to know your system, write - the simulators and follow the steps you described? +How long does it take to get to know your system, write the simulators and + follow the steps you described? Is the workflow more efficient using your + system? \end_layout \begin_layout Itemize -Did you calculate a difference of time between the two approaches? +Did you calculate a difference of time between development on the hardware + versus in a simulated environment? \end_layout \begin_layout Standard The graphs provided are inconclusive and lack good descriptive texts. It is unclear which metrics are used on each axis, and exactly what is - being measured; for instance, what is a sample? + being measured; for instance, what is a +\begin_inset Quotes eld +\end_inset + +sample +\begin_inset Quotes erd +\end_inset + +? \end_layout \begin_layout Standard @@ -254,21 +262,6 @@ The accuracy of the simulators was presented in a graph, and it can be seen impacts does this have on the simulation? \end_layout -\begin_layout Standard -According to 7.4, API:s and simulators must be created when they don't already - exist. - Isn't it a huge project within itself, creating an API:s and simulators? - Does your application provide any ways to reduce development time of simulators -? The quality of a simulator may vary. - There may take a long time to make it perform well and be flexible to work - with. - You created three simple device simulators. - How long did it take to create them? These times could prove why the developmen -t of simulators wouldn't be a great deal and to estimate creation time of - other simulators. - -\end_layout - \begin_layout Section* Language \end_layout @@ -283,23 +276,27 @@ The language style in the thesis is not formal as it would be expected in \begin_layout Standard Some terms could be introduced better; OTP, Beagle Board, Gumstix, Ångström/Angs trom, distro, NAT, OS, Panda Board, VM, stub, public/subscribe, request-response -, OS variable, ssh. +, OS variable and SSH. Erlang is introduced properly, and the same could perhaps be done for these terms as well. The structure of function calls (fun/num of pars) is not obvious to the reader, perhaps it could be explained. \end_layout +\begin_layout Standard +It is hard to refer to the figures since they are not numbered. +\end_layout + \begin_layout Section* What we would like to see ... \end_layout \begin_layout Standard It would be interesting to see this system combined with a testing framework, - like QuickCheck in order to create a powerful test suite which generates + like QuickCheck, in order to create a powerful test suite which generates tests using real data samples. If the data generated by the recorder could be used as input to a testing - framework, like QuickCheck a very powerful and random test suite could + framework, like QuickCheck, a very powerful and random test suite could be created. \end_layout diff --git a/report2.pdf b/report2.pdf new file mode 100644 index 0000000..0f98ef2 Binary files /dev/null and b/report2.pdf differ diff --git a/report_commented.lyx b/report_commented.lyx new file mode 100644 index 0000000..f721a28 --- /dev/null +++ b/report_commented.lyx @@ -0,0 +1,8335 @@ +#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 +\author 260405038 "goetz" +\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/logoBW} +\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 + +Göteborgs Universitet +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + +Institutionen för data- och informationsteknik +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + +Göteborg, Sverige 2011 +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + +Kandidatarbete 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 Reliable 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 simultanously. +\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 Reliable Generic Game Server, hereafter known as the GGS +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{GGS}}{Generic Game Server, a software for reliably hosting network + games. + The subject of this thesis.} +\end_layout + +\end_inset + +, is a computer program designed to +\emph on +host +\emph default + network games on one or more server computers. + Hosting, in a network software setting, means allowing client software + 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 failiure}}{A failiure in hardware (hard drive, memory, processor +, etc.) which causes a system to stop functioning.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Software failiure}}{A failiure in software (the GGS, the operating + system, etc.) which causes a system to stop functioning.} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Background +\begin_inset CommandInset label +LatexCommand label +name "sec:Background" + +\end_inset + + +\end_layout + +\begin_layout Standard +The 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 citet +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 citet +key "Armstrong03" + +\end_inset + +, or roughly +\begin_inset Formula $15ms$ +\end_inset + + downtime in a year. + The level of instability and bad fault tolerance seen in the game server + industry would not have been accepted in the telecom industry. + This level of instability should not be accepted in the game server industry + either. + An unavailable phone system could potentially have life threatening consequence +s, leaving the public unable to contact emergency services. + The same cannot be said about an unavailable game server. + The statement that game servers are less important than phone systems is + not a reason not to draw wisdom from what the telecoms have already learned. +\end_layout + +\begin_layout Standard +Moving back to the gaming industry. + The main reason to develop reliable servers is a higher revenue 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 citet +key "Bondi:2000:CSI:350391.350432" + +\end_inset + +. + These two issues are addressed in this thesis. + Structural scalability means expanding an architecture, e.g. + adding nodes to a system without requiring modification of the system. + Load scalability means using the available resources in a way which allows + handling increasing load, e.g more users, gracefully. +\end_layout + +\begin_layout Standard +Fault tolerance (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Fault-Tolerance" + +\end_inset + +) is used to raise the level of +\emph on +dependability +\emph default + in a system, so that the dependability is high even in presence of errors. + Dependability is the statistical probability of the system functioning + as intended at a given point in time. + Fault tolerance is the 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 citet +key "Gartner:1999:FFD:311531.311532" + +\end_inset + + +\end_layout + +\begin_layout Standard +A generic (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Generic" + +\end_inset + +) game server has to be able to run different client-server network games + regardless of the platform the clients are running on. + It runs network games of different 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 some language which + runs in the +\emph on +Java Virtual Machine +\emph default +. + An example of an application server not powering web applications, but + instead regular business logic, is Oracle’s +\emph on +TUXEDO +\emph default + application server, which can be used to run applications written in COBOL, + C++ and other languages. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SQL}}{Structured Query Language, a computer language common in querying + certain databases.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{JavaScript}}{A programming language originally developed by Netscape, + common in web programming.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{COBOL}}{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 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 +A great deal of work is devoted to make the GGS +\emph on +reliable +\emph default +. + This includes ensuring that the system scales well and to make sure it + is fault tolerant. + In order to facilitate scalability the GGS needs a storage platform which + is accessible and consistent. + The scalability aspects of the GGS are discussed from a theoretical point + of view, however no practical implementation of the scalability aspects + are found in the prototype. +\end_layout + +\begin_layout Section +Limitations of the prototype +\end_layout + +\begin_layout Standard +The implementation of the GGS protocol together with storage possibilities, + server capacity, and game language support imposes some limitations on + the project. + To get a functional prototype, some limits must be set on the types 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 citet +key "Farber:2002:NGT:566500.566508" + +\end_inset + +). + Latency sensitive games include most of the first person shooters with + multiplayer ability, for example +\emph on +Counter Strike +\emph default + or massively multiplayer online role playing games (MMORPGs), for example + +\emph on +World of Warcraft +\emph default +. +\end_layout + +\begin_layout Standard +In turn-based games each player has to wait for their turn. + Latency is not a problem since the gameplay does not require fast interactions + among the players, long round trip times will not be noticed. + Examples of turn-based games include board and card games, as well as multiplay +er games like +\emph on +Jeopardy +\emph default +. + Both game types have varying difficulties and needs when it comes to implementi +ng them, 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 chess + club, the player must pass by the entrance. + By having each player pass by the entrance, a tally +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Does this mean what I think it does? +\begin_inset Quotes eld +\end_inset + +Räkning +\begin_inset Quotes erd +\end_inset + +? +\end_layout + +\begin_layout Plain Layout +Richard: it means a list where you count how many people entered or left + for example +\end_layout + +\end_inset + + can be kept, ensuring that there are not too many players within the building. + In the GGS setting, too many players entering would mean too many connections + have been accepted by the GGS system, and that the structure of the system + thus must be modified, 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 Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Performance measurements +\end_layout + +\begin_layout Plain Layout +Tue apr 26, 9:15. + Continue from here on. + Discuss which results we may expect in a fully fledged GGS system. + What impedes the speeds, what raises the CPU load (and therefore the temperatur +es & power consumption). + What factors are there in the network saturation problem? +\end_layout + +\begin_layout Plain Layout +Which games are affected by what, and what does this mean for the number + of players a GGS can handle? +\end_layout + +\end_inset + + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Create a game with several thousand players, see how our server scales, + how can we improve the performance? Sharding isn’t very nice.. + alternatives? Improve the speed of sharding? +\end_layout + +\begin_layout Itemize +See how the server scales +\end_layout + +\begin_deeper +\begin_layout Itemize +When adding many clients +\end_layout + +\begin_deeper +\begin_layout Itemize +Measure in +\begin_inset Formula $ms$ +\end_inset + + (ping to clients) +\end_layout + +\begin_layout Itemize +measure in system load +\end_layout + +\begin_layout Itemize +Measure in loss of messages +\end_layout + +\begin_layout Itemize +Measure in # of timeouts? (if any??) +\end_layout + +\begin_layout Itemize +Measure in time-to-crash +\end_layout + +\end_deeper +\begin_layout Itemize +When adding new machines to the pool +\end_layout + +\begin_deeper +\begin_layout Itemize +% increase of performance per machine +\end_layout + +\end_deeper +\begin_layout Itemize +Single-core CPU vs multi-core CPU +\end_layout + +\begin_deeper +\begin_layout Itemize +It's very important to scale well on multi-core systems, since this is where + the industry is going. + Multicore is the future. +\end_layout + +\end_deeper +\end_deeper +\begin_layout Plain Layout +Find reference on how to benchmark distributed, multiprocess systems +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Choosing a network protocol +\begin_inset CommandInset label +LatexCommand label +name "sec:Choice-of-network" + +\end_inset + + +\end_layout + +\begin_layout Standard +There are two main types of protocols with help of which computer communication + over the Internet usually takes place; TCP and UDP which are known as the + 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 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 operation system +\begin_inset Note Note +status open + +\begin_layout Plain Layout +If you want to use OS, you should add it to the nomenclature. +\end_layout + +\end_inset + + independent and run on Windows, OS X and Linux. + The GGS can be run as a listen server on the players computer and host + games locally. + It could also be a dedicated server running on dedicated independent hardware. + It is meant to run any game in any environment in any way desired, therefore + being as generic as possible. +\end_layout + +\begin_layout Standard +Clients upload the source code of the game they would like to play on the + GGS, this way any client can connect to the server and install the game + through a API without the need of installation through the server provider + or maintainer. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{API}}{Application programming interface.} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Fault tolerance +\begin_inset CommandInset label +LatexCommand label +name "sec:Fault-Tolerance" + +\end_inset + + +\end_layout + +\begin_layout Standard +Merriam-Webster’s dictionary +\begin_inset CommandInset citation +LatexCommand citeyearpar +key "Dictionary.com2011" + +\end_inset + + defines fault tolerance as: +\end_layout + +\begin_layout Quotation +1. + The ability of a system or component to continue normal operation despite + the presence of hardware or software faults. + This often involves some degree of redundancy. +\end_layout + +\begin_layout Quotation +2. + The number of faults a system or component can withstand before normal + operation is impaired. + +\end_layout + +\begin_layout Standard +Fault tolerance is an important factor in servers A server that is fault + tolerant should be able to follow a given specification when parts of the + system fail. + This means that fault tolerance is 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 citet +key "Gartner:1999:FFD:311531.311532" + +\end_inset + + +\end_layout + +\begin_layout Section +Availability +\begin_inset CommandInset label +LatexCommand label +name "sec:Availability" + +\end_inset + + +\end_layout + +\begin_layout Standard +An important factor of any server is availability. + A server which is unreachable is an useless server. + +\end_layout + +\begin_layout Standard +Within the telecom sector high-availability has been achieved +\begin_inset CommandInset citation +LatexCommand citet +key "armstrong2011" + +\end_inset + +. + In the game development sector however the lack of high-availability problem + has not yet been solved. +\end_layout + +\begin_layout Standard +There are several good papers (e.g. + +\begin_inset CommandInset citation +LatexCommand citet +key "VM:Jin2010,VM:Polze" + +\end_inset + +) on how to migrate whole virtual machines 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 numbers 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 citet +key "Leach98uuidsand" + +\end_inset + +: +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{MAC Address}}{Media Access Control address, used to identify network + cards.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SHA-1}}{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 one of the mechanisms + mentioned in this document, it is either guaranteed to be different from + all other UUIDs/GUIDs 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 citet +key "Lidholt02designand" + +\end_inset + +, who describes a test bench using +\emph on +bots +\emph default + for testing his generic hazard-gaming server. + Lidholt describes how his server, capable of running several different + casino games, 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 Erlang machine, or 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 gamers computers, and not + on the GGS machine. + If a game of chess is to be played on the server, the clients on the machines + of the gamers will be chess game clients. + Clients connect through a network, pictured as a cloud, to the dispatcher + process in the GGS. + The dispatcher process and all other modules are discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:The-modular-structure" + +\end_inset + +. + For each connection, a new player process is spawned, which immediately + after spawning is integrated 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 citet +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 citet +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 citet +key "NIF:website" + +\end_inset + +. +\end_layout + +\begin_layout Standard +The GGS uses Erlang ports for generating UUIDs +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +UUIDs are discussed in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:UUID" + +\end_inset + + +\end_layout + +\end_inset + + and NIFs for interfacing with the 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 to 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 he or she is seated + by, this corresponds clearly to how the GGS is structured, as can be seen + in the following sections. +\end_layout + +\begin_layout Subsection +The protocol parser module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-protocol-parser" + +\end_inset + + +\end_layout + +\begin_layout Standard +The protocol parser is an easily interchangeable module in the GGS, handling + the client-to-server, and server-to-client protocol parsing. + In the GGS prototype, there is only one protocol supported, namely the + +\emph on +GGS Protocol +\emph default +. + The role of the protocol parser is to translate the meaning of packets + sent using the protocol in use to internal messages of the GGS system. + The GGS protocol, discussed below is used as a sample protocol in order + to explain how protocol parsers can be built for the GGS. +\end_layout + +\begin_layout Subsubsection +The structure of the GGS Protocol +\begin_inset CommandInset label +LatexCommand label +name "sub:The-structure-of" + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS protocol is modeled after the HTTP protocol. + The main reason for this is the familiarity many developers already have + with HTTP due to its presence in internet software. + Each GGS protocol packet contains a headers section. + The headers section is followed by a data section. + In the headers section, parameters concerning the packet is placed. + In the data section, the actual data payload of the packet is placed. +\end_layout + +\begin_layout Standard +There is no requirement of any specific order of the parameters in the headers + section, however the data section must always follow directly after the + headers section separated by a 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 at 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 at 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 citet +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 is the table token and the + name of the namespace required, but a unique key so that the value can + be successfully retrieved or modified later. + The key is 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 citet +key "webstorage:website" + +\end_inset + +. + Usage of the Web Storage standard in the GGS provides a well documented + interface to the database backend. +\end_layout + +\begin_layout Section +Communication with the GDL VM +\begin_inset CommandInset label +LatexCommand label +name "sec:Communication-with-the-GDL-VM" + +\end_inset + + +\end_layout + +\begin_layout Standard +A game launched on the GGS is run within a virtual machine. + For each programming language supported, there is a virtual machine 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 citet +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 open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Reliability}}{The ability of a system or component to perform its + required functions under stated conditions for a specified period of time} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{IEEE}}{Institute of Electrical and Electronics Engineers, read "I-triple- +E"} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Itemize + +\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 citet +key "Savor:1997:HSA:851010.856089" + +\end_inset + +. + When a process misbehaves, the supervisor takes some action to restore + the process to a functional state. + 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 open + +\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 citet +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. +\change_inserted 260405038 1305572717 + +\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 + + +\change_unchanged + +\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 exist 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 citet +key "Arts:2006:TTS:1159789.1159792" + +\end_inset + +. +\end_layout + +\begin_layout Standard +The entire GGS was not tested using QuickCheck, nor was the entire client + protocol for a game tested using QuickCheck, however the tests performed + using QuickCheck show that an automated testing system such as QuickCheck + is a very viable testing method for the GGS. +\end_layout + +\begin_layout Standard +QuickCheck has features to generate very large and complex tests, the results + of which can be hard to analyze. + The solution to reading these complex test 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 citet +key "Arts:2006:TTS:1159789.1159792" + +\end_inset + +. +\end_layout + +\begin_layout Standard +QuickCheck was originally made for the programming language Haskell. + There are lots of reimplementations of QuickCheck in various programming + languages. + Erlang QuickCheck (EQC) and Triq are two variants of QuickCheck for Erlang. + EQC was chosen for testing the GGS. + Besides the standard functionality that QuickCheck provides, EQC is capable + of testing concurrency within a program. +\end_layout + +\begin_layout 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 Subsubsection +Pong +\change_inserted 260405038 1305573315 + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +I think this section should be somewhere else? +\end_layout + +\end_inset + + +\change_unchanged + +\end_layout + +\begin_layout Standard +Pong is a classic video game released by atari. + Being a real-time game, the game state will be constantly broadcasted to + all the players of a started Pong game in the GGS. + Each time a Pong game has been started and two bots have joined to play, + it should be clearly observable that the number of messages sent from the + server per second has increased and is stable until a later Pong game has + been started with two bots playing. + If the game would have been turn-based, then the game state would only + be broadcasted when a bot has made a turn. + The time for a bot to make a turn would depend on the complexity of the + current situation of the game. + Because the corresponding situation varies as the game progresses, the + time between each broadcasted game state varies also throughout the game. + This would result in making the observations from the robustness test telling + more about the game than the GGS. + +\end_layout + +\begin_layout Standard +Pong is a game that consists of two paddles and a ball. + Each paddle is controlled by a player and the goal of the game is to keep + the ball between the two pads. + If the ball reaches the opposite side of a players pad then that player + loses while the other player scores. + The ball is displayed in the game as a dot and each pad as a short vertical + line. + The pad can only go straight up or straight down. + The ball moves with constant speed in one direction and never changes its + heading before it reaches a pad or the boundary of the game area. + +\end_layout + +\begin_layout Standard +The logic of the bots in the Pong game can be simple and still behave realistic + by watching the ball and moving its pad up or down according to the position + of the ball. + In this way the game logic can be evaluated in constant time so that it + doesn't have a bad effect while measuring robustness. + +\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 in 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 is a Server-Command or a Game-Comman +d. + 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 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 planed 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 +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 use JavaScript as the GDL. + The JavaScript is run through Google V8. + The database module uses Mnesia. +\end_layout + +\begin_layout Standard +During the sessions two measurements were recorded. +\end_layout + +\begin_layout Itemize + +\series bold +Messages per second +\series default + is used to see how many incoming and outgoing messages the server can process + each second. + The results of the messages per second testing are shown for a high demanding + application in figure +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:msg-per-sec-MNESIA" + +\end_inset + +, and for a low demanding application in +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:msg-per-sec-NOMNESIA" + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Latency between server and client +\series default + is used to measure the round-trip time for a message 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 therefore is 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 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 an easy 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 executes a 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