diff --git a/merge.lyx b/merge.lyx deleted file mode 100644 index 938b4e6..0000000 --- a/merge.lyx +++ /dev/null @@ -1,7228 +0,0 @@ -#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 deleted file mode 100644 index 579d6b8..0000000 --- a/not-working.lyx +++ /dev/null @@ -1,7817 +0,0 @@ -#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/working.lyx b/working.lyx deleted file mode 100644 index bdc12ed..0000000 --- a/working.lyx +++ /dev/null @@ -1,7223 +0,0 @@ -#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