From 20d00ba619855589adcefde723aaa00832d326f4 Mon Sep 17 00:00:00 2001 From: Jeena Paradies Date: Fri, 6 May 2011 17:54:47 +0200 Subject: [PATCH] fixed broken reference --- merge.lyx | 7228 +++++++++++++++++++++++++++++++++++++++++++ not-working.lyx | 7817 +++++++++++++++++++++++++++++++++++++++++++++++ report.lyx | 15 +- working.lyx | 7223 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 22279 insertions(+), 4 deletions(-) create mode 100644 merge.lyx create mode 100644 not-working.lyx create mode 100644 working.lyx diff --git a/merge.lyx b/merge.lyx new file mode 100644 index 0000000..938b4e6 --- /dev/null +++ b/merge.lyx @@ -0,0 +1,7228 @@ +#LyX 2.0 created this file. For more info see http://www.lyx.org/ +\lyxformat 413 +\begin_document +\begin_header +\textclass report +\begin_preamble +\usepackage{indentfirst} +\usepackage{tocloft} +\usepackage{calc} +\date{} +\usepackage[section] {placeins} +\def\myClearpage{% + \ifvmode + \ifnum \@dbltopnum =\m@ne + \ifdim \pagetotal <\topskip + \hbox{}% + \fi + \fi + \fi +% \newpage + \write\m@ne{}% + \vbox{}% + \penalty -\@Mi +} +\def\myCleardoublepage{\myClearpage\if@twoside \ifodd\c@page\else + \hbox{}\if@twocolumn\hbox{}\fi\fi\fi} +\usepackage{morefloats} +\usepackage{graphicx} +\usepackage{subfig} +\usepackage{tocloft} +\renewcommand{\cftchapfont}{\bfseries} +\renewcommand{\cftchappagefont}{\bfseries} +\renewcommand{\cftchappresnum}{Chapter } +\renewcommand{\cftchapnumwidth}{6em} + +\oddsidemargin 0.5in +\textwidth 6in +\topmargin 0.0in +\textheight 8.0in +\setlength\topskip{24pt} +\footskip 0.75in + +\usepackage[compact]{titlesec} + + +\titleformat{\chapter}[display] +{\vskip-8em\normalfont\bfseries} +{\LARGE\raggedright\thechapter} +{14ex} +{\vspace{-20ex}% +\LARGE\raggedleft} +[\vspace{1ex}% +{\titlerule[1pt]}] + +\usepackage[absolute]{textpos} + +\usepackage{fancyheadings} +\pagestyle{fancy} +\lhead{\thechapter} + +\usepackage[hmargin=3cm,vmargin=3.5cm]{geometry} +\usepackage{algorithmic} +\usepackage{listings} + +\usepackage{color} +\definecolor{lightgray}{rgb}{.9,.9,.9} +\definecolor{darkgray}{rgb}{.4,.4,.4} +\definecolor{purple}{rgb}{0.65, 0.12, 0.82} + +\lstdefinelanguage{JavaScript}{ + keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break}, + keywordstyle=\color{blue}\bfseries, + ndkeywords={class, export, boolean, throw, implements, import, this}, + ndkeywordstyle=\color{darkgray}\bfseries, + identifierstyle=\color{black}, + sensitive=false, + comment=[l]{//}, + morecomment=[s]{/*}{*/}, + commentstyle=\color{purple}\ttfamily, + stringstyle=\color{red}\ttfamily, + morestring=[b]', + morestring=[b]" +} + +\lstdefinelanguage{Erlang}{ + keywords={typeof, true, false, catch, return, null, catch, switch, var, if, in, while, do, else, case, break, expose}, + keywordstyle=\color{blue}\bfseries, + ndkeywords={class, export, boolean, throw, implements, import, this,erlv8_vm, erlv8_fun_invocation +,erlv8_object}, + ndkeywordstyle=\color{darkgray}\bfseries, + identifierstyle=\color{black}, + sensitive=false, + comment=[l]{\%}, + morecomment=[s]{/*}{*/}, + commentstyle=\color{purple}\ttfamily, + stringstyle=\color{red}\ttfamily, + morestring=[b]', + morestring=[b]" +} + +\usepackage{float} + +\floatstyle{ruled} +\newfloat{code}{thp}{lop} +\floatname{code}{Code} + +\usepackage{nomencl} +\makenomenclature +\renewcommand{\nomname}{Glossary} +\end_preamble +\use_default_options true +\maintain_unincluded_children false +\language english +\language_package default +\inputencoding auto +\fontencoding global +\font_roman lmodern +\font_sans default +\font_typewriter default +\font_default_family rmdefault +\use_non_tex_fonts false +\font_sc false +\font_osf false +\font_sf_scale 100 +\font_tt_scale 100 + +\graphics default +\default_output_format default +\output_sync 0 +\bibtex_command default +\index_command default +\paperfontsize default +\spacing onehalf +\use_hyperref false +\papersize a4paper +\use_geometry false +\use_amsmath 1 +\use_esint 1 +\use_mhchem 1 +\use_mathdots 1 +\cite_engine natbib_authoryear +\use_bibtopic false +\use_indices false +\paperorientation portrait +\suppress_date false +\use_refstyle 0 +\index Index +\shortcut idx +\color #008000 +\end_index +\paperwidth 11in +\paperheight 8.5in +\leftmargin 1.25in +\topmargin 0in +\rightmargin 1in +\bottommargin 1.7in +\secnumdepth 2 +\tocdepth 2 +\paragraph_separation indent +\paragraph_indentation default +\quotes_language english +\papercolumns 1 +\papersides 1 +\paperpagestyle empty +\tracking_changes false +\output_changes false +\html_math_output 0 +\html_css_as_file 0 +\html_be_strict false +\end_header + +\begin_body + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{textblock*}{ +\backslash +paperwidth}(0mm,40mm) +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{center} +\end_layout + +\begin_layout Plain Layout + + +\backslash +includegraphics[width= +\backslash +paperwidth/2]{graphics/logo} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{center} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{textblock*} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Title +A Reliable Generic Game Server +\end_layout + +\begin_layout Author +Niklas Landin +\begin_inset Newline newline +\end_inset + +Richard Pannek +\begin_inset Newline newline +\end_inset + +Mattias Pettersson +\begin_inset Newline newline +\end_inset + +Jonatan Pålsson +\end_layout + +\begin_layout Abstract +This is the abstract! +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +pagenumbering{roman} +\end_layout + +\begin_layout Plain Layout + + +\backslash +setcounter{page}{3} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +contentsname{Table of Contents} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand{ +\backslash +cfttoctitlefont}{ +\backslash +hfill +\backslash +Large} +\backslash +renewcommand{ +\backslash +cftaftertoctitle}{ +\backslash +hfill} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +cftpartdotsep{6.6} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +cftchapdotsep{6.6} +\end_layout + +\end_inset + + +\begin_inset CommandInset toc +LatexCommand tableofcontents + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Newpage newpage +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +pagenumbering{arabic} +\end_layout + +\begin_layout Plain Layout + + +\backslash +setcounter{page}{1} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Chapter +Introduction +\end_layout + +\begin_layout Standard +Online gaming, and computer gaming in general has become an important part + in many peoples day-to day lives. + A few years ago, computer games were not at all as popular as they are + today. + With the advances in computer graphics and computer hardware today's games + are much more sophisticated then they were in the days of +\emph on +NetHack +\emph default +, +\emph on +Zork, +\emph default +or +\emph on +Pacman. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Zork}}{A textual computer game developed by students at MIT} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Pacman}}{An early graphical computer game developed by Namco} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{NetHack}}{An early computer game developed by the NetHack team, arguably + the oldest computer game still in development} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The early computer games featured simple, or no graphics at all +\begin_inset CommandInset citation +LatexCommand citet +key "nethack:website" + +\end_inset + +. + The games often took place in a textual world, leaving the task of picturing + the world up to the player. + Multiplayer games were not as common as they are today, whereas most games + today are expected to have a multiplayer mode, most early games did not. +\end_layout + +\begin_layout Standard +Since these early games, the gaming industry have become much more influential + in many ways. + Many advanced in computer hardware are thought to come from pressure from + the computer game industry. + More powerful games require more powerful, and more easily available hardware +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Drop a reference to the gaming industry pressuring more advanced hardware +\end_layout + +\end_inset + +. + Due to the high entertainment value of modern computer games, gaming has + become a huge industry, where large amounts of money are invested. + The gaming industry is today, in some places even larger than the motion + picture industry. + +\begin_inset CommandInset citation +LatexCommand citet +key "esa:website,thenumbers:website" + +\end_inset + + +\end_layout + +\begin_layout Standard +Due to the increasing importance of computer gaming, more focus should be + spent on improving the quality of the gaming service. + As more and more computer games are gaining multiplayer capabilities, the + demands for multiplayer networking software rises. + This thesis is about techniques for improving the quality of this networking + software. +\end_layout + +\begin_layout Standard +The reliable generic game server, hereafter known as GGS +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{GGS}}{Generic Game Server, a software for reliably hosting network + games. + The subject of this thesis.} +\end_layout + +\end_inset + +, is a computer program designed to +\emph on +host +\emph default + network games on one or more server computers. + Hosting, in a network software setting, means allowing client software + connect to the server software, for the purpose of utilizing services provided + by the server. + The GGS software provides games as a service, and the clients connecting + to the GGS can play these games on the GGS. +\end_layout + +\begin_layout Standard +The idea of game servers is not new, network games have been played for + decades. + Early, popular examples of network games include the +\emph on +Quake +\emph default + series, or the +\emph on +Doom +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout + +\emph on +Come up w/ better game +\end_layout + +\end_inset + + +\emph default + games. + Newer examples of network games include +\emph on +World of Warcraft +\emph default +, and +\emph on +Counter-Strike +\emph default +. + The difference between the GGS and the servers for these games is that + the servers for Doom, Quake, and the others listed, were designed with + these specific games in mind. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Quake}}{A first person shooter series developed by ID software. + The series consists of four games.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Doom}}{A first person shooter series developed by ID software. + The series consists of three games.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Counter-Strike}}{A multiplayer first person shooter game, popular + in E-Sports.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Counter-Strike}}{A multiplayer first person shooter game, popular + in E-Sports.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Framework}}{A supporting structure, the GGS is a framework for developing + network games} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{First-person shooter}}{A game in which centers around gun combat + from the first person perspective.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{MMORPG}}{Massively multiplayer online role playing game. + An online game with several thousand participants.} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +What GGS does is to provide a +\emph on +generic +\emph default + framework for developing network games. + The framework is generic in the sense that it is not bound to a specific + game. + There are many different types of games, some are inherently more time + sensitive than others, strategy games are examples of games which are not + very sensitive to time delays, first-person shooters however, can be very + sensitive. +\end_layout + +\begin_layout Standard +The generic nature of the GGS allows the creation of many different types + of games, the motivation behind this is to remove the necessity of writing + new game servers when developing new games. +\end_layout + +\begin_layout Standard +The GGS is in addition to being generic, also +\emph on +reliable +\emph default + in the sense that the gaming service provided is consistent and available. + A consistent and available server is a server that handles hardware failures + and software failures gracefully. + In the event of a component breaking within the GGS, the error is handled + by fault recovery processes, thereby creating a more reliable system. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Hardware failiure}}{A failiure in hardware (hard drive, memory, processor +, etc) which causes a system to stop functioning} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Software failiure}}{A failiure in software (the GGS, the operating + system, etc) which causes a system to stop functioning} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Background +\end_layout + +\begin_layout Standard +The game industry is a quickly growing industry where the need for new technique +s are large. + One specific section where the development has stalled is the game server + section. +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + + The existing game servers are functional but they lack good fault tolerance + and the ability to scale well +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + +. + Users will notice this in low uptime and many crashes. + This is a problem that has existed and been resolved in other industries. + In the telecom industry solutions to similar problems have been found. +\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, or roughly +\begin_inset Formula $15ms$ +\end_inset + + downtime in a year +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + +. + The level of instability and bad fault tolerance seen in the game server + industry would not have been accepted in the telecoms 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 can not 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 are monetary, it is important + for game companies to expand its customer base. + Reliable game servers are one improvement that will create a good image + of a company. + In general the downtime of game servers is much higher than the downtime + of telecom system +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed... +\end_layout + +\end_inset + +. + The structure of the system is similar in many ways and it should be possible + to reuse solutions from the telecom system to improve game servers. + +\end_layout + +\begin_layout Standard +In the current state game servers are developed on a per-game basis, in + many cases this seems like a bad solution. + Developers of network game need to understand network programming. + A way to change this is a generic game server which give the game developers + a server which they implement their game towards. + 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 factors key to the development of GGS have been isolated. + Many of these come from the telecom sector. + The factors are +\emph on +scalability, fault tolerance +\emph default +and being +\emph on +generic +\emph default +. + 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 defined as the statistical probability of the system functioni +ng as intended at a given point in time. + Fault tolerance is defined as the property of a system to always follow + a specification, even in the presence of errors. + The specification could take the form of error handling procedures which + activate when an error occurs. + This means that a fault tolerant, dependable system, will have a very high + probability of functioning at a given point in time, and is exactly what + is desired. + +\begin_inset CommandInset citation +LatexCommand citet +key "Gartner:1999:FFD:311531.311532" + +\end_inset + + +\end_layout + +\begin_layout Standard +A generic (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Generic" + +\end_inset + +) game server has to be able to run different client-server network games + regardless of the platform the clients are running on. + It runs network games of different type. + A very rough separation of games is real time games and turn based games. +\end_layout + +\begin_layout Standard +The server behaves in a way similar to an application server, but is designed + to help running games. + 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. +\end_layout + +\begin_layout Standard +The most common type of application servers are web servers, where you run + a web application within the server. + The application server provides an environment and interfaces to the outer + world, in which applications run. + Hooks and helpers are provided to use the resources of the server. + Some examples for web application servers are the +\emph on +Glassfish +\emph default + server which allows running applications written in Java or the +\emph on +Google App Engine +\emph default + where you can run applications written in Python or some language which + runs in the +\emph on +Java Virtual Machine +\emph default +. + An example of an application server not powering web applications, but + instead regular business logic, is Oracle’s +\emph on +TUXEDO +\emph default + application server, which can be used to run applications written in COBOL, + C++ and other languages. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SQL}}{Structured Query Language, a computer language common in querying + certain databases} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{JavaScript}}{A programming language originally developed by Netscape, + common in web programming} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{COBOL}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{C++}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Java}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{AXD301}}{Telephone switch developed by Ericsson} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Erlang}}{A concurrent programming language, often used for telecom + applications. + The main language of the GGS} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +A database server can also be seen as an application server. + Scripts, for example SQL queries or JavaScript, are sent to the server, + which runs them and returns the evaluated data to the clients. + +\end_layout + +\begin_layout Standard +One purpose of this thesis is to investigate how we can make a game server + as generic as possible. + Some important helpers are discussed, such as abstraction of the network + layer, data store and game specific features. + +\end_layout + +\begin_layout Standard +As an aid in discussing the theoretical parts of the GGS a prototype has + been developed. + The prototype does not feature all of 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 implementation language for the prototype of the GGS was made + with inspiration from the telecom industry. + The Erlang language was developed by the 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 is also possibly has the largest code base even written in a + functional language +\begin_inset CommandInset citation +LatexCommand citep +key "Armstrong03" + +\end_inset + +. + The same language is used to develop the prototype of the GGS. + 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 + +. + Chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Implementation-of-a" + +\end_inset + + provides a description of the prototype developed for this thesis. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +We could go on and on about erlang.. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Purpose +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout +The purpose of the GGS project. + What is the purpose of creating a fault tolerant server, why is it generic, + and what good does it do to have a scalable system? In the background, + we should give the motivations behind creating this software, but here + we should outline why the software is needed. + This section should be shortened, and the bulk of the text should be moved + to theory or background. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The purpose of creating a generic and fault tolerant game server is to provide + a good framework for the development of many different types of games. + Allowing the system to scale up and down is a powerful way to maximize + the usage of physical resources. + By scaling up to new machines when load increases, and scaling down from + machines when load decreases costs and energy consumption can be optimized. +\end_layout + +\begin_layout Standard +Fault tolerance is important for the GGS to create a reliable service. + The purpose of a reliable game server is to provide a consistent service + to people using the server. + Going back to the telecom example, the purpose of creating a reliable telecom + system is to allow calls, possibly emergency calls, at any time. + Should the telecom network be unavailable at any time, emergency services + may become unavailable, furthermore the consumer image of the telecom system + degrades. +\end_layout + +\begin_layout Standard +Returning to the game industry, emergency services will not be contacted + using a game server, however an unavailable server will degrade the consumer + 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 can not 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 wrote in different programming + languages, besides 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 decide the feasibility + of a language: +\end_layout + +\begin_layout Itemize +How well it integrates with Erlang, which is used in the core the GGS system + +\end_layout + +\begin_layout Itemize +How easy it is to send messages to the virtual machine of the GDL from the + GGS +\end_layout + +\begin_layout Itemize +How easy it is to send messages from the GDL VM to the GGS +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add more like threads, events, etc. +\end_layout + +\end_inset + + +\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 for use in interacting 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 gaming clients has to take place over 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 large challenge during this project is to decide whether an existing + protocol can be used, and if not, how a new protocol can be designed which + performs technically as desired, while still being familiar enough to existing + developers. +\end_layout + +\begin_layout Standard +A great deal of work is devoted to make the GGS +\emph on +reliable +\emph default +. + This includes ensuring that the system scales well, and to make sure it + is fault tolerant. + In order to facilitate scalability, we need a storage platform which is + accessible and consistent among all of the GGS, this is also investigated. +\end_layout + +\begin_layout Section +Limitations of the prototype +\end_layout + +\begin_layout Standard +The implementation of the GGS protocol, together with storage possibilities, + server capacity, and game language support imposes some limitations on + the project. + To get a functional prototype some limits must be set on the types games + that can be played on the prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{UDP}}{User Datagram Protocol, a connectionless networking protocol} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{TCP}}{Transmission Control Protocol, a streaming network protocol} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The UDP protocol is not supported for communication between client and server. + The TCP protocol was chosen in favor of UDP, due to the fact that the implement +ation process using TCP was faster than if UDP would have been used. + UDP is generally considered to be faster than TCP for the transfer of game + (and other) related data, this is discussed in more depth in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Choice-of-network" + +\end_inset + +. + In short, the decision of using TCP means that games that requires a high + speed protocol will not be supported by the GGS prototype. + Another limitation necessary to set on the system is the possibility to + have huge game worlds due to the implementation of the scaling mechanism + in the prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Latency}}{A measure of delay, often measured in milliseconds} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +In real time games all players are playing together at the same time. + Latency is a huge problem in real time games, a typical round trip time + for such games are one of +\begin_inset Formula $50$ +\end_inset + + to +\begin_inset Formula $150ms$ +\end_inset + + and everything above +\begin_inset Formula $200ms$ +\end_inset + + is reported to be intolerable +\begin_inset CommandInset citation +LatexCommand citet +key "Farber:2002:NGT:566500.566508" + +\end_inset + +. + Latency sensitive games include most of the first person shooters with + multiplayer ability, for example +\emph on +Counter Strike +\emph default + or massively multiplayer online role playing games (MMORPGs), for example + +\emph on +World of Warcraft +\emph default +. +\end_layout + +\begin_layout Standard +In turn based games each player has to wait for their turn. + Latency is not a problem since the gameplay does not require fast interactions + among the players, long round trip times will not be noticed. + Examples of turn based games include board and card games, as well as multiplay +er games like +\emph on +Jeopardy +\emph default +. + Both game types have varying difficulties and needs when it comes to implementi +ng them, a Generic Game Server should address all of them and help the developer + to accomplish his goal. +\end_layout + +\begin_layout Standard +Due to the limited capability of threading in many GDL VM:s, the GGS prototype + will not support MMORPG:s. +\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 + are no need to implement more advanced features in the system. + Note that these limitations only apply for the prototype of the project, + and that further developments to the GGS could be to implement these features. +\end_layout + +\begin_layout Section +Method +\end_layout + +\begin_layout Standard +A prototype was developed early on in the project to carry out experiments. + Using this prototype, the system was divided into modules. + A demand specification was created, using this specification, the modules + were easily identifiable. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Module}}{A part of a larger system} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The first prototype of the GGS consisted of simple modules, however, due + to the separation of concerns among the modules, they were easily independently + modified and improved. + Once the basic structure of the GGS had been established, the first prototype + was removed, remaining was the structure of the modules and the internal + flow of the application. + This could be seen as an iterative workflow, with the first prototype being + the first iteration. + The second iteration later became the final result of the GGS. +\end_layout + +\begin_layout Standard +The layout of the GGS is both layered and modular. + The first layer handles the most primitive data and produces a higher level + representation of the data, passing it along to different modules of the + GGS. + The modular structure of the GGS plays an important role in making the + system fault tolerant. + The approach to fault tolerance is by replication, and restarting the faulting + modules with the last known good data. +\end_layout + +\begin_layout Standard +An informal specification and list of requirements of the system was outlined + early on in the project. + Usability goals for developers were set. + During the project several demo applications were constructed, by constructing + these applications, the usability goals were enforced. +\end_layout + +\begin_layout Chapter +Theory behind the GGS +\begin_inset CommandInset label +LatexCommand label +name "cha:Theory" + +\end_inset + + +\end_layout + +\begin_layout Standard +In this chapter, the theory behind the techniques used in the GGS are discussed. + Performance issues and the measuring of performance is discussed. + Benchmarking techniques are discussed. + The options when choosing network protocols are given, along with a discussion + of each alternative. + Finally, an overview of scalability, fault tolerance and availability are + 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 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 a computer. + The requirements and limitations imposed on the real-world system can, + using the proper tools, be transferred in to the software. +\end_layout + +\begin_layout Standard +The real world system chosen for 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. + Since a real-world scenario is readily available, and to such a large extent + resembles the computer software required for the GGS, the next step in + developing the GGS system is to duplicate this real world scenario in a + software setting. +\end_layout + +\begin_layout Standard +Some requirements, limitations and additions were made to the chess club + system, so that the system would more easily and efficiently be replicated + in a software setting. +\end_layout + +\begin_layout Standard +In the text below, two examples will be presented. + On example is that of a real-world chess club, in which players meet to + play chess against each other, the other example is the GGS, and how it + corresponds to this chess club. + +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/theory_layout.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:theory-layout" + +\end_inset + +The layout of a physical +\begin_inset Quotes eld +\end_inset + +Chess club +\begin_inset Quotes erd +\end_inset + + with two players (P) sitting by each chess table (Table), a coordinator + keeps track of all moves and players in the building. + A player has to pass by the entrance to enter or exit the building. + The building is represented by the outermost box. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +In figure +\begin_inset CommandInset ref +LatexCommand vref +reference "fig:theory-layout" + +\end_inset + + a graphical representation for the chess club is presented. + The club is seen from above. + The outermost box represents the building. + In the GGS setting, the building would represent one instance of GGS. + Several buildings linked together would represent a cluster of GGS instances. + In order for a player (the P symbol in the graphic) to enter the theoretical + chess club, the player must pass by the entrance. + By having each player pass by the entrance, a tally +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Does this mean what I think it does? +\begin_inset Quotes eld +\end_inset + +Räkning +\begin_inset Quotes erd +\end_inset + + ? +\end_layout + +\end_inset + + can be kept, ensuring that there are not too many players within the building. + In the GGS setting, too many players entering would mean too many connections + have been accepted by the GGS system, and that the structure of the system + thus must be modified, adding additional servers. +\end_layout + +\begin_layout Standard +Once a player has been allowed in to the chess club the player is greeted + by the host of the chess club, in the GGS setting represented by the +\emph on +Coordinator +\emph default +, and is seated by a table. + The coordinator keeps track of all the players in the building, and all + moved made by the players. + The information available to the coordinator means that cheating can be + monitored and book keeping can be performed by this entity. +\end_layout + +\begin_layout Standard +Moves by players are made using the tables present in the chess club. + Every game is isolated to a table, just as expected. + This means that communication during a game only has to pass by the players + of that particular game, and the coordinator, making sure that no cheating + takes place. +\end_layout + +\begin_layout Standard +This isolation of the games play an important part in many properties of + the GGS, the isolation means that games can for example be transferred + among different chess clubs, furthermore, if cheating takes place, corruption + can only occur in the particular table where it was found, and can not + 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 a property 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 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 tolerant and generic traits are added to the GGS. + These are not shown in the algorithm, as these traits are tools in making + the algorithm behaves 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 no limits in the GGS on the number + of players connecting, for example. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status collapsed + +\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 played. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Performance +\end_layout + +\begin_layout Standard +There are many ways in which performance could be measured. + For the clients, time and response times are useful measurements in time + critical settings. + In non-time critical settings, the reliability of message delivery may + be an even more important factor than speed. +\end_layout + +\begin_layout Standard +In a first person shooter game, the speed of delivery of messages is essential. + 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 practical results for the prototype is discussed in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Implementation-of-a" + +\end_inset + +. +\end_layout + +\begin_layout Subsection +Performance measurements +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\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 + + +\end_layout + +\begin_layout Standard +How many players can we have on a server? Performance differences between + games? e.g can one game have thousands players on a server and another only + have hundreds? Questions +\end_layout + +\begin_layout Standard +In the current state game servers is coded for each game that needs it, + in many cases this seems like a bad solution. + Developers that want to make a network game need to understand network + programming. + A way to change this is a generic game server which give the game developers + a server which they implement their game towards. + 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. + to be discussed here. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Create a game with several thousand players, see how our server scales, + how can we improve the performance? Sharding isn’t very nice.. + alternatives? Improve the speed of sharding? +\end_layout + +\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 +Choice of network protocol +\begin_inset CommandInset label +LatexCommand label +name "sec:Choice-of-network" + +\end_inset + + +\end_layout + +\begin_layout Standard +There are two main ways in which computer communication over the Internet + usually takes place; TCP, UDP are known network layer protocols and HTTP + is the most prominent application layer protocol. + The transport layer protocols, are commonly used to transport application + layer protocols, such as HTTP. + TCP and UDP can not be used on their own, without an application layer + protocol on top. + Application layer protocols such as HTTP on the other hand needs a transport + layer protocol in order to work. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{HTTP}}{Hyper Text Transport Protocol, a network protocol commonly + used to deliver web pages} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +HTTP +\end_layout + +\begin_layout Standard +Since HTTP is so widely used on the Internet today in web servers, it is + available on most Internet connected devices. + This means that if HTTP is used in the GGS, firewalls will not pose problems, + which is a great benefit. + However, due to the intended usage of HTTP in web servers, the protocol + was designed to be stateless and client-initiated. + In order to maintain a state during a game session using HTTP, some sort + of token would have to be passed between client and server at all times, + much like how a web server works. + These facts combined makes HTTP unsuitable for our purposes, since 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, + and what is said about TCP also applies to HTTP. + +\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 the data transferred is in good shape, some sort of error checking + mechanisms must be implemented. + UDP is a good choice for applications where it is more important that data + arrives in a timely manner than that all data arrives undamaged, it is + thus very suitable for media streaming, for example. + In the GGS reliability of transfer was chosen before the speed of the transfer, + ruling out UDP as the transport later protocol. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Perhaps we should only say that we chose TCP just for our GGS prototype + and why. + If we leave it like that it seems that we think it is not suitable. +\end_layout + +\end_inset + + +\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. + In the GGS, data consistency is more important than transfer speeds, and + thus TCP is a better alternative than UDP. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Same here it is simply not true for a generic server to chose one or the + other. + We should rephrase it so it is clear that we only state it about the GGS + prototype. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Generic +\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 any kind of game. + Any game with a client-server behavior should be perfectly suited for GGS. + 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. + Such as different programming languages. + The GGS should be OS independent and run on Windows, OSX 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 independent hardware. + It is meant to run any game in any environment in any way desired, therefor + being as generic as possible. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Bad name of the chapter, but here we should give the theory of how the server + is generic +\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 +Fault tolerance is an important factor in all servers, a server that is + fault tolerant should be able to follow a given specification when parts + of the system failures. + This means that fault tolerance is different in each system depending on + what specification they have. + A system could be fault tolerant in different aspects, one is where the + system is guaranteed to be available but not safe and it could also be + reversed, that the system is safe but not guaranteed to be available. + Depending on the system one property may be more important(some example + here). + A system could also have non existent fault tolerance or it could be both + safe and guaranteed to be available. + 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 but it has features that + support and encourage the development of fault tolerant systems. + In the GGS it is important that the system overall is fault tolerant. + Crashes of the whole system should be avoided as this would make the system + unusable for a time. + By using supervisor structures it is possible to crash and restart small + parts of the system, this is convenient as fault can be handled within + small modules thus never forcing a crash of the system. +\end_layout + +\begin_layout Standard +The need for fault tolerance in game servers is not as obvious as it may + be for other type of servers. + In general all servers strive to be fault tolerant as fault tolerance means + more uptime and a safer system. + This applies to game servers as well, in brief good fault tolerance is + a way of satisfying customers. + In general, game servers differ from many other fault tolerant systems + in that high-availability is more important than the safety of the system. + For example a simple calculation error will not be critical for a game + server but it may be in a life-critical system and then it is better that + the system crashes than works with the faulty data. + There are cases where safety may be critical in game servers, one example + is in games where in-game money exist. +\end_layout + +\begin_layout Subsubsection +Performance penalties +\end_layout + +\begin_layout Section +Availability +\begin_inset CommandInset label +LatexCommand label +name "sec:Availability" + +\end_inset + + +\end_layout + +\begin_layout Standard +One important factor of any server is the availability. + A server to which you are unable to connect to is an useless server. + Other then within telecommunication, their uptime is of about 99,9999999%, + the game developer community has not approached this problem very genuinely + yet so there is much room for improvement. +\end_layout + +\begin_layout Standard +There are several good papers on how to migrate whole virtual machines among + nodes to replicate them +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add more information about that +\end_layout + +\end_inset + + but for the GGS a different approach has been chosen. + Instead of just duplicating a virtual machine, the programming language + Erlang has been used which offers several features to increase the availability. + Some of them are +\emph on +hot code replacement +\emph default +, where code can be updated while the application is running and without + the need to restart it, the +\emph on +supervisor structure +\emph default + provided by +\emph on +OTP +\emph default + and the inter node and process communication via +\emph on +messages +\emph default + instead of shared memory. + We will discuss each of them later on. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Supervisor}}{A process monitoring and hadning crashes in other processes} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Scalability +\begin_inset CommandInset label +LatexCommand label +name "sec:Scalability" + +\end_inset + + +\end_layout + +\begin_layout Standard +Each instance of the GGS contains several tables. + Each table is an isolated instance of a game, for example a chess game + or a poker game. + The way that the GGS scales is to distribute these tables on different + servers. + In many games it is not necessary for a player to move among tables during + games. + This is for example not a common occurrence in chess, where it would be + represented as a player standing up from her current table and sitting + down at a new table, all within the same game session. + Therefore, the main focus of the GGS is not to move players among tables, + but to keep a player in a table, and to start new tables instead. + When a server has reached a certain number of players the performance will + start to decrease. + 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 and find out how many players that are optimal + for each server. + This approach makes it possible to use all resources with moderate load, + instead of having some resources with heavy load and some with almost no + load. +\end_layout + +\begin_layout Standard +As mentioned in the purpose section there are two different types of scalability +, structural scalability and load scalability. + To make the GGS scalable both types of scalability are needed. + Structural scalability means in our case that it should be possible to + add more servers to an existing cluster of servers. + By adding more servers the limits of how many users a system can have is + increased. + Load scalability in contrast to structural scalability is not about how + to increase the actual limits of the system. + Instead it means how good the system handles increased load. + The GGS should be able to scale well in both categories. +\end_layout + +\begin_layout Subsection +Load balancing +\end_layout + +\begin_layout Standard +The need for load balancing varies among different kind of systems. + Small systems that only use one or a couple of servers can cope with a + simple implementation of it, while in large systems it is critical to have + extensive and well working load balancing. + The need also depends on what kind of server structure that the system + works on. + A static structure where the number of servers are predefined or a dynamic + structure where the number varies. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Amazon EC2}}{A cloud computation service} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Load balancing and scaling is difficult in different scenarios. + When running in a separate server park, there are a set number of servers + available, this means that an even distribution on all servers is preferable. + When running the GGS in a cloud, such as Amazon EC2, it is possible to + add an almost infinite number of servers as execution goes on. + 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 load + becomes too high on all of them, then comes a new problem: +\end_layout + +\begin_deeper +\begin_layout Itemize +How do we distribute load on these new servers? +\end_layout + +\end_deeper +\begin_layout Standard +Load balancing is a key component to achieve scalability in network systems. + The GGS is a good example of a system that needs to be scalable, to attain + this load balancing is necessary. + Optimization of the load balancing for a system is an important task to + provide a stable and fast load balancer. + There are certain persistence problems that can occur with load balancing, + if a player moves from a server to another data loss may occur. + This is an important aspect to consider when the load balancer is designed + and implemented. +\end_layout + +\begin_layout Standard +Load balancing can often be implemented using dedicated software, this means + that in many applications load balancing may not be implemented because + it already exist functional solutions. + This depends on what specific needs the system have and a minor goal of + the project is to analyze whether the GGS project can use existing load + balancing tools or if it is necessary 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 + + +\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 +\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 +Inside the GGS, everything has a unique identifier. + There are identifiers for players, tables and other resources. + When players communicate amongst each other, or communicate with tables, + they need to be able to uniquely identify all of these resources. + Within one machine, this is mostly not a problem. + A simple system with a counter can be imagined, where each request for + a new ID increments the previous identifier and returns the new identifier + based off 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 lock, which may work well in many concurrent systems. + In a distributed system, this lock, along with the state, would have to + be distributed. + If the lock is not distributed, no guarantee can be made that two nodes + in the distributed system do not generate the same number. + 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. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{MAC Address}}{Media Access Control address, used to identify network + cards} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SHA-1}}{Cryptigraphic hash function, designed by the National Security + Agency (NSA)} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +According to +\begin_inset CommandInset citation +LatexCommand citet +key "Leach98uuidsand" + +\end_inset + +, +\begin_inset Quotes eld +\end_inset + +A UUID is 128 bits long, and if generated according to the one of the mechanisms + in this document, is either guaranteed to be different from all other UUIDs/GUI +Ds generated until 3400 A.D. + or extremely likely to be different +\begin_inset Quotes erd +\end_inset + +. + This 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 + ID:s. + The gathered data is then +\emph on +hashed +\emph default + +\begin_inset space ~ +\end_inset + +using an algorithm such as SHA-1. +\end_layout + +\begin_layout Standard +When using system wide unique identifiers, such as the ones generated by + algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + + with mutual exclusion, it is not possible to have identifier collisions + when recovering from network splits between the GGS clusters. + Consider figure +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:network-split" + +\end_inset + +, where +\emph on +Site A +\emph default + is separated from +\emph on +Site B +\emph default + by a faulty network (illustrated by the cloud and lightening bolt). + 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 ID:s 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 UUID:s solve. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Network split}}{Separation of two networks, occurs when two networks + can not communicate, commonly because of a hardware or software failiure} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/netsplit2.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add clients on each side, and replace the cloud with pole-landlines being + cut by a pair of scissors +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:network-split" + +\end_inset + +An example of a network split +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Security +\end_layout + +\begin_layout Standard +We only support languages running in a sandboxed environment. + Each game session is started in its own sandbox. + The sandboxing isolates the games in such a way that they can not interfere + with each other. + If sandboxing was not in place, one game could potentially modify the contents + of a different game. + A similar approach is taken with the persistent storage we provide. + In the storage each game has its own namespace, much like a table in a + relational database. + A game is not allowed to venture outside this namespace, and can because + this not modify the persistent data of other games. + of 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 Subsection +Encryption +\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 +There is only a very limited number of game developers who would like to + write their games in Erlang, therefore we had to come up with something + to resolve this problem. + The main idea was to offer a replaceable module which would introduce a + 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 of + its advantages. +\end_layout + +\begin_layout Subsection +JavaScript +\end_layout + +\begin_layout Standard +JavaScript has gained a lot of popularity lately, it is used in large projects + such as +\emph on +Riak +\emph default + +\begin_inset Foot +status open + +\begin_layout Plain Layout +\begin_inset Flex URL +status collapsed + +\begin_layout Plain Layout + +http://wiki.basho.com/An-Introduction-to-Riak.html +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +, +\emph on +CouchDB +\emph default + +\begin_inset Foot +status open + +\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 open + +\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. + The popularity of JavaScript in the programming community, in combination + with the availability of several different JavaScript virtual machines + was an important influence in choosing JavaScript as the main control language + for our GGS prototype. +\begin_inset ERT +status 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 +, +\emph on +ActionScript +\emph default + are suitable as well because 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 our 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. +\end_layout + +\begin_layout Standard +Due lack of time we have decided to use just the Erlang <-> JavaScript bridge + with our interface. +\end_layout + +\begin_layout Section +Testing +\end_layout + +\begin_layout Standard +There are several ways in which the GGS can be tested. + The most important aspect has been deemed to be the experience players + have when using the GGS. + In order 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 need not participate in the same instance of the game, games + such as chess are prime candidates for the GGS. +\end_layout + +\begin_layout Standard +When developing the GGS, two main categories of games exhibiting different + performance demands were identified; real-time games and turn-based games. + The real-time games were deemed more demanding than the turn based games. + Tests were carried out using a real time game, since this is the more demanding + type of games. +\end_layout + +\begin_layout Standard +The real time game chosen for testing the GGS is +\emph on +Pong +\emph default +, a game in which two players play a game involving a all 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 quite 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 were performed on the GGS, and the results of these tests + are visible in chapter +\begin_inset CommandInset ref +LatexCommand ref +reference "chap:Results-and-discussion" + +\end_inset + +. + The tests were initially performed by starting an operating system process + for each player. + Due to lack of hardware, not enough player processes could be started in + this way. + The bots were re-written in Erlang, and due to Erlang's light weigh threads, + enough processes could be created to successfully test the server. +\end_layout + +\begin_layout Chapter +Implementation of a prototype +\begin_inset CommandInset label +LatexCommand label +name "cha:Implementation-of-a" + +\end_inset + + +\end_layout + +\begin_layout Standard +This chapter contains the realization of much of the principles and techniques + described in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Theory" + +\end_inset + +. + Here the problems and their solutions are discussed in greater detail, + and at times the text becomes more specific to GGS. +\end_layout + +\begin_layout Standard +Much of what is discussed in this chapter has been implemented in the Erlang + GGS prototype. + Specific solutions such as +\emph on +supervisor structures +\emph default +and distribution of erlang nodes on physical nodes. + The different means of communications within the GGS and outside the GGS + with third parties are also discussed here. +\end_layout + +\begin_layout Section +Overview of the prototype +\end_layout + +\begin_layout Standard +The prototype of the GGS was developed using the Erlang language. + The functional and concurrent style of Erlang facilitates development of + software based on a real-world model +\begin_inset CommandInset citation +LatexCommand citep +key "armstrong2011" + +\end_inset + +. + In Erlang, most things are processes. + The software running the Erlang code is known as the Erlang machine, or + an Erlang node. + Each Erlang node is capable of running several +\emph on +threads +\emph default +(also known as +\emph on +Light Weight Processes; LWP +\emph default +) +\emph on +, +\emph default +much like the threads in an operating system. + Threads in a Linux system, for example, are treated much like operating + system processes in different systems. + Due to the size of data structures related to each process, swapping one + process for another (known as +\emph on +context switching +\emph default +) is an expensive task in many systems +\begin_inset CommandInset citation +LatexCommand citep +after "pg 80" +key "McKusick:2004:DIF:1014910" + +\end_inset + +. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{LWP}}{Light Weight Process} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Context switch}}{The act of switching from one context, commonly + a process, to another. + Used by operating systems to achieve multi tasking} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The cost of swapping operating system processes becomes a problem when many + processes are involved. + If the GGS system had been developed using regular operating system processes, + it would have had to be designed in a way to minimize the number of processes. + Using Erlang, which is capable of running very many processes, several + times more than an operating system can, the mapping between the real world + system (described in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Design-of-the" + +\end_inset + +) becomes clearer. +\end_layout + +\begin_layout Standard +Erlang allows the GGS to create several process for each player connecting, + these processes can handle a multitude of different tasks, parsing data + for example. + Since each task is handled by a different process, the tasks are clearly + separated and the failure of one is easily recovered without affecting + the others. +\end_layout + +\begin_layout Standard +In addition to creating (or +\emph on +spawning +\emph default +) processes specifically to handle new players connecting, the GGS has more + permanent processes running at all times. + The constantly running processes in the GGS system are called +\emph on +modules +\emph default +. + An example of a module in the GGS is the +\emph on +dispatcher module +\emph default +, which handles the initial connection made by a client, passing the connection + along further in to the system. +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/Chess_no_text.eps + width 100text% + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:The-layout-of" + +\end_inset + +The layout of the GGS. + The circles marked with 'C' topmost in the picture represent clients. + The cloud marked 'network' pictured directly below the clients can be any + network, for example the Internet. + The barell figure marked 'backup' is a process being fed backup data from + the coordinator. + The barell 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 gamers + machines will be chess game clients. + Clients connect through a network, pictured as a cloud, to the dispatcher + process in the GGS. + The dispatcher process and all other modules are discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:The-modular-structure" + +\end_inset + +. + For each connection, a new player process is spawned, which immediately + after spawning is integrated in to the GGS by the coordinator process. +\end_layout + +\begin_layout Section +The usage of Erlang in the GGS +\begin_inset CommandInset label +LatexCommand label +name "sec:The-usage-of-erlang" + +\end_inset + + +\end_layout + +\begin_layout Standard +Erlang was designed by Ericsson, beginning in 1986, for the purpose of creating + concurrent applications and improving telecom software. + Features essential for the telecom industry to achieve high availability + in telecom switches were added to the language. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Mutex}}{A construct for achieving mutial exclusion, used to avoid + simultaneous access to shared resources in computer systems} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Erlang uses message passing in favor of shared memory, mutexes and locks, + something which at the time was controversial among fellow developers +\begin_inset CommandInset citation +LatexCommand citet +key "Armstrong:2010:ERL:1810891.1810910" + +\end_inset + +. + The reason for using message passing, according to Armstrong, was that + applications should operate correctly before optimizations are done, where + efficient internal communication within the Erlang machine was considered + a later optimization. +\end_layout + +\begin_layout Standard +In using message passing in favor of the methods commonly used at the time, + the issues commonly associated with shared memory and locking were avoided. + In Erlang, everything is a process, and everything operates in its own + memory space. + Memory can not be shared among processes, which prohibits a process from + corrupting the memory of a different process. +\end_layout + +\begin_layout Standard +Messages are sent between the processes in an asynchronous manner, and each + process has a mailbox in which these messages can be retrieved. +\end_layout + +\begin_layout Standard +Processes in Erlang are also called +\emph on +Light Weight Processes. + +\emph default +The Erlang processes are very cheaply created. + Processes exist within an Erlang machine, or Erlang node. + The Erlang machine has its own scheduler and does not rely on the operating + system's scheduler, this is a main reason of Erlang's capability of running + many concurrent processes +\begin_inset CommandInset citation +LatexCommand citet +key "Armstrong03" + +\end_inset + +. +\end_layout + +\begin_layout Standard +The strong isolation of Erlang processes make them ideal for multi-core + and distributed systems. + Distribution of software is included as a fundamental part in the Erlang + language. + The 'physical' location of a process, e.g. + which computer the process runs on, is not important when communicating + with the process. + Processes can communicate regardless of whether they run on the same system + of not, transparently. +\end_layout + +\begin_layout Standard +The distributed nature of Erlang is something the GGS makes use of when + scaling across several computers in order to achieve higher performance. + The distribution is also important in creating redundancy. + Erlang promotes a non-defensive programming style in which processes are + allowed to crash and be restarted in favor of having the processes recover + from errors. + The distributed nature of Erlang means supervisor processes (discussed + in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Supervisor-structure" + +\end_inset + +) can reside on remote systems, thereby increasing the reliability of the + system as a whole. +\end_layout + +\begin_layout Standard +A very important feature of Erlang, used in the GGS, is the ability to interface + with external hardware and software. + Erlang allows communication with external resources through +\emph on +ports +\emph default + and +\emph on +NIF +\emph default +:s (Native implemented functions) +\emph on +. + +\emph default + Through ports communication can take place much in the same way communication + is performed over sockets. + NIF:s are called like any other functions without any difference to the + caller but are implemented in C. +\end_layout + +\begin_layout Standard +The GGS uses Erlang ports for generating UUID:s +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +UUID:s are discussed in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:UUID" + +\end_inset + + +\end_layout + +\end_inset + + and NIF:s for interfacing with the virtual machines of games +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +Virtual machines of games are discussed in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Game-Development-Language" + +\end_inset + + +\end_layout + +\end_inset + +. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{OTP}}{Open Telecom Platform, a software suite for Erlang} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Behaviour}}{A design pattern in OTP} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Development of the GGS would have been hard if not impossible had it not + been for the +\emph on +OTP +\emph default + supplied with the standard Erlang distribution. + The OTP (Open Telecom Platform) is a set of standard libraries and design + patterns, called +\emph on +behaviors +\emph default +, which are used when developing Erlang systems. +\end_layout + +\begin_layout Standard +The GGS makes heavy use of the behaviors supplied in the OTP. + The behaviors impose a programming style suitable for distributed and concurren +t applications, perfectly suitable for the GGS. + In particular, the GGS uses the following behaviors: +\end_layout + +\begin_layout Itemize +The +\emph on +supervisor +\emph default + behavior, which is used when creating a supervisor. + Supervisors are used when monitoring processes in the Erlang system. + When a process exits wrongfully, the supervisor monitoring the process + in question decides which action to take. + In the GGS, the most common action is simply to restart the faulting process. + A more thorough discussion on supervisors can be found in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Supervisor-structure" + +\end_inset + +. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_tcp +\emph default +behavior, which is used to work with TCP sockets for network communication. + Using the gen_tcp behavior, network messages are converted to internal + Erlang messages and passed to a protocol parser, where the messages are + processed further. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_server +\emph default + behavior, which is used when constructing OTP servers in Erlang. + Using this behavior, a state can easily be kept in a server process, greatly + increasing the usefulness of the server process. + There are many gen_servers in the GGS, it is the most widely used behavior + in the project. + In addition to introducing a state to the server, the gen_server behavior + also imposes patterns for synchronous and asynchronous communication between + other gen_servers and other OTP behaviors. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_fsm +\emph default + behavior is used in the protocol parser module in the GGS. + Using the gen_fsm behavior, finite state machines are easily developed. + Protocol parsers are an ideal example of where to use finite state machines, + which are widely used for parsing strings of text. +\end_layout + +\begin_layout Standard +In addition to supplying behaviors, the OTP also has a style for packaging + and running Erlang applications. + By packaging the GGS as an +\emph on +application +\emph default +the GGS can be started in a way uniform to most erlang software, providing + familiarity for other Erlang users, and eases the incorporation of the + GGS in other applications. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Application}}{A way of packaging Erlang software in a uniform way} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Short introduction to the Erlang syntax +\end_layout + +\begin_layout Standard +In order to understand examples in this thesis, a small subset of Erlang + must be understood. + In this section, the very syntactic basics of Erlang are given. +\end_layout + +\begin_layout Itemize + +\series bold +Variables +\series default + start with an uppercase letter, examples include +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt X, Var}, and { +\backslash +tt Global} +\end_layout + +\end_inset + +. + A variable can only be assigned once. +\end_layout + +\begin_layout Itemize + +\series bold +Atoms +\emph on + +\series default +\emph default +start with lower case letters, for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + + { +\backslash +tt atom, a} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Functions +\series default + are defined starting with an atom for the name, parenthesis containing + parameters, an arrow, a function body and finally a dot marking the end + of a function. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt square(X) -> X*X.} +\end_layout + +\end_inset + + is an example of a function producing the square of X. +\end_layout + +\begin_layout Itemize +Functions are +\series bold +called +\series default + by suffixing an atom with the function name with parenthesis, for example + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt square(10)} +\end_layout + +\end_inset + +. + Qualified names can be specified using ':', for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt math:square(10)} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Tuples +\series default + are containers of fixed type for Erlang data types. + They are constructed using curly brackets, for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt +\backslash +{atom1, atom2, atom3 +\backslash +}}. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Itemize + +\series bold +Lists +\series default + are constructed using [ and ], for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt [1,2,3]} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Strings +\series default + doubly quoted lists of characters, for example +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt "Hello world"} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Records +\series default + are erlang tuples coupled with a tag for each tuple element. + This allows referring to elements by name instead of by position. + An example of a record looks like this: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt +\backslash +#myRecord{}} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Section +Communication with external systems and applications +\begin_inset CommandInset label +LatexCommand label +name "sec:Communication-with-external" + +\end_inset + + +\end_layout + +\begin_layout Standard +A game launched on the GGS is run within a virtual machine. + For each programming language supported, there is a virtual machine that + interprets the game. + Furthermore an interface for communication between the GGS, the game and + the players playing the game must be present. +\end_layout + +\begin_layout Standard +The reason for the GGS requiring a communication channel between the game + VM and Erlang is in part because the GGS makes heavy use of callbacks. + 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 between players. + The interface provides access to three objects called +\emph on +world +\emph default +, +\emph on +player +\emph default + and +\emph on +localstorage +\emph default +. + The game state is safely stored in a database and retrieved for manipulation + by a call for the world object. + Interaction with the players is done the same way using the player object + instead. + The localstorage is a convenient way to store global data and other data + separated from the game state. + In section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Exposing-Erlang-functionality" + +\end_inset + + a concrete example of the implementation of the localstorage and world + objects is given. +\begin_inset Note Note +status open + +\begin_layout Plain Layout + Unique id:s called gametokens are generated for hosted games so that they + are not mixed up. + -- good text, integrate more. +\end_layout + +\end_inset + + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{WebStorage}}{A new standard for letting websites store data on visitors' + computers} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Exposing Erlang functionality to the GDL VM +\begin_inset CommandInset label +LatexCommand label +name "sub:Exposing-Erlang-functionality" + +\end_inset + + +\end_layout + +\begin_layout Standard +This section contains a concrete example of how the localstorage and world + objects are exposed to a GDL VM. + The example comes from the GGS prototype, which uses JavaScript powered + by Google V8 as its GDL VM. +\end_layout + +\begin_layout Standard +The code given in +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:exposing-erlang" + +\end_inset + + is specific to V8 and JavaScript, however implementations for different + GDL:s, or different JavaScript VM:s should be similar. +\end_layout + +\begin_layout Standard +In JavaScript is is common to use a top level object, called a global object, + to establish a global scope. + This allows declaration of global variables and functions. + To gain access to the global object in the GGS, the +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt erlv8 +\backslash +_vm:global(..)} +\end_layout + +\end_inset + + function on line 2 of the example is used. + Using the global object, declarations of the world and GGS object can be + placed in the global scope. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt Global:set +\backslash +_value(..)} +\end_layout + +\end_inset + + is a call to the global object, declaring new objects in the global scope. + On line 4 the GGS object is declared. + By accessing +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt GGS.localStorage } +\end_layout + +\end_inset + + from within the GDL, access to the localstorage is provided, thus the localstor +age must be connected to the GGS object, this can be seen in line 5. +\end_layout + +\begin_layout Standard +Both the GGS and localstorage objects are dummy objects, which provide no + functionality, these two objects are simply placed in the GDL for the purpose + clearing up the code. + In order to perform an action using the GGS and localstorage objects, the + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt getItem} and { +\backslash +tt setItem} +\end_layout + +\end_inset + + functions must be used. + These items are directly connected to the database module of the GGS, which + is discussed in more detail in +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:The-database-module" + +\end_inset + +. +\end_layout + +\begin_layout Standard +Similarly the functions +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt sendCommand, sendCommandToAll} and { +\backslash +tt setTimeout} +\end_layout + +\end_inset + + are directly connected to a piece of code in the GGS which performs the + desired action. + The +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt sendCommand} +\end_layout + +\end_inset + + functions are used to send commands or text to participants of the table. + The +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt setTimeout} +\end_layout + +\end_inset + + function introduces timeouts to the V8 engine, which are not available + per default. +\end_layout + +\begin_layout Standard +\begin_inset 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", fund(#erlv8_fun_invocation{}, [Time, Function])-> +\end_layout + +\begin_layout Plain Layout + + timer:apply_after(Time, ?MODULE, call_js, [GameVM, Function]) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])). +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:exposing-erlang" + +\end_inset + +An example of how Erlang functionality is exposed to a Javascript GDL +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +TODO: Go in to more detail about how the world, player and localstorage + objects are implemented. + Also discuss localstorage and how it derives from the webstorage standard + in detail. + This is a great point on how we try to follow standards. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +My idea here is that we describe the erlang-js (which failed, but nonetheless), + v8, UUID and other external communication. + We shouldn't describe sockets here though.. + or.. + maybe? +\end_layout + +\begin_layout Plain Layout +Also discuss how we allow GDLs to communicate with Erlang, this is +\begin_inset Quotes eld +\end_inset + +external +\begin_inset Quotes erd +\end_inset + + to three GDL. + Discuss the GGS world object (there is a reference to this secxtion for + that purpose) +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +The modular structure of the GGS prototype +\begin_inset CommandInset label +LatexCommand label +name "sec:The-modular-structure" + +\end_inset + + +\end_layout + +\begin_layout Standard +The separation of concerns, and principle of single responsibility +\begin_inset Foot +status open + +\begin_layout Plain Layout +More information on the SRP is available at: +\begin_inset CommandInset href +LatexCommand href +target "http://www.objectmentor.com/resources/articles/srp.pdf" + +\end_inset + + +\end_layout + +\end_inset + + are widely respected as good practices in the world of software engineering + and development. + By dividing the GGS up into modules each part of the GGS can be modified + without damaging the rest of the system. +\end_layout + +\begin_layout Standard +The responsibility and concern of each module comes from the responsibility + and concern of the real-world entity the model represents. + The modeling of the GGS after a real world system was discussed in chapter + +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Theory" + +\end_inset + +. +\end_layout + +\begin_layout Standard +In the text below the word module refers to the actual code of the discussed + feature, while the word process is used when referring to a running instance + of the code. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SRP}}{Single Responsibility Principle} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Object Oriented Programming}}{A programming paradigm focusing on + objects} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +The dispatcher module +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +The discussion of the modules is divided into the following parts: +\end_layout + +\begin_layout Itemize +What does the module do? +\end_layout + +\begin_layout Itemize +What happens when the module fails? +\end_layout + +\begin_layout Itemize +How does the module correspond to the real-world scenario of the chess club? +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The dispatcher module is the first module to have contact with a player. + When a player connects to the GGS, it is first greeted by the dispatcher + module, which sets up an accepting socket for each player. + +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout +Is this the proper way to day the dispatcher greets connecting players? +\end_layout + +\end_inset + + The dispatcher is the module which handles the interfacing to the operating + system when working with sockets. + Operating system limits concerning the number of open files, or number + of open sockets are handled here. + The operating system limits can impose problems on the GGS, this is discussed + more in detail in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Problems-of-implementation" + +\end_inset + +. +\end_layout + +\begin_layout Standard +Should the dispatcher module fail to function, no new connections to the + GGS can be made. + In the event of a crash in the dispatcher module, a supervisor process + immediately restarts the dispatcher. + There exists a window of time between the crashing of the dispatcher and + the restarting of the dispatcher, this window is very short, and only during + this window is the GGS unable to process new connection requests. + Due to the modular structure of the GGS, the rest of the system is not + harmed by the dispatcher process not functioning. + The process does not contain a state, therefore a simple restart of the + process is sufficient in restoring the GGS to a pristine state after a + dispatcher crash +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Well.. + In theory.. +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Standard +Returning to scenario of the chess club, the dispatcher module is the doorman + of the club. + When a player enters the chess club, the player is greeted by the doorman, + letting the player in to the club. + The actual letting in to the club is in the GGS represented by the creation + of a player process discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-player-module" + +\end_inset + +. + The newly created player process is handed, and granted rights to, the + socket of the newly connected player. +\end_layout + +\begin_layout Subsection +The player module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-player-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +The player module is responsible for representing a player in the system. + Each connected player has its own player process. + The player process has access to the connection of the player it represents, + and can communicate with this player. + In order to communicate with a player, the data to and from the player + object must pass through a protocol parser module, discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-protocol-parser" + +\end_inset + +. + Raw communication, without passing the data through a protocol parser is + in theory possible, but is not useful. +\end_layout + +\begin_layout Standard +In the creation of a player process, the coordinator process, discussed + in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-coordinator-module" + +\end_inset + +, is notified by the newly connected process. +\end_layout + +\begin_layout Standard +In the event of a crash in a player process, several things happen. + +\end_layout + +\begin_layout Enumerate +The player process, which is the only process with a reference to the socket + leading to the remote client software, passes this reference of the socket + to the coordinator process temporarily. +\end_layout + +\begin_layout Enumerate +The player process exits. +\end_layout + +\begin_layout Enumerate +The coordinator spawns a new player process, with the same socket reference + as the old player process had. +\end_layout + +\begin_layout Enumerate +The player process resumes operation, immediately starting a new protocol + parser process, and begins to receive and send network messages again. +\end_layout + +\begin_layout Standard +The window of time between the crash of the player process and the starting + of a new player process is, as with the dispatcher, very short. + Since the connection changes owners for a short period of time, but is + never dropped, the implications of a crash are only noticed, at worst, + as choppy gameplay for the client. + Note however that this crash recovery scheme is not implemented in the + GGS prototype. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Can we do this..? Seems a bit sneaky. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Moving back to the real world example, the player process represent an actual + person in the chess club. + When a person sits down at a table in the chess club, the person does so + by requesting a seat from some coordinating person, and is then seated + by the same coordinator. + Once seated, the player may make moves on the table he or she is seated + by, this corresponds clearly to how the GGS is structured, as can be seen + in the following sections. +\end_layout + +\begin_layout Subsection +The protocol parser module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-protocol-parser" + +\end_inset + + +\end_layout + +\begin_layout Standard +The protocol parser is an easily interchangeable module in the GGS, handling + the client-to-server, and server-to-client protocol parsing. + In the GGS prototype, there is only one protocol supported, namely the + +\emph on +GGS Protocol +\emph default +. + The role of the protocol parser is to translate the meaning of packets + sent using the protocol in use to internal messages of the GGS system. + The GGS protocol, discussed below is used as a sample protocol in order + to explain how protocol parsers can be built for the GGS. +\end_layout + +\begin_layout Subsubsection +The structure of the GGS Protocol +\begin_inset CommandInset label +LatexCommand label +name "sub:The-structure-of" + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS protocol is modeled after the HTTP protocol. + The main reason for this is the familiarity many developers already have + with HTTP due to its presence in internet software. + Each GGS protocol packet contains a headers section. + The headers section is followed by a data section. + In the headers section, parameters concerning the packet is placed. + In the data section, the actual data payload of the packet is placed. +\end_layout + +\begin_layout Standard +There is no requirement of any specific order of the parameters in the headers + section, however the data section must always follow directly after the + headers section. +\end_layout + +\begin_layout Standard +In the example below, line 1 contains a Game-Command parameter. + This parameter is used to determine which game-specific command the client + is trying to perform. + The handling of this parameter is specific to each game, and can be anything. +\end_layout + +\begin_layout Standard +Line 2 specifies a game token. + This is a UUID which is generated for each client upon authentication with + the GGS. + The GGS uses this token in case a client is disconnected and the new connection + created when the client reconnects must be re-paired with the player object + inside the GGS. + The UUID is also used as a unique ID within GDL VMs. +\end_layout + +\begin_layout Standard +Line 3 specifies the content type of the payload of this particular packet. + This parameter allows the GGS to invoke special parsers, should the data + be encoded or encrypted. + When encryption is employed, only the payload is encrypted, not the header + section. + This is a scheme which does not allow for strong encryption, but is deemed + feasible for gaming purposes. +\end_layout + +\begin_layout Standard +Line 4 specifies the content length of the payload following immediately + after the headers section. +\end_layout + +\begin_layout Standard +The parser of the GGS protocol implemented in the GGS prototype is designed + as a finite state machine using the gen_fsm behavior. + When a full message has been parsed by the parser, the message is converted + into the internal structure of the GGS messages, and sent in to the system + from the protocol parser using message passing. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Packet below is not an algorithm, but I don't know how to change that label.. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting} +\end_layout + +\begin_layout Plain Layout + +Game-Command: chat +\end_layout + +\begin_layout Plain Layout + +Token: e30174d4-185e-493b-a21a-832e2d9d7a1a +\end_layout + +\begin_layout Plain Layout + +Content-Type: text +\end_layout + +\begin_layout Plain Layout + +Content-Length: 18 +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + +Hello world, guys! +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-sample-packet" + +\end_inset + +A sample packet sent from a client to the GGS during a chat session +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Mention that the protocol is heavily influenced bye HTTP, is parsed using + a FSM, perhaps give a sample packet. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +The coordinator module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-coordinator-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +The coordinator module is responsible for keeping track of all players, + their seats and tables. + Players register with the coordinator process when first connecting to + the server, and the coordinator places each player by their respective + table. +\end_layout + +\begin_layout Standard +The coordinator keeps mappings between each player and table, therefore + it is used to perform lookups on tables and players to find out which are + connected. + The connectivity of players and tables is important when sending messages + to all participants in a game. + A lookup in the coordinator process is performed prior to notifying all + players in a game to ensure the message reaches all players. + The lookup can be performed either using internal identification codes + or using the UUID associated with each client and table. +\end_layout + +\begin_layout Standard +The coordinator process contains important state, therefore a backup process + is kept at allt times. + All good data processed by the coordinator is stored for safekeeping in + the backup process as well. + Data which is potentisally harmful is not stored in the backup process. +\end_layout + +\begin_layout Standard +Upon a crash, the coordinator process recovers the prior good state from + the backup process and continues where it left off. + A supervisor process monitors the coordinator process and restarts the + process when it malfunctions. + There is a window of time between the crash of the coordinator and the + restarting of the coordinator, during this time, players can not be seated + by new tables, and can not disconnect from the server. + This window of time is very small, and the unavailability of the coordinator + process should not be noticed by more than a short time lag for the clients. +\end_layout + +\begin_layout Standard +Moving back to the example of the chess club, the coordinator process can + be seen as a judge, monitoring all moves of the players. + At the same time as acting as a judge, the coordinator process is also + a host in the chess club, seating players by their tables and offering + services to the players. +\end_layout + +\begin_layout Subsection +The table module +\end_layout + +\begin_layout Standard +The table module is mostly a hub used for communication. + New table processes are created by the coordinator on demand. + The table module does not contain any business logic, however each process + contains information concerning which players are seated by that particular + table. +\end_layout + +\begin_layout Standard +The information about which players are seated by each table is used when + notifying all players by a table of an action. + Consider a game of chess, each player notifies the table of its actions, + the table then notifies the rest of the participants of these actions after + having had the ac tions processed by the game VM, where an action could + be moving a playing piece. +\end_layout + +\begin_layout Standard +Each table is associated with a game VM. + The actions sent to a table are processed by the game VM, this is where + the game logic is implemented. +\end_layout + +\begin_layout Standard +After a crash in a table process, the entire table must be rebuilt and the + players must be re-associated with the table. + Data concerning players is kept in the coordinator process, and is restored + from there. + Data kept in the actual game is not automatically corrupted by the crash + in a table, however the table must be re-associated with the game VM is + was associated with prior to the crash of the table. + The table process maps well into the setting of the real-world chess club + scenario previously discussed. + A table works in the same way in a real world setting as in the GGS setting. +\end_layout + +\begin_layout Subsection +The game virtual machine module +\end_layout + +\begin_layout Standard +This module holds the game logic of a game and is responsible for the VM + associated with each game. + +\end_layout + +\begin_layout Standard +The game VM contains the state of the VM and a table token associated with + a running game. + GameVM is started by the table module. + The table module hands over a token to the game VM during initialization. + During initialization a new VM instance and various objects associated + to the VM instance will be created. + Callbacks to Erlang are registered into the VM and then the source code + of a game is loaded into the VM and the game is ready for startup. + The only means for a game to communicate with the VM is through usage of + a provided interface. + +\end_layout + +\begin_layout Standard +The VM itself makes it possible for the game developer to program in the + programming language covered by the VM. + In future releases, more game VM:s will be added to support more programming + languages. + Because the game VM keeps track of the correct table, the game developer + does not need to take this into consideration when programming a game. + If a method within the game sends data to a player, it will be delivered + to the player in the correct running game. + The same game token is used to store the game state in the database. + Therefore, no game states will be mixed up either. +\end_layout + +\begin_layout Standard +This module does not affect game runtime but evaluates a new game state + and handles communication between the game and the players. + A closer look at the structure of this model is given in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Communication-with-the-GDL-VM" + +\end_inset + +. +\end_layout + +\begin_layout Subsection +The database module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-database-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +Game data from all games on the GGS are stored in the database backend of + the database module. +\end_layout + +\begin_layout Standard +In the GGS prototype the database module is using a database management + system called Mnesia. + Mnesia ships with the standard Erlang distribution and is a key-value store + type database. + Mnesia is designed to handle the stress of telecoms systems, and has some + features specifically tailored for telecoms which are not commonly found + in other databases. + Key features of the Mnesia database are: +\end_layout + +\begin_layout Itemize +Fast key/value lookups +\end_layout + +\begin_layout Itemize +Distribution of the database system +\end_layout + +\begin_layout Itemize +Fault tolerance +\end_layout + +\begin_layout Standard +\begin_inset CommandInset citation +LatexCommand citet +key "667766" + +\end_inset + + +\end_layout + +\begin_layout Standard +The features of Mnesia originally intended for telecoms prove very useful + for the purposes of the GGS as well. + The fault tolerance and speed of Mnesia are very valuable tools, the fast + key/value lookups permit many lookups per second to the database. +\end_layout + +\begin_layout Standard +Game data will not be lost when a game is stopped or has gone down for unknown + reasons. + This makes it possible to continue a game just before the failure without + having to start the game from the beginning. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Mnesia}}{Database server used in the GGS} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS stores the game state in the distributed Mnesia database, from which + the state can be restored in the event of a crash. +\end_layout + +\begin_layout Standard +Each game is uniquely identified by a table token and the data of each game + is stored within two different namespaces. + The namespaces are named World and Localstorage. + The World is used contain all game data related to the game state. + This sort of game data may change during the runtime of the game. + The Localstorage should contain data independent of the game state. + Game resources, constants and global variables are all examples of data + that could reside within the Localstorage. + To store a value within the database, not only is the table token and the + name of the namespace required, but a unique key so that the value can + be successfully retrieved or modified later. + The key is fully decidable by the game developer. + +\end_layout + +\begin_layout Standard +The interface of the database module is an implementation of the upcoming + W3C Web Storage specification. + Web Storage is intended for use in web browsers, providing a persistent + storage on the local machine for web applications. + The storage can be used to communicate in between browser windows (which + is difficult when using cookies), and to store larger chunks of data +\begin_inset CommandInset citation +LatexCommand citet +key "webstorage:website" + +\end_inset + +. + Usage of the web storage standard in the GGS provides a well documented + interface to the database backend. +\end_layout + +\begin_layout Section +Techniques for ensuring reliability +\end_layout + +\begin_layout Standard +One of the main goals of the project is to achieve high reliability. + The term +\begin_inset Quotes eld +\end_inset + +reliable system +\begin_inset Quotes erd +\end_inset + + is defined by the IEEE as a system with +\begin_inset Quotes eld +\end_inset + +the ability of a system or component to perform its required functions under + stated conditions for a specified period of time +\begin_inset Quotes erd +\end_inset + + +\begin_inset CommandInset citation +LatexCommand citet +key "ieee_90" + +\end_inset + +. + There are some tools for creating reliable applications built in to Erlang. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Reliability}}{The ability of a system or component to perform its + required functions under stated conditions for a specified period of time} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{IEEE}}{Institute of Electrical and Electronics Engineers, read "I-triple- +E"} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Itemize +Links between processes. + When a process spawns a new child process, and the child process later + exits, the parent process is notified of the exit. + +\end_layout + +\begin_layout Itemize +Transparent distribution over a network of processors. + When several nodes participate in a network, it does not matter on which + of these machines a process is run. + Communication between processes does not depend on the node in which each + process is run. + +\end_layout + +\begin_layout Itemize +Hot code replacements. + Two versions of the same module can reside in the memory of Erlang at any + time. + This means that a simple swap between these versions can take place very + quickly, and without stopping the machine. +\end_layout + +\begin_layout Standard +These three features are some of the basic building blocks for more sophisticate +d reliability systems in Erlang. + Many times it is not necessary to use these features directly, but rather + through the design patterns described below. +\end_layout + +\begin_layout Subsection +Supervisor structure +\begin_inset CommandInset label +LatexCommand label +name "sub:Supervisor-structure" + +\end_inset + + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +This entire section is bad. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +By linking processes together and notifying parents when children exit, + supervisors are created. + A supervisor is a common approach in ensuring that an application functions + in the way it was intended +\begin_inset CommandInset citation +LatexCommand citet +key "Savor:1997:HSA:851010.856089" + +\end_inset + +. + When a process misbehaves, the supervisor takes some action to restore + the process to a functional state. + +\end_layout + +\begin_layout Standard +There are several approaches to supervisor design in general (when not just + considering how they work in Erlang). + One common approach is to have the supervisor look in to the state of the + process(es) it supervises, and let the supervisor make decisions based + on this state. + The supervisor has a specification of how the process it supervises should + function, and this is how it makes decisions. + +\end_layout + +\begin_layout Standard +In Erlang, we have a simple version of supervisors. + We do not inspect the state of the processes being supervised. + We do have a specification of how the supervised processes should behave, + but on a higher level. + The specification describes things such as how many times in a given time + interval a child process may crash, which processes need restarting when + crashes occur, and so forth. + +\end_layout + +\begin_layout Standard +When the linking of processes in order to monitor exit behavior is coupled + with the transparent distribution of Erlang, a very powerful supervision + system is created. + For instance, we can restart a failing process on a different, new node, + with minimal impact on the system as a whole. + +\end_layout + +\begin_layout Standard +In the GGS, we have separated the system in to two large supervised parts. + We try to restart a crashing child separately, if this fails too many +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +Exactly how many +\begin_inset Quotes eld +\end_inset + +too many +\begin_inset Quotes erd +\end_inset + + is depends on a setting in the supervisor, ten crashes per second is a + reasonable upper limit. +\end_layout + +\end_inset + + times, we restart the nearest supervisor of this child. + This ensures separation of the subsystems so that a crash is as isolated + as possible. +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset Note Note +status open + +\begin_layout Plain Layout +We should really do this graphic in EPS instead of PNG +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/Supervisor_tree_GGS.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +The supervisor structure of GGS +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The graphic above shows our two subsystems, the coordinator subsystem and + the dispatcher subsystem. + Since these two systems perform very different tasks they have been separated. + Each subsystem has one worker process, the coordinator or the dispatcher. + The worker process keeps a state which should not be lost upon a crash. +\end_layout + +\begin_layout Standard +We have chosen to let faulty processes crash very easily when they receive + bad data, or something unexpected happens. + The alternative to crashing would have been to try and fix this faulty + data, or to foresee the unexpected events. + We chose not to do this because it is so simple to monitor and restart + processes, and so difficult to try and mend broken states. + This approach is something widely deployed in the Erlang world, and developers + are often encouraged to “Let it crash”. +\end_layout + +\begin_layout Standard +To prevent any data loss, the good state of the worker processes is stored + in their respective backup processes. + When a worker process (re)starts, it asks the backup process for any previous + state, if there is any that state is loaded in to the worker and it proceeds + where it left off. + If on the other hand no state is available, a special message is delivered + instead, making the worker create a new state, this is what happens when + the workers are first created. +\end_layout + +\begin_layout Subsection +Redundancy +\end_layout + +\begin_layout Standard +The modules in the GGS are built to be capable of redundant operation. + By adding a backup process to sensitive processes, the state can be kept + in the event of a crash. + The coordinator of the GGS prototype has this backup feature built in. + The coordinator passes state along to the backup process which keeps the + data safe. + In the event of a crash, the coordinator recovers the state from the backup + process. + Figure +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:redundancy" + +\end_inset + + depicts the redundancy built in to the coordinator process. +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/redundancy.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:redundancy" + +\end_inset + +To the left normal execution is pictured; the server state is backed up. + To the right; the exceptional execution, where the state is retrieved from + the backup to repopulate the server. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Hot code replacement +\end_layout + +\begin_layout Standard +Hot code replacement is a technique used to update systems while they are + running. + The main use of hot code replacement are in critical systems that require + low downtime, such as telecom systems. + By using hot code replacement system can be able to achieve as high uptime + as possible and thus improving the reliability of the system. + Code replacement is a feature that exist in Erlang which means that with + some work it could be implemented into the GGS. +\end_layout + +\begin_layout Section +Example of a GGS server application in Javascript +\end_layout + +\begin_layout Standard +Below is a concrete example of a simple chat server application written + using the GGS. + The language chosen for this chat server is JavaScript. + The GGS processes all incoming data through a protocol parser, which interprets + the data and parses it into an internal format for the GGS. +\end_layout + +\begin_layout Standard +When the GGS receives a +\emph on +Game-Command +\emph default + from a client, it is passed along to the game VM through a function called + +\emph on +playerCommand +\emph default + which is the entry point for each game and has to be implemented by the + developer; one can think of it like the +\emph on +main() +\emph default + function of a C or Java program +\emph on +. + +\emph default + Typically the +\emph on +playerCommand +\emph default + function contains conditional constructs which decide the next action to + take. + In +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-concrete-example" + +\end_inset + + an example of the +\emph on +playerCommand +\emph default + function can be seen. +\end_layout + +\begin_layout Standard +In +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-concrete-example" + +\end_inset + + the +\emph on +playerCommand +\emph default + function accepts two different commands. + The first command is a command which allows chat clients connected to the + chat server to change nicknames, which are used when chatting. + In order to change the nickname, a client must send a Game-Command +\begin_inset Quotes eld +\end_inset + +nick +\begin_inset Quotes erd +\end_inset + + with the actual new nickname as a argument. + When a message arrives to the GGS which has the form corresponding to the + nickname change, the +\emph on +playerCommand +\emph default + function is called with the parameters +\emph on +player_id, command, +\emph default +and +\emph on +args +\emph default + filled in appropriately. +\end_layout + +\begin_layout Standard +The +\emph on +playerCommand +\emph default + function is responsible for calling the helper functions responsibly for + carrying out the actions of each message received. + +\emph on +changeNick +\emph default + is a function which is called when the +\begin_inset Quotes eld +\end_inset + +nick +\begin_inset Quotes erd +\end_inset + + message is received. + The +\emph on +changeNick +\emph default +function uses a feature of the GGS called localstorage (see section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Communication-with-the-GDL-VM" + +\end_inset + +), which is an interface to the database backend contained in the database + module (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:The-database-module" + +\end_inset + +). + The database can be used as any key-value store, however the syntax for + insertions and fetch operations is tighty integrated in the GDL of the + GGS. +\end_layout + +\begin_layout Standard +Access to the localStorage is provided through the +\emph on +GGS object +\emph default +, which also can be used to communicate with the rest of the system from + the GDL. + Implementation specifics of the GGS object are provided in +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Communication-with-the-GDL-VM" + +\end_inset + +. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +language=JavaScript, +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting}[language=JavaScript] +\end_layout + +\begin_layout Plain Layout + +function playerCommand(player_id, command, args) { +\end_layout + +\begin_layout Plain Layout + + if(command == "nick") { +\end_layout + +\begin_layout Plain Layout + + changeNick(player_id, args); +\end_layout + +\begin_layout Plain Layout + + } else if(command == "message") { +\end_layout + +\begin_layout Plain Layout + + message(player_id, args); +\end_layout + +\begin_layout Plain Layout + + } +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + +function changeNick(player_id, nick) { +\end_layout + +\begin_layout Plain Layout + + var old_nick = GGS.localStorage.getItem("nick_" + player_id); +\end_layout + +\begin_layout Plain Layout + + GGS.localStorage.setItem("nick_" + player_id, nick); +\end_layout + +\begin_layout Plain Layout + + if (!old_nick) { +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll("notice", nick + " joined"); +\end_layout + +\begin_layout Plain Layout + + } else { +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll("notice", old_nick + " is now called " + nick); +\end_layout + +\begin_layout Plain Layout + + } +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + +function message(player_id, message) { +\end_layout + +\begin_layout Plain Layout + + var nick = GGS.localStorage.getItem("nick_" + player_id); +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll('message', nick + "> " + message); +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-concrete-example" + +\end_inset + +A concrete example of a simple chat server written in JavaScript, running + on the GGS +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Chapter +Problems of implementation +\begin_inset CommandInset label +LatexCommand label +name "cha:Problems-of-implementation" + +\end_inset + + +\end_layout + +\begin_layout Standard +This chapter contains specific problems encountered when implementing the + GGS prototype. + Some of the problems described have solutions attached, however some problems + were not solved, therefore only ideas for slutions have been attached. +\end_layout + +\begin_layout Standard +The integration of JavaScript as a GDL in the GGS prototype was particularily + difficult, and is handled in this section. + Unique identification is also handled, as is the design of the GGS protocol. +\end_layout + +\begin_layout Section +JavaScript engine +\end_layout + +\begin_layout Standard +The GGS prototype uses a vistual machine to sandbox each game. + JavaScript was chosen for the prototype due to its commonality in web applicati +ons and the flexibility of the language. + Any language with the proper bindings to Erlang could have been used in + theory. +\end_layout + +\begin_layout Standard +There are two main JavaScript virtual machines, or +\emph on +engines +\emph default + 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 V8. + 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. +\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 thee possibility + to communicate from erlang_js to Erlang. + The ability to communicate from JavaScript to Erlang functionality is not + yet implemented in erlang_js, due to lack of time on the behalf of the + erlang_js developers. +\end_layout + +\begin_layout Standard +There were two possible solutions to the problem of the JavaScript to Erlang + communication path missing, the path could be implemented by the GGS project, + or a switch from erlang_js for some other JavaScript engine could be made. + +\end_layout + +\begin_layout Standard +Attempts at creating the communication path from JavaScript to Erlang were + initially made, however the communication path 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 rather than the engines + developed by Mozilla. + The ability to communicate with Erlang from JavaScript using callbacks + is available in the erlv8 bindings, therefore this feature does not have + to be added to the bindings in order to be used in the GGS. +\end_layout + +\begin_layout Standard +Initial releases of the erlv8 bindings had stability issues, these were + however solved by the erlv8 developers during the usage of erlv8 in the + GGS. + 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 +UUID +\end_layout + +\begin_layout Standard +Erlang identifies processes uniquely throughout the entire Erlang network + using process IDs (PID). + When we wish to refer to erlang processes from outside our erlang system, + for example in a virtual machine for a different language, possibly on + a different machine, these PID:s are no longer useful. + +\end_layout + +\begin_layout Standard +This problem is not new, and a common solution is to use a Universally Unique + Identifier, a UUID. + These identifiers are generated both using randomization and using time. + A reasonably large number of UUID:s can be generated before a collision + should occur. + There are standard tools in many UNIX systems to generate UUID:s, we chose + to use the uuidgen command, which employs an equidistributed combined Tausworth +e generator. +\end_layout + +\begin_layout Section +Protocol design +\end_layout + +\begin_layout Standard +Initially the GGS protocol was designed to use the UDP protocol for transport. + Due to the lack of error checking in the UDP protocol, the UDP protocol + is faster than the TCP protocol, this was a main reason to use UDP. + The GGS does however need error checking to be as reliable as possible, + therefore an error checking layer would have to be placed on top of UDP. +\end_layout + +\begin_layout Standard +The development of an error checking layer was weighed against the implementatio +n of TCP instead of UDP, thus losing some speed. + Even though speed was lost, TCP was chosen due to the relative ease of + implementation compared to UDP. + Due to the modularity of the GGS, a UDP extension is possible by replacing + the network parts of the GGS. +\end_layout + +\begin_layout Standard +Furthermore, in a move to increase the speed of the GGS protocol the binary + BSON protocol +\begin_inset CommandInset citation +LatexCommand citet +key "bson:website" + +\end_inset + + was initially considered. + BSON is a protocol which can be used for very fast traversal of data. + The BSON protocol is however rather difficult to read in its plain format, + and no implementation has been bade for the GGS. +\end_layout + +\begin_layout Standard +The Apache Thrift +\begin_inset CommandInset citation +LatexCommand citep +key "Slee2007" + +\end_inset + + was also an alternative. + Using Thrift would mean the GGS would feature a standard protocol for network + communication. + Before finding out about Thrift, an implementation of the GGS protocol + had already been made, moving to Thrift would mean too much work. +\end_layout + +\begin_layout Standard +The use of Thrift, BSON, or other protocols can be supported quite easily + by developing protocol modules for each protocol. + No protocol modules for these protocols have however been developed during + the writing of this thesis +\end_layout + +\begin_layout Section +Design choices +\begin_inset Note Note +status open + +\begin_layout Plain Layout +This section is wrongly placed +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +When designing concurrent applications, it is useful to picture them as + real world scenarios, and to model each actor as a real world process. + A real world process is a process which performs some action in the real + world, such as a mailbox receiving a letter, a door being opened, a person + translating a text, a soccer player kicking the ball, just to name a few + examples. + Since we focus on games in this project, it is suitable to model our system + as a place where games take place. + We imagined a chess club. + +\end_layout + +\begin_layout Standard +The clients pictured as green circles can be thought of as the physical + chess players. +\end_layout + +\begin_layout Standard +When a player wants to enter the our particular chess club, he must first + be let in by the doorman, called the +\emph on +Dispatcher +\emph default + in the GGS. +\end_layout + +\begin_layout Standard +He then gets a name badge, and thus becomes a +\emph on +Player +\emph default + process in the system. + He is also guided in to the lobby by the +\emph on +Coordinator +\emph default +, which has the role of the host of the chess club. +\end_layout + +\begin_layout Standard +When players wish to play against each other, they talk to the +\emph on +Coordinator +\emph default + who pairs them up, and places them at a table. + Once they have sat down at the table, they no longer need the assistance + of the +\emph on +Coordinator +\emph default +, all further communication takes place via the table. + This can be thought of as the actual chess game commencing. + +\end_layout + +\begin_layout Standard +All the moves made in the game are recorded by the table, such that the + table can restore the game in case something would happen, such as the + table tipping over, which would represent the table process crashing. +\end_layout + +\begin_layout Standard +Once a player wishes to leave a game, or the entire facility, he should + contact the +\emph on +Coordinator +\emph default +, who revokes his name badge and the +\emph on +Dispatcher +\emph default + will let the player out. +\end_layout + +\begin_layout Standard +With the information kept in the tables and the +\emph on +Coordinator +\emph default + combined, we can rebuild the entire state of the server at a different + location. + This can be thought of the chess club catching fire, and the +\emph on +Coordinator +\emph default + rounding up all the tables, running to a new location and building the + club up in the exact state it was prior to the fire. +\end_layout + +\begin_layout Chapter +Results and discussion +\begin_inset CommandInset label +LatexCommand label +name "chap:Results-and-discussion" + +\end_inset + + +\end_layout + +\begin_layout Section +Statistics +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Mention the hardware which the GGS was run on; A Thinkpad T410 wityh a core + i5 and 4GB of ram. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +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 can not 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 Standard +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 + +\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/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 + +\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 + +\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 + +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Future improvements +\end_layout + +\begin_layout Standard +The specification of the GGS prototype is huge and like many other software + projects relying on outside technologies, in time it would require a lot + of maintenance. + Therefore there are a lot of areas in which the GGS could be improved such + as performance, compatibility, ease of setup and usage. +\end_layout + +\begin_layout Subsection +Performance +\end_layout + +\begin_layout Subsubsection +Protocols +\end_layout + +\begin_layout Standard +Because of TCP being a connection oriented protocol, it is not suited for + all types of game data transfers. + Each transmission will consume more network bandwidth than connectionless + protocols like UDP and cause unnecessary load on the processor. + Therefore support for UDP would mean that more games could be run simultaneousl +y on the GGS. + Another advantage of UDP is latency being reduced. + Without having to setup a connection for each group packets of data being + sent, they will be sent instantly and therefore arrive earlier. + Latency is of highest importance in real-time games as it improves realism + and fairness in gameplay and many game developers requires 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. + This could be prevented by replacing Mnesia with another database management + system or use Mnesia in combination with the ETS module of erlang. + ETS provides fast access to the RAM and thus Mnesia could be used less + frequently. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{ETS}}{Erlang Term Storage} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Compatibility +\end_layout + +\begin_layout Standard +GGS relies on modern technologies. + This includes the virtual machines(VM) that the GGS uses for communication + between Erlang and the GDL:s. + These specific VM:s are crucial for game developers to be able to write + games in other languages than Erlang. + Therefore it would be best for the GGS to have as many of these VM:s implemente +d as possible. + The VM:s taken into consideration so far have been unstable or incomplete + and it is possible to search for more VM:s, testing them and integrate + them into the GGS prototype. +\end_layout + +\begin_layout Subsection +Setup +\end_layout + +\begin_layout Standard +The GGS prototype installation procedure requires different configuration + and building steps and thus it is not in an acceptable release state. + An executable installation file for each supported platform would be optimal. +\end_layout + +\begin_layout Subsection* +5.3.4 Usage +\end_layout + +\begin_layout Subsubsection +Programming languages +\end_layout + +\begin_layout Standard +The GGS does not support many programming languages. + For a programming language to be compatible with the GGS, not only does + it require a VM for that specific language, but the VM must have the ability + to communicate to Erlang. + More research is needed to find VM:s with this built in functionality. + +\end_layout + +\begin_layout Subsubsection +Documentation +\end_layout + +\begin_layout Standard +To start the GGS is not self explanatory. + This together with overall usage of GGS should be documented. + The interface for usage of game developers is also in need of documentation. + Features and requirements with respect to the GGS would assist users to + know what they need in order to use the GGS and how they would benefit + of it. + The GGS does not support many programming languages nor does it have a + complete documentation. + This needs to be taken care of in future versions. +\end_layout + +\begin_layout Chapter +Conclusion +\end_layout + +\begin_layout Standard +\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 + +\end_layout + +\begin_layout Standard +\begin_inset CommandInset bibtex +LatexCommand bibtex +bibfiles "bibliography" +options "plainnat" + +\end_inset + + +\end_layout + +\end_body +\end_document diff --git a/not-working.lyx b/not-working.lyx new file mode 100644 index 0000000..579d6b8 --- /dev/null +++ b/not-working.lyx @@ -0,0 +1,7817 @@ +#LyX 2.0 created this file. For more info see http://www.lyx.org/ +\lyxformat 413 +\begin_document +\begin_header +\textclass report +\begin_preamble +\usepackage{indentfirst} +\usepackage{tocloft} +\usepackage{calc} +\date{} +\usepackage[section] {placeins} +\def\myClearpage{% + \ifvmode + \ifnum \@dbltopnum =\m@ne + \ifdim \pagetotal <\topskip + \hbox{}% + \fi + \fi + \fi +% \newpage + \write\m@ne{}% + \vbox{}% + \penalty -\@Mi +} +\def\myCleardoublepage{\myClearpage\if@twoside \ifodd\c@page\else + \hbox{}\if@twocolumn\hbox{}\fi\fi\fi} +\usepackage{morefloats} +\usepackage{graphicx} +\usepackage{subfig} +\usepackage{tocloft} +\renewcommand{\cftchapfont}{\bfseries} +\renewcommand{\cftchappagefont}{\bfseries} +\renewcommand{\cftchappresnum}{Chapter } +\renewcommand{\cftchapnumwidth}{6em} + +\oddsidemargin 0.5in +\textwidth 6in +\topmargin 0.0in +\textheight 8.0in +\setlength\topskip{24pt} +\footskip 0.75in + +\usepackage[compact]{titlesec} + + +\titleformat{\chapter}[display] +{\vskip-8em\normalfont\bfseries} +{\LARGE\raggedright\thechapter} +{14ex} +{\vspace{-20ex}% +\LARGE\raggedleft} +[\vspace{1ex}% +{\titlerule[1pt]}] + +\usepackage[absolute]{textpos} + +\usepackage{fancyheadings} +\pagestyle{fancy} +\lhead{\thechapter} + +\usepackage[hmargin=3cm,vmargin=3.5cm]{geometry} +\usepackage{algorithmic} +\usepackage{listings} + +\usepackage{color} +\definecolor{lightgray}{rgb}{.9,.9,.9} +\definecolor{darkgray}{rgb}{.4,.4,.4} +\definecolor{purple}{rgb}{0.65, 0.12, 0.82} + +\lstdefinelanguage{JavaScript}{ + keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break}, + keywordstyle=\color{blue}\bfseries, + ndkeywords={class, export, boolean, throw, implements, import, this}, + ndkeywordstyle=\color{darkgray}\bfseries, + identifierstyle=\color{black}, + sensitive=false, + comment=[l]{//}, + morecomment=[s]{/*}{*/}, + commentstyle=\color{purple}\ttfamily, + stringstyle=\color{red}\ttfamily, + morestring=[b]', + morestring=[b]" +} + +\lstdefinelanguage{Erlang}{ + keywords={typeof, true, false, catch, return, null, catch, switch, var, if, in, while, do, else, case, break, expose}, + keywordstyle=\color{blue}\bfseries, + ndkeywords={class, export, boolean, throw, implements, import, this,erlv8_vm, erlv8_fun_invocation +,erlv8_object}, + ndkeywordstyle=\color{darkgray}\bfseries, + identifierstyle=\color{black}, + sensitive=false, + comment=[l]{\%}, + morecomment=[s]{/*}{*/}, + commentstyle=\color{purple}\ttfamily, + stringstyle=\color{red}\ttfamily, + morestring=[b]', + morestring=[b]" +} + +\usepackage{float} + +\floatstyle{ruled} +\newfloat{code}{thp}{lop} +\floatname{code}{Code} + +\usepackage{nomencl} +\makenomenclature +\renewcommand{\nomname}{Glossary} +\end_preamble +\use_default_options true +\maintain_unincluded_children false +\language english +\language_package default +\inputencoding auto +\fontencoding global +\font_roman lmodern +\font_sans default +\font_typewriter default +\font_default_family rmdefault +\use_non_tex_fonts false +\font_sc false +\font_osf false +\font_sf_scale 100 +\font_tt_scale 100 + +\graphics default +\default_output_format default +\output_sync 0 +\bibtex_command default +\index_command default +\paperfontsize default +\spacing onehalf +\use_hyperref false +\papersize a4paper +\use_geometry false +\use_amsmath 1 +\use_esint 1 +\use_mhchem 1 +\use_mathdots 1 +\cite_engine natbib_authoryear +\use_bibtopic false +\use_indices false +\paperorientation portrait +\suppress_date false +\use_refstyle 0 +\index Index +\shortcut idx +\color #008000 +\end_index +\paperwidth 11in +\paperheight 8.5in +\leftmargin 1.25in +\topmargin 0in +\rightmargin 1in +\bottommargin 1.7in +\secnumdepth 2 +\tocdepth 2 +\paragraph_separation indent +\paragraph_indentation default +\quotes_language english +\papercolumns 1 +\papersides 1 +\paperpagestyle empty +\tracking_changes false +\output_changes false +\html_math_output 0 +\html_css_as_file 0 +\html_be_strict false +\end_header + +\begin_body + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{textblock*}{ +\backslash +paperwidth}(0mm,40mm) +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{center} +\end_layout + +\begin_layout Plain Layout + + +\backslash +includegraphics[width= +\backslash +paperwidth/2]{graphics/logo} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{center} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{textblock*} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Title +A Reliable Generic Game Server +\end_layout + +\begin_layout Author +Niklas Landin +\begin_inset Newline newline +\end_inset + +Richard Pannek +\begin_inset Newline newline +\end_inset + +Mattias Pettersson +\begin_inset Newline newline +\end_inset + +Jonatan Pålsson +\end_layout + +\begin_layout Abstract +This is the abstract! +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +pagenumbering{roman} +\end_layout + +\begin_layout Plain Layout + + +\backslash +setcounter{page}{3} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +contentsname{Table of Contents} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand{ +\backslash +cfttoctitlefont}{ +\backslash +hfill +\backslash +Large} +\backslash +renewcommand{ +\backslash +cftaftertoctitle}{ +\backslash +hfill} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +cftpartdotsep{6.6} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +cftchapdotsep{6.6} +\end_layout + +\end_inset + + +\begin_inset CommandInset toc +LatexCommand tableofcontents + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Newpage newpage +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +pagenumbering{arabic} +\end_layout + +\begin_layout Plain Layout + + +\backslash +setcounter{page}{1} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Chapter +Introduction +\end_layout + +\begin_layout Standard +Online gaming, and computer gaming in general has become an important part + in many peoples day-to day lives. + A few years ago, computer games were not at all as popular as they are + today. + With the advances in computer graphics and computer hardware today's games + are much more sophisticated then they were in the days of +\emph on +NetHack +\emph default +, +\emph on +Zork, +\emph default +or +\emph on +Pacman. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Zork}}{A textual computer game developed by students at MIT} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Pacman}}{An early graphical computer game developed by Namco} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{NetHack}}{An early computer game developed by the NetHack team, arguably + the oldest computer game still in development} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The early computer games featured simple, or no graphics at all +\begin_inset CommandInset citation +LatexCommand citet +key "nethack:website" + +\end_inset + +. + The games often took place in a textual world, leaving the task of picturing + the world up to the player. + Multi-player games were not as common as they are today, whereas most games + today are expected to have a multi-player mode, most early games did not. +\end_layout + +\begin_layout Standard +Since these early games, the gaming industry have become much more influential + in many ways. + Many advanced in computer hardware are thought to come from pressure from + the computer game industry. + More powerful games require more powerful, and more easily available hardware +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Drop a reference to the gaming industry pressuring more advanced hardware +\end_layout + +\end_inset + +. + Due to the high entertainment value of modern computer games, gaming has + become a huge industry, where large amounts of money are invested. + The gaming industry is today, in some places even larger than the motion + picture industry. + +\begin_inset CommandInset citation +LatexCommand citet +key "esa:website,thenumbers:website" + +\end_inset + + +\end_layout + +\begin_layout Standard +Due to the increasing importance of computer gaming, more focus should be + spent on improving the quality of the gaming service. + As more and more computer games are gaining multi-player capabilities, + the demands for multiplayer networking software rises. + This thesis is about techniques for improving the quality of this networking + software. +\end_layout + +\begin_layout Standard +The reliable generic game server, hereafter known as GGS +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{GGS}}{Generic Game Server, a software for reliably hosting network + games. + The subject of this thesis.} +\end_layout + +\end_inset + +, is a computer program designed to +\emph on +host +\emph default + network games on one or more server computers. + Hosting, in a network software setting, means allowing client software + connect to the server software, for the purpose of utilizing services provided + by the server. + The GGS software provides games as a service, and the clients connecting + to the GGS can play these games on the GGS. +\end_layout + +\begin_layout Standard +The idea of game servers is not new, network games have been played for + decades. + Early, popular examples of network games include the +\emph on +Quake +\emph default + series, or the +\emph on +Doom +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout + +\emph on +Come up w/ better game +\end_layout + +\end_inset + + +\emph default + games. + Newer examples of network games include +\emph on +World of Warcraft +\emph default +, and +\emph on +Counter-Strike +\emph default +. + The difference between the GGS and the servers for these games is that + the servers for Doom, Quake, and the others listed, were designed with + these specific games in mind. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Quake}}{A first person shooter series developed by ID software. + The series consists of four games.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Doom}}{A first person shooter series developed by ID software. + The series consists of three games.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{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{Counter-Strike}}{A multiplayer first person shooter game, popular + in E-Sports.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Framework}}{A supporting structure, the GGS is a framework for developing + network games} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{First-person shooter}}{A game in which centers around gun combat + from the first person perspective.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{MMORPG}}{Massively multiplayer online role playing game. + An online game with several thousand participants.} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +What GGS does is to provide a +\emph on +generic +\emph default + framework for developing network games. + The framework is generic in the sense that it is not bound to a specific + game. + There are many different types of games, some are inherently more time + sensitive than others, strategy games are examples of games which are not + very sensitive to time delays, first-person shooters however, can be very + sensitive. +\end_layout + +\begin_layout Standard +The generic nature of the GGS allows the creation of many different types + of games, the motivation behind this is to remove the necessity of writing + new game servers when developing new games. +\end_layout + +\begin_layout Standard +The GGS is in addition to being generic, also +\emph on +reliable +\emph default + in the sense that the gaming service provided is consistent and available. + A consistent and available server is a server that handles hardware failures + and software failures gracefully. + In the event of a component breaking within the GGS, the error is handled + by fault recovery processes, thereby creating a more reliable system. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Hardware failiure}}{A failiure in hardware (hard drive, memory, processor +, etc) which causes a system to stop functioning} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Software failiure}}{A failiure in software (the GGS, the operating + system, etc) which causes a system to stop functioning} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Background +\end_layout + +\begin_layout Standard +The game industry is a quickly growing industry where the need for new technique +s are large. + One specific section where the development has stalled is the game server + section. +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + + The existing game servers are functional but they lack good fault tolerance + and the ability to scale well +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + +. + Users will notice this in low uptime and many crashes. + This is a problem that has existed and been resolved in other industries. + In the telecom industry solutions to similar problems have been found. +\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, or rougly +\begin_inset Formula $15ms$ +\end_inset + + downtime in a year +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + +. + The level of instability and bad fault tolerance seen in the game server + industry would not have been accepted in the telecoms industry. + This level of instability should not be accepted in the game server industry + either. + An unavailabvle phone system could potentially have life threatening consequenc +es, leaving the public unable to contant emergency services. + The same can not 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 learnt. +\end_layout + +\begin_layout Standard +Moving back to the gaming industry. + The main reason to develop reliable servers are monetary, it is important + for game companies to expand its customer base. + Reliable game servers are one improvement that will create a good image + of a company. + In general the downtime of game servers is much higher than the downtime + of telecom system +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed... +\end_layout + +\end_inset + +. + The structure of the system is similar in many ways and it should be possible + to reuse solutions from the telecom system to improve game servers. + +\end_layout + +\begin_layout Standard +In the current state game servers are developed on a per-game basis, in + many cases this seems like a bad solution. + Developers of network game need to understand network programming. + A way to change this is a generic game server which give the game developers + a server which they implement their game towards. + 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 factors key to the development of GGS have been isolated. + Many of these come from the telecom sector. + The factors are +\emph on +scalability, fault tolerance +\emph default +and being +\emph on +generic +\emph default +. + 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 defined as the statistical probability of the system functioni +ng as intended at a given point in time. + Fault tolerance is defined as the property of a system to always follow + a specification, even in the presence of errors. + The specification could take the form of error handling procedures which + activate when an error occurs. + This means that a fault tolerant, dependable system, will have a very high + probability of functioning at a given point in time, and is exactly what + is desired. + +\begin_inset CommandInset citation +LatexCommand citet +key "Gartner:1999:FFD:311531.311532" + +\end_inset + + +\end_layout + +\begin_layout Standard +A generic (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Generic" + +\end_inset + +) game server has to be able to run different client-server network games + regardless of the platform the clients are running on. + It runs network games of different type. + A very rough separation of games is real time games and turn based games. +\end_layout + +\begin_layout Standard +The server behaves in a way similar to an application server, but is designed + to help running games. + 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. +\end_layout + +\begin_layout Standard +The most common type of application servers are web servers, where you run + a web application within the server. + The application server provides an environment and interfaces to the outer + world, in which applications run. + Hooks and helpers are provided to use the resources of the server. + Some examples for web application servers are the +\emph on +Glassfish +\emph default + server which allows running applications written in Java or the +\emph on +Google App Engine +\emph default + where you can run applications written in Python or some language which + runs in the +\emph on +Java Virtual Machine +\emph default +. + An example of an application server not powering web applications, but + instead regular business logic, is Oracle’s +\emph on +TUXEDO +\emph default + application server, which can be used to run applications written in COBOL, + C++ and other languages. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SQL}}{Structured Query Language, a computer language common in querying + certain databases} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{JavaScript}}{A programming language originally developed by Netscape, + common in web programming} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{COBOL}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{C++}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Java}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{AXD301}}{Telephone switch developed by Ericsson} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Erlang}}{A concurrent programming language, often used for telecom + applications. + The main language of the GGS} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +A database server can also be seen as an application server. + Scripts, for example SQL queries or JavaScript, are sent to the server, + which runs them and returns the evaluated data to the clients. + +\end_layout + +\begin_layout Standard +One purpose of this thesis is to investigate how we can make a game server + as generic as possible. + Some important helpers are discussed, such as abstraction of the network + layer, data store and game specific features. + +\end_layout + +\begin_layout Standard +As an aid in discussing the theoretical parts of the GGS a prototype has + been developed. + The prototype does not feature all of 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 implementation language for the prototype of the GGS was made + with inspiration from the telecom industry. + The Erlang language was developed by the 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 is also possibly has the largest code base even written in a + functional language +\begin_inset CommandInset citation +LatexCommand citep +key "Armstrong03" + +\end_inset + +. + The same language is used to develop the prototype of the GGS. + 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 + +. + Chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Implementation-of-a" + +\end_inset + + provides a description of the prototype developed for this thesis. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +We could go on and on about erlang.. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Purpose +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout +The purpose of the GGS project. + What is the purpose of creating a fault tolerant server, why is it generic, + and what good does it do to have a scalable system? In the background, + we should give the motivations behind creating this software, but here + we should outline why the software is needed. + This section should be shortened, and the bulk of the text should be moved + to theory or background. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The purpose of creating a generic and fault tolerant game server is to provide + a good framework for the development of many different types of games. + Allowing the system to scale up and down is a powerful way to maximize + the usage of physical resources. + By scaling up to new machines when load increases, and scaling down from + machines when load decreases costs and energy consumption can be optimized. +\end_layout + +\begin_layout Standard +Fault tolerance is important for the GGS to create a reliable service. + The purpose of a reliable game server is to provide a consistent service + to people using the server. + Going back to the telecom example, the purpose of creating a reliable telecom + system is to allow calls, possibly emergency calls, at any time. + Should the telecom network be unavailable at any time, emergency services + may become unavailable, furthermore the consumer image of the telecom system + degrades. +\end_layout + +\begin_layout Standard +Returning to the game industry, emergency services will not be contacted + using a game server, however an unavailable server will degrade the consumer + 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 can not 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 wrote in different programming + languages, besides 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 decide the feasibility + of a language: +\end_layout + +\begin_layout Itemize +How well it integrates with Erlang, which is used in the core the GGS system + +\end_layout + +\begin_layout Itemize +How easy it is to send messages to the virtual machine of the GDL from the + GGS +\end_layout + +\begin_layout Itemize +How easy it is to send messages from the GDL VM to the GGS +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add more like threads, events, etc. +\end_layout + +\end_inset + + +\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 for use in interacting 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 gaming clients has to take place over 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 large challenge during this project is to decide whether an existing + protocol can be used, and if not, how a new protocol can be designed which + performs technically as desired, while still being familiar enough to existing + developers. +\end_layout + +\begin_layout Standard +A great deal of work is devoted to make the GGS +\emph on +reliable +\emph default +. + This includes ensuring that the system scales well, and to make sure it + is fault tolerant. + In order to facilitate scalability, we need a storage platform which is + accessible and consistent among all of the GGS, this is also investigated. +\end_layout + +\begin_layout Section +Limitations of the prototype +\end_layout + +\begin_layout Standard +The implementation of the GGS protocol, together with storage possibilities, + server capacity, and game language support imposes some limitations on + the project. + To get a functional prototype some limits must be set on the types games + that can be played on the prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{UDP}}{User Datagram Protocol, a connectionless networking protocol} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{TCP}}{Transmission Control Protocol, a streaming network protocol} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The UDP protocol is not supported for communication between client and server. + The TCP protocol was chosen in favour of UDP, due to the fact that the + implementation process using TCP was faster than if UDP would have been + used. + UDP is generally considered to be faster than TCP for the transfer of game + (and other) related data, this is discussed in more depth in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Choice-of-network" + +\end_inset + +. + In short, the decision of using TCP means that games that requires a high + speed protocol will not be supported by the GGS prototype. + Another limitation necessary to set on the system is the possibility to + have huge game worlds due to the implementation of the scaling mechanism + in the prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Latency}}{A measure of delay, often measured in milliseconds} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +In real time games all players are playing together at the same time. + Latency is a huge problem in real time games, a typical round trip time + for such games are one of +\begin_inset Formula $50$ +\end_inset + + to +\begin_inset Formula $150ms$ +\end_inset + + and everything above +\begin_inset Formula $200ms$ +\end_inset + + is reported to be intolerable +\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 (MMORPG:s), for example + +\emph on +World of Warcraft +\emph default +. +\end_layout + +\begin_layout Standard +In turn based games each player has to wait for their turn. + Latency is not a problem since the gameplay does not require fast interactions + among the players, long round trip times will not be noticed. + Examples of turn based games include board and card games, as well as multiplay +er games like +\emph on +Jeopardy +\emph default +. + Both game types have varying difficulties and needs when it comes to implementi +ng them, a Generic Game Server should address all of them and help the developer + to accomplish his goal. +\end_layout + +\begin_layout Standard +Due to the limited capability of threading in many GDL VM:s, the GGS prototype + will not support MMORPG:s. +\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 + are no need to implement more advanced features in the system. + Note that these limitations only apply for the prototype of the project, + and that further developments to the GGS could be to implement these features. +\end_layout + +\begin_layout Section +Method +\end_layout + +\begin_layout Standard +A prototype was developed early on in the project to carry out experiments. + Using this prototype, the system was divided into modules. + A demand specification was created, using this specification, the modules + were easily identifiable. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Module}}{A part of a larger system} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The first prototype of the GGS consisted of simple modules, however, due + to the separation of concerns among the modules, they were easily independently + modified and improved. +\end_layout + +\begin_layout Standard +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 interative workflow, with the first prototype + being the first iteration. + The second iteration later became the final result of the GGS. +\end_layout + +\begin_layout Standard +The layout of the GGS is both layered and modular. + The first layer handles the most primitive data and produces a higher level + representation of the data, passing it along to different modules of the + GGS. + The modular structure of the GGS plays an important role in making the + system fault tolerant. + The approach to fault tolerance is by replication, and restarting the faulting + modules with the last known good data. +\end_layout + +\begin_layout Standard +An informal specification and list of requirements of the system was outlined + early on in the project. + Usaility goals for developers were set. + During the project several demo applications were constructed, by constructing + these applications, the usability goals were enforced. +\end_layout + +\begin_layout Chapter +Theory behind the GGS +\begin_inset CommandInset label +LatexCommand label +name "cha:Theory" + +\end_inset + + +\end_layout + +\begin_layout Standard +In this chapter, the theory behind the techniques used in the GGS are discussed. + Performance issues and the measuring of performance is discussed. + Benchmarking techniques are discussed. + The options when choosing network protocols are given, along with a discussion + of each alternative. + Finally, an overview of scalability, fault tolerance and availability are + 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 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 a computer. + The requirements and limitations imposed on the real-world system can, + using the proper tools, be transferred in to the software. +\end_layout + +\begin_layout Standard +The real world system chosen for 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. + Since a real-world scenario is readily available, and to such a large extent + resembles the computer software required for the GGS, the next step in + developing the GGS system is to duplicate this real world scenario in a + software setting. +\end_layout + +\begin_layout Standard +Some requirements, limitations and additions were made to the chess club + system, so that the system would more easily and efficiently be replicated + in a software setting. +\end_layout + +\begin_layout Standard +In the text below, two examples will be presented. + On example is that of a real-world chess club, in which players meet to + play chess against each other, the other example is the GGS, and how it + corresponds to this chess club. + +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/theory_layout.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:theory-layout" + +\end_inset + +The layout of a physical +\begin_inset Quotes eld +\end_inset + +Chess club +\begin_inset Quotes erd +\end_inset + + with two players (P) sitting by each chess table (Table), a coordinator + keeps track of all moves and players in the building. + A player has to pass by the entrance to enter or exit the building. + The building is represented by the outermost box. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +In figure +\begin_inset CommandInset ref +LatexCommand vref +reference "fig:theory-layout" + +\end_inset + + a graphical representation for the chess club is presented. + The club is seen from above. + The outermost box represents the building. + In the GGS setting, the building would represent one instance of GGS. + Several buildings linked together would represent a cluster of GGS instances. + In order for a player (the P symbol in the graphic) to enter the theoretical + chess club, the player must pass by the entrance. + By having each player pass by the entrance, a tally +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Does this mean what I think it does? +\begin_inset Quotes eld +\end_inset + +Räkning +\begin_inset Quotes erd +\end_inset + + ? +\end_layout + +\end_inset + + can be kept, ensuring that there are not too many players within the building. + In the GGS setting, too many players entering would mean too many connections + have been accepted by the GGS system, and that the structure of the system + thus must be modified, adding additional servers. +\end_layout + +\begin_layout Standard +Once a player has been allowed in to the chess club the player is greeted + by the host of the chess club, in the GGS setting represented by the +\emph on +Coordinator +\emph default +, and is seated by a table. + The coordinator keeps track of all the players in the building, and all + moved made by the players. + The information available to the coordinator means that cheating can be + monitored and book keeping can be performed by this entity. +\end_layout + +\begin_layout Standard +Moves by players are made using the tables present in the chess club. + Every game is isolated to a table, just as expected. + This means that communication during a game only has to pass by the players + of that particular game, and the coordinator, making sure that no cheating + takes place. +\end_layout + +\begin_layout Standard +This isolation of the games play an important part in many properties of + the GGS, the isolation means that games can for example be transferred + among different chess clubs, furthermore, if cheating takes place, corruption + can only occur in the particular table where it was found, and can not + 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 a property 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 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 tolerant and generic traits are added to the GGS. + These are not shown in the algorithm, as these traits are tools in making + the algorithm behaves 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 no limits in the GGS on the number + of players connecting, for example. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status collapsed + +\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, de-registering 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 played. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Performance +\end_layout + +\begin_layout Standard +There are many ways in which performance could be measured. + For the clients, time and response times are useful measurements in time + critical settings. + In non-time critical settings, the reliability of message delivery may + be an even more important factor than speed. +\end_layout + +\begin_layout Standard +In a first person shooter game, the speed of delivery of messages is essential. + 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 perceieved 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 practical results for the prototype is discussed in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Implementation-of-a" + +\end_inset + +. +\end_layout + +\begin_layout Subsection +Performance measurements +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\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 temperetur +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 + + +\end_layout + +\begin_layout Standard +How many players can we have on a server? Performance differences between + games? e.g can one game have thousands players on a server and another only + have hundreds? Questions +\end_layout + +\begin_layout Standard +In the current state game servers is coded for each game that needs it, + in many cases this seems like a bad solution. + Developers that want to make a network game need to understand network + programming. + A way to change this is a generic game server which give the game developers + a server which they implement their game towards. + 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. + to be discussed here. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Create a game with several thousand players, see how our server scales, + how can we improve the performance? Sharding isn’t very nice.. + alternatives? Improve the speed of sharding? +\end_layout + +\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 +Choice of network protocol +\begin_inset CommandInset label +LatexCommand label +name "sec:Choice-of-network" + +\end_inset + + +\end_layout + +\begin_layout Standard +There are two main ways in which computer communication over the Internet + usually takes place; TCP, UDP are known network layer protocols and HTTP + is the most prominent application layer protocol. + The transport layer protocols, are commonly used to transport application + layer protocols, such as HTTP. + TCP and UDP can not be used on their own, without an application layer + protocol on top. + Application layer protocols such as HTTP on the other hand needs a transport + layer protocol in order to work. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{HTTP}}{Hyper Text Transport Protocol, a network protocol commonly + used to deliver web pages} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +HTTP +\end_layout + +\begin_layout Standard +Since HTTP is so widely used on the Internet today in web servers, it is + available on most Internet connected devices. + This means that if HTTP is used in the GGS, firewalls will not pose problems, + which is a great benefit. + However, due to the intended usage of HTTP in web servers, the protocol + was designed to be stateless and client-initiated. + In order to maintain a state during a game session using HTTP, some sort + of token would have to be passed between client and server at all times, + much like how a web server works. + These facts combined makes HTTP unsuitable for our purposes, since 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, + and what is said about TCP also applies to HTTP. + +\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 the data transferred is in good shape, some sort of error checking + mechanisms must be implemented. + UDP is a good choice for applications where it is more important that data + arrives in a timely manner than that all data arrives undamaged, it is + thus very suitable for media streaming, for example. + In the GGS reliability of transfer was chosen before the speed of the transfer, + ruling out UDP as the transport later protocol. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Perhaps we should only say that we chose TCP just for our GGS prototype + and why. + If we leave it like that it seems that we think it is not suitable. +\end_layout + +\end_inset + + +\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. + In the GGS, data consistency is more important than transfer speeds, and + thus TCP is a better alternative than UDP. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Same here it is simply not true for a generic server to chose one or the + other. + We should rephrase it so it is clear that we only state it about the GGS + prototype. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Generic +\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 any kind of game. + Any game with a client-server behaviour should be perfectly suited for + GGS. + 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. + Such as different programming languages. + The GGS should be OS independent and run on Windows, OSX 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 independent hardware. + It is meant to run any game in any environment in any way desired, therefor + being as generic as possible. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Bad name of the chapter, but here we should give the theory of how the server + is generic +\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 +Fault tolerance is an important factor in all servers, a server that is + fault tolerant should be able to follow a given specification when parts + of the system failures. + This means that fault tolerance is different in each system depending on + what specification they have. + A system could be fault tolerant in different aspects, one is where the + system is guaranteed to be available but not safe and it could also be + reversed, that the system is safe but not guaranteed to be available. + Depending on the system one property may be more important(some example + here). + A system could also have non existent fault tolerance or it could be both + safe and guaranteed to be available. + 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 but it has features that + support and encourage the development of fault tolerant systems. + In the GGS it is important that the system overall is fault tolerant. + Crashes of the whole system should be avoided as this would make the system + unusable for a time. + By using supervisor structures it is possible to crash and restart small + parts of the system, this is convenient as fault 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 typ 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, in brief good fault tolerance is + a way of satisfying customers. + In general, game servers differ from many other fault tolerant systems + in that high-availability is more important than the safety of the system. + For example a simple calculation error will not be critical for a game + server but it may be in a life-critical system and then it is better that + the system crashes than works with the faulty data. + There are cases where safety may be critical in game servers, one example + is in games where in-game money exist. +\end_layout + +\begin_layout Subsubsection +Performance penalties +\end_layout + +\begin_layout Section +Availability +\begin_inset CommandInset label +LatexCommand label +name "sec:Availability" + +\end_inset + + +\end_layout + +\begin_layout Standard +One important factor of any server is the availability. + A server to which you are unable to connect to is an useless server. + Other then within telecommunication, their uptime is of about 99,9999999%, + the game developer community has not approached this problem very genuinely + yet so there is much room for improvement. +\end_layout + +\begin_layout Standard +There are several good papers on how to migrate whole virtual machines among + nodes to replicate them +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add more information about that +\end_layout + +\end_inset + + but for the GGS a different approach has been chosen. + Instead of just duplicating a virtual machine, the programming language + Erlang has been used which offers several features to increase the availability. + Some of them are +\emph on +hot code replacement +\emph default +, where code can be updated while the application is running and without + the need to restart it, the +\emph on +supervisor structure +\emph default + provided by +\emph on +OTP +\emph default + and the inter node and process communication via +\emph on +messages +\emph default + instead of shared memory. + We will discuss each of them later on. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Supervisor}}{A process monitoring and hadning crashes in other processes} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Scalability +\begin_inset CommandInset label +LatexCommand label +name "sec:Scalability" + +\end_inset + + +\end_layout + +\begin_layout Standard +Each instance of the GGS contains several tables. + Each table is an isolated instance of a game, for example a chess game + or a poker game. + The way that the GGS scales is to distribute these tables on different + servers. + In many games it is not necessary for a player to move among tables during + games. + This is for example not a common occurrence in chess, where it would be + represented as a player standing up from her current table and sitting + down at a new table, all within the same game session. + Therefore, the main focus of the GGS is not to move players among tables, + but to keep a player in a table, and to start new tables instead. + When a server has reached a certain number of players the performance will + start to decrease. + 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 and find out how many players that are optimal + for each server. + This approach makes it possible to use all resources with moderate load, + instead of having some resources with heavy load and some with almost no + load. +\end_layout + +\begin_layout Standard +As mentioned in the purpose section there are two different types of scalability +, structural scalability and load scalability. + To make the GGS scalable both types of scalability are needed. + Structural scalability means in our case that it should be possible to + add more servers to an existing cluster of servers. + By adding more servers the limits of how many users a system can have is + increased. + Load scalability in contrast to structural scalability is not about how + to increase the actual limits of the system. + Instead it means how good the system handles increased load. + The GGS should be able to scale well in both categories. +\end_layout + +\begin_layout Subsection +Load balancing +\end_layout + +\begin_layout Standard +The need for load balancing varies among different kind of systems. + Small systems that only use one or a couple of servers can cope with a + simple implementation of it, while in large systems it is critical to have + extensive and well working load balancing. + The need also depends on what kind of server structure that the system + works on. + A static structure where the number of servers are predefined or a dynamic + structure where the number varies. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Amazon EC2}}{A cloud computation service} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Load balancing and scaling is difficult in different scenarios. + When running in a separate server park, there are a set number of servers + available, this means that an even distribution on all servers is preferable. + When running the GGS in a cloud, such as Amazon EC2, it is possible to + add an almost infinite number of servers as execution goes on. + 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 load + becomes too high on all of them, then comes a new problem: +\end_layout + +\begin_deeper +\begin_layout Itemize +How do we distribute load on these new servers? +\end_layout + +\end_deeper +\begin_layout Standard +Load balancing is a key component to achieve scalability in network systems. + The GGS is a good example of a system that needs to be scalable, to attain + this load balancing is necessary. + Optimization of the load balancing for a system is an important task to + provide a stable and fast load balancer. + There are certain persistence problems that can occur with load balancing, + if a player moves from a server to another data loss may occur. + This is an important aspect to consider when the load balancer is designed + and implemented. +\end_layout + +\begin_layout Standard +Load balancing can often be implemented using dedicated software, this means + that in many applications load balancing may not be implemented because + it already exist functional solutions. + This depends on what specific needs the system have and a minor goal of + the project is to analyze whether the GGS project can use existing load + balancing tools or if it is necessary 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 + + +\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 +\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 +Inside the GGS, everything has a unique identifier. + There are identifiers for players, tables and other resources. + When players communicate amongst each other, or communicate with tables, + they need to be able to uniquely identify all of these resources. + Within one machine, this is mostly not a problem. + A simple system with a counter can be imagined, where each request for + a new ID increments the previous identifier and returns the new identifier + based off 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 lock, which may work well in many concurrent systems. + In a distributed system, this lock, along with the state, would have to + be distributed. + If the lock is not distributed, no guarantee can be made that two nodes + in the distributed system do not generate the same number. + 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. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{MAC Address}}{Media Access Control address, used to identify network + cards} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SHA-1}}{Cryptigraphic hash function, designed by the National Security + Agency (NSA)} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +According to +\begin_inset CommandInset citation +LatexCommand citet +key "Leach98uuidsand" + +\end_inset + +, +\begin_inset Quotes eld +\end_inset + +A UUID is 128 bits long, and if generated according to the one of the mechanisms + in this document, is either guaranteed to be different from all other UUIDs/GUI +Ds generated until 3400 A.D. + or extremely likely to be different +\begin_inset Quotes erd +\end_inset + +. + This 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 + ID:s. + The gathered data is then +\emph on +hashed +\emph default + +\begin_inset space ~ +\end_inset + +using an algorithm such as SHA-1. +\end_layout + +\begin_layout Standard +When using system wide unique identifiers, such as the ones generated by + algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + + with mutual exclusion, it is not possible to have identifier collisions + when recovering from network splits between the GGS clusters. + Consider figure +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:network-split" + +\end_inset + +, where +\emph on +Site A +\emph default + is separated from +\emph on +Site B +\emph default + by a faulty network (illustrated by the cloud and lightening bolt). + 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 ID:s 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 UUID:s solve. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Network split}}{Separation of two networks, occurs when two networks + can not communicate, commonly because of a hardware or software failiure} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/netsplit2.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add clients on each side, and replace the cloud with phole-landlines being + cut by a pair of scissors +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:network-split" + +\end_inset + +An example of a network split +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Security +\end_layout + +\begin_layout Standard +We only support languages running in a sandboxed environment. + Each game session is started in its own sandbox. + The sandboxing isolates the games in such a way that they can not interfere + with each other. + If sandboxing was not in place, one game could potentially modify the contents + of a different game. + A similar approach is taken with the persistent storage we provide. + In the storage each game has its own namespace, much like a table in a + relational database. + A game is not allowed to venture outside this namespace, and can because + this not modify the persistent data of other games. + of 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 Subsection +Encryption +\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 +There is only a very limited number of game developers who would like to + write their games in Erlang, therefore we had to come up with something + to resolve this problem. + The main idea was to offer a replacable module which would introduce a + interface to different virtual machines which would run the game code. + This way a game developer can write the game in his favourite language + while the server part still is written in Erlang and can benefit from all + of its advantages. +\end_layout + +\begin_layout Subsection +JavaScript +\end_layout + +\begin_layout Standard +JavaScript has gained a lot of popularity lately, it is used in large projects + such as +\emph on +Riak +\emph default + +\begin_inset Foot +status open + +\begin_layout Plain Layout +\begin_inset Flex URL +status collapsed + +\begin_layout Plain Layout + +http://wiki.basho.com/An-Introduction-to-Riak.html +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +, +\emph on +CouchDB +\emph default + +\begin_inset Foot +status open + +\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 open + +\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. + The popularity of JavaScript in the programming community, in combination + with the availability of several different JavaScript virtual machines + was an important influence in choosing JavaScript as the main control language + for our GGS prototype. +\begin_inset ERT +status 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 +, +\emph on +ActionScript +\emph default + are suitable as well because 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 our 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. +\end_layout + +\begin_layout Standard +Due lack of time we have decided to use just the Erlang <-> JavaScript bridge + with our interface. +\end_layout + +\begin_layout Section +Testing +\end_layout + +\begin_layout Standard +There are several ways in which the GGS can be tested. + The most important aspect has been deemed to be the experience players + have when using the GGS. + In order 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 need not participate in the same instance of the game, games + such as chess are prime candidates for the GGS. +\end_layout + +\begin_layout Standard +When developing the GGS, two main categories of games exhibiting different + performance demands were identified; real-time games and turn-based games. + The real-time games were deemed more demanding than the turn based games. + Tests were carried out using a real time game, since this is the more demanding + type of games. +\end_layout + +\begin_layout Standard +The real time game chosen for testing the GGS is +\emph on +Pong +\emph default +, a game in which two players play a game involving a all and two paddles. + The goal for each player is to shoot eside the othre player's paddle while + not allowing the ball to pass by her own paddle. + The game requires real time updates and is quite 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 were performed on the GGS, and the results of these tests + are visible in chapter +\begin_inset CommandInset ref +LatexCommand ref +reference "chap:Results-and-discussion" + +\end_inset + +. + The tests were initially performed by starting an operating system process + for each player. + Due to lack of hardware, not enough player processes could be started in + this way. + The bots were re-written in Erlang, and due to Erlang's light weigh threads, + enough processes could be created to successfully test the server. +\end_layout + +\begin_layout Chapter +Implementation of a prototype +\begin_inset CommandInset label +LatexCommand label +name "cha:Implementation-of-a" + +\end_inset + + +\end_layout + +\begin_layout Standard +This chapter contains the realization of much of the principles and techniques + described in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Theory" + +\end_inset + +. + Here the problems and their solutions are discussed in greater detail, + and at times the text becomes more specific to GGS. +\end_layout + +\begin_layout Standard +Much of what is discussed in this chapter has been implemented in the Erlang + GGS prototype. + Specific solutions such as +\emph on +supervisor structures +\emph default +and distribution of erlang nodes on physical nodes. + The different means of communications within the GGS and outside the GGS + with third parties are also discussed here. +\end_layout + +\begin_layout Section +Overview of the prototype +\end_layout + +\begin_layout Standard +The prototype of the GGS was developed using the Erlang language. + The functional and concurrent style of Erlang facilitates devlopment of + software based on a real-world model +\begin_inset CommandInset citation +LatexCommand citep +key "armstrong2011" + +\end_inset + +. + In Erlang, most things are processes. + The software running the Erlang code is known as the Erlang machine, or + an Erlang node. + Each Erlang node is capable of running several +\emph on +threads +\emph default +(also known as +\emph on +Light Weight Processes; LWP +\emph default +) +\emph on +, +\emph default +much like the threads in an operating system. + Threads in a Linux system, for example, are treated much like operating + system processes in different systems. + Due to the size of datastructures related to each process, swapping one + process for another (known as +\emph on +context switching +\emph default +) is an expensive task in many systems +\begin_inset CommandInset citation +LatexCommand citep +after "pg 80" +key "McKusick:2004:DIF:1014910" + +\end_inset + +. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{LWP}}{Light Weight Process} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Context switch}}{The act of switching from one context, commonly + a process, to another. + Used by operating systems to achieve multi tasking} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The cost of swapping operating system processes becomes a problem when many + processes are involved. + If the GGS system had been developed using regular operating system processes, + it would have had to be designed in a way to minimize the number of processes. + Using Erlang, which is capable of running very many processes, several + times more than an operating system can, the mapping between the real world + system (described in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Design-of-the" + +\end_inset + +) becomes clearer. +\end_layout + +\begin_layout Standard +Erlang allows the GGS to create several process for each player connecting, + these processes can handle a multitude of different tasks, parsing data + for example. + Since each task is handled by a different process, the tasks are clearly + separated and the failiure of one is easily recovered without affecting + the others. +\end_layout + +\begin_layout Standard +In addition to creating (or +\emph on +spawning +\emph default +) processes specifically to handle new players connecting, the GGS has more + permanent processes running at all times. + The constantly running processes in the GGS system are called +\emph on +modules +\emph default +. + An example of a module in the GGS is the +\emph on +dispatcher module +\emph default +, which handles the initial connection made by a client, passing the connection + along further in to the system. +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/Chess_no_text.eps + width 100text% + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:The-layout-of" + +\end_inset + +The layout of the GGS. + The circles marked with 'C' topmost in the picture represent clients. + The cloud marked 'network' pictured directly below the clients can be any + network, for example the Internet. + The barell figure marked 'backup' is a process being fed backup data from + the coordinator. + The barell 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 gamers' + machines will be chess game clients. + Clients connect through a network, pictured as a cloud, to the dispatcher + process in the GGS. + The dispatcher process and all other modules are discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:The-modular-structure" + +\end_inset + +. + For each connection, a new player process is spawned, which immediately + after spawning is integrated in to the GGS by the coordinator process. +\end_layout + +\begin_layout Section +The usage of Erlang in the GGS +\begin_inset CommandInset label +LatexCommand label +name "sec:The-usage-of-erlang" + +\end_inset + + +\end_layout + +\begin_layout Standard +Erlang was designed by Ericsson, beginning in 1986, for the purpose of creating + concurrent applications and improving telecom software. + Features essential for the telecom instustry to achieve high availability + in telecom switches were added to the language. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Mutex}}{A construct for achieving mutial exclusion, used to avoid + simultaneous access to shared resources in computer systems} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Erlang uses message passing in favour of shared memory, mutextes and locks, + something which at the time was controversial among fellow developers +\begin_inset CommandInset citation +LatexCommand citet +key "Armstrong:2010:ERL:1810891.1810910" + +\end_inset + +. + The reason for using message passing, according to Armstrong, was that + applications should operate correctly before optimizations are done, where + efficient internal communication within the Erlang machine was considered + a later optimization. +\end_layout + +\begin_layout Standard +In using message passing in favour of the methods commonly used at the time, + the issues commonly associated with shared memory and locking were avoided. + In Erlang, everything is a process, and everything operates in its own + memory space. + Memory can not be shared among processes, which prohibits a process from + corrupting the memory of a different process. +\end_layout + +\begin_layout Standard +Messages are sent between the processes in an asynchronous manner, and each + process has a mailbox in which these messages can be retrieved. +\end_layout + +\begin_layout Standard +Processes in Erlang are also called +\emph on +Light Weight Processes. + +\emph default +The Erlang processes are very cheaply created. + Processes exist within an Erlang machine, or Erlang node. + The Erlang machine has its own scheduler and does not rely on the operating + system's scheduler, this is a main reason of Erlang's capability of running + many concurrent processes +\begin_inset CommandInset citation +LatexCommand citet +key "Armstrong03" + +\end_inset + +. +\end_layout + +\begin_layout Standard +The strong isolation of Erlang processes make them ideal for multicore and + distributed systems. + Distribution of software is included as a fundamental part in the Erlang + language. + The 'physical' location of a process, e.g. + which computer the process runs on, is not important when communicating + with the process. + Processes can communicate regardless of whether they run on the same system + of not, transparently. +\end_layout + +\begin_layout Standard +The distributed nature of Erlang is something the GGS makes use of when + scaling across several computers in order to achieve higher performance. + The distribution is also important in creating redundancy. + Erlang promotes a non-defensive programming style in which processes are + allowed to crash and be restarted in favour of having the processes recover + from errors. + The distributed nature of Erlang means supervisor processes (discussed + in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Supervisor-structure" + +\end_inset + +) can reside on remote systems, thereby increasing the reliability of the + system as a whole. +\end_layout + +\begin_layout Standard +A very important feature of Erlang, used in the GGS, is the ability to interface + with external hardware and software. + Erlang allows communication with external resources through +\emph on +ports +\emph default + and +\emph on +NIF +\emph default +:s (Native implemented functions) +\emph on +. + +\emph default + Through ports communication can take place much in the same way communication + is performed over sockets. + NIF:s are called like any other functions without any difference to the + caller but are implemented in C. +\end_layout + +\begin_layout Standard +The GGS uses Erlang ports for generating UUID:s +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +UUID:s are discussed in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:UUID" + +\end_inset + + +\end_layout + +\end_inset + + and NIF:s for interfacing with the virtual machines of games +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +Virtual machines of games are discussed in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Game-Development-Language" + +\end_inset + + +\end_layout + +\end_inset + +. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{OTP}}{Open Telecom Platform, a software suite for Erlang} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Behaviour}}{A design pattern in OTP} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Development of the GGS would have been hard if not impossible had it not + been for the +\emph on +OTP +\emph default + supplied with the standard Erlang distribution. + The OTP (Open Telecom Platform) is a set of standard libraries and design + patterns, called +\emph on +behaviours +\emph default +, which are used when developing Erlang systems. +\end_layout + +\begin_layout Standard +The GGS makes heavy use of the behaviours supplied in the OTP. + The behaviours impose a programming style suitable for distributed and + concurrent applications, perfectly suitable for the GGS. + In particular, the GGS uses the following behaviours: +\end_layout + +\begin_layout Itemize +The +\emph on +supervisor +\emph default + behaviour, which is used when creating a supervisor. + Supervisors are used when monitoring processes in the Erlang system. + When a process exits wrongfully, the supervisor monitoring the process + in question decides which action to take. + In the GGS, the most common action is simply to restart the faulting process. + A more thorough discussion on supervisors can be found in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Supervisor-structure" + +\end_inset + +. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_tcp +\emph default +behaviour, which is used to work with TCP sockets for network communication. + Using the gen_tcp behaviour, 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 + behaviour, which is used when constructing OTP servers in Erlang. + Using this behaviour, a state can easily be kept in a server process, greatly + increasing the usefulness of the server process. + There are many gen_servers in the GGS, it is the most widely used behaviour + in the project. + In addition to intruducing a state to the server, the gen_server behaviour + also imposes patterns for synchronous and asynchronous communication between + other gen_servers and other OTP behaviours. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_fsm +\emph default + behaviour is used in the protocol parser module in the GGS. + Using the gen_fsm behaviour, 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 behaviours, the OTP also has a style for packaging + and running Erlang applications. + By packaging the GGS as an +\emph on +application +\emph default +the GGS can be started in a way uniform to most erlang software, providing + familiarity for other Erlang users, and eases the incorporation of the + GGS in other applications. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Application}}{A way of packaging Erlang software in a uniform way} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Short introduction to the Erlang syntax +\end_layout + +\begin_layout Standard +In order to understand examples in this thesis, a small subset of Erlang + must be understood. + In this section, the very syntactic basics of Erlang are given. +\end_layout + +\begin_layout Itemize + +\series bold +Variables +\series default + start with an uppercase letter, examples include +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt X, Var}, and { +\backslash +tt Global} +\end_layout + +\end_inset + +. + A variable can only be assigned once. +\end_layout + +\begin_layout Itemize + +\series bold +Atoms +\emph on + +\series default +\emph default +start with lower case letters, for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + + { +\backslash +tt atom, a} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Functions +\series default + are defined starting with an atom for the name, parenthesis containing + parameters, an arrow, a function body and finally a dot marking the end + of a function. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt square(X) -> X*X.} +\end_layout + +\end_inset + + is an example of a function producing the square of X. +\end_layout + +\begin_layout Itemize +Functions are +\series bold +called +\series default + by suffixing an atom with the function name with parenthesis, for example + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt square(10)} +\end_layout + +\end_inset + +. + Qualified names can be specified using ':', for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt math:square(10)} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Tuples +\series default + are containers of fixed type for Erlang data types. + They are constructed using curly brackets, for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt +\backslash +{atom1, atom2, atom3 +\backslash +}}. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Itemize + +\series bold +Lists +\series default + are constructed using [ and ], for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt [1,2,3]} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Strings +\series default + doubly qouted 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 refering 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 +Communication with external systems and applications +\begin_inset CommandInset label +LatexCommand label +name "sec:Communication-with-external" + +\end_inset + + +\end_layout + +\begin_layout Standard +A game launched on the GGS is run within a virtual machine. + For each programming language supported, there is a virtual machine that + interprets the game. + Furthermore an interface for communication between the GGS, the game and + the players playing the game must be present. +\end_layout + +\begin_layout Standard +The reason for the GGS requiring a communication channel between the game + VM and Erlang is in part because the GGS makes heavy use of callbacks. + 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 between players. + The interface provides access to three objects called +\emph on +world +\emph default +, +\emph on +player +\emph default + and +\emph on +localstorage +\emph default +. + The game state is safely stored in a database and retrieved for manipulation + by a call for the world object. + Interaction with the players is done the same way using the player object + instead. + The localstorage is a convenient way to store globals and other data seperated + from the game state. + In section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Exposing-Erlang-functionality" + +\end_inset + + a concrete example of the implementation of the localStorage and world + objects is given. +\begin_inset Note Note +status open + +\begin_layout Plain Layout + Unique id:s called gametokens are generated for hosted games so that they + are not mixed up. + -- good text, integrate more. +\end_layout + +\end_inset + + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{WebStorage}}{A new standard for letting websites store data on visitors' + computers} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Exposing Erlang functionality to the GDL VM +\begin_inset CommandInset label +LatexCommand label +name "sub:Exposing-Erlang-functionality" + +\end_inset + + +\end_layout + +\begin_layout Standard +This section contains a concrete example of how the localStorage and world + objects are exposed to a GDL VM. + The example comes from the GGS prototype, which uses JavaScript powered + by Google V8 as its GDL VM. +\end_layout + +\begin_layout Standard +The code given in +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:exposing-erlang" + +\end_inset + + is specific to V8 and JavaScript, however implementations for different + GDL:s, or different JavaScript VM:s should be similar. +\end_layout + +\begin_layout Standard +In JavaScript is is common to use a top level object, called a global object, + to establish a global scope. + This allows declaration of global variables and functions. + To gain access to the global object in the GGS, the +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt erlv8 +\backslash +_vm:global(..)} +\end_layout + +\end_inset + + function on line 2 of the example is used. + Using the global object, declarations of the world and GGS object can be + placed in the global scope. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt Global:set +\backslash +_value(..)} +\end_layout + +\end_inset + + is a call to the global object, declaring new objects in the global scope. + On line 4 the GGS object is declared. + By accessing +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt GGS.localStorage } +\end_layout + +\end_inset + + from within the GDL, access to the localstorage is provided, thus the localstor +age must be connected to the GGS object, this can be seen in line 5. +\end_layout + +\begin_layout Standard +Both the GGS and localStorage objects are dummy objects, which provide no + functionality, these two objects are simply placed in the GDL for the purpose + clearing up the code. + In order to perform an action using the GGS and localStorage objects, the + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt getItem} and { +\backslash +tt setItem} +\end_layout + +\end_inset + + functions must be used. + These items are directly connected to the database module of the GGS, which + is discussed in more detail in +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:The-database-module" + +\end_inset + +. +\end_layout + +\begin_layout Standard +Similarly the functions +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt sendCommand, sendCommandToAll} and { +\backslash +tt setTimeout} +\end_layout + +\end_inset + + are directly connected to a piece of code in the GGS which performs the + desired action. + The +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt sendCommand} +\end_layout + +\end_inset + + functions are used to send commands or text to participants of the table. + The +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt setTimeout} +\end_layout + +\end_inset + + function introduces timeouts to the V8 engine, which are not available + per default. +\end_layout + +\begin_layout Standard +\begin_inset 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", fund(#erlv8_fun_invocation{}, [Time, Function])-> +\end_layout + +\begin_layout Plain Layout + + timer:apply_after(Time, ?MODULE, call_js, [GameVM, Function]) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])). +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:exposing-erlang" + +\end_inset + +An example of how Erlang functionality is exposed to a Javascript GDL +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +TODO: Go in to more detail about how the world, player and localstorage + objects are implemented. + Also discuss localstorage and how it derives from the webstorage standard + in detail. + This is a great point on how we try to follow standards. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +My idea here is that we describe the erlang-js (which failed, but nontheless), + v8, UUID and other external communication. + We shouldn't describe sockets here though.. + or.. + maybe? +\end_layout + +\begin_layout Plain Layout +Also discuss how we allow GDLs to communicate with Erlang, this is +\begin_inset Quotes eld +\end_inset + +external +\begin_inset Quotes erd +\end_inset + + to thre GDL. + Discuss the GGS world object (there is a reference to this secxtion for + that purpose) +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +The modular structure of the GGS prototype +\begin_inset CommandInset label +LatexCommand label +name "sec:The-modular-structure" + +\end_inset + + +\end_layout + +\begin_layout Standard +The separation of concerns, and principle of single responsibility +\begin_inset Foot +status open + +\begin_layout Plain Layout +More information on the SRP is available at: +\begin_inset CommandInset href +LatexCommand href +target "http://www.objectmentor.com/resources/articles/srp.pdf" + +\end_inset + + +\end_layout + +\end_inset + + are widely respected as good practices in the world of software engineering + and development. + By dividing the GGS up into modules each part of the GGS can be modified + without damaging the rest of the system. +\end_layout + +\begin_layout Standard +The responsibility and concern of each module comes from the responsibility + and concern of the real-world entity the model represents. + The modelling of the GGS after a real world system was discussed in chapter + +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Theory" + +\end_inset + +. +\end_layout + +\begin_layout Standard +In the text below the word module refers to the actual code of the discussed + feature, while the word process is used when referring to a running instance + of the code. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SRP}}{Single Responsibility Principle} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Object Oriented Programming}}{A programming paradigm focusing on + objects} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +The dispatcher module +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +The discussion of the modules is divided into the following parts: +\end_layout + +\begin_layout Itemize +What does the module do? +\end_layout + +\begin_layout Itemize +What happens when the module fails? +\end_layout + +\begin_layout Itemize +How does the module correspond to the real-world scenario of the chess club? +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The dispatcher module is the first module to have contact with a player. + When a player connects to the GGS, it is first greeted by the dispatcher + module, which sets up an accepting socket for each player. + +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout +Is this the proper way to day the dispatcher greets connecting players? +\end_layout + +\end_inset + + The dispatcher is the module which handles the interfacing to the operating + system when working with sockets. + Operating system limits concering the number of open files, or number of + open sockets are handled here. + The operating system limits can impose problems on the GGS, this is discussed + more in detail in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Problems-of-implementation" + +\end_inset + +. +\end_layout + +\begin_layout Standard +Should the dispatcher module fail to function, no new connections to the + GGS can be made. + In the event of a crash in the dispatcher module, a supervisor process + immediately restarts the dispatcher. + There exists a window of time between the crashing of the dispatcher and + the restarting of the dispatcher, this window is very short, and only during + this window is the GGS unable to process new connection requests. + Due to the modular structure of the GGS, the rest of the system is not + harmed by the dispatcher process not functioning. + The process does not contain a state, therefore a simple restart of the + process is sufficient in restoring the GGS to a pristine state after a + dispatcher crash +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Well.. + In theory.. +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Standard +Returning to scenario of the chess club, the dispatcher module is the doorman + of the club. + When a player enters the chess club, the player is greeted by the doorman, + letting the player in to the club. + The actual letting in to the club is in the GGS represented by the creation + of a player process discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-player-module" + +\end_inset + +. + The newly created player process is handed, and granted rights to, the + socket of the newly connected player. +\end_layout + +\begin_layout Subsection +The player module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-player-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +The player module is responsible for representing a player in the system. + Each connected player has its own player process. + The player process has access to the connection of the player it represents, + and can communicate with this player. + In order to communicate with a player, the data to and from the player + object must pass through a protocol parser module, discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-protocol-parser" + +\end_inset + +. + Raw communication, witout passing the data through a protocol parser is + in theory possible, but is not useful. +\end_layout + +\begin_layout Standard +In the creation of a player process, the coordinator process, discussed + in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-coordinator-module" + +\end_inset + +, is notified by the newly connected process. +\end_layout + +\begin_layout Standard +In the event of a crash in a player process, several things happen. + +\end_layout + +\begin_layout Enumerate +The player process, which is the only process with a reference to the socket + leading to the remote client software, passes this reference of the socket + to the coordinator process temporarily. +\end_layout + +\begin_layout Enumerate +The player process exits. +\end_layout + +\begin_layout Enumerate +The coordinator spawns a new player process, with the same socket reference + as the old player process had. +\end_layout + +\begin_layout Enumerate +The player process resumes operation, immediately starting a new protocol + parser process, and begind receiving and sending network messaged again. +\end_layout + +\begin_layout Standard +The window of time between the crash of the player process and the starting + of a new player process is, as with the dispatcher, very short. + Since the connection changes owners for a short period of time, but is + never dropped, the implications of a crash are only noticed, at worst, + as choppy gameplay for the client. + Note however that this crash recovery scheme is not implemented in the + GGS prototype. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Can we do this..? Seems a bit sneaky. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Moving back to the real world example, the player process represent an actual + person in the chess club. + When a person sits down at a table in the chess club, the person does so + by requesting a seat from some coordinating person, and is then seated + by the same coordinator. + Once seated, the player may make moves on the table he or she is seated + by, this corresponds clearly to how the GGS is structured, as can be seen + in the following sections. +\end_layout + +\begin_layout Subsection +The protocol parser module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-protocol-parser" + +\end_inset + + +\end_layout + +\begin_layout Standard +The protocol parser is an easily interchangable 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 prototocol 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 modelled after the HTTP protocol. + The main reason for this is the familiarity many developers already have + with HTTP due to its presence in internet software. + Each GGS protocol packet contains a headers section. + The headers section is followed by a data section. + In the headers section, parameters concerning the packet is placed. + In the data section, the actual data payload of the packet is placed. +\end_layout + +\begin_layout Standard +There is no requirement of any specific order of the parameters in the headers + section, however the data section must always follow directly after the + headers section. +\end_layout + +\begin_layout Standard +In the example below, line 1 contains a Game-Command parameter. + This parameter is used to determine which game-specific command the client + is trying to perform. + The handling of this parameter is specific to each game, and can be anything. +\end_layout + +\begin_layout Standard +Line 2 specifies a game token. + This is a UUID which is generated for each client upon authentication with + the GGS. + The GGS uses this token in case a client is disconnected and the new connection + created when the client reconnects must be re-paired with the player object + inside the GGS. + The UUID is also used as a unique ID within GDL VMs. +\end_layout + +\begin_layout Standard +Line 3 specifies the content type of the payload of this particular packet. + This parameter allows the GGS to invoke special parsers, should the data + be encoded or encrypted. + When encryption is employed, only the payload is encrypted, not the header + section. + This is a scheme which does not allow for strong encryption, but is deemed + feasible for gaming purposes. +\end_layout + +\begin_layout Standard +Line 4 specifies the content length of the payload following immediately + after the headers section. +\end_layout + +\begin_layout Standard +The parser of the GGS protocol implemented in the GGS prototype is designed + as a finite state machine using the gen_fsm behaviour. + When a full message has been parsed by the parser, the message is converted + into the internal structure of the GGS messages, and sent in to the system + from the protocol paser using message passing. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Packet below is not an algorithm, but I don't know how to change that label.. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting} +\end_layout + +\begin_layout Plain Layout + +Game-Command: chat +\end_layout + +\begin_layout Plain Layout + +Token: e30174d4-185e-493b-a21a-832e2d9d7a1a +\end_layout + +\begin_layout Plain Layout + +Content-Type: text +\end_layout + +\begin_layout Plain Layout + +Content-Length: 18 +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + +Hello world, guys! +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-sample-packet" + +\end_inset + +A sample packet sent from a client to the GGS during a chat session +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Mention that the protocol is heavily influenced bye HTTP, is parsed using + a FSM, perhaps give a sample packet. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +The coordinator module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-coordinator-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +The coordinator module is responsible for keeping track of all players, + their seats and tables. + Players register with the coordinator process when first connecting to + the server, and the coordinator places each player by their respective + table. +\end_layout + +\begin_layout Standard +The coordinator keeps mappings between each player and table, therefore + it is used to perform lookups on tables and players to find out which are + connected. + The connectivity of players and tables is important when sending messages + to all participants in a game. + A lookup in the coordinator process is performed prior to notifying all + players in a game to ensure the message reaches all players. + The lookup can be performed either using internal identification codes + or using the UUID associated with each client and table. +\end_layout + +\begin_layout Standard +The coordinator process contains important state, therefore a backup process + is kept at allt times. + All good data processed by the coordinator is stored for safekeeping in + the backup process as well. + Data which is potentisally harmful is not stored in the backup process. +\end_layout + +\begin_layout Standard +Upon a crash, the coordinator process recovers the prior good state from + the backup process and continues where it left off. + A supervisor process monitors the coordinator process and restarts the + process when it malfunctions. + There is a window of time between the crash of the coordinator and the + restarting of the coordinator, during this time, players can not be seated + by new tables, and can not disconnect from the server. + This window of time is very small, and the unavailability of the coordinator + process should not be noticed by more than a short time lag for the clients. +\end_layout + +\begin_layout Standard +Moving back to the example of the chess club, the coordinator process can + be seen as a judge, monitoring all moves of the players. + At the same time as acting as a judge, the coordinator process is also + a host in the chess club, seating players by their tables and offering + services to the players. +\end_layout + +\begin_layout Subsection +The table module +\end_layout + +\begin_layout Standard +The table module is mostly a hub used for communication. + New table processes are created by the coordinator on demand. + The table module does not contain any business logic, however each process + contains information concerning which players are seated by that particular + table. +\end_layout + +\begin_layout Standard +The information about which players are seated by each table is used when + notifying all players by a table of an action. + Consider a game of chess, each player notifies the table of its actions, + the table then notifies the rest of the participants of these actions after + having had the ac tions processed by the game VM, where an action could + be moving a playing piece. +\end_layout + +\begin_layout Standard +Each table is associated with a game VM. + The actions sent to a table are processed by the game VM, this is where + the game logic is implemented. +\end_layout + +\begin_layout Standard +After a crash in a table process, the entire table must be rebuilt and the + players must be re-associated with the table. + Data concerning players is kept in the coordinator process, and is restored + from there. + Data kept in the actual game is not automatically corrupted by the crash + in a table, however the table must be re-associated with the game VM is + was associated with prior to the crash of the table. + The table process maps well into the setting of the real-world chess club + scenario previously discussed. + A table works in the same way in a real world setting as in the GGS setting. +\end_layout + +\begin_layout Subsection +The game virtual machine module +\end_layout + +\begin_layout Standard +This module holds the game logic of a game and is responsible for the VM + associated with each game. + +\end_layout + +\begin_layout Standard +The game VM contains the state of the VM and a table token associated with + a running game. + GameVM is started by the table module. + The table module hands over a token to the game VM during initialization. + During initialization a new VM instance and various objects associated + to the VM instance will be created. + Callbacks to Erlang are registered into the VM and then the source code + of a game is loaded into the VM and the game is ready for startup. + The only means for a game to communicate with the VM is through usage of + a provided interface. + +\end_layout + +\begin_layout Standard +The VM itself makes it possible for the game developer to program in the + prograimming language covered by the VM. + In future releases, more game VM:s will be added to support more programming + languages. + Because the game VM keeps track of the correct table, the game developer + doesn't need to take this into consideration when programming a game. + If a method within the game sends data to a player, it will be delivered + to the player in the correct running game. + The same game token is used to store the game state in the database. + Therefore, no game states will be mixed up either. +\end_layout + +\begin_layout Standard +This module does not affect game runtime but evaluates a new game state + and handles communication between the game and the players. + A closer look at the structure of this model is given in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Communication-with-the-GDL-VM" + +\end_inset + +. +\end_layout + +\begin_layout Subsection +The database module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-database-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +Game data from all games on the GGS are stored in the database backend of + the database module. +\end_layout + +\begin_layout Standard +In the GGS prototype the database module is using a database management + system called Mnesia. + Mnesia ships with the standard Erlang distribution and is a key-value store + type database. + Mnesia is designed to handle the stress of telecoms systems, and has some + features specifically tailored for telecoms which are not commonly found + in other databases. + Key features of the Mnesia database are: +\end_layout + +\begin_layout Itemize +Fast key/value lookups +\end_layout + +\begin_layout Itemize +Distribution of the database system +\end_layout + +\begin_layout Itemize +Fault tolerance +\end_layout + +\begin_layout Standard +\begin_inset CommandInset citation +LatexCommand citet +key "667766" + +\end_inset + + +\end_layout + +\begin_layout Standard +The features of Mnesia originally intended for telecoms prove very useful + for the purposes of the GGS as well. + The fault tolerance and speed of Mnesia are very valueable tools, the fast + key/value lookups permit many lookups per second to the database. +\end_layout + +\begin_layout Standard +Game data will not be lost when a game is stopped or has gone down for unknown + reasons. + This makes it possible to continue a game just before the failure without + having to start the game from the beginning. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Mnesia}}{Database server used in the GGS} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS stores the game state in the distributed Mnesia database, from which + the state can be restored in the event of a crash. +\end_layout + +\begin_layout Standard +Each game is uniquely identified by a table token and the data of each game + is stored within two different namespaces. + The namespaces are named World and Localstorage. + The World is used contain all game data related to the game state. + This sort of game data may change during the runtime of the game. + The Localstorage should contain data independent of the game state. + Game resources, constants and globals are all examples of data that could + reside within the Localstorage. + To store a value within the database, not only is the table token and the + name of the namespace required, but a unique key so that the value can + be successfully retrieved or modified later. + The key is fully decidable by the game developer. + +\end_layout + +\begin_layout Standard +The interface of the database module is an implementation of the upcoming + W3C Web Storage specification. + Web Storage is intended for use in web browsers, providing a persistant + storage on the local machine for web applications. + The storage can be used to communicate in between browser windows (which + is difficult when using cookies), and to store larger chunks of data +\begin_inset CommandInset citation +LatexCommand citet +key "webstorage:website" + +\end_inset + +. + Usage of the web storage standard in the GGS provides a well documented + interface to the database backend. +\end_layout + +\begin_layout Subsection +A case study +\end_layout + +\begin_layout Standard +So what happens when a client sends a typical game command? Let us look + at one particular example of a chat client sending the message to change + the nick of a user (we will discuss a example implementation in JavaScript + in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Example-of-a-GGS-server-application-in-JavaScript" + +\end_inset + +). + Every communication between modules happens asynchronously, nothing is + blocking, which is very important in concurrent systems. + It is probably much easier to follow the steps by following them on +\begin_inset CommandInset ref +LatexCommand vref +reference "fig:The-layout-of" + +\end_inset + +. +\end_layout + +\begin_layout Enumerate +Client packages a Game-Command into a package which conforms to the protocol + structure the GGS is using and sends it over the network +\end_layout + +\begin_layout Enumerate +The player module, which is coupled to the TCP-module to react on incoming + messages accepts the message and forwards the raw data to the protocol + parser module +\end_layout + +\begin_layout Enumerate +The protocol parser parses the message and brings it into the format of + the internal GGS presentation of such a message, which is just a specialized + Erlang touple +\end_layout + +\begin_layout Enumerate +The protocol parser sends this Erlang touple back to the player module +\end_layout + +\begin_layout Enumerate +The player module checks if it is a Server-Command or a Game-Commane. + In our example it is a Game-Command and it sends the message to the table + module +\end_layout + +\begin_layout Enumerate +The table module sends it to its own Game VM +\end_layout + +\begin_layout Enumerate +The Game VM module calls the function +\emph on +playerCommand( +\begin_inset Quotes eld +\end_inset + +278d5002-77d6-11e0-b772-af884def5349 +\begin_inset Quotes erd +\end_inset + +, +\begin_inset Quotes eld +\end_inset + +nick +\begin_inset Quotes erd +\end_inset + +, +\begin_inset Quotes eld +\end_inset + +Peter +\begin_inset Quotes erd +\end_inset + +) +\emph default + within the JavaScript VM +\end_layout + +\begin_layout Enumerate +The JavaScript VM (JSVM) - at this stage Googles V8 JavaScript Engine - + evaluates the function within the sandboxed game context which has been + established earlier during the setup of the game. +\end_layout + +\begin_layout Enumerate +In the example ( +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Example-of-a-GGS-server-application-in-JavaScript" + +\end_inset + +) we see that the GGS-functios +\emph on +GGS.localStorage.setItem(key, value) +\emph default + and +\emph on +GGS.localStorage(key) +\emph default + are used. + Both are callbacks coupled to the database module functions. +\end_layout + +\begin_layout Enumerate +Data is being read from and written to the database and handed over to the + JSVM via the database module +\end_layout + +\begin_layout Enumerate +In the example the +\emph on +GGS.sendCommandToAll() +\emph default + is beeing called then which is a callback to a function of the table module + which iterates thrugh its player list and sends the command to every player +\end_layout + +\begin_layout Enumerate +The table module sends every player instance 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 module asks the protocol module to create a message conforming + to the protocol which is being used +\end_layout + +\begin_layout Enumerate +The protocol module creates a string according to the protocol and returns + it to the player module +\end_layout + +\begin_layout Enumerate +The player module sends the message with help of the gen_tcp module to the + client +\end_layout + +\begin_layout Section +Communication with the GDL VM +\begin_inset CommandInset label +LatexCommand label +name "sec:Communication-with-the-GDL-VM" + +\end_inset + + +\end_layout + +\begin_layout Standard +A game launched on the GGS is run within a virtual machine. + For each programming language supported, there is a virtual machine that + interprets the game. + Furthermore an interface for communication between the GGS, the game and + the players playing the game is present. +\end_layout + +\begin_layout Standard +Callbacks written in Erlang are registered to the VM for the interface to + work. + It is only with the help of the interface that the game developer can access + the game state and send messages to the clients. + The interface provides access to three objects called +\emph on +world, players +\emph default + and +\emph on +localStorage +\emph default +. + The game state is safely stored in a database and retrieved for manipulation + by a call for the world object. + Interaction with the players is done by using the +\emph on +GGS.sendCommand(player_id, command, args) +\emph default + and +\emph on +GGS. +\emph default +sendCommandToAll(command, args). + The localStorage is a convenient way to store globals and other variables + seperated from the game state. + Unique id:s called gametokens 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{WebStorage}}{A new standard for letting websites store data on visitors' + computers} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Exposing Erlang functionality to the GDL VM +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Prior to this section, the Erlang syntax has to be briefly explained. + I think the 'usage of erlang' section is a good place to do this in. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +language=Erlang, +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting}[language=Erlang] +\end_layout + +\begin_layout Plain Layout + +% @doc Exposes some GGS functions to JavaScript +\end_layout + +\begin_layout Plain Layout + +expose(GameVM, Table) -> +\end_layout + +\begin_layout Plain Layout + + Global = erlv8_vm:global(GameVM), +\end_layout + +\begin_layout Plain Layout + + Global:set_value("GGS", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"localStorage", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:setItem(Table, local_storage, Key, Val) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:getItem(Table, local_storage, Key) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])}, +\end_layout + +\begin_layout Plain Layout + + {"world", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:setItem(Table, world, Key, Val), +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command_to_all( +\end_layout + +\begin_layout Plain Layout + + Table, {"world_set", Key ++ "=" ++ Val} +\end_layout + +\begin_layout Plain Layout + + ) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:getItem(Table, world, Key), +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])}, +\end_layout + +\begin_layout Plain Layout + + {"sendCommand", fun(#erlv8_fun_invocation{}, [Player, Command, Args])-> +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command(Table, Player, {Command, Args}) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"sendCommandToAll", fun(#erlv8_fun_invocation{}, [Command, Args])-> +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command_to_all(Table, {Command, Args}) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + {"setTimeout", fun(#erlv8_fun_invocation{}, [Time, Function])-> +\end_layout + +\begin_layout Plain Layout + + timer:apply_after(Time, ?MODULE, call_js, [GameVM, Function]) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])). +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:exposing-erlang" + +\end_inset + +An example of how Erlang functionality is exposed to a JavaScript GDL +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +TODO: Go in to more detail about how the world, player and localstorage + objects are implemented. + Also discuss localstorage and how it derives from the webstorage standard + in detail. + This is a great point on how we try to follow standards. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +My idea here is that we describe the erlang-js (which failed, but nontheless), + v8, UUID and other external communication. + We shouldn't describe sockets here though.. + or.. + maybe? +\end_layout + +\begin_layout Plain Layout +Also discuss how we allow GDLs to communicate with Erlang, this is +\begin_inset Quotes eld +\end_inset + +external +\begin_inset Quotes erd +\end_inset + + to thre GDL. + Discuss the GGS world object (there is a reference to this secxtion for + that purpose) +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Techniques for ensuring reliability +\end_layout + +\begin_layout Standard +One of the main goals of the project is to achieve high reliability. + The term +\begin_inset Quotes eld +\end_inset + +reliable system +\begin_inset Quotes erd +\end_inset + + is defined by the IEEE as a system with +\begin_inset Quotes eld +\end_inset + +the ability of a system or component to perform its required functions under + stated conditions for a specified period of time +\begin_inset Quotes erd +\end_inset + + +\begin_inset CommandInset citation +LatexCommand citet +key "ieee_90" + +\end_inset + +. + There are some tools for creating reliable applications built in to Erlang. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Reliability}}{The ability of a system or component to perform its + required functions under stated conditions for a specified period of time} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{IEEE}}{Institute of Electrical and Electronics Engineers, read "I-triple- +E"} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Itemize +Links between processes. + When a process spawns a new child process, and the child process later + exits, the parent process is notified of the exit. + +\end_layout + +\begin_layout Itemize +Transparent distribution over a network of processors. + When several nodes participate in a network, it does not matter on which + of these machines a process is run. + Communication between processes does not depend on the node in which each + process is run. + +\end_layout + +\begin_layout Itemize +Hot code replacements. + Two versions of the same module can reside in the memory of Erlang at any + time. + This means that a simple swap between these versions can take place very + quickly, and without stopping the machine. +\end_layout + +\begin_layout Standard +These three features are some of the basic building blocks for more sophisticate +d reliability systems in Erlang. + Many times it is not necessary to use these features directly, but rather + through the design patterns described below. +\end_layout + +\begin_layout Subsection +Supervisor structure +\begin_inset CommandInset label +LatexCommand label +name "sub:Supervisor-structure" + +\end_inset + + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +This entire section is bad. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +By linking processes together and notifying parents when children exit, + supervisors are created. + A supervisor is a common approach in ensuring that an application functions + in the way it was intended +\begin_inset CommandInset citation +LatexCommand citet +key "Savor:1997:HSA:851010.856089" + +\end_inset + +. + When a process misbehaves, the supervisor takes some action to restore + the process to a functional state. + +\end_layout + +\begin_layout Standard +There are several approaches to supervisor design in general (when not just + considering how they work in Erlang). + One common approach is to have the supervisor look in to the state of the + process(es) it supervises, and let the supervisor make decisions based + on this state. + The supervisor has a specification of how the process it supervises should + function, and this is how it makes decisions. + +\end_layout + +\begin_layout Standard +In Erlang, we have a simple version of supervisors. + We do not inspect the state of the processes being supervised. + We do have a specification of how the supervised processes should behave, + but on a higher level. + The specification describes things such as how many times in a given time + interval a child process may crash, which processes need restarting when + crashes occur, and so forth. + +\end_layout + +\begin_layout Standard +When the linking of processes in order to monitor exit behaviour is coupled + with the transparent distribution of Erlang, a very powerful supervision + system is created. + For instance, we can restart a failing process on a different, new node, + with minimal impact on the system as a whole. + +\end_layout + +\begin_layout Standard +In the GGS, we have separated the system in to two large supervised parts. + We try to restart a crashing child separately, if this fails too many +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +Exactly how many +\begin_inset Quotes eld +\end_inset + +too many +\begin_inset Quotes erd +\end_inset + + is depends on a setting in the supervisor, ten crashes per second is a + reasonable upper limit. +\end_layout + +\end_inset + + times, we restart the nearest supervisor of this child. + This ensures separation of the subsystems so that a crash is as isolated + as possible. +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset Note Note +status open + +\begin_layout Plain Layout +We should really do this graphic in EPS instead of PNG +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/Supervisor_tree_GGS.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +The supervisor structure of GGS +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The graphic above shows our two subsystems, the coordinator subsystem and + the dispatcher subsystem. + Since these two systems perform very different tasks they have been separated. + Each subsystem has one worker process, the coordinator or the dispatcher. + The worker process keeps a state which should not be lost upon a crash. +\end_layout + +\begin_layout Standard +We have chosen to let faulty processes crash very easily when they receive + bad data, or something unexpected happens. + The alternative to crashing would have been to try and fix this faulty + data, or to foresee the unexpected events. + We chose not to do this because it is so simple to monitor and restart + processes, and so difficult to try and mend broken states. + This approach is something widely deployed in the Erlang world, and developers + are often encouraged to “Let it crash”. +\end_layout + +\begin_layout Standard +To prevent any data loss, the good state of the worker processes is stored + in their respective backup processes. + When a worker process (re)starts, it asks the backup process for any previous + state, if there is any that state is loaded in to the worker and it proceeds + where it left off. + If on the other hand no state is available, a special message is delivered + instead, making the worker create a new state, this is what happens when + the workers are first created. +\end_layout + +\begin_layout Subsection +Reduncancy +\end_layout + +\begin_layout Standard +The modules in the GGS are built to be capable of redundant operation. + By adding a backup process to sensitive processes, the state can be kept + in the event of a crash. + The coordinator of the GGS prototype has this backup feature built in. + The coordinator passes state along to the backup process which keeps the + data safe. + In the event of a crash, the coordinator recovers the state from the backup + process. + Figure +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:redundancy" + +\end_inset + + depicts the redundancy built in to the coordinator process. +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/redundancy.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:redundancy" + +\end_inset + +To the left normal execution is pictured; the server state is backed up. + To the left; the exceptional excution, where the state is retrieved from + the backup to repopulate the server. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Hot code replacement +\end_layout + +\begin_layout Standard +Hot code replacement is a technique used to update systems while they are + running. + The main use of hot code replacement are in critical systems that require + low downtime, such as telecom systems. + By using hot code replacement system can be able to achieve as high uptime + as possible and thus improving the reliability of the system. + Code replacement is a feature that exist in Erlang which means that with + some work it could be implemented into the GGS. +\end_layout + +\begin_layout Section +Example of a GGS server application in Javascript +\end_layout + +\begin_layout Standard +Below is a concrete example of a simple chat server application written + using the GGS. + The language chosen for this chat server is JavaScript. + The GGS processes all incoming data through a protocol parser, which interprets + the data and parses it into an internal format for the GGS. +\end_layout + +\begin_layout Standard +When the GGS receives a +\emph on +Game-Command +\emph default + from a client, it is passed along to the game VM through a function called + +\emph on +playerCommand +\emph default + which is the entry point for each game and has to be implemented by the + developer; one can think of it like the +\emph on +main() +\emph default + function of a C or Java programm +\emph on +. + +\emph default + Typically the +\emph on +playerCommand +\emph default + function contains conditional constructs which decide the next action to + take. + In +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-concrete-example" + +\end_inset + + an example of the +\emph on +playerCommand +\emph default + function can be seen. +\end_layout + +\begin_layout Standard +In +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-concrete-example" + +\end_inset + + the +\emph on +playerCommand +\emph default + function accepts two different commands. + The first command is a command which allows chat clients connected to the + chat server to change nicknames, which are used when chatting. + In order to change the nickname, a client must send a Game-Command +\begin_inset Quotes eld +\end_inset + +nick +\begin_inset Quotes erd +\end_inset + + with the actuall new nickname as a argument. + When a message arrives to the GGS which has the form corresponding to the + nickname change, the +\emph on +playerCommand +\emph default + function is called with the parameters +\emph on +player_id, command, +\emph default +and +\emph on +args +\emph default + filled in appropriately. +\end_layout + +\begin_layout Standard +The +\emph on +playerCommand +\emph default + function is responsible for calling the helper functions responsibly for + carrying out the actions of each message received. + +\emph on +changeNick +\emph default + is a function which is called when the +\begin_inset Quotes eld +\end_inset + +nick +\begin_inset Quotes erd +\end_inset + + message is received. + The +\emph on +changeNick +\emph default +function uses a feature of the GGS called localStorage (see section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Communication-with-the-GDL-VM" + +\end_inset + +), which is an interface to the database backend contained in the database + module (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:The-database-module" + +\end_inset + +). + The database can be used as any key-value store, however the syntax for + insertions and fetch operations is tighty integrated in the GDL of the + GGS. +\end_layout + +\begin_layout Standard +Access to the localStorage is provided through the +\emph on +GGS object +\emph default +, which also can be used to communicate with the rest of the system from + the GDL. + Implementation specifics of the GGS object are provided in +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Communication-with-the-GDL-VM" + +\end_inset + +. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +language=JavaScript, +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting}[language=JavaScript] +\end_layout + +\begin_layout Plain Layout + +function playerCommand(player_id, command, args) { +\end_layout + +\begin_layout Plain Layout + + if(command == "nick") { +\end_layout + +\begin_layout Plain Layout + + changeNick(player_id, args); +\end_layout + +\begin_layout Plain Layout + + } else if(command == "message") { +\end_layout + +\begin_layout Plain Layout + + message(player_id, args); +\end_layout + +\begin_layout Plain Layout + + } +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + +function changeNick(player_id, nick) { +\end_layout + +\begin_layout Plain Layout + + var old_nick = GGS.localStorage.getItem("nick_" + player_id); +\end_layout + +\begin_layout Plain Layout + + GGS.localStorage.setItem("nick_" + player_id, nick); +\end_layout + +\begin_layout Plain Layout + + if (!old_nick) { +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll("notice", nick + " joined"); +\end_layout + +\begin_layout Plain Layout + + } else { +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll("notice", old_nick + " is now called " + nick); +\end_layout + +\begin_layout Plain Layout + + } +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + +function message(player_id, message) { +\end_layout + +\begin_layout Plain Layout + + var nick = GGS.localStorage.getItem("nick_" + player_id); +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll('message', nick + "> " + message); +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-concrete-example" + +\end_inset + +A concrete example of a simple chat server written in JavaScript, running + on the GGS +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Chapter +Problems of implementation +\begin_inset CommandInset label +LatexCommand label +name "cha:Problems-of-implementation" + +\end_inset + + +\end_layout + +\begin_layout Standard +This chapter contains specific problems encountered when implementing the + GGS prototype. + Some of the problems described have solutions attached, however some problems + were not solved, therefore only ideas for slutions have been attached. +\end_layout + +\begin_layout Standard +The integration of JavaScript as a GDL in the GGS prototype was particularily + difficult, and is handled in this section. + Unique identification is also handled, as is the design of the GGS protocol. +\end_layout + +\begin_layout Section +JavaScript engine +\end_layout + +\begin_layout Standard +The GGS prototype uses a vistual machine to sandbox each game. + JavaScript was chosen for the prototype due to its commonality in web applicati +ons and the flexibility of the language. + Any language with the proper bindings to Erlang could have been used in + theory. +\end_layout + +\begin_layout Standard +There are two main JavaScript virtual machines, or +\emph on +engines +\emph default + 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 V8. + 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. +\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 thee possibility + to communicate from erlang_js to Erlang. + The ability to communicate from JavaScript to Erlang functionality is not + yet implemented in erlang_js, due to lack of time on the behalf of the + erlang_js developers. +\end_layout + +\begin_layout Standard +There were two possible solutions to the problem of the JavaScript to Erlang + communication path missing, the path could be implemented by the GGS project, + or a switch from erlang_js for some other JavaScript engine could be made. + +\end_layout + +\begin_layout Standard +Attempts at creating the communication path from JavaScript to Erlang were + initially made, however the communiucation path 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 rather than the engines + developed by Mozilla. + The ability to communicate with Erlang from JavaScript using callbacks + is available in the erlv8 bindings, therefore this feature does not have + to be added to the bindings in order to be used in the GGS. +\end_layout + +\begin_layout Standard +Initial releases of the erlv8 bindings had stability issues, these were + however solved by the erlv8 developers during the usage of erlv8 in the + GGS. + 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 Subsection +UUID +\end_layout + +\begin_layout Standard +Erlang identifies processes uniquely throughout the entire Erlang network + using process IDs (PID). + When we wish to refer to erlang processes from outside our erlang system, + for example in a virtual machine for a different language, possibly on + a different machine, these PID:s are no longer useful. + +\end_layout + +\begin_layout Standard +This problem is not new, and a common solution is to use a Universally Unique + Identifier, a UUID. + These identifiers are generated both using randomization and using time. + A reasonably large number of UUID:s can be generated before a collision + should occur. + There are standard tools in many UNIX systems to generate UUID:s, we chose + to use the uuidgen command, which employs an equidistributed combined Tausworth +e generator. +\end_layout + +\begin_layout Subsection +Protocol design +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Discuss how the early GGS protocol were going to use both UDP and binary + plists to be as fast as possible. + Then discuss how complex these solutions were going to be to implement + in the prototype. + Mention that the modular structure of the GGS allows these features to + be implemented later on, but are not currently implemented. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Design choices +\begin_inset Note Note +status open + +\begin_layout Plain Layout +This section is wrongly placed +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +When designing concurrent applications, it is useful to picture them as + real world scenarios, and to model each actor as a real world process. + A real world process is a process which performs some action in the real + world, such as a mailbox receiving a letter, a door being opened, a person + translating a text, a soccer player kicking the ball, just to name a few + examples. + Since we focus on games in this project, it is suitable to model our system + as a place where games take place. + We imagined a chess club. + +\end_layout + +\begin_layout Standard +The clients pictured as green circles can be thought of as the physical + chess players. +\end_layout + +\begin_layout Standard +When a player wants to enter the our particular chess club, he must first + be let in by the doorman, called the +\emph on +Dispatcher +\emph default + in the GGS. +\end_layout + +\begin_layout Standard +He then gets a name badge, and thus becomes a +\emph on +Player +\emph default + process in the system. + He is also guided in to the lobby by the +\emph on +Coordinator +\emph default +, which has the role of the host of the chess club. +\end_layout + +\begin_layout Standard +When players wish to play against each other, they talk to the +\emph on +Coordinator +\emph default + who pairs them up, and places them at a table. + Once they have sat down at the table, they no longer need the assistance + of the +\emph on +Coordinator +\emph default +, all further communication takes place via the table. + This can be thought of as the actual chess game commencing. + +\end_layout + +\begin_layout Standard +All the moves made in the game are recorded by the table, such that the + table can restore the game in case something would happen, such as the + table tipping over, which would represent the table process crashing. +\end_layout + +\begin_layout Standard +Once a player wishes to leave a game, or the entire facility, he should + contact the +\emph on +Coordinator +\emph default +, who revokes his name badge and the +\emph on +Dispatcher +\emph default + will let the player out. +\end_layout + +\begin_layout Standard +With the information kept in the tables and the +\emph on +Coordinator +\emph default + combined, we can rebuild the entire state of the server at a different + location. + This can be thought of the chess club catching fire, and the +\emph on +Coordinator +\emph default + rounding up all the tables, running to a new location and building the + club up in the exact state it was prior to the fire. +\end_layout + +\begin_layout Section +Usability +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Discuss how the GGS can be difficult to use for people not versed with Erlang +\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 Section +Software development methodology +\end_layout + +\begin_layout Standard +The project has not followed any specific software development methodology. + All work has been based on a predefined schedule and the specifications + are made by team members rather than an outside customer or stakeholder. + The process can be described as a plan-driven development method going + from brainstorming to design, then implementation and finally testing. + Yet there has been cycles in the process in form of redesign and code refactori +ng. +\end_layout + +\begin_layout Section +Statistics +\end_layout + +\begin_layout Standard +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 can not 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 Standard +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 + +\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/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 + +\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 + +\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 + +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Future improvements +\end_layout + +\begin_layout Standard +The specification of the GGS prototype is huge and like many other software + projects relying on outside technologies, in time it would require a lot + of maintanance. + Therefore there are a lot of areas in which the GGS could be improved such + as performance, compatibility, ease of setup and usage. +\end_layout + +\begin_layout Subsection +Performance +\end_layout + +\begin_layout Subsubsection +Protocols +\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 bandwith than connectionless + protocols like UDP and cause uneccessary load on the processor. + Therefore support for UDP would mean that more games could be run simultaneousl +y on the GGS. + Another advantage of UDP is latency being reduced. + Without having to setup a connection for each group packets of data being + sent, they will be sent instantly and therefore arrive earlier. + Latency is of highest importance in realtime games as it improves realism + and fairness in gameplay and many game developers requires 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. + This could be prevented by replacing Mnesia with another database management + system or use Mnesia in combination with the ETS module of erlang. + ETS provides fast access to the RAM and thus Mnesia could be used less + frequently. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{ETS}}{Erlang Term Storage} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Compatibility +\end_layout + +\begin_layout Standard +GGS relies on modern technologies. + This includes the virtual machines(VM) that the GGS uses for communication + between Erlang and the GDL:s. + These specific VM:s are crucial for game developers to be able to write + games in other languages than Erlang. + Therefore it would be best for the GGS to have as many of these VM:s implemente +d as possible. + The VM:s taken into consideration so far have been unstable or incomplete + and it is possible to search for more VM:s, testing them and intergrate + them into the GGS prototype. +\end_layout + +\begin_layout Subsection +Setup +\end_layout + +\begin_layout Standard +The GGS prototype installation procedure requires different configuring + and building steps and thus it isn't in an acceptable release state. + An executable installation file for each supported platform would be optimal. +\end_layout + +\begin_layout Subsection* +5.3.4 Usage +\end_layout + +\begin_layout Subsubsection +Programming languages +\end_layout + +\begin_layout Standard +The GGS does not support many programming languages. + For a programming language to be compatible with the GGS, not only does + it require a VM for that specific language, but the VM must have the ability + to communicate to Erlang. + More research is needed to find VM:s with this built in functionality. + +\end_layout + +\begin_layout Subsubsection +Documentation +\end_layout + +\begin_layout Standard +To start the GGS is not self explanatory. + This together with overall usage of GGS should be documented. + The interface for usage of game developers is also in need of documentation. + Features and requirements with respect to the GGS would assist users to + know what they need in order to use the GGS and how they would benefit + of it. + The GGS does not support many programming languages nor does it have a + complete documentation. + This needs to be taken care of in future versions. +\end_layout + +\begin_layout Chapter +Conclusion +\end_layout + +\begin_layout Standard +\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 + +\end_layout + +\begin_layout Standard +\begin_inset CommandInset bibtex +LatexCommand bibtex +bibfiles "bibliography" +options "plainnat" + +\end_inset + + +\end_layout + +\end_body +\end_document diff --git a/report.lyx b/report.lyx index e3e7d06..c99883f 100644 --- a/report.lyx +++ b/report.lyx @@ -5797,14 +5797,14 @@ The JavaScript VM (JSVM) - at this stage Googles V8 JavaScript Engine - \end_layout \begin_layout Enumerate -In the example ( +In the example in section \begin_inset CommandInset ref LatexCommand ref -reference "sec:Example-of-a-GGS-server-application-in-JavaScript" +reference "sec:Example-of-a-GGS-app" \end_inset -) we see that the GGS-functions + we see that the GGS-functions \emph on GGS.localStorage.setItem(key, value) \emph default @@ -6703,7 +6703,14 @@ Hot code replacement is a technique used to update systems while they are \end_layout \begin_layout Section -Example of a GGS server application in Javascript +Example of 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 diff --git a/working.lyx b/working.lyx new file mode 100644 index 0000000..bdc12ed --- /dev/null +++ b/working.lyx @@ -0,0 +1,7223 @@ +#LyX 2.0 created this file. For more info see http://www.lyx.org/ +\lyxformat 413 +\begin_document +\begin_header +\textclass report +\begin_preamble +\usepackage{indentfirst} +\usepackage{tocloft} +\usepackage{calc} +\date{} +\usepackage[section] {placeins} +\def\myClearpage{% + \ifvmode + \ifnum \@dbltopnum =\m@ne + \ifdim \pagetotal <\topskip + \hbox{}% + \fi + \fi + \fi +% \newpage + \write\m@ne{}% + \vbox{}% + \penalty -\@Mi +} +\def\myCleardoublepage{\myClearpage\if@twoside \ifodd\c@page\else + \hbox{}\if@twocolumn\hbox{}\fi\fi\fi} +\usepackage{morefloats} +\usepackage{graphicx} +\usepackage{subfig} +\usepackage{tocloft} +\renewcommand{\cftchapfont}{\bfseries} +\renewcommand{\cftchappagefont}{\bfseries} +\renewcommand{\cftchappresnum}{Chapter } +\renewcommand{\cftchapnumwidth}{6em} + +\oddsidemargin 0.5in +\textwidth 6in +\topmargin 0.0in +\textheight 8.0in +\setlength\topskip{24pt} +\footskip 0.75in + +\usepackage[compact]{titlesec} + + +\titleformat{\chapter}[display] +{\vskip-8em\normalfont\bfseries} +{\LARGE\raggedright\thechapter} +{14ex} +{\vspace{-20ex}% +\LARGE\raggedleft} +[\vspace{1ex}% +{\titlerule[1pt]}] + +\usepackage[absolute]{textpos} + +\usepackage{fancyheadings} +\pagestyle{fancy} +\lhead{\thechapter} + +\usepackage[hmargin=3cm,vmargin=3.5cm]{geometry} +\usepackage{algorithmic} +\usepackage{listings} + +\usepackage{color} +\definecolor{lightgray}{rgb}{.9,.9,.9} +\definecolor{darkgray}{rgb}{.4,.4,.4} +\definecolor{purple}{rgb}{0.65, 0.12, 0.82} + +\lstdefinelanguage{JavaScript}{ + keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break}, + keywordstyle=\color{blue}\bfseries, + ndkeywords={class, export, boolean, throw, implements, import, this}, + ndkeywordstyle=\color{darkgray}\bfseries, + identifierstyle=\color{black}, + sensitive=false, + comment=[l]{//}, + morecomment=[s]{/*}{*/}, + commentstyle=\color{purple}\ttfamily, + stringstyle=\color{red}\ttfamily, + morestring=[b]', + morestring=[b]" +} + +\lstdefinelanguage{Erlang}{ + keywords={typeof, true, false, catch, return, null, catch, switch, var, if, in, while, do, else, case, break, expose}, + keywordstyle=\color{blue}\bfseries, + ndkeywords={class, export, boolean, throw, implements, import, this,erlv8_vm, erlv8_fun_invocation +,erlv8_object}, + ndkeywordstyle=\color{darkgray}\bfseries, + identifierstyle=\color{black}, + sensitive=false, + comment=[l]{\%}, + morecomment=[s]{/*}{*/}, + commentstyle=\color{purple}\ttfamily, + stringstyle=\color{red}\ttfamily, + morestring=[b]', + morestring=[b]" +} + +\usepackage{float} + +\floatstyle{ruled} +\newfloat{code}{thp}{lop} +\floatname{code}{Code} + +\usepackage{nomencl} +\makenomenclature +\renewcommand{\nomname}{Glossary} +\end_preamble +\use_default_options true +\maintain_unincluded_children false +\language english +\language_package default +\inputencoding auto +\fontencoding global +\font_roman lmodern +\font_sans default +\font_typewriter default +\font_default_family rmdefault +\use_non_tex_fonts false +\font_sc false +\font_osf false +\font_sf_scale 100 +\font_tt_scale 100 + +\graphics default +\default_output_format default +\output_sync 0 +\bibtex_command default +\index_command default +\paperfontsize default +\spacing onehalf +\use_hyperref false +\papersize a4paper +\use_geometry false +\use_amsmath 1 +\use_esint 1 +\use_mhchem 1 +\use_mathdots 1 +\cite_engine natbib_authoryear +\use_bibtopic false +\use_indices false +\paperorientation portrait +\suppress_date false +\use_refstyle 0 +\index Index +\shortcut idx +\color #008000 +\end_index +\paperwidth 11in +\paperheight 8.5in +\leftmargin 1.25in +\topmargin 0in +\rightmargin 1in +\bottommargin 1.7in +\secnumdepth 2 +\tocdepth 2 +\paragraph_separation indent +\paragraph_indentation default +\quotes_language english +\papercolumns 1 +\papersides 1 +\paperpagestyle empty +\tracking_changes false +\output_changes false +\html_math_output 0 +\html_css_as_file 0 +\html_be_strict false +\end_header + +\begin_body + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{textblock*}{ +\backslash +paperwidth}(0mm,40mm) +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{center} +\end_layout + +\begin_layout Plain Layout + + +\backslash +includegraphics[width= +\backslash +paperwidth/2]{graphics/logo} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{center} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{textblock*} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Title +A Reliable Generic Game Server +\end_layout + +\begin_layout Author +Niklas Landin +\begin_inset Newline newline +\end_inset + +Richard Pannek +\begin_inset Newline newline +\end_inset + +Mattias Pettersson +\begin_inset Newline newline +\end_inset + +Jonatan Pålsson +\end_layout + +\begin_layout Abstract +This is the abstract! +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +pagenumbering{roman} +\end_layout + +\begin_layout Plain Layout + + +\backslash +setcounter{page}{3} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +contentsname{Table of Contents} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand{ +\backslash +cfttoctitlefont}{ +\backslash +hfill +\backslash +Large} +\backslash +renewcommand{ +\backslash +cftaftertoctitle}{ +\backslash +hfill} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +cftpartdotsep{6.6} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +cftchapdotsep{6.6} +\end_layout + +\end_inset + + +\begin_inset CommandInset toc +LatexCommand tableofcontents + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Newpage newpage +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +pagenumbering{arabic} +\end_layout + +\begin_layout Plain Layout + + +\backslash +setcounter{page}{1} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Chapter +Introduction +\end_layout + +\begin_layout Standard +Online gaming, and computer gaming in general has become an important part + in many peoples day-to day lives. + A few years ago, computer games were not at all as popular as they are + today. + With the advances in computer graphics and computer hardware today's games + are much more sophisticated then they were in the days of +\emph on +NetHack +\emph default +, +\emph on +Zork, +\emph default +or +\emph on +Pacman. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Zork}}{A textual computer game developed by students at MIT} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Pacman}}{An early graphical computer game developed by Namco} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{NetHack}}{An early computer game developed by the NetHack team, arguably + the oldest computer game still in development} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The early computer games featured simple, or no graphics at all +\begin_inset CommandInset citation +LatexCommand citet +key "nethack:website" + +\end_inset + +. + The games often took place in a textual world, leaving the task of picturing + the world up to the player. + Multi-player games were not as common as they are today, whereas most games + today are expected to have a multi-player mode, most early games did not. +\end_layout + +\begin_layout Standard +Since these early games, the gaming industry have become much more influential + in many ways. + Many advanced in computer hardware are thought to come from pressure from + the computer game industry. + More powerful games require more powerful, and more easily available hardware +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Drop a reference to the gaming industry pressuring more advanced hardware +\end_layout + +\end_inset + +. + Due to the high entertainment value of modern computer games, gaming has + become a huge industry, where large amounts of money are invested. + The gaming industry is today, in some places even larger than the motion + picture industry. + +\begin_inset CommandInset citation +LatexCommand citet +key "esa:website,thenumbers:website" + +\end_inset + + +\end_layout + +\begin_layout Standard +Due to the increasing importance of computer gaming, more focus should be + spent on improving the quality of the gaming service. + As more and more computer games are gaining multi-player capabilities, + the demands for multiplayer networking software rises. + This thesis is about techniques for improving the quality of this networking + software. +\end_layout + +\begin_layout Standard +The reliable generic game server, hereafter known as GGS +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{GGS}}{Generic Game Server, a software for reliably hosting network + games. + The subject of this thesis.} +\end_layout + +\end_inset + +, is a computer program designed to +\emph on +host +\emph default + network games on one or more server computers. + Hosting, in a network software setting, means allowing client software + connect to the server software, for the purpose of utilizing services provided + by the server. + The GGS software provides games as a service, and the clients connecting + to the GGS can play these games on the GGS. +\end_layout + +\begin_layout Standard +The idea of game servers is not new, network games have been played for + decades. + Early, popular examples of network games include the +\emph on +Quake +\emph default + series, or the +\emph on +Doom +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout + +\emph on +Come up w/ better game +\end_layout + +\end_inset + + +\emph default + games. + Newer examples of network games include +\emph on +World of Warcraft +\emph default +, and +\emph on +Counter-Strike +\emph default +. + The difference between the GGS and the servers for these games is that + the servers for Doom, Quake, and the others listed, were designed with + these specific games in mind. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Quake}}{A first person shooter series developed by ID software. + The series consists of four games.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Doom}}{A first person shooter series developed by ID software. + The series consists of three games.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{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{Counter-Strike}}{A multiplayer first person shooter game, popular + in E-Sports.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Framework}}{A supporting structure, the GGS is a framework for developing + network games} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{First-person shooter}}{A game in which centers around gun combat + from the first person perspective.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{MMORPG}}{Massively multiplayer online role playing game. + An online game with several thousand participants.} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +What GGS does is to provide a +\emph on +generic +\emph default + framework for developing network games. + The framework is generic in the sense that it is not bound to a specific + game. + There are many different types of games, some are inherently more time + sensitive than others, strategy games are examples of games which are not + very sensitive to time delays, first-person shooters however, can be very + sensitive. +\end_layout + +\begin_layout Standard +The generic nature of the GGS allows the creation of many different types + of games, the motivation behind this is to remove the necessity of writing + new game servers when developing new games. +\end_layout + +\begin_layout Standard +The GGS is in addition to being generic, also +\emph on +reliable +\emph default + in the sense that the gaming service provided is consistent and available. + A consistent and available server is a server that handles hardware failures + and software failures gracefully. + In the event of a component breaking within the GGS, the error is handled + by fault recovery processes, thereby creating a more reliable system. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Hardware failiure}}{A failiure in hardware (hard drive, memory, processor +, etc) which causes a system to stop functioning} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Software failiure}}{A failiure in software (the GGS, the operating + system, etc) which causes a system to stop functioning} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Background +\end_layout + +\begin_layout Standard +The game industry is a quickly growing industry where the need for new technique +s are large. + One specific section where the development has stalled is the game server + section. +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + + The existing game servers are functional but they lack good fault tolerance + and the ability to scale well +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + +. + Users will notice this in low uptime and many crashes. + This is a problem that has existed and been resolved in other industries. + In the telecom industry solutions to similar problems have been found. +\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, or rougly +\begin_inset Formula $15ms$ +\end_inset + + downtime in a year +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + +. + The level of instability and bad fault tolerance seen in the game server + industry would not have been accepted in the telecoms industry. + This level of instability should not be accepted in the game server industry + either. + An unavailabvle phone system could potentially have life threatening consequenc +es, leaving the public unable to contant emergency services. + The same can not 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 learnt. +\end_layout + +\begin_layout Standard +Moving back to the gaming industry. + The main reason to develop reliable servers are monetary, it is important + for game companies to expand its customer base. + Reliable game servers are one improvement that will create a good image + of a company. + In general the downtime of game servers is much higher than the downtime + of telecom system +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed... +\end_layout + +\end_inset + +. + The structure of the system is similar in many ways and it should be possible + to reuse solutions from the telecom system to improve game servers. + +\end_layout + +\begin_layout Standard +In the current state game servers are developed on a per-game basis, in + many cases this seems like a bad solution. + Developers of network game need to understand network programming. + A way to change this is a generic game server which give the game developers + a server which they implement their game towards. + 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 factors key to the development of GGS have been isolated. + Many of these come from the telecom sector. + The factors are +\emph on +scalability, fault tolerance +\emph default +and being +\emph on +generic +\emph default +. + 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 defined as the statistical probability of the system functioni +ng as intended at a given point in time. + Fault tolerance is defined as the property of a system to always follow + a specification, even in the presence of errors. + The specification could take the form of error handling procedures which + activate when an error occurs. + This means that a fault tolerant, dependable system, will have a very high + probability of functioning at a given point in time, and is exactly what + is desired. + +\begin_inset CommandInset citation +LatexCommand citet +key "Gartner:1999:FFD:311531.311532" + +\end_inset + + +\end_layout + +\begin_layout Standard +A generic (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Generic" + +\end_inset + +) game server has to be able to run different client-server network games + regardless of the platform the clients are running on. + It runs network games of different type. + A very rough separation of games is real time games and turn based games. +\end_layout + +\begin_layout Standard +The server behaves in a way similar to an application server, but is designed + to help running games. + 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. +\end_layout + +\begin_layout Standard +The most common type of application servers are web servers, where you run + a web application within the server. + The application server provides an environment and interfaces to the outer + world, in which applications run. + Hooks and helpers are provided to use the resources of the server. + Some examples for web application servers are the +\emph on +Glassfish +\emph default + server which allows running applications written in Java or the +\emph on +Google App Engine +\emph default + where you can run applications written in Python or some language which + runs in the +\emph on +Java Virtual Machine +\emph default +. + An example of an application server not powering web applications, but + instead regular business logic, is Oracle’s +\emph on +TUXEDO +\emph default + application server, which can be used to run applications written in COBOL, + C++ and other languages. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SQL}}{Structured Query Language, a computer language common in querying + certain databases} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{JavaScript}}{A programming language originally developed by Netscape, + common in web programming} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{COBOL}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{C++}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Java}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{AXD301}}{Telephone switch developed by Ericsson} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Erlang}}{A concurrent programming language, often used for telecom + applications. + The main language of the GGS} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +A database server can also be seen as an application server. + Scripts, for example SQL queries or JavaScript, are sent to the server, + which runs them and returns the evaluated data to the clients. + +\end_layout + +\begin_layout Standard +One purpose of this thesis is to investigate how we can make a game server + as generic as possible. + Some important helpers are discussed, such as abstraction of the network + layer, data store and game specific features. + +\end_layout + +\begin_layout Standard +As an aid in discussing the theoretical parts of the GGS a prototype has + been developed. + The prototype does not feature all of 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 implementation language for the prototype of the GGS was made + with inspiration from the telecom industry. + The Erlang language was developed by the 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 is also possibly has the largest code base even written in a + functional language +\begin_inset CommandInset citation +LatexCommand citep +key "Armstrong03" + +\end_inset + +. + The same language is used to develop the prototype of the GGS. + 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 + +. + Chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Implementation-of-a" + +\end_inset + + provides a description of the prototype developed for this thesis. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +We could go on and on about erlang.. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Purpose +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout +The purpose of the GGS project. + What is the purpose of creating a fault tolerant server, why is it generic, + and what good does it do to have a scalable system? In the background, + we should give the motivations behind creating this software, but here + we should outline why the software is needed. + This section should be shortened, and the bulk of the text should be moved + to theory or background. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The purpose of creating a generic and fault tolerant game server is to provide + a good framework for the development of many different types of games. + Allowing the system to scale up and down is a powerful way to maximize + the usage of physical resources. + By scaling up to new machines when load increases, and scaling down from + machines when load decreases costs and energy consumption can be optimized. +\end_layout + +\begin_layout Standard +Fault tolerance is important for the GGS to create a reliable service. + The purpose of a reliable game server is to provide a consistent service + to people using the server. + Going back to the telecom example, the purpose of creating a reliable telecom + system is to allow calls, possibly emergency calls, at any time. + Should the telecom network be unavailable at any time, emergency services + may become unavailable, furthermore the consumer image of the telecom system + degrades. +\end_layout + +\begin_layout Standard +Returning to the game industry, emergency services will not be contacted + using a game server, however an unavailable server will degrade the consumer + 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 can not 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 wrote in different programming + languages, besides 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 decide the feasibility + of a language: +\end_layout + +\begin_layout Itemize +How well it integrates with Erlang, which is used in the core the GGS system + +\end_layout + +\begin_layout Itemize +How easy it is to send messages to the virtual machine of the GDL from the + GGS +\end_layout + +\begin_layout Itemize +How easy it is to send messages from the GDL VM to the GGS +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add more like threads, events, etc. +\end_layout + +\end_inset + + +\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 for use in interacting 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 gaming clients has to take place over 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 large challenge during this project is to decide whether an existing + protocol can be used, and if not, how a new protocol can be designed which + performs technically as desired, while still being familiar enough to existing + developers. +\end_layout + +\begin_layout Standard +A great deal of work is devoted to make the GGS +\emph on +reliable +\emph default +. + This includes ensuring that the system scales well, and to make sure it + is fault tolerant. + In order to facilitate scalability, we need a storage platform which is + accessible and consistent among all of the GGS, this is also investigated. +\end_layout + +\begin_layout Section +Limitations of the prototype +\end_layout + +\begin_layout Standard +The implementation of the GGS protocol, together with storage possibilities, + server capacity, and game language support imposes some limitations on + the project. + To get a functional prototype some limits must be set on the types games + that can be played on the prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{UDP}}{User Datagram Protocol, a connectionless networking protocol} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{TCP}}{Transmission Control Protocol, a streaming network protocol} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The UDP protocol is not supported for communication between client and server. + The TCP protocol was chosen in favour of UDP, due to the fact that the + implementation process using TCP was faster than if UDP would have been + used. + UDP is generally considered to be faster than TCP for the transfer of game + (and other) related data, this is discussed in more depth in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Choice-of-network" + +\end_inset + +. + In short, the decision of using TCP means that games that requires a high + speed protocol will not be supported by the GGS prototype. + Another limitation necessary to set on the system is the possibility to + have huge game worlds due to the implementation of the scaling mechanism + in the prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Latency}}{A measure of delay, often measured in milliseconds} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +In real time games all players are playing together at the same time. + Latency is a huge problem in real time games, a typical round trip time + for such games are one of +\begin_inset Formula $50$ +\end_inset + + to +\begin_inset Formula $150ms$ +\end_inset + + and everything above +\begin_inset Formula $200ms$ +\end_inset + + is reported to be intolerable +\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 (MMORPG:s), for example + +\emph on +World of Warcraft +\emph default +. +\end_layout + +\begin_layout Standard +In turn based games each player has to wait for their turn. + Latency is not a problem since the gameplay does not require fast interactions + among the players, long round trip times will not be noticed. + Examples of turn based games include board and card games, as well as multiplay +er games like +\emph on +Jeopardy +\emph default +. + Both game types have varying difficulties and needs when it comes to implementi +ng them, a Generic Game Server should address all of them and help the developer + to accomplish his goal. +\end_layout + +\begin_layout Standard +Due to the limited capability of threading in many GDL VM:s, the GGS prototype + will not support MMORPG:s. +\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 + are no need to implement more advanced features in the system. + Note that these limitations only apply for the prototype of the project, + and that further developments to the GGS could be to implement these features. +\end_layout + +\begin_layout Section +Method +\end_layout + +\begin_layout Standard +A prototype was developed early on in the project to carry out experiments. + Using this prototype, the system was divided into modules. + A demand specification was created, using this specification, the modules + were easily identifiable. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Module}}{A part of a larger system} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The first prototype of the GGS consisted of simple modules, however, due + to the separation of concerns among the modules, they were easily independently + modified and improved. +\end_layout + +\begin_layout Standard +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. +\end_layout + +\begin_layout Standard +Design This could be seen as an interative workflow, with the first prototype + being the first iteration. + The second iteration later became the final result of the GGS. +\end_layout + +\begin_layout Standard +The layout of the GGS is both layered and modular. + The first layer handles the most primitive data and produces a higher level + representation of the data, passing it along to different modules of the + GGS. + The modular structure of the GGS plays an important role in making the + system fault tolerant. + The approach to fault tolerance is by replication, and restarting the faulting + modules with the last known good data. +\end_layout + +\begin_layout Standard +An informal specification and list of requirements of the system was outlined + early on in the project. + Usaility goals for developers were set. + During the project several demo applications were constructed, by constructing + these applications, the usability goals were enforced. +\end_layout + +\begin_layout Chapter +Theory behind the GGS +\begin_inset CommandInset label +LatexCommand label +name "cha:Theory" + +\end_inset + + +\end_layout + +\begin_layout Standard +In this chapter, the theory behind the techniques used in the GGS are discussed. + Performance issues and the measuring of performance is discussed. + Benchmarking techniques are discussed. + The options when choosing network protocols are given, along with a discussion + of each alternative. + Finally, an overview of scalability, fault tolerance and availability are + 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 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 a computer. + The requirements and limitations imposed on the real-world system can, + using the proper tools, be transferred in to the software. +\end_layout + +\begin_layout Standard +The real world system chosen for 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. + Since a real-world scenario is readily available, and to such a large extent + resembles the computer software required for the GGS, the next step in + developing the GGS system is to duplicate this real world scenario in a + software setting. +\end_layout + +\begin_layout Standard +Some requirements, limitations and additions were made to the chess club + system, so that the system would more easily and efficiently be replicated + in a software setting. +\end_layout + +\begin_layout Standard +In the text below, two examples will be presented. + On example is that of a real-world chess club, in which players meet to + play chess against each other, the other example is the GGS, and how it + corresponds to this chess club. + +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/theory_layout.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:theory-layout" + +\end_inset + +The layout of a physical +\begin_inset Quotes eld +\end_inset + +Chess club +\begin_inset Quotes erd +\end_inset + + with two players (P) sitting by each chess table (Table), a coordinator + keeps track of all moves and players in the building. + A player has to pass by the entrance to enter or exit the building. + The building is represented by the outermost box. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +In figure +\begin_inset CommandInset ref +LatexCommand vref +reference "fig:theory-layout" + +\end_inset + + a graphical representation for the chess club is presented. + The club is seen from above. + The outermost box represents the building. + In the GGS setting, the building would represent one instance of GGS. + Several buildings linked together would represent a cluster of GGS instances. + In order for a player (the P symbol in the graphic) to enter the theoretical + chess club, the player must pass by the entrance. + By having each player pass by the entrance, a tally +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Does this mean what I think it does? +\begin_inset Quotes eld +\end_inset + +Räkning +\begin_inset Quotes erd +\end_inset + + ? +\end_layout + +\end_inset + + can be kept, ensuring that there are not too many players within the building. + In the GGS setting, too many players entering would mean too many connections + have been accepted by the GGS system, and that the structure of the system + thus must be modified, adding additional servers. +\end_layout + +\begin_layout Standard +Once a player has been allowed in to the chess club the player is greeted + by the host of the chess club, in the GGS setting represented by the +\emph on +Coordinator +\emph default +, and is seated by a table. + The coordinator keeps track of all the players in the building, and all + moved made by the players. + The information available to the coordinator means that cheating can be + monitored and book keeping can be performed by this entity. +\end_layout + +\begin_layout Standard +Moves by players are made using the tables present in the chess club. + Every game is isolated to a table, just as expected. + This means that communication during a game only has to pass by the players + of that particular game, and the coordinator, making sure that no cheating + takes place. +\end_layout + +\begin_layout Standard +This isolation of the games play an important part in many properties of + the GGS, the isolation means that games can for example be transferred + among different chess clubs, furthermore, if cheating takes place, corruption + can only occur in the particular table where it was found, and can not + 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 a property 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 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 tolerant and generic traits are added to the GGS. + These are not shown in the algorithm, as these traits are tools in making + the algorithm behaves 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 no limits in the GGS on the number + of players connecting, for example. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status collapsed + +\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, de-registering 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 played. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Performance +\end_layout + +\begin_layout Standard +There are many ways in which performance could be measured. + For the clients, time and response times are useful measurements in time + critical settings. + In non-time critical settings, the reliability of message delivery may + be an even more important factor than speed. +\end_layout + +\begin_layout Standard +In a first person shooter game, the speed of delivery of messages is essential. + 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 perceieved 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 practical results for the prototype is discussed in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Implementation-of-a" + +\end_inset + +. +\end_layout + +\begin_layout Subsection +Performance measurements +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\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 temperetur +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 + + +\end_layout + +\begin_layout Standard +How many players can we have on a server? Performance differences between + games? e.g can one game have thousands players on a server and another only + have hundreds? Questions +\end_layout + +\begin_layout Standard +In the current state game servers is coded for each game that needs it, + in many cases this seems like a bad solution. + Developers that want to make a network game need to understand network + programming. + A way to change this is a generic game server which give the game developers + a server which they implement their game towards. + 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. + to be discussed here. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Create a game with several thousand players, see how our server scales, + how can we improve the performance? Sharding isn’t very nice.. + alternatives? Improve the speed of sharding? +\end_layout + +\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 +Choice of network protocol +\begin_inset CommandInset label +LatexCommand label +name "sec:Choice-of-network" + +\end_inset + + +\end_layout + +\begin_layout Standard +There are three main ways in which computer communication over the Internet + usually takes place; TCP, UDP and HTTP. + The first two is transport layer protocols, which are commonly used to + transport application layer protocols, such as HTTP. + TCP and UDP can not be used on their own, without an application layer + protocol on top. + Application layer protocols such as HTTP on the other hand needs a transport + layer protocol to work. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{HTTP}}{Hyper Text Transport Protocol, a network protocol commonly + used to deliver web pages} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +HTTP +\end_layout + +\begin_layout Standard +Since HTTP is so widely used on the Internet today in web servers, it is + available on most Internet connected devices. + This means that if HTTP is used in the GGS, firewalls will not pose problems, + which is a great benefit. + However, due to the intended usage of HTTP in web servers, the protocol + was designed to be stateless and client-initiated. + In order to maintain a state during a game session using HTTP, some sort + of token would have to be passed between client and server at all times, + much like how a web server works. + These facts combined makes HTTP unsuitable for our purposes, since 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, + and what is said about TCP also applies to HTTP. + +\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 the data transferred is in good shape, some sort of error checking + mechanisms must be implemented. + UDP is a good choice for applications where it is more important that data + arrives in a timely manner than that all data arrives undamaged, it is + thus very suitable for media streaming, for example. + In the GGS reliability of transfer was chosen before the speed of the transfer, + ruling out UDP as the transport later protocol. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Perhaps we should only say that we chose TCP just for our GGS prototype + and why. + If we leave it like that it seems that we think it is not suitable. +\end_layout + +\end_inset + + +\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 is the error checking and correction mechanisms + missing in UDP. + This ensures the consistency of data, but also makes the transfer slower + than if UDP had been used. + In the GGS, data consistency is more important than transfer speeds, and + thus TCP is a better alternative than UDP. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Same here it is simply not true for a generic server to chose one or the + other. + We should rephrase it so it is clear that we only state it about the GGS + prototype. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Generic +\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 any kind of game. + Any game with a client-server behaviour should be perfectly suited for + GGS. + 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. + Such as different programming languages. + The GGS should be OS independent and run on Windows, OSX 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 independent hardware. + It is meant to run any game in any environment in any way desired, therefor + being as generic as possible. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Bad name of the chapter, but here we should give the theory of how the server + is generic +\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 +Fault tolerance is an important factor in all servers, a server that is + fault tolerant should be able to follow a given specification when parts + of the system failures. + This means that fault tolerance is different in each system depending on + what specification they have. + A system could be fault tolerant in different aspects, one is where the + system is guaranteed to be available but not safe and it could also be + reversed, that the system is safe but not guaranteed to be available. + Depending on the system one property may be more important(some example + here). + A system could also have non existent fault tolerance or it could be both + safe and guaranteed to be available. + It should be noted that it is not possible to achieve complete fault tolerance, + a system will always have a certain risk of failure. + Therefore the goal is to make the GGS prototype as fault tolerant as possible. +\end_layout + +\begin_layout Standard +To make the GGS prototype fault tolerant the programming language Erlang + has been used. + Erlang will not guarantee a fault tolerant system but it has features that + support and encourage the development of fault tolerant systems. + In the GGS it is important that the system overall is fault tolerant. + Crashes of the whole system should be avoided as this would make the system + unusable for a time. + By using supervisor structures it is possible to crash and restart small + parts of the system, this is convenient as fault 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 are not as obvious as it may + be for other type of servers. + In general all servers strive to be fault tolerant as fault tolerance means + more uptime and a safer system. + This applies to game servers as well, in brief good fault tolerance is + a way of satisfying customers. + In general, game servers differ from many other fault tolerant systems + in that high-availability is more important than the safety of the system. + For example a simple calculation error will not be critical for a game + server but it may be in a life-critical system and then it is better that + the system crashes than works with the faulty data. + There are cases where safety may be critical in game servers, one example + is in games where in-game money exist. +\end_layout + +\begin_layout Subsubsection +Performance penalties +\end_layout + +\begin_layout Section +Availability +\begin_inset CommandInset label +LatexCommand label +name "sec:Availability" + +\end_inset + + +\end_layout + +\begin_layout Standard +One important factor of any server is the availability. + A server to which you are unable to connect to is an useless server. + Other then within telecommunication, their uptime is of about 99,9999999%, + the game developer community has not approached this problem very genuinely + yet so there is much room for improvement. +\end_layout + +\begin_layout Standard +There are several good papers on how to migrate whole virtual machines among + nodes to replicate them +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add more information about that +\end_layout + +\end_inset + + but for the GGS a different approach has been chosen. + Instead of just duplicating a virtual machine, the programming language + Erlang has been used which offers several features to increase the availability. + Some of them are +\emph on +hot code replacement +\emph default +, where code can be updated while the application is running and without + the need to restart it, the +\emph on +supervisor structure +\emph default + provided by +\emph on +OTP +\emph default + and the inter node and process communication via +\emph on +messages +\emph default + instead of shared memory. + We will discuss each of them later on. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Supervisor}}{A process monitoring and hadning crashes in other processes} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Scalability +\begin_inset CommandInset label +LatexCommand label +name "sec:Scalability" + +\end_inset + + +\end_layout + +\begin_layout Standard +Each instance of the GGS contains several tables. + Each table is an isolated instance of a game, for example a chess game + or a poker game. + The way that the GGS scales is to distribute these tables on different + servers. + In many games it is not necessary for a player to move among tables during + games. + This is for example not a common occurrence in chess, where it would be + represented as a player standing up from her current table and sitting + down at a new table, all within the same game session. + Therefore, the main focus of the GGS is not to move players among tables, + but to keep a player in a table, and to start new tables instead. + When a server has reached a certain number of players the performance will + start to decrease. + 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 and find out how many players that are optimal + for each server. + This approach makes it possible to use all resources with moderate load, + instead of having some resources with heavy load and some with almost no + load. +\end_layout + +\begin_layout Standard +As mentioned in the purpose section there are two different types of scalability +, structural scalability and load scalability. + To make the GGS scalable both types of scalability are needed. + Structural scalability means in our case that it should be possible to + add more servers to an existing cluster of servers. + By adding more servers the limits of how many users a system can have is + increased. + Load scalability in contrast to structural scalability is not about how + to increase the actual limits of the system. + Instead it means how good the system handles increased load. + The GGS should be able to scale well in both categories. +\end_layout + +\begin_layout Subsection +Load balancing +\end_layout + +\begin_layout Standard +The need for load balancing varies among different kind of systems. + Small systems that only use one or a couple of servers can cope with a + simple implementation of it, while in large systems it is critical to have + extensive and well working load balancing. + The need also depends on what kind of server structure that the system + works on. + A static structure where the number of servers are predefined or a dynamic + structure where the number varies. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Amazon EC2}}{A cloud computation service} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Load balancing and scaling is difficult in different scenarios. + When running in a separate server park, there are a set number of servers + available, this means that an even distribution on all servers are 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. + In this cloud setting, it may be more important to distribute evenly 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 for 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 load + becomes too high on all of them, then comes a new problem: +\end_layout + +\begin_deeper +\begin_layout Itemize +How do we distribute load on these new servers? +\end_layout + +\end_deeper +\begin_layout Standard +Load balancing is a key component to achieve scalability in network systems. + The GGS is a good example of a system that needs to be scalable, to attain + this load balancing is necessary. + Optimization of the load balancing for a system is an important task to + provide a stable and fast load balancer. + There are certain persistence problems that can occur with load balancing, + if a player moves from a server to another data loss may occur. + This is an important aspect to consider when the load balancer is designed + and implemented. +\end_layout + +\begin_layout Standard +Load balancing can often be implemented using dedicated software, this means + that in many applications load balancing may not be implemented because + it already exist functional solutions. + This depends on what specific needs the system has and a minor goal of + the project is to analyze whether the GGS project can use existing load + balancing tools or if it is necessary 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 + + +\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 +\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 +Inside the GGS, everything has an unique identifier. + There are identifiers for players, tables and other resources. + When players communicate amongst one another, or communicate with tables, + they need to be able to uniquely identify all these resources. + Within one machine, this is mostly not a problem. + A simple system with a counter can be imagined, where each request for + a new ID increments the previous identifier and returns the new identifier + based off 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 lock, which may work well in many concurrent systems. + In a distributed system, this lock, along with the state, would have to + be distributed. + If the lock is not distributed, no guarantee can be made that two nodes + in the distributed system do not generate the same number. + 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. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{MAC Address}}{Media Access Control address, used to identify network + cards} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SHA-1}}{Cryptigraphic hash function, designed by the National Security + Agency (NSA)} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +According to +\begin_inset CommandInset citation +LatexCommand citet +key "Leach98uuidsand" + +\end_inset + +, +\begin_inset Quotes eld +\end_inset + +A UUID is 128 bits long, and if generated according to the one of the mechanisms + in this document, is either guaranteed to be different from all other UUIDs/GUI +Ds generated until 3400 A.D. + or extremely likely to be different +\begin_inset Quotes erd +\end_inset + +. + This 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 + ID:s. + The gathered data is then +\emph on +hashed +\emph default + +\begin_inset space ~ +\end_inset + +using an algorithm such as SHA-1. +\end_layout + +\begin_layout Standard +When using system wide unique identifiers, such as the ones generated by + algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + + with mutual exclusion, it is not possible to have identifier collisions + when recovering from network splits between the GGS clusters. + Consider figure +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:network-split" + +\end_inset + +, where +\emph on +Site A +\emph default + is separated from +\emph on +Site B +\emph default + by a faulty network (illustrated by the cloud and lightening bolt). + 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 ID:s 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 UUID:s solve. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Network split}}{Separation of two networks, occurs when two networks + can not communicate, commonly because of a hardware or software failiure} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/netsplit2.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add clients on each side, and replace the cloud with phole-landlines being + cut by a pair of scissors +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:network-split" + +\end_inset + +An example of a network split +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Security +\end_layout + +\begin_layout Standard +We only support languages running in a sandboxed environment. + Each game session is started in its own sandbox. + The sandboxing isolates the games in such a way that they can not interfere + with each other. + If sandboxing was not in place, one game could potentially modify the contents + of a different game. + A similar approach is taken with the persistent storage we provide. + In the storage each game has its own namespace, much like a table in a + relational database. + A game is not allowed to venture outside this namespace, and can because + this not modify the persistent data of other games. + of 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 Subsection +Encryption +\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 +There is only a very limited number of game developers who would like to + write their games in Erlang, therefore we had to come up with something + to resolve this problem. + The main idea was to offer a replacable module which would introduce a + interface to different virtual machines which would run the game code. + This way a game developer can write the game in his favourite language + while the server part still is written in Erlang and can benefit from all + of its advantages. +\end_layout + +\begin_layout Subsection +JavaScript +\end_layout + +\begin_layout Standard +JavaScript has gained a lot of popularity lately, it is used in large projects + such as +\emph on +Riak +\emph default + +\begin_inset Foot +status open + +\begin_layout Plain Layout +\begin_inset Flex URL +status collapsed + +\begin_layout Plain Layout + +http://wiki.basho.com/An-Introduction-to-Riak.html +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +, +\emph on +CouchDB +\emph default + +\begin_inset Foot +status open + +\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 open + +\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. + The popularity of JavaScript in the programming community, in combination + with the availability of several different JavaScript virtual machines + was an important influence in choosing JavaScript as the main control language + for our GGS prototype. +\begin_inset ERT +status 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 +, +\emph on +ActionScript +\emph default + are suitable as well because 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 our 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. +\end_layout + +\begin_layout Standard +Due lack of time we have decided to use just the Erlang <-> JavaScript bridge + with our interface. +\end_layout + +\begin_layout Section +Testing +\end_layout + +\begin_layout Standard +There are several ways in which the GGS can be tested. + The most important aspect has been deemed to be the experience players + have when using the GGS. + In order 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 need not participate in the same instance of the game, games + such as chess are prime candidates for the GGS. +\end_layout + +\begin_layout Standard +When developing the GGS, two main categories of games exhibiting different + performance demands were identified; real-time games and turn-based games. + The real-time games were deemed more demanding than the turn based games. + Tests were carried out using a real time game, since this is the more demanding + type of games. +\end_layout + +\begin_layout Standard +The real time game chosen for testing the GGS is +\emph on +Pong +\emph default +, a game in which two players play a game involving a all and two paddles. + The goal for each player is to shoot eside the othre player's paddle while + not allowing the ball to pass by her own paddle. + The game requires real time updates and is quite 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 were performed on the GGS, and the results of these tests + are visible in chapter +\begin_inset CommandInset ref +LatexCommand ref +reference "chap:Results-and-discussion" + +\end_inset + +. + The tests were initially performed by starting an operating system process + for each player. + Due to lack of hardware, not enough player processes could be started in + this way. + The bots were re-written in Erlang, and due to Erlang's light weigh threads, + enough processes could be created to successfully test the server. +\end_layout + +\begin_layout Chapter +Implementation of a prototype +\begin_inset CommandInset label +LatexCommand label +name "cha:Implementation-of-a" + +\end_inset + + +\end_layout + +\begin_layout Standard +This chapter contains the realization of much of the principles and techniques + described in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Theory" + +\end_inset + +. + Here the problems and 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 Erlang + GGS prototype. + Specific solutions such as +\emph on +supervisor structures +\emph default +and distribution of erlang nodes on physical nodes. + The different means of communications within the GGS and outside the GGS + with third parties are also discussed here. +\end_layout + +\begin_layout Section +Overview of the prototype +\end_layout + +\begin_layout Standard +The prototype of the GGS was developed using the Erlang language. + The functional and concurrent style of Erlang facilitates devlopment of + software based on a real-world model +\begin_inset CommandInset citation +LatexCommand citep +key "armstrong2011" + +\end_inset + +. + In Erlang, most things are processes. + The software running the Erlang code is known as the Erlang machine, or + an Erlang node. + Each Erlang node is capable of running several +\emph on +threads +\emph default +(also known as +\emph on +Light Weight Processes; LWP +\emph default +) +\emph on +, +\emph default +much like the threads in an operating system. + Threads in a Linux system, for example, are treated much like operating + system processes in different systems. + Due to the size of datastructures related to each process, swapping one + process for another (known as +\emph on +context switching +\emph default +) is an expensive task in many systems +\begin_inset CommandInset citation +LatexCommand citep +after "pg 80" +key "McKusick:2004:DIF:1014910" + +\end_inset + +. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{LWP}}{Light Weight Process} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Context switch}}{The act of switching from one context, commonly + a process, to another. + Used by operating systems to achieve multi tasking} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The cost of swapping operating system processes becomes a problem when many + processes are involved. + If the GGS system had been developed using regular operating system processes, + it would have had to be designed in a way to minimize the number of processes. + Using Erlang, which is capable of running very many processes, several + times more than an operating system can, the mapping between the real world + system (described in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Design-of-the" + +\end_inset + +) becomes clearer. +\end_layout + +\begin_layout Standard +Erlang allows the GGS to create several process for each player connecting, + these processes can handle a multitude of different tasks, parsing data + for example. + Since each task is handled by a different process, the tasks are clearly + separated and the failiure of one is easily recovered without affecting + the others. +\end_layout + +\begin_layout Standard +In addition to creating (or +\emph on +spawning +\emph default +) processes specifically to handle new players connecting, the GGS has more + permanent processes running at all times. + The constantly running processes in the GGS system are called +\emph on +modules +\emph default +. + An example of a module in the GGS is the +\emph on +dispatcher module +\emph default +, which handles the initial connection made by a client, passing the connection + along further in to the system. +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/Chess_no_text.eps + width 100text% + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:The-layout-of" + +\end_inset + +The layout of the GGS. + The circles marked with 'C' topmost in the picture represent clients. + The cloud marked 'network' pictured directly below the clients can be any + network, for example the Internet. + The barell figure marked 'backup' is a process being fed backup data from + the coordinator. + The barell 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 gamers' + machines will be chess game clients. + Clients connect through a network, pictured as a cloud, to the dispatcher + process in the GGS. + The dispatcher process and all other modules are discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:The-modular-structure" + +\end_inset + +. + For each connection, a new player process is spawned, which immediately + after spawning is integrated in to the GGS by the coordinator process. +\end_layout + +\begin_layout Section +The usage of Erlang in the GGS +\begin_inset CommandInset label +LatexCommand label +name "sec:The-usage-of-erlang" + +\end_inset + + +\end_layout + +\begin_layout Standard +Erlang was designed by Ericsson, beginning in 1986, for the purpose of creating + concurrent applications and improving telecom software. + Features essential for the telecom instustry to achieve high availability + in telecom switches were added to the language. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Mutex}}{A construct for achieving mutial exclusion, used to avoid + simultaneous access to shared resources in computer systems} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Erlang uses message passing in favour of shared memory, mutextes and locks, + something which at the time was controversial among fellow developers +\begin_inset CommandInset citation +LatexCommand citet +key "Armstrong:2010:ERL:1810891.1810910" + +\end_inset + +. + The reason for using message passing, according to Armstrong, was that + applications should operate correctly before optimizations are done, where + efficient internal communication within the Erlang machine was considered + a later optimization. +\end_layout + +\begin_layout Standard +In using message passing in favour of the methods commonly used at the time, + the issues commonly associated with shared memory and locking were avoided. + In Erlang, everything is a process, and everything operates in its own + memory space. + Memory can not be shared among processes, which prohibits a process from + corrupting the memory of a different process. +\end_layout + +\begin_layout Standard +Messages are sent between the processes in an asynchronous manner, and each + process has a mailbox in which these messages can be retrieved. +\end_layout + +\begin_layout Standard +Processes in Erlang are also called +\emph on +Light Weight Processes. + +\emph default +The Erlang processes are very cheaply created. + Processes exist within an Erlang machine, or Erlang node. + The Erlang machine has its own scheduler and does not rely on the operating + system's scheduler, this is a main reason of Erlang's capability of running + many concurrent processes +\begin_inset CommandInset citation +LatexCommand citet +key "Armstrong03" + +\end_inset + +. +\end_layout + +\begin_layout Standard +The strong isolation of Erlang processes make them ideal for multicore and + distributed systems. + Distribution of software is included as a fundamental part in the Erlang + language. + The 'physical' location of a process, e.g. + which computer the process runs on, is not important when communicating + with the process. + Processes can communicate regardless of whether they run on the same system + of not, transparently. +\end_layout + +\begin_layout Standard +The distributed nature of Erlang is something the GGS makes use of when + scaling across several computers in order to achieve higher performance. + The distribution is also important in creating redundancy. + Erlang promotes a non-defensive programming style in which processes are + allowed to crash and be restarted in favour 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 + Through ports communication can take place much in the same way communication + is performed over sockets. +\end_layout + +\begin_layout Standard +The GGS uses Erlang ports for generating UUID:s +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +UUID:s are discussed in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:UUID" + +\end_inset + + +\end_layout + +\end_inset + + and for interfacing with the virtual machines of games +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +Virtual machines of games are discussed in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Game-Development-Language" + +\end_inset + + +\end_layout + +\end_inset + +. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{OTP}}{Open Telecom Platform, a software suite for Erlang} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Behaviour}}{A design pattern in OTP} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Development of the GGS would have been hard if not impossible had it not + been for the +\emph on +OTP +\emph default + supplied with the standard Erlang distribution. + The OTP (Open Telecom Platform) is a set of standard libraries and design + patterns, called +\emph on +behaviours +\emph default +, which are used when developing Erlang systems. +\end_layout + +\begin_layout Standard +The GGS makes heavy use of the behaviours supplied in the OTP. + The behaviours impose a programming style suitable for distributed and + concurrent applications, perfectly suitable for the GGS. + In particular, the GGS uses the following behaviours: +\end_layout + +\begin_layout Itemize +The +\emph on +supervisor +\emph default + behaviour, which is used when creating a supervisor. + Supervisors are used when monitoring processes in the Erlang system. + When a process exits wrongfully, the supervisor monitoring the process + in question decides which action to take. + In the GGS, the most common action is simply to restart the faulting process. + A more thorough discussion on supervisors can be found in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Supervisor-structure" + +\end_inset + +. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_tcp +\emph default +behaviour, which is used to work with TCP sockets for network communication. + Using the gen_tcp behaviour, 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 + behaviour, which is used when constructing OTP servers in Erlang. + Using this behaviour, a state can easily be kept in a server process, greatly + increasing the usefulness of the server process. + There are many gen_servers in the GGS, it is the most widely used behaviour + in the project. + In addition to intruducing a state to the server, the gen_server behaviour + also imposes patterns for synchronous and asynchronous communication between + other gen_servers and other OTP behaviours. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_fsm +\emph default + behaviour is used in one module in the GGS, the protocol parser. + Using the gen_fsm behaviour, 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 behaviours, the OTP also has a style for packaging + and running Erlang applications. + By packaging the GGS as an +\emph on +application +\emph default +the GGS can be started in a way uniform to most erlang software, providing + familiarity for other Erlang users, and eases the incorporation of the + GGS in other applications. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Application}}{A way of packaging Erlang software in a uniform way} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Short introduction to the Erlang syntax +\end_layout + +\begin_layout Standard +In order to understand examples in this thesis, a small subset of Erlang + must be understood. + In this section, the very syntactic basics of Erlang are given. +\end_layout + +\begin_layout Itemize + +\series bold +Variables +\series default + start with an uppercase letter, examples include +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt X, Var}, and { +\backslash +tt Global} +\end_layout + +\end_inset + +. + A variable can only be assigned once. +\end_layout + +\begin_layout Itemize + +\series bold +Atoms +\emph on + +\series default +\emph default +start with lower case letters, for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + + { +\backslash +tt atom, a} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Functions +\series default + are defined starting with an atom for the name, parenthesis containing + parameters, an arrow, a function body and finally a dot marking the end + of a function. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt square(X) -> X*X.} +\end_layout + +\end_inset + + is an example of a function producing the square of X. +\end_layout + +\begin_layout Itemize +Functions are +\series bold +called +\series default + by suffixing an atom with the function name with parenthesis, for example + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt square(10)} +\end_layout + +\end_inset + +. + Qualified names can be specified using ':', for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt math:square(10)} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Tuples +\series default + are containers of fixed type for Erlang data types. + They are constructed using curly brackets, for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt +\backslash +{atom1, atom2, atom3 +\backslash +}}. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Itemize + +\series bold +Lists +\series default + are constructed using [ and ], for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt [1,2,3]} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Strings +\series default + doubly qouted 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 refering 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 +Communication with external systems and applications +\begin_inset CommandInset label +LatexCommand label +name "sec:Communication-with-external" + +\end_inset + + +\end_layout + +\begin_layout Standard +A game launched on the GGS is run within a virtual machine. + For each programming language supported, there is a virtual machine that + interprets the game. + Furthermore an interface for communication between the GGS, the game and + the players playing the game must be present. +\end_layout + +\begin_layout Standard +The reason for the GGS requiring a communication channel between the game + VM and Erlang is in part because the GGS makes heavy use of callbacks. + 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 between players. + The interface provides access to three objects called +\emph on +world +\emph default +, +\emph on +player +\emph default + and +\emph on +localstorage +\emph default +. + The game state is safely stored in a database and retrieved for manipulation + by a call for the world object. + Interaction with the players is done the same way using the player object + instead. + The localstorage is a convenient way to store globals and other data seperated + from the game state. + In section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Exposing-Erlang-functionality" + +\end_inset + + a concrete example of the implementation of the localStorage and world + objects is given. +\begin_inset Note Note +status open + +\begin_layout Plain Layout + Unique id:s called gametokens are generated for hosted games so that they + are not mixed up. + -- good text, integrate more. +\end_layout + +\end_inset + + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{WebStorage}}{A new standard for letting websites store data on visitors' + computers} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Exposing Erlang functionality to the GDL VM +\begin_inset CommandInset label +LatexCommand label +name "sub:Exposing-Erlang-functionality" + +\end_inset + + +\end_layout + +\begin_layout Standard +This section contains a concrete example of how the localStorage and world + objects are exposed to a GDL VM. + The example comes from the GGS prototype, which uses JavaScript powered + by Google V8 as its GDL VM. +\end_layout + +\begin_layout Standard +The code given in +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:exposing-erlang" + +\end_inset + + is specific to V8 and JavaScript, however implementations for different + GDL:s, or different JavaScript VM:s should be similar. +\end_layout + +\begin_layout Standard +In JavaScript is is common to use a top level object, called a global object, + to establish a global scope. + This allows declaration of global variables and functions. + To gain access to the global object in the GGS, the +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt erlv8 +\backslash +_vm:global(..)} +\end_layout + +\end_inset + + function on line 2 of the example is used. + Using the global object, declarations of the world and GGS object can be + placed in the global scope. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt Global:set +\backslash +_value(..)} +\end_layout + +\end_inset + + is a call to the global object, declaring new objects in the global scope. + On line 4 the GGS object is declared. + By accessing +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt GGS.localStorage } +\end_layout + +\end_inset + + from within the GDL, access to the localstorage is provided, thus the localstor +age must be connected to the GGS object, this can be seen in line 5. +\end_layout + +\begin_layout Standard +Both the GGS and localStorage objects are dummy objects, which provide no + functionality, these two objects are simply placed in the GDL for the purpose + clearing up the code. + In order to perform an action using the GGS and localStorage objects, the + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt getItem} and { +\backslash +tt setItem} +\end_layout + +\end_inset + + functions must be used. + These items are directly connected to the database module of the GGS, which + is discussed in more detail in +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:The-database-module" + +\end_inset + +. +\end_layout + +\begin_layout Standard +Similarly the functions +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt sendCommand, sendCommandToAll} and { +\backslash +tt setTimeout} +\end_layout + +\end_inset + + are directly connected to a piece of code in the GGS which performs the + desired action. + The +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt sendCommand} +\end_layout + +\end_inset + + functions are used to send commands or text to participants of the table. + The +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt setTimeout} +\end_layout + +\end_inset + + function introduces timeouts to the V8 engine, which are not available + per default. +\end_layout + +\begin_layout Standard +\begin_inset 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", fund(#erlv8_fun_invocation{}, [Time, Function])-> +\end_layout + +\begin_layout Plain Layout + + timer:apply_after(Time, ?MODULE, call_js, [GameVM, Function]) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])). +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:exposing-erlang" + +\end_inset + +An example of how Erlang functionality is exposed to a Javascript GDL +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +TODO: Go in to more detail about how the world, player and localstorage + objects are implemented. + Also discuss localstorage and how it derives from the webstorage standard + in detail. + This is a great point on how we try to follow standards. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +My idea here is that we describe the erlang-js (which failed, but nontheless), + v8, UUID and other external communication. + We shouldn't describe sockets here though.. + or.. + maybe? +\end_layout + +\begin_layout Plain Layout +Also discuss how we allow GDLs to communicate with Erlang, this is +\begin_inset Quotes eld +\end_inset + +external +\begin_inset Quotes erd +\end_inset + + to thre GDL. + Discuss the GGS world object (there is a reference to this secxtion for + that purpose) +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +The modular structure of the GGS prototype +\begin_inset CommandInset label +LatexCommand label +name "sec:The-modular-structure" + +\end_inset + + +\end_layout + +\begin_layout Standard +The separation of concerns, and principle of single responsibility +\begin_inset Foot +status open + +\begin_layout Plain Layout +More information on the SRP is available at: +\begin_inset CommandInset href +LatexCommand href +target "http://www.objectmentor.com/resources/articles/srp.pdf" + +\end_inset + + +\end_layout + +\end_inset + + are widely respected as good practices in the world of software engineering + and development. + By dividing the GGS up into modules each part of the GGS can be modified + without damaging the rest of the system. +\end_layout + +\begin_layout Standard +The responsibility and concern of each module comes from the responsibility + and concern of the real-world entity the model represents. + The modelling of the GGS after a real world system was discussed in chapter + +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Theory" + +\end_inset + +. +\end_layout + +\begin_layout Standard +In the text below the word module refers to the actual code of the discussed + feature, while the word process is used when referring to a running instance + of the code. + Those familiar to object oriented programming may be helped by thinking + in the lines of classes and objects. +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Am I right here? +\end_layout + +\end_inset + + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SRP}}{Single Responsibility Principle} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Object Oriented Programming}}{A programming paradigm focusing on + objects} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +The dispatcher module +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +The discussion of the modules is divided into the following parts: +\end_layout + +\begin_layout Itemize +What does the module do? +\end_layout + +\begin_layout Itemize +What happens when the module fails? +\end_layout + +\begin_layout Itemize +How does the module correspond to the real-world scenario of the chess club? +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The dispatcher module is the first module to have contact with a player. + When a player connects to the GGS, it is first greeted by the dispatcher + module, which sets up an accepting socket for each player. + +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout +Is this the proper way to day the dispatcher greets connecting players? +\end_layout + +\end_inset + + The dispatcher is the module which handles the interfacing to the operating + system when working with sockets. + Operating system limits concering the number of open files, or number of + open sockets are handled here. + The operating system limits can impose problems on the GGS, this is discussed + more in detail in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Problems-of-implementation" + +\end_inset + +. +\end_layout + +\begin_layout Standard +Should the dispatcher module fail to function, no new connections to the + GGS can be made. + In the event of a crash in the dispatcher module, a supervisor process + immediately restarts the dispatcher. + There exists a window of time between the crashing of the dispatcher and + the restarting of the dispatcher, this window is very short, and only during + this window is the GGS unable to process new connection requests. + Due to the modular structure of the GGS, the rest of the system is not + harmed by the dispatcher process not functioning. + The process does not contain a state, therefore a simple restart of the + process is sufficient in restoring the GGS to a pristine state after a + dispatcher crash +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Well.. + In theory.. +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Standard +Returning to scenario of the chess club, the dispatcher module is the doorman + of the club. + When a player enters the chess club, the player is greeted by the doorman, + letting the player in to the club. + The actual letting in to the club is in the GGS represented by the creation + of a player process discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-player-module" + +\end_inset + +. + The newly created player process is handed, and granted rights to, the + socket of the newly connected player. +\end_layout + +\begin_layout Subsection +The player module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-player-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +The player module is responsible for representing a player in the system. + Each connected player has its own player process. + The player process has access to the connection of the player it represents, + and can communicate with this player. + In order to communicate with a player, the data to and from the player + object must pass through a protocol parser module, discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-protocol-parser" + +\end_inset + +. + Raw communication, witout passing the data through a protocol parser is + in theory possible, but is not useful. +\end_layout + +\begin_layout Standard +In the creation of a player process, the coordinator process, discussed + in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-coordinator-module" + +\end_inset + +, is notified by the newly connected process. +\end_layout + +\begin_layout Standard +In the event of a crash in a player process, several things happen. + +\end_layout + +\begin_layout Enumerate +The player process, which is the only process with a reference to the socket + leading to the remote client software, passes this reference of the socket + to the coordinator process temporarily. +\end_layout + +\begin_layout Enumerate +The player process exits. +\end_layout + +\begin_layout Enumerate +The coordinator spawns a new player process, with the same socket reference + as the old player process had. +\end_layout + +\begin_layout Enumerate +The player process resumes operation, immediately starting a new protocol + parser process, and begind receiving and sending network messaged again. +\end_layout + +\begin_layout Standard +The window of time between the crash of the player process and the starting + of a new player process is, as with the dispatcher, very short. + Since the connection changes owners for a short period of time, but is + never dropped, the implications of a crash are only noticed, at worst, + as choppy gameplay for the client. + Note however that this crash recovery scheme is not implemented in the + GGS prototype. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Can we do this..? Seems a bit sneaky. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Moving back to the real world example, the player process represent an actual + person in the chess club. + When a person sits down at a table in the chess club, the person does so + by requesting a seat from some coordinating person, and is then seated + by the same coordinator. + Once seated, the player may make moves on the table he or she is seated + by, this corresponds clearly to how the GGS is structured, as can be seen + in the following sections. +\end_layout + +\begin_layout Subsection +The protocol parser module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-protocol-parser" + +\end_inset + + +\end_layout + +\begin_layout Standard +The protocol parser is an easily interchangable 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 prototocol 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 modelled after the HTTP protocol. + The main reason for this is the familiarity many developers already have + with HTTP due to its presence in internet software. + Each GGS protocol packet contains a headers section. + The headers section is followed by a data section. + In the headers section, parameters concerning the packet is placed. + In the data section, the actual data payload of the packet is placed. +\end_layout + +\begin_layout Standard +There is no requirement of any specific order of the parameters in the headers + section, however the data section must always follow directly after the + headers section. +\end_layout + +\begin_layout Standard +In the example below, line 1 contains a Game-Command parameter. + This parameter is used to determine which game-specific command the client + is trying to perform. + The handling of this parameter is specific to each game, and can be anything. +\end_layout + +\begin_layout Standard +Line 2 specifies a game token. + This is a UUID which is generated for each client upon authentication with + the GGS. + The GGS uses this token in case a client is disconnected and the new connection + created when the client reconnects must be re-paired with the player object + inside the GGS. + The UUID is also used as a unique ID within GDL VMs. +\end_layout + +\begin_layout Standard +Line 3 specifies the content type of the payload of this particular packet. + This parameter allows the GGS to invoke special parsers, should the data + be encoded or encrypted. + When encryption is employed, only the payload is encrypted, not the header + section. + This is a scheme which does not allow for strong encryption, but is deemed + feasible for gaming purposes. +\end_layout + +\begin_layout Standard +Line 4 specifies the content length of the payload following immediately + after the headers section. +\end_layout + +\begin_layout Standard +The parser of the GGS protocol implemented in the GGS prototype is designed + as a finite state machine using the gen_fsm behaviour. + When a full message has been parsed by the parser, the message is converted + into the internal structure of the GGS messages, and sent in to the system + from the protocol paser using message passing. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Packet below is not an algorithm, but I don't know how to change that label.. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting} +\end_layout + +\begin_layout Plain Layout + +Game-Command: chat +\end_layout + +\begin_layout Plain Layout + +Token: e30174d4-185e-493b-a21a-832e2d9d7a1a +\end_layout + +\begin_layout Plain Layout + +Content-Type: text +\end_layout + +\begin_layout Plain Layout + +Content-Length: 18 +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + +Hello world, guys! +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-sample-packet" + +\end_inset + +A sample packet sent from a client to the GGS during a chat session +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Mention that the protocol is heavily influenced bye HTTP, is parsed using + a FSM, perhaps give a sample packet. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +The coordinator module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-coordinator-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +The coordinator module is responsible for keeping track of all players, + their seats and tables. + Players register with the coordinator process when first connecting to + the server, and the coordinator places each player by their respective + table. +\end_layout + +\begin_layout Standard +The coordinator keeps mappings between each player and table, therefore + it is used to perform lookups on tables and players to find out which are + connected. + The connectivity of players and tables is important when sending messages + to all participants in a game. + A lookup in the coordinator process is performed prior to notifying all + players in a game to ensure the message reaches all players. + The lookup can be performed either using internal identification codes + or using the UUID associated with each client and table. +\end_layout + +\begin_layout Standard +The coordinator process contains important state, therefore a backup process + is kept at allt times. + All good data processed by the coordinator is stored for safekeeping in + the backup process as well. + Data which is potentisally harmful is not stored in the backup process. +\end_layout + +\begin_layout Standard +Upon a crash, the coordinator process recovers the prior good state from + the backup process and continues where it left off. + A supervisor process monitors the coordinator process and restarts the + process when it malfunctions. + There is a window of time between the crash of the coordinator and the + restarting of the coordinator, during this time, players can not be seated + by new tables, and can not disconnect from the server. + This window of time is very small, and the unavailability of the coordinator + process should not be noticed by more than a short time lag for the clients. +\end_layout + +\begin_layout Standard +Moving back to the example of the chess club, the coordinator process can + be seen as a judge, monitoring all moves of the players. + At the same time as acting as a judge, the coordinator process is also + a host in the chess club, seating players by their tables and offering + services to the players. +\end_layout + +\begin_layout Subsection +The table module +\end_layout + +\begin_layout Standard +The table module is mostly a hub used for communication. + New table processes are created by the coordinator on demand. + The table module does not contain any business logic, however each process + contains information concerning which players are seated by that particular + table. +\end_layout + +\begin_layout Standard +The information about which players are seated by each table is used when + notifying all players by a table of an action. + Consider a game of chess, each player notifies the table of its actions, + the table then notifies the rest of the participants of these actions after + having had the ac tions processed by the game VM, where an action could + be moving a playing piece. +\end_layout + +\begin_layout Standard +Each table is associated with a game VM. + The actions sent to a table are processed by the game VM, this is where + the game logic is implemented. +\end_layout + +\begin_layout Standard +After a crash in a table process, the entire table must be rebuilt and the + players must be re-associated with the table. + Data concerning players is kept in the coordinator process, and is restored + from there. + Data kept in the actual game is not automatically corrupted by the crash + in a table, however the table must be re-associated with the game VM is + was associated with prior to the crash of the table. + The table process maps well into the setting of the real-world chess club + scenario previously discussed. + A table works in the same way in a real world setting as in the GGS setting. +\end_layout + +\begin_layout Subsection +The game virtual machine module +\end_layout + +\begin_layout Standard +This module holds the game logic of a game and is responsible for the VM + associated with each game. + +\end_layout + +\begin_layout Standard +The game VM contains the state of the VM and a table token associated with + a running game. + GameVM is started by the table module. + The table module hands over a token to the game VM during initialization. + During initialization a new VM instance and various objects associated + to the VM instance will be created. + Callbacks to Erlang are registered into the VM and then the source code + of a game is loaded into the VM and the game is ready for startup. + The only means for a game to communicate with the VM is through usage of + a provided interface. + +\end_layout + +\begin_layout Standard +The VM itself makes it possible for the game developer to program in the + prograimming language covered by the VM. + In future releases, more game VM:s will be added to support more programming + languages. + Because the game VM keeps track of the correct table, the game developer + doesn't need to take this into consideration when programming a game. + If a method within the game sends data to a player, it will be delivered + to the player in the correct running game. + The same game token is used to store the game state in the database. + Therefore, no game states will be mixed up either. +\end_layout + +\begin_layout Standard +This module does not affect game runtime but evaluates a new game state + and handles communication between the game and the players. +\end_layout + +\begin_layout Subsection +The database module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-database-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +Game data from all games on the GGS are stored in the database backend of + the database module. +\end_layout + +\begin_layout Standard +In the GGS prototype the database module is using a database management + system called Mnesia. + Mnesia ships with the standard Erlang distribution and is a key-value store + type database. + Mnesia is designed to handle the stress of telecoms systems, and has some + features specifically tailored for telecoms which are not commonly found + in other databases. + Key features of the Mnesia database are: +\end_layout + +\begin_layout Itemize +Fast key/value lookups +\end_layout + +\begin_layout Itemize +Distribution of the database system +\end_layout + +\begin_layout Itemize +Fault tolerance +\end_layout + +\begin_layout Standard +\begin_inset CommandInset citation +LatexCommand citet +key "667766" + +\end_inset + + +\end_layout + +\begin_layout Standard +The features of Mnesia originally intended for telecoms prove very useful + for the purposes of the GGS as well. + The fault tolerance and speed of Mnesia are very valueable tools, the fast + key/value lookups permit many lookups per second to the database. +\end_layout + +\begin_layout Standard +Game data will not be lost when a game is stopped or has gone down for unknown + reasons. + This makes it possible to continue a game just before the failure without + having to start the game from the beginning. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Mnesia}}{Database server used in the GGS} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS stores the game state in the distributed Mnesia database, from which + the state can be restored in the event of a crash. +\end_layout + +\begin_layout Standard +Each game is uniquely identified by a table token and the data of each game + is stored within two different namespaces. + The namespaces are named World and Localstorage. + The World is used contain all game data related to the game state. + This sort of game data may change during the runtime of the game. + The Localstorage should contain data independent of the game state. + Game resources, constants and globals are all examples of data that could + reside within the Localstorage. + To store a value within the database, not only is the table token and the + name of the namespace required, but a unique key so that the value can + be successfully retrieved or modified later. + The key is fully decidable by the game developer. + +\end_layout + +\begin_layout Standard +The interface of the database module is an implementation of the upcoming + W3C Web Storage specification. + Web Storage is intended for use in web browsers, providing a persistant + storage on the local machine for web applications. + The storage can be used to communicate in between browser windows (which + is difficult when using cookies), and to store larger chunks of data +\begin_inset CommandInset citation +LatexCommand citet +key "webstorage:website" + +\end_inset + +. + Usage of the web storage standard in the GGS provides a well documented + interface to the database backend. +\end_layout + +\begin_layout Section +Techniques for ensuring reliability +\end_layout + +\begin_layout Standard +One of the main goals of the project is to achieve high reliability. + The term +\begin_inset Quotes eld +\end_inset + +reliable system +\begin_inset Quotes erd +\end_inset + + is defined by the IEEE as a system with +\begin_inset Quotes eld +\end_inset + +the ability of a system or component to perform its required functions under + stated conditions for a specified period of time +\begin_inset Quotes erd +\end_inset + + +\begin_inset CommandInset citation +LatexCommand citet +key "ieee_90" + +\end_inset + +. + There are some tools for creating reliable applications built in to Erlang. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Reliability}}{The ability of a system or component to perform its + required functions under stated conditions for a specified period of time} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{IEEE}}{Institute of Electrical and Electronics Engineers, read "I-triple- +E"} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Itemize +Links between processes. + When a process spawns a new child process, and the child process later + exits, the parent process is notified of the exit. + +\end_layout + +\begin_layout Itemize +Transparent distribution over a network of processors. + When several nodes participate in a network, it does not matter on which + of these machines a process is run. + Communication between processes does not depend on the node in which each + process is run. + +\end_layout + +\begin_layout Itemize +Hot code replacements. + Two versions of the same module can reside in the memory of Erlang at any + time. + This means that a simple swap between these versions can take place very + quickly, and without stopping the machine. +\end_layout + +\begin_layout Standard +These three features are some of the basic building blocks for more sophisticate +d reliability systems in Erlang. + Many times it is not necessary to use these features directly, but rather + through the design patterns described below. +\end_layout + +\begin_layout Subsection +Supervisor structure +\begin_inset CommandInset label +LatexCommand label +name "sub:Supervisor-structure" + +\end_inset + + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +This entire section is bad. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +By linking processes together and notifying parents when children exit, + supervisors are created. + A supervisor is a common approach in ensuring that an application functions + in the way it was intended +\begin_inset CommandInset citation +LatexCommand citet +key "Savor:1997:HSA:851010.856089" + +\end_inset + +. + When a process misbehaves, the supervisor takes some action to restore + the process to a functional state. + +\end_layout + +\begin_layout Standard +There are several approaches to supervisor design in general (when not just + considering how they work in Erlang). + One common approach is to have the supervisor look in to the state of the + process(es) it supervises, and let the supervisor make decisions based + on this state. + The supervisor has a specification of how the process it supervises should + function, and this is how it makes decisions. + +\end_layout + +\begin_layout Standard +In Erlang, we have a simple version of supervisors. + We do not inspect the state of the processes being supervised. + We do have a specification of how the supervised processes should behave, + but on a higher level. + The specification describes things such as how many times in a given time + interval a child process may crash, which processes need restarting when + crashes occur, and so forth. + +\end_layout + +\begin_layout Standard +When the linking of processes in order to monitor exit behaviour is coupled + with the transparent distribution of Erlang, a very powerful supervision + system is created. + For instance, we can restart a failing process on a different, new node, + with minimal impact on the system as a whole. + +\end_layout + +\begin_layout Standard +In the GGS, we have separated the system in to two large supervised parts. + We try to restart a crashing child separately, if this fails too many +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +Exactly how many +\begin_inset Quotes eld +\end_inset + +too many +\begin_inset Quotes erd +\end_inset + + is depends on a setting in the supervisor, ten crashes per second is a + reasonable upper limit. +\end_layout + +\end_inset + + times, we restart the nearest supervisor of this child. + This ensures separation of the subsystems so that a crash is as isolated + as possible. +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset Note Note +status open + +\begin_layout Plain Layout +We should really do this graphic in EPS instead of PNG +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/Supervisor_tree_GGS.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +The supervisor structure of GGS +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The graphic above shows our two subsystems, the coordinator subsystem and + the dispatcher subsystem. + Since these two systems perform very different tasks they have been separated. + Each subsystem has one worker process, the coordinator or the dispatcher. + The worker process keeps a state which should not be lost upon a crash. +\end_layout + +\begin_layout Standard +We have chosen to let faulty processes crash very easily when they receive + bad data, or something unexpected happens. + The alternative to crashing would have been to try and fix this faulty + data, or to foresee the unexpected events. + We chose not to do this because it is so simple to monitor and restart + processes, and so difficult to try and mend broken states. + This approach is something widely deployed in the Erlang world, and developers + are often encouraged to “Let it crash”. +\end_layout + +\begin_layout Standard +To prevent any data loss, the good state of the worker processes is stored + in their respective backup processes. + When a worker process (re)starts, it asks the backup process for any previous + state, if there is any that state is loaded in to the worker and it proceeds + where it left off. + If on the other hand no state is available, a special message is delivered + instead, making the worker create a new state, this is what happens when + the workers are first created. +\end_layout + +\begin_layout Subsection +Reduncancy +\end_layout + +\begin_layout Standard +The modules in the GGS are built to be capable of redundant operation. + By adding a backup process to sensitive processes, the state can be kept + in the event of a crash. + The coordinator of the GGS prototype has this backup feature built in. + The coordinator passes state along to the backup process which keeps the + data safe. + In the event of a crash, the coordinator recovers the state from the backup + process. + Figure +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:redundancy" + +\end_inset + + depicts the redundancy built in to the coordinator process. +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/redundancy.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:redundancy" + +\end_inset + +To the left normal execution is pictured; the server state is backed up. + To the right; the exceptional excution, where the state is retrieved from + the backup to repopulate the server. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Hot code replacement +\end_layout + +\begin_layout Standard +Hot code replacement is a technique used to update systems while they are + running. + The main use of hot code replacement are in critical systems that require + low downtime, such as telecom systems. + By using hot code replacement system can be able to achieve as high uptime + as possible and thus improving the reliability of the system. + Code replacement is a feature that exist in Erlang which means that with + some work it could be implemented into the GGS. +\end_layout + +\begin_layout Section +Example of a GGS server application in Javascript +\end_layout + +\begin_layout Standard +Below is a concrete example of a simple chat server application written + using the GGS. + The language chosen for this chat server is JavaScript. + The GGS processes all incoming data through a protocol parser, which interprets + the data and parses it into an internal format for the GGS. +\end_layout + +\begin_layout Standard +When the GGS receives a command from a client, it is passed along to the + game VM in a function called +\emph on +playerCommand. + +\emph default + The +\emph on +playerCommand +\emph default + function is responsible for accepting the command into the VM. + Typically the +\emph on +playerCommand +\emph default + function contains conditional constructs which decide the next action to + take. + In +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-concrete-example" + +\end_inset + + an example of the +\emph on +playerCommand +\emph default + function can be seen. +\end_layout + +\begin_layout Standard +In +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-concrete-example" + +\end_inset + + the +\emph on +playerCommand +\emph default + function accepts two different commands. + The first command is a command which allows chat clients connected to the + chat server to change nicknames, which are used when chatting. + In order to change nickname, a client must send +\begin_inset Quotes eld +\end_inset + +/nick +\begin_inset Quotes erd +\end_inset + + immediately followed by a nickname. + When a message arrives to the GGS which has the form corresponding to the + nickname change, the +\emph on +playerCommand +\emph default + function is called with the parameters +\emph on +player_id, command, +\emph default +and +\emph on +args +\emph default + filled in appropriately. +\end_layout + +\begin_layout Standard +The +\emph on +playerCommand +\emph default + function is responsible for calling the helper functions responsibly for + carrying out the actions of each message received. + +\emph on +changeNick +\emph default + is a function which is called when the +\begin_inset Quotes eld +\end_inset + +/nick +\begin_inset Quotes erd +\end_inset + + message is received. + The +\emph on +changeNick +\emph default +function uses a feature of the GGS called localStorage (see section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Communication-with-external" + +\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 tighty integrated in the GDL of the + GGS. +\end_layout + +\begin_layout Standard +Access to the localStorage is provided through the +\emph on +GGS object +\emph default +, which also can be used to communicate with the rest of the system from + the GDL. + Implementation specifics of the GGS object are provided in +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Communication-with-external" + +\end_inset + +. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +language=JavaScript, +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting}[language=JavaScript] +\end_layout + +\begin_layout Plain Layout + +function playerCommand(player_id, command, args) { +\end_layout + +\begin_layout Plain Layout + + if(command == "/nick") { +\end_layout + +\begin_layout Plain Layout + + changeNick(player_id, args); +\end_layout + +\begin_layout Plain Layout + + } else if(command == "message") { +\end_layout + +\begin_layout Plain Layout + + message(player_id, args); +\end_layout + +\begin_layout Plain Layout + + } +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + +function changeNick(player_id, nick) { +\end_layout + +\begin_layout Plain Layout + + var old_nick = GGS.localStorage.getItem("nick_" + player_id); +\end_layout + +\begin_layout Plain Layout + + GGS.localStorage.setItem("nick_" + player_id, nick); +\end_layout + +\begin_layout Plain Layout + + if (!old_nick) { +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll("notice", nick + " joined"); +\end_layout + +\begin_layout Plain Layout + + } else { +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll("notice", old_nick + " is now called " + nick); +\end_layout + +\begin_layout Plain Layout + + } +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + +function message(player_id, message) { +\end_layout + +\begin_layout Plain Layout + + var nick = GGS.localStorage.getItem("nick_" + player_id); +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll('message', nick + "> " + message); +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-concrete-example" + +\end_inset + +A concrete example of a simple chat server written in Javascript, running + on the GGS +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Chapter +Problems of implementation +\begin_inset CommandInset label +LatexCommand label +name "cha:Problems-of-implementation" + +\end_inset + + +\end_layout + +\begin_layout Standard +This chapter contains specific problems encountered when implementing the + GGS prototype. + Some of the problems described have solutions attached, however some problems + were not solved, therefore only ideas for slutions have been attached. +\end_layout + +\begin_layout Standard +The integration of JavaScript as a GDL in the GGS prototype was particularily + difficult, and is handled in this section. + Unique identification is also handled, as is the design of the GGS protocol. +\end_layout + +\begin_layout Section +JavaScript engine +\end_layout + +\begin_layout Standard +The GGS prototype uses a vistual machine to sandbox each game. + JavaScript was chosen for the prototype due to its commonality in web applicati +ons and the flexibility of the language. + Any language with the proper bindings to Erlang could have been used in + theory. +\end_layout + +\begin_layout Standard +There are two main JavaScript virtual machines, or +\emph on +engines +\emph default + 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 V8. + 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. +\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 thee possibility + to communicate from erlang_js to Erlang. + The ability to communicate from JavaScript to Erlang functionality is not + yet implemented in erlang_js, due to lack of time on the behalf of the + erlang_js developers. +\end_layout + +\begin_layout Standard +There were two possible solutions to the problem of the JavaScript to Erlang + communication path missing, the path could be implemented by the GGS project, + or a switch from erlang_js for some other JavaScript engine could be made. + +\end_layout + +\begin_layout Standard +Attempts at creating the communication path from JavaScript to Erlang were + initially made, however the communiucation path 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 rather than the engines + developed by Mozilla. + The ability to communicate with Erlang from JavaScript using callbacks + is available in the erlv8 bindings, therefore this feature does not have + to be added to the bindings in order to be used in the GGS. +\end_layout + +\begin_layout Standard +Initial releases of the erlv8 bindings had stability issues, these were + however solved by the erlv8 developers during the usage of erlv8 in the + GGS. + 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 +UUID +\end_layout + +\begin_layout Standard +Erlang identifies processes uniquely throughout the entire Erlang network + using process IDs (PID). + When we wish to refer to erlang processes from outside our erlang system, + for example in a virtual machine for a different language, possibly on + a different machine, these PID:s are no longer useful. + +\end_layout + +\begin_layout Standard +This problem is not new, and a common solution is to use a Universally Unique + Identifier, a UUID. + These identifiers are generated both using randomization and using time. + A reasonably large number of UUID:s can be generated before a collision + should occur. + There are standard tools in many UNIX systems to generate UUID:s, we chose + to use the uuidgen command, which employs an equidistributed combined Tausworth +e generator. +\end_layout + +\begin_layout Section +Protocol design +\end_layout + +\begin_layout Standard +Initially the GGS protocol was designed to use the UDP protocol for transport. + Due to the lack of error checking in the UDP protocol, the UDP protocol + is faster than the TCP protocol, this was a main reason to use UDP. + The GGS does however need error checking to be as reliable as possible, + therefore an error checking layer would have to be placed on top of UDP. +\end_layout + +\begin_layout Standard +The development of an error checking layer was weighed against the implementatio +n of TCP instead of UDP, thus losing some speed. + Even though speed was lost, TCP was chosen due to the relative ease of + implementation compared to UDP. + Due to the modularity of the GGS, a UDP extension is possible by replacing + the network parts of the GGS. +\end_layout + +\begin_layout Standard +Furthermore, in a move to increase the speed of the GGS prototcol the binary + BSON protocol +\begin_inset CommandInset citation +LatexCommand citet +key "bson:website" + +\end_inset + + was initially considered. + BSON is a protocol which can be used for vert fast traversal of data. + The BSON protocol is however rather difficult to read in its plain format, + and no implementation has been bade for the GGS. +\end_layout + +\begin_layout Standard +The Apache Thrift +\begin_inset CommandInset citation +LatexCommand citep +key "Slee2007" + +\end_inset + + was also an alternative. + Using Thrift would mean the GGS would feature a standard protocol for network + communication. + Before finding out about Thrift, an implementation of the GGS protocol + had already been made, moving to Thrift would mean too much work. +\end_layout + +\begin_layout Standard +The use of Thrift, BSON, or other protocols can be supported quite easily + by develpping protocol modules for each protocol. + No protocol modules for these protocols have however been developed during + the writing of this thesis +\end_layout + +\begin_layout Section +Design choices +\begin_inset Note Note +status open + +\begin_layout Plain Layout +This section is wrongly placed +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +When designing concurrent applications, it is useful to picture them as + real world scenarios, and to model each actor as a real world process. + A real world process is a process which performs some action in the real + world, such as a mailbox receiving a letter, a door being opened, a person + translating a text, a soccer player kicking the ball, just to name a few + examples. + Since we focus on games in this project, it is suitable to model our system + as a place where games take place. + We imagined a chess club. + +\end_layout + +\begin_layout Standard +The clients pictured as green circles can be thought of as the physical + chess players. +\end_layout + +\begin_layout Standard +When a player wants to enter the our particular chess club, he must first + be let in by the doorman, called the +\emph on +Dispatcher +\emph default + in the GGS. +\end_layout + +\begin_layout Standard +He then gets a name badge, and thus becomes a +\emph on +Player +\emph default + process in the system. + He is also guided in to the lobby by the +\emph on +Coordinator +\emph default +, which has the role of the host of the chess club. +\end_layout + +\begin_layout Standard +When players wish to play against each other, they talk to the +\emph on +Coordinator +\emph default + who pairs them up, and places them at a table. + Once they have sat down at the table, they no longer need the assistance + of the +\emph on +Coordinator +\emph default +, all further communication takes place via the table. + This can be thought of as the actual chess game commencing. + +\end_layout + +\begin_layout Standard +All the moves made in the game are recorded by the table, such that the + table can restore the game in case something would happen, such as the + table tipping over, which would represent the table process crashing. +\end_layout + +\begin_layout Standard +Once a player wishes to leave a game, or the entire facility, he should + contact the +\emph on +Coordinator +\emph default +, who revokes his name badge and the +\emph on +Dispatcher +\emph default + will let the player out. +\end_layout + +\begin_layout Standard +With the information kept in the tables and the +\emph on +Coordinator +\emph default + combined, we can rebuild the entire state of the server at a different + location. + This can be thought of the chess club catching fire, and the +\emph on +Coordinator +\emph default + rounding up all the tables, running to a new location and building the + club up in the exact state it was prior to the fire. +\end_layout + +\begin_layout Chapter +Results and discussion +\begin_inset CommandInset label +LatexCommand label +name "chap:Results-and-discussion" + +\end_inset + + +\end_layout + +\begin_layout Section +Software development methodology +\end_layout + +\begin_layout Standard +The project has not followed any specific software development methodology. + All work has been based on a predefined schedule and the specifications + are made by team members rather than an outside customer or stakeholder. + The process can be described as a plan-driven development method going + from brainstorming to design, then implementation and finally testing. + Yet there has been cycles in the process in form of redesign and code refactori +ng. +\end_layout + +\begin_layout Section +Statistics +\end_layout + +\begin_layout Standard +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 can not 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 Standard +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 + +\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/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 + +\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 + +\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 + +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Future improvements +\end_layout + +\begin_layout Standard +The specification of the GGS prototype is huge and like many other software + projects relying on outside technologies, in time it would require a lot + of maintanance. + Therefore there are a lot of areas in which the GGS could be improved such + as performance, compatibility, ease of setup and usage. +\end_layout + +\begin_layout Subsection +Performance +\end_layout + +\begin_layout Subsubsection +Protocols +\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 bandwith than connectionless + protocols like UDP and cause uneccessary load on the processor. + Therefore support for UDP would mean that more games could be run simultaneousl +y on the GGS. + Another advantage of UDP is latency being reduced. + Without having to setup a connection for each group packets of data being + sent, they will be sent instantly and therefore arrive earlier. + Latency is of highest importance in realtime games as it improves realism + and fairness in gameplay and many game developers requires 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. + This could be prevented by replacing Mnesia with another database management + system or use Mnesia in combination with the ETS module of erlang. + ETS provides fast access to the RAM and thus Mnesia could be used less + frequently. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{ETS}}{Erlang Term Storage} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Compatibility +\end_layout + +\begin_layout Standard +GGS relies on modern technologies. + This includes the virtual machines(VM) that the GGS uses for communication + between Erlang and the GDL:s. + These specific VM:s are crucial for game developers to be able to write + games in other languages than Erlang. + Therefore it would be best for the GGS to have as many of these VM:s implemente +d as possible. + The VM:s taken into consideration so far have been unstable or incomplete + and it is possible to search for more VM:s, testing them and intergrate + them into the GGS prototype. +\end_layout + +\begin_layout Subsection +Setup +\end_layout + +\begin_layout Standard +The GGS prototype installation procedure requires different configuring + and building steps and thus it isn't in an acceptable release state. + An executable installation file for each supported platform would be optimal. +\end_layout + +\begin_layout Subsection* +5.3.4 Usage +\end_layout + +\begin_layout Subsubsection +Programming languages +\end_layout + +\begin_layout Standard +The GGS does not support many programming languages. + For a programming language to be compatible with the GGS, not only does + it require a VM for that specific language, but the VM must have the ability + to communicate to Erlang. + More research is needed to find VM:s with this built in functionality. + +\end_layout + +\begin_layout Subsubsection +Documentation +\end_layout + +\begin_layout Standard +To start the GGS is not self explanatory. + This together with overall usage of GGS should be documented. + The interface for usage of game developers is also in need of documentation. + Features and requirements with respect to the GGS would assist users to + know what they need in order to use the GGS and how they would benefit + of it. + The GGS does not support many programming languages nor does it have a + complete documentation. + This needs to be taken care of in future versions. +\end_layout + +\begin_layout Chapter +Conclusion +\end_layout + +\begin_layout Standard +\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 + +\end_layout + +\begin_layout Standard +\begin_inset CommandInset bibtex +LatexCommand bibtex +bibfiles "bibliography" +options "plainnat" + +\end_inset + + +\end_layout + +\end_body +\end_document