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