From d21d6479dc3ee9229b26abe213b66cc465f864de Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Fri, 6 May 2011 14:59:02 +0200 Subject: [PATCH 01/16] UUID & 'Protocol design' moved out one level --- report.lyx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/report.lyx b/report.lyx index 7c7ad6f..a0ea855 100644 --- a/report.lyx +++ b/report.lyx @@ -6622,7 +6622,7 @@ textbf{SpiderMonkey}}{JavaScript engine developed by Mozilla} \end_layout -\begin_layout Subsection +\begin_layout Section UUID \end_layout @@ -6646,7 +6646,7 @@ This problem is not new, and a common solution is to use a Universally Unique e generator. \end_layout -\begin_layout Subsection +\begin_layout Section Protocol design \end_layout From e086bfc25825a50468bc0c023ef009fab481430c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Fri, 6 May 2011 15:36:08 +0200 Subject: [PATCH 02/16] Added references to Thrift and BSON. Added text in problems about protocols --- bibliography.bib | 29 +++++++++++++++++++ report.lyx | 73 ++++++++++++++++++++++++++++++------------------ 2 files changed, 75 insertions(+), 27 deletions(-) diff --git a/bibliography.bib b/bibliography.bib index 8ddd134..963a6c9 100644 --- a/bibliography.bib +++ b/bibliography.bib @@ -270,3 +270,32 @@ YEAR = {2011}, URL = "http://dev.w3.org/html5/webstorage/" } + + +@MISC{bson:website, + AUTHOR = "BSON", + TITLE = "BSON - Binary JSON", + MONTH = "May", + YEAR = {2011}, + URL = "http://bsonspec.org" +} + + +@techreport{Slee2007, + author = {Aditya Agarwal and Mark Slee and Marc Kwiatkowski}, + institution = {Facebook}, + interhash = {105e59dd8576a9d92bb7db1ecc7e4980}, + intrahash = {2593c1a9666cfc633d674051d887c8e3}, + title = {Thrift: Scalable Cross-Language Services Implementation}, + url = {http://incubator.apache.org/thrift/static/thrift-20070401.pdf}, + year = 2007, + timestamp = {2009-11-02T17:24:36.000+0100}, + keywords = {Thrift datamodeling language specification}, + added-at = {2009-11-02T17:24:36.000+0100}, + biburl = {http://www.bibsonomy.org/bibtex/22593c1a9666cfc633d674051d887c8e3/voj}, + month = {April}, + abstract = {Thrift is a software library and set of code-generation tools developed at Facebook to expedite development and implementation of efficient and scalable backend services. Its primary goal is to enable efficient and reliable communication across programming languages by abstracting the portions of each language that tend to require the most customization into a common library that is implemented in each language. Specifically, Thrift allows developers to define datatypes and service interfaces in a single language-neutral file and generate all the necessary code to build RPC clients and servers. + +This paper details the motivations and design choices we made in Thrift, as well as some of the more interesting implementation details. It is not intended to be taken as research, but rather it is an exposition on what we did and why. +} +} diff --git a/report.lyx b/report.lyx index a0ea855..b0ed2bf 100644 --- a/report.lyx +++ b/report.lyx @@ -6651,21 +6651,57 @@ Protocol design \end_layout \begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Discuss how the early GGS protocol were going to use both UDP and binary - plists to be as fast as possible. - Then discuss how complex these solutions were going to be to implement - in the prototype. - Mention that the modular structure of the GGS allows these features to - be implemented later on, but are not currently implemented. +Initially the GGS protocol was designed to use the UDP protocol for transport. + Due to the lack of error checking in the UDP protocol, the UDP protocol + is faster than the TCP protocol, this was a main reason to use UDP. + The GGS does however need error checking to be as reliable as possible, + therefore an error checking layer would have to be placed on top of UDP. \end_layout +\begin_layout Standard +The development of an error checking layer was weighed against the implementatio +n of TCP instead of UDP, thus losing some speed. + Even though speed was lost, TCP was chosen due to the relative ease of + implementation compared to UDP. + Due to the modularity of the GGS, a UDP extension is possible by replacing + the network parts of the GGS. +\end_layout + +\begin_layout Standard +Furthermore, in a move to increase the speed of the GGS prototcol the binary + BSON protocol +\begin_inset CommandInset citation +LatexCommand citet +key "bson:website" + \end_inset + was initially considered. + BSON is a protocol which can be used for vert fast traversal of data. + The BSON protocol is however rather difficult to read in its plain format, + and no implementation has been bade for the GGS. +\end_layout +\begin_layout Standard +The Apache Thrift +\begin_inset CommandInset citation +LatexCommand citep +key "Slee2007" + +\end_inset + + was also an alternative. + Using Thrift would mean the GGS would feature a standard protocol for network + communication. + Before finding out about Thrift, an implementation of the GGS protocol + had already been made, moving to Thrift would mean too much work. +\end_layout + +\begin_layout Standard +The use of Thrift, BSON, or other protocols can be supported quite easily + by develpping protocol modules for each protocol. + No protocol modules for these protocols have however been developed during + the writing of this thesis \end_layout \begin_layout Section @@ -6772,23 +6808,6 @@ Coordinator club up in the exact state it was prior to the fire. \end_layout -\begin_layout Section -Usability -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Discuss how the GGS can be difficult to use for people not versed with Erlang -\end_layout - -\end_inset - - -\end_layout - \begin_layout Chapter Results and discussion \begin_inset CommandInset label From aad3e2118caa39d6e4c366eb35f08136e0a5eeda Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Fri, 6 May 2011 15:43:20 +0200 Subject: [PATCH 03/16] Typo in figure 3.3 text --- report.lyx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/report.lyx b/report.lyx index b0ed2bf..19e5270 100644 --- a/report.lyx +++ b/report.lyx @@ -6077,7 +6077,7 @@ name "fig:redundancy" \end_inset To the left normal execution is pictured; the server state is backed up. - To the left; the exceptional excution, where the state is retrieved from + To the right; the exceptional excution, where the state is retrieved from the backup to repopulate the server. \end_layout From 38369d71d525c31d8da4b895636fc89e5eed7590 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Fri, 6 May 2011 15:46:16 +0200 Subject: [PATCH 04/16] Fixed an old bad merge --- report.lyx | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/report.lyx b/report.lyx index 19e5270..bdc12ed 100644 --- a/report.lyx +++ b/report.lyx @@ -1406,12 +1406,10 @@ The first prototype of the GGS consisted of simple modules, however, due \begin_layout Standard Once the basic structure of the GGS had been established, the first prototype was removed, remaining was the structure of the modules and the internal - flow of the application.<<<<<<< HEAD This could be seen as an iterative - workflow, with the first prototype being the first iteration. - The second iteration later became the result of the GGS + flow of the application. \end_layout -\begin_layout Subsection +\begin_layout Standard Design This could be seen as an interative workflow, with the first prototype being the first iteration. The second iteration later became the final result of the GGS. From 476b56e0044f0c90d70b47e513312d264166b479 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Fri, 6 May 2011 15:46:16 +0200 Subject: [PATCH 05/16] Fixed an old bad merge --- report.lyx | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/report.lyx b/report.lyx index 19e5270..e7338b2 100644 --- a/report.lyx +++ b/report.lyx @@ -1401,18 +1401,10 @@ textbf{Module}}{A part of a larger system} The first prototype of the GGS consisted of simple modules, however, due to the separation of concerns among the modules, they were easily independently modified and improved. -\end_layout - -\begin_layout Standard -Once the basic structure of the GGS had been established, the first prototype + 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.<<<<<<< HEAD This could be seen as an iterative - workflow, with the first prototype being the first iteration. - The second iteration later became the result of the GGS -\end_layout - -\begin_layout Subsection -Design This could be seen as an interative workflow, with the first prototype + flow of the application. + This could be seen as an interative workflow, with the first prototype being the first iteration. The second iteration later became the final result of the GGS. \end_layout From 3755ab5dc5631a1b721db9e934d9922f1be1e706 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Fri, 6 May 2011 15:51:46 +0200 Subject: [PATCH 06/16] Removed obolete section & added note concerning hardware for testing --- report.lyx | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/report.lyx b/report.lyx index e7338b2..f8ef7af 100644 --- a/report.lyx +++ b/report.lyx @@ -6811,22 +6811,19 @@ name "chap:Results-and-discussion" \end_layout -\begin_layout Section -Software development methodology -\end_layout - -\begin_layout Standard -The project has not followed any specific software development methodology. - All work has been based on a predefined schedule and the specifications - are made by team members rather than an outside customer or stakeholder. - The process can be described as a plan-driven development method going - from brainstorming to design, then implementation and finally testing. - Yet there has been cycles in the process in form of redesign and code refactori -ng. -\end_layout - \begin_layout Section Statistics +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Mention the hardware which the GGS was run on; A Thinkpad T410 wityh a core + i5 and 4GB of ram. +\end_layout + +\end_inset + + \end_layout \begin_layout Standard From 6bdb9f0d903e27ff72ebe4f96fdda5e4c4730206 Mon Sep 17 00:00:00 2001 From: Jeena Paradies Date: Fri, 6 May 2011 16:27:14 +0200 Subject: [PATCH 07/16] fixed one latex error --- report.lyx | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/report.lyx b/report.lyx index 184e1cf..64f481a 100644 --- a/report.lyx +++ b/report.lyx @@ -554,18 +554,16 @@ textbf{Doom}}{A first person shooter series developed by ID software. \backslash nomenclature{ \backslash -textbf{World of Warcraft}}{A MMORPG game developed by Blizzard. - The world's most popular MMORPG by subscriber count.} +textbf{Counter-Strike}}{A multiplayer first person shooter game, popular + in E-Sports.} \end_layout \begin_layout Plain Layout - +/nomenclature{ \backslash -nomenclature{ -\backslash -textbf{Counter-Strike}}{A multiplayer first person shooter game, popular - in E-Sports.} +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 From 4cf13b249fe5ab89212fcc6d4bb7095521ad6f72 Mon Sep 17 00:00:00 2001 From: unknown Date: Fri, 6 May 2011 16:51:20 +0200 Subject: [PATCH 08/16] Fixed error! --- report.lyx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/report.lyx b/report.lyx index 64f481a..46f268c 100644 --- a/report.lyx +++ b/report.lyx @@ -7801,7 +7801,7 @@ addcontentsline{toc}{section}{Glossary} \backslash -printnomenclature +\printnomenclature \end_layout \end_inset From 676989b82d60d9d3ea15e954d1f23f9078a2623a Mon Sep 17 00:00:00 2001 From: unknown Date: Fri, 6 May 2011 17:41:21 +0200 Subject: [PATCH 09/16] Small content changes and spelling/grammar changes --- report.lyx | 208 ++++++++++++++++++++++++++--------------------------- 1 file changed, 103 insertions(+), 105 deletions(-) diff --git a/report.lyx b/report.lyx index 46f268c..e3e7d06 100644 --- a/report.lyx +++ b/report.lyx @@ -416,8 +416,8 @@ key "nethack:website" . The games often took place in a textual world, leaving the task of picturing the world up to the player. - Multi-player games were not as common as they are today, whereas most games - today are expected to have a multi-player mode, most early games did not. + 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 @@ -453,8 +453,8 @@ key "esa:website,thenumbers:website" \begin_layout Standard Due to the increasing importance of computer gaming, more focus should be spent on improving the quality of the gaming service. - As more and more computer games are gaining multi-player capabilities, - the demands for multiplayer networking software rises. + As more and more computer games are gaining multiplayer capabilities, the + demands for multiplayer networking software rises. This thesis is about techniques for improving the quality of this networking software. \end_layout @@ -738,7 +738,7 @@ the nine nines \begin_inset Formula $99.999999999\%$ \end_inset - of availability, or rougly + of availability, or roughly \begin_inset Formula $15ms$ \end_inset @@ -757,11 +757,11 @@ Citation needed industry would not have been accepted in the telecoms industry. This level of instability should not be accepted in the game server industry either. - An unavailabvle phone system could potentially have life threatening consequenc -es, leaving the public unable to contant emergency services. + An unavailable phone system could potentially have life threatening consequence +s, leaving the public unable to contact emergency services. The same can not be said about an unavailable game server. The statement that game servers are less important than phone systems is - not a reason not to draw wisdom from what the telecoms have already learnt. + not a reason not to draw wisdom from what the telecoms have already learned. \end_layout \begin_layout Standard @@ -1271,9 +1271,8 @@ textbf{TCP}}{Transmission Control Protocol, a streaming network protocol} \begin_layout Standard The UDP protocol is not supported for communication between client and server. - The TCP protocol was chosen in favour of UDP, due to the fact that the - implementation process using TCP was faster than if UDP would have been - used. + The TCP protocol was chosen in favor of UDP, due to the fact that the implement +ation process using TCP was faster than if UDP would have been used. UDP is generally considered to be faster than TCP for the transfer of game (and other) related data, this is discussed in more depth in \begin_inset CommandInset ref @@ -1333,7 +1332,7 @@ key "Farber:2002:NGT:566500.566508" \emph on Counter Strike \emph default - or massively multiplayer online role playing games (MMORPG:s), for example + or massively multiplayer online role playing games (MMORPGs), for example \emph on World of Warcraft @@ -1402,8 +1401,8 @@ The first prototype of the GGS consisted of simple modules, however, due Once the basic structure of the GGS had been established, the first prototype was removed, remaining was the structure of the modules and the internal flow of the application. - This could be seen as an interative workflow, with the first prototype - being the first iteration. + 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 @@ -1421,7 +1420,7 @@ The layout of the GGS is both layered and modular. \begin_layout Standard An informal specification and list of requirements of the system was outlined early on in the project. - Usaility goals for developers were set. + 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 @@ -2037,7 +2036,7 @@ INDSTATE \end_inset -alert the coordinator, de-registering the players +alert the coordinator, unregistering the players \end_layout \begin_layout Plain Layout @@ -2112,7 +2111,7 @@ In a first person shooter game, the speed of delivery of messages is essential. Failure to deliver messages in time results in choppy gameplay for the players. In strategy games, the reliability of delivery may be more important than - the speed, since the game is not perceieved as choppy even if the messages + the speed, since the game is not perceived as choppy even if the messages are delayed. \end_layout @@ -2142,7 +2141,7 @@ status open Tue apr 26, 9:15. Continue from here on. Discuss which results we may expect in a fully fledged GGS system. - What impedes the speeds, what raises the CPU load (and therefore the temperetur + 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 @@ -2387,8 +2386,7 @@ name "sec:Generic" \begin_layout Standard The GGS is a game server. It was made with a desire to be suitable for any kind of game. - Any game with a client-server behaviour should be perfectly suited for - GGS. + Any game with a client-server behavior should be perfectly suited for GGS. A game should not only be able to vary in terms of genre, graphics, gameplay etc, but also in the way the game is implemented. Such as different programming languages. @@ -2459,7 +2457,7 @@ In order to make the GGS prototype fault tolerant the programming language \begin_layout Standard The need for fault tolerance in game servers is not as obvious as it may - be for other typ of servers. + be for other type of servers. In general all servers strive to be fault tolerant as fault tolerance means more uptime and a safer system. This applies to game servers as well, in brief good fault tolerance is @@ -3110,7 +3108,7 @@ end{centering} status open \begin_layout Plain Layout -Add clients on each side, and replace the cloud with phole-landlines being +Add clients on each side, and replace the cloud with pole-landlines being cut by a pair of scissors \end_layout @@ -3196,11 +3194,11 @@ name "sec:Game-Development-Language" There is only a very limited number of game developers who would like to write their games in Erlang, therefore we had to come up with something to resolve this problem. - The main idea was to offer a replacable module which would introduce a + The main idea was to offer a replaceable module which would introduce a interface to different virtual machines which would run the game code. - This way a game developer can write the game in his favourite language - while the server part still is written in Erlang and can benefit from all - of its advantages. + This way a game developer can write the game in his favorite language while + the server part still is written in Erlang and can benefit from all of + its advantages. \end_layout \begin_layout Subsection @@ -3423,7 +3421,7 @@ The real time game chosen for testing the GGS is Pong \emph default , a game in which two players play a game involving a all and two paddles. - The goal for each player is to shoot eside the othre player's paddle while + The goal for each player is to shoot beside the other players paddle while not allowing the ball to pass by her own paddle. The game requires real time updates and is quite demanding when played in several instances concurrently. @@ -3516,7 +3514,7 @@ Overview of the prototype \begin_layout Standard The prototype of the GGS was developed using the Erlang language. - The functional and concurrent style of Erlang facilitates devlopment of + The functional and concurrent style of Erlang facilitates development of software based on a real-world model \begin_inset CommandInset citation LatexCommand citep @@ -3543,7 +3541,7 @@ Light Weight Processes; LWP much like the threads in an operating system. Threads in a Linux system, for example, are treated much like operating system processes in different systems. - Due to the size of datastructures related to each process, swapping one + Due to the size of data structures related to each process, swapping one process for another (known as \emph on context switching @@ -3607,7 +3605,7 @@ Erlang allows the GGS to create several process for each player connecting, these processes can handle a multitude of different tasks, parsing data for example. Since each task is handled by a different process, the tasks are clearly - separated and the failiure of one is easily recovered without affecting + separated and the failure of one is easily recovered without affecting the others. \end_layout @@ -3721,9 +3719,9 @@ reference "fig:The-layout-of" the entire GGS system is represented graphically. The circles marked with 'C' topmost in the picture represent game clients. - These circles represent processes running on gamers' computers, and not + These circles represent processes running on gamers computers, and not on the GGS machine. - If a game of chess is to be played on the server, the clients on the gamers' + If a game of chess is to be played on the server, the clients on the gamers machines will be chess game clients. Clients connect through a network, pictured as a cloud, to the dispatcher process in the GGS. @@ -3753,7 +3751,7 @@ name "sec:The-usage-of-erlang" \begin_layout Standard Erlang was designed by Ericsson, beginning in 1986, for the purpose of creating concurrent applications and improving telecom software. - Features essential for the telecom instustry to achieve high availability + Features essential for the telecom industry to achieve high availability in telecom switches were added to the language. \begin_inset ERT status open @@ -3774,7 +3772,7 @@ textbf{Mutex}}{A construct for achieving mutial exclusion, used to avoid \end_layout \begin_layout Standard -Erlang uses message passing in favour of shared memory, mutextes and locks, +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 @@ -3790,7 +3788,7 @@ key "Armstrong:2010:ERL:1810891.1810910" \end_layout \begin_layout Standard -In using message passing in favour of the methods commonly used at the time, +In using message passing in favor of the methods commonly used at the time, the issues commonly associated with shared memory and locking were avoided. In Erlang, everything is a process, and everything operates in its own memory space. @@ -3824,8 +3822,8 @@ key "Armstrong03" \end_layout \begin_layout Standard -The strong isolation of Erlang processes make them ideal for multicore and - distributed systems. +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. @@ -3840,7 +3838,7 @@ The distributed nature of Erlang is something the GGS makes use of when scaling across several computers in order to achieve higher performance. The distribution is also important in creating redundancy. Erlang promotes a non-defensive programming style in which processes are - allowed to crash and be restarted in favour of having the processes recover + 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 @@ -3948,16 +3946,16 @@ OTP The OTP (Open Telecom Platform) is a set of standard libraries and design patterns, called \emph on -behaviours +behaviors \emph default , which are used when developing Erlang systems. \end_layout \begin_layout Standard -The GGS makes heavy use of the behaviours supplied in the OTP. - The behaviours impose a programming style suitable for distributed and - concurrent applications, perfectly suitable for the GGS. - In particular, the GGS uses the following behaviours: +The GGS makes heavy use of the behaviors supplied in the OTP. + The behaviors impose a programming style suitable for distributed and concurren +t applications, perfectly suitable for the GGS. + In particular, the GGS uses the following behaviors: \end_layout \begin_layout Itemize @@ -3965,7 +3963,7 @@ The \emph on supervisor \emph default - behaviour, which is used when creating a supervisor. + 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. @@ -3985,8 +3983,8 @@ The \emph on gen_tcp \emph default -behaviour, which is used to work with TCP sockets for network communication. - Using the gen_tcp behaviour, network messages are converted to internal +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 @@ -3996,14 +3994,14 @@ The \emph on gen_server \emph default - behaviour, which is used when constructing OTP servers in Erlang. - Using this behaviour, a state can easily be kept in a server process, greatly + 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 behaviour + There are many gen_servers in the GGS, it is the most widely used behavior in the project. - In addition to intruducing a state to the server, the gen_server behaviour + 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 behaviours. + other gen_servers and other OTP behaviors. \end_layout \begin_layout Itemize @@ -4011,14 +4009,14 @@ The \emph on gen_fsm \emph default - behaviour is used in the protocol parser module in the GGS. - Using the gen_fsm behaviour, finite state machines are easily developed. + 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 behaviours, the OTP also has a style for packaging +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 @@ -4214,7 +4212,7 @@ tt [1,2,3]} \series bold Strings \series default - doubly qouted lists of characters, for example + doubly quoted lists of characters, for example \begin_inset ERT status open @@ -4236,7 +4234,7 @@ tt "Hello world"} Records \series default are erlang tuples coupled with a tag for each tuple element. - This allows refering to elements by name instead of by position. + This allows referring to elements by name instead of by position. An example of a record looks like this: \begin_inset ERT status open @@ -4298,8 +4296,8 @@ localstorage by a call for the world object. Interaction with the players is done the same way using the player object instead. - The localstorage is a convenient way to store globals and other data seperated - from the game state. + The localstorage is a convenient way to store global data and other data + separated from the game state. In section \begin_inset CommandInset ref LatexCommand ref @@ -4307,7 +4305,7 @@ reference "sub:Exposing-Erlang-functionality" \end_inset - a concrete example of the implementation of the localStorage and world + a concrete example of the implementation of the localstorage and world objects is given. \begin_inset Note Note status open @@ -4351,7 +4349,7 @@ name "sub:Exposing-Erlang-functionality" \end_layout \begin_layout Standard -This section contains a concrete example of how the localStorage and world +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. @@ -4428,10 +4426,10 @@ 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 +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 + In order to perform an action using the GGS and localstorage objects, the \begin_inset ERT status open @@ -4847,7 +4845,7 @@ TODO: Go in to more detail about how the world, player and localstorage status open \begin_layout Plain Layout -My idea here is that we describe the erlang-js (which failed, but nontheless), +My idea here is that we describe the erlang-js (which failed, but nonetheless), v8, UUID and other external communication. We shouldn't describe sockets here though.. or.. @@ -4863,7 +4861,7 @@ external \begin_inset Quotes erd \end_inset - to thre GDL. + to three GDL. Discuss the GGS world object (there is a reference to this secxtion for that purpose) \end_layout @@ -4911,7 +4909,7 @@ target "http://www.objectmentor.com/resources/articles/srp.pdf" \begin_layout Standard The responsibility and concern of each module comes from the responsibility and concern of the real-world entity the model represents. - The modelling of the GGS after a real world system was discussed in chapter + The modeling of the GGS after a real world system was discussed in chapter \begin_inset CommandInset ref LatexCommand vref @@ -4998,8 +4996,8 @@ Is this the proper way to day the dispatcher greets connecting players? The dispatcher is the module which handles the interfacing to the operating system when working with sockets. - Operating system limits concering the number of open files, or number of - open sockets are handled here. + Operating system limits concerning the number of open files, or number + of open sockets are handled here. The operating system limits can impose problems on the GGS, this is discussed more in detail in chapter \begin_inset CommandInset ref @@ -5080,7 +5078,7 @@ reference "sub:The-protocol-parser" \end_inset . - Raw communication, witout passing the data through a protocol parser is + Raw communication, without passing the data through a protocol parser is in theory possible, but is not useful. \end_layout @@ -5118,7 +5116,7 @@ The coordinator spawns a new player process, with the same socket reference \begin_layout Enumerate The player process resumes operation, immediately starting a new protocol - parser process, and begind receiving and sending network messaged again. + parser process, and begins to receive and send network messages again. \end_layout \begin_layout Standard @@ -5165,7 +5163,7 @@ name "sub:The-protocol-parser" \end_layout \begin_layout Standard -The protocol parser is an easily interchangable module in the GGS, handling +The protocol parser is an easily interchangeable module in the GGS, handling the client-to-server, and server-to-client protocol parsing. In the GGS prototype, there is only one protocol supported, namely the @@ -5174,7 +5172,7 @@ GGS Protocol \emph default . The role of the protocol parser is to translate the meaning of packets - sent using the prototocol in use to internal messages of the GGS system. + sent using the protocol in use to internal messages of the GGS system. The GGS protocol, discussed below is used as a sample protocol in order to explain how protocol parsers can be built for the GGS. \end_layout @@ -5191,7 +5189,7 @@ name "sub:The-structure-of" \end_layout \begin_layout Standard -The GGS protocol is modelled after the HTTP protocol. +The GGS protocol is modeled after the HTTP protocol. The main reason for this is the familiarity many developers already have with HTTP due to its presence in internet software. Each GGS protocol packet contains a headers section. @@ -5240,10 +5238,10 @@ Line 4 specifies the content length of the payload following immediately \begin_layout Standard The parser of the GGS protocol implemented in the GGS prototype is designed - as a finite state machine using the gen_fsm behaviour. + 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 paser using message passing. + from the protocol parser using message passing. \end_layout \begin_layout Standard @@ -5559,11 +5557,11 @@ The game VM contains the state of the VM and a table token associated with \begin_layout Standard The VM itself makes it possible for the game developer to program in the - prograimming language covered by the VM. + programming language covered by the VM. In future releases, more game VM:s will be added to support more programming languages. Because the game VM keeps track of the correct table, the game developer - doesn't need to take this into consideration when programming a game. + 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. @@ -5635,7 +5633,7 @@ key "667766" \begin_layout Standard The features of Mnesia originally intended for telecoms prove very useful for the purposes of the GGS as well. - The fault tolerance and speed of Mnesia are very valueable tools, the fast + 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 @@ -5674,8 +5672,8 @@ Each game is uniquely identified by a table token and the data of each game The World is used contain all game data related to the game state. This sort of game data may change during the runtime of the game. The Localstorage should contain data independent of the game state. - Game resources, constants and globals are all examples of data that could - reside within the Localstorage. + 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. @@ -5686,7 +5684,7 @@ Each game is uniquely identified by a table token and the data of each game \begin_layout Standard The interface of the database module is an implementation of the upcoming W3C Web Storage specification. - Web Storage is intended for use in web browsers, providing a persistant + 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 @@ -5743,7 +5741,7 @@ The player module, which is coupled to the TCP-module to react on incoming \begin_layout Enumerate The protocol parser parses the message and brings it into the format of the internal GGS presentation of such a message, which is just a specialized - Erlang touple + Erlang tuple \end_layout \begin_layout Enumerate @@ -5751,7 +5749,7 @@ The protocol parser sends this Erlang touple back to the player module \end_layout \begin_layout Enumerate -The player module checks if it is a Server-Command or a Game-Commane. +The player module 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 module \end_layout @@ -5806,7 +5804,7 @@ reference "sec:Example-of-a-GGS-server-application-in-JavaScript" \end_inset -) we see that the GGS-functios +) we see that the GGS-functions \emph on GGS.localStorage.setItem(key, value) \emph default @@ -5828,8 +5826,8 @@ In the example the \emph on GGS.sendCommandToAll() \emph default - is beeing called then which is a callback to a function of the table module - which iterates thrugh its player list and sends the command to every player + 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 @@ -5896,8 +5894,8 @@ GGS.sendCommand(player_id, command, args) GGS. \emph default sendCommandToAll(command, args). - The localStorage is a convenient way to store globals and other variables - seperated from the game state. + The localstorage is a convenient way to store global data and other variables + separated from the game state. Unique id:s called gametokens are generated for hosted games so that they are not mixed up. \begin_inset ERT @@ -6454,7 +6452,7 @@ In Erlang, we have a simple version of supervisors. \end_layout \begin_layout Standard -When the linking of processes in order to monitor exit behaviour is coupled +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, @@ -6594,7 +6592,7 @@ To prevent any data loss, the good state of the worker processes is stored \end_layout \begin_layout Subsection -Reduncancy +Redundancy \end_layout \begin_layout Standard @@ -6675,7 +6673,7 @@ name "fig:redundancy" \end_inset To the left normal execution is pictured; the server state is backed up. - To the right; the exceptional excution, where the state is retrieved from + To the right; the exceptional execution, where the state is retrieved from the backup to repopulate the server. \end_layout @@ -6731,7 +6729,7 @@ playerCommand \emph on main() \emph default - function of a C or Java programm + function of a C or Java program \emph on . @@ -6779,7 +6777,7 @@ nick \begin_inset Quotes erd \end_inset - with the actuall new nickname as a argument. + 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 @@ -6820,7 +6818,7 @@ nick \emph on changeNick \emph default -function uses a feature of the GGS called localStorage (see section +function uses a feature of the GGS called localstorage (see section \begin_inset CommandInset ref LatexCommand ref reference "sec:Communication-with-the-GDL-VM" @@ -7178,7 +7176,7 @@ There were two possible solutions to the problem of the JavaScript to Erlang \begin_layout Standard Attempts at creating the communication path from JavaScript to Erlang were - initially made, however the communiucation path never became stable enough + initially made, however the communication path never became stable enough for usage in the GGS and the erlang_js software was abandoned. \end_layout @@ -7274,7 +7272,7 @@ n of TCP instead of UDP, thus losing some speed. \end_layout \begin_layout Standard -Furthermore, in a move to increase the speed of the GGS prototcol the binary +Furthermore, in a move to increase the speed of the GGS protocol the binary BSON protocol \begin_inset CommandInset citation LatexCommand citet @@ -7283,7 +7281,7 @@ key "bson:website" \end_inset was initially considered. - BSON is a protocol which can be used for vert fast traversal of data. + BSON is a protocol which can be used for very fast traversal of data. The BSON protocol is however rather difficult to read in its plain format, and no implementation has been bade for the GGS. \end_layout @@ -7305,7 +7303,7 @@ key "Slee2007" \begin_layout Standard The use of Thrift, BSON, or other protocols can be supported quite easily - by develpping protocol modules for each protocol. + by developing protocol modules for each protocol. No protocol modules for these protocols have however been developed during the writing of this thesis \end_layout @@ -7662,7 +7660,7 @@ Future improvements \begin_layout Standard The specification of the GGS prototype is huge and like many other software projects relying on outside technologies, in time it would require a lot - of maintanance. + of maintenance. Therefore there are a lot of areas in which the GGS could be improved such as performance, compatibility, ease of setup and usage. \end_layout @@ -7678,14 +7676,14 @@ Protocols \begin_layout Standard Because of TCP being a connection oriented protocol, it is not suited for all types of game data transfers. - Each transmission will consume more network bandwith than connectionless - protocols like UDP and cause uneccessary load on the processor. + 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 realtime games as it improves realism + Latency is of highest importance in real-time games as it improves realism and fairness in gameplay and many game developers requires the freedom to take care of safety issues as packet losses themselves. This concludes that UDP would be a benefit for the GGS, game developers @@ -7735,7 +7733,7 @@ GGS relies on modern technologies. Therefore it would be best for the GGS to have as many of these VM:s implemente d as possible. The VM:s taken into consideration so far have been unstable or incomplete - and it is possible to search for more VM:s, testing them and intergrate + and it is possible to search for more VM:s, testing them and integrate them into the GGS prototype. \end_layout @@ -7744,8 +7742,8 @@ Setup \end_layout \begin_layout Standard -The GGS prototype installation procedure requires different configuring - and building steps and thus it isn't in an acceptable release state. +The GGS prototype installation procedure requires different configuration + and building steps and thus it is not in an acceptable release state. An executable installation file for each supported platform would be optimal. \end_layout @@ -7801,7 +7799,7 @@ addcontentsline{toc}{section}{Glossary} \backslash -\printnomenclature + \end_layout \end_inset From 20d00ba619855589adcefde723aaa00832d326f4 Mon Sep 17 00:00:00 2001 From: Jeena Paradies Date: Fri, 6 May 2011 17:54:47 +0200 Subject: [PATCH 10/16] fixed broken reference --- merge.lyx | 7228 +++++++++++++++++++++++++++++++++++++++++++ not-working.lyx | 7817 +++++++++++++++++++++++++++++++++++++++++++++++ report.lyx | 15 +- working.lyx | 7223 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 22279 insertions(+), 4 deletions(-) create mode 100644 merge.lyx create mode 100644 not-working.lyx create mode 100644 working.lyx diff --git a/merge.lyx b/merge.lyx new file mode 100644 index 0000000..938b4e6 --- /dev/null +++ b/merge.lyx @@ -0,0 +1,7228 @@ +#LyX 2.0 created this file. For more info see http://www.lyx.org/ +\lyxformat 413 +\begin_document +\begin_header +\textclass report +\begin_preamble +\usepackage{indentfirst} +\usepackage{tocloft} +\usepackage{calc} +\date{} +\usepackage[section] {placeins} +\def\myClearpage{% + \ifvmode + \ifnum \@dbltopnum =\m@ne + \ifdim \pagetotal <\topskip + \hbox{}% + \fi + \fi + \fi +% \newpage + \write\m@ne{}% + \vbox{}% + \penalty -\@Mi +} +\def\myCleardoublepage{\myClearpage\if@twoside \ifodd\c@page\else + \hbox{}\if@twocolumn\hbox{}\fi\fi\fi} +\usepackage{morefloats} +\usepackage{graphicx} +\usepackage{subfig} +\usepackage{tocloft} +\renewcommand{\cftchapfont}{\bfseries} +\renewcommand{\cftchappagefont}{\bfseries} +\renewcommand{\cftchappresnum}{Chapter } +\renewcommand{\cftchapnumwidth}{6em} + +\oddsidemargin 0.5in +\textwidth 6in +\topmargin 0.0in +\textheight 8.0in +\setlength\topskip{24pt} +\footskip 0.75in + +\usepackage[compact]{titlesec} + + +\titleformat{\chapter}[display] +{\vskip-8em\normalfont\bfseries} +{\LARGE\raggedright\thechapter} +{14ex} +{\vspace{-20ex}% +\LARGE\raggedleft} +[\vspace{1ex}% +{\titlerule[1pt]}] + +\usepackage[absolute]{textpos} + +\usepackage{fancyheadings} +\pagestyle{fancy} +\lhead{\thechapter} + +\usepackage[hmargin=3cm,vmargin=3.5cm]{geometry} +\usepackage{algorithmic} +\usepackage{listings} + +\usepackage{color} +\definecolor{lightgray}{rgb}{.9,.9,.9} +\definecolor{darkgray}{rgb}{.4,.4,.4} +\definecolor{purple}{rgb}{0.65, 0.12, 0.82} + +\lstdefinelanguage{JavaScript}{ + keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break}, + keywordstyle=\color{blue}\bfseries, + ndkeywords={class, export, boolean, throw, implements, import, this}, + ndkeywordstyle=\color{darkgray}\bfseries, + identifierstyle=\color{black}, + sensitive=false, + comment=[l]{//}, + morecomment=[s]{/*}{*/}, + commentstyle=\color{purple}\ttfamily, + stringstyle=\color{red}\ttfamily, + morestring=[b]', + morestring=[b]" +} + +\lstdefinelanguage{Erlang}{ + keywords={typeof, true, false, catch, return, null, catch, switch, var, if, in, while, do, else, case, break, expose}, + keywordstyle=\color{blue}\bfseries, + ndkeywords={class, export, boolean, throw, implements, import, this,erlv8_vm, erlv8_fun_invocation +,erlv8_object}, + ndkeywordstyle=\color{darkgray}\bfseries, + identifierstyle=\color{black}, + sensitive=false, + comment=[l]{\%}, + morecomment=[s]{/*}{*/}, + commentstyle=\color{purple}\ttfamily, + stringstyle=\color{red}\ttfamily, + morestring=[b]', + morestring=[b]" +} + +\usepackage{float} + +\floatstyle{ruled} +\newfloat{code}{thp}{lop} +\floatname{code}{Code} + +\usepackage{nomencl} +\makenomenclature +\renewcommand{\nomname}{Glossary} +\end_preamble +\use_default_options true +\maintain_unincluded_children false +\language english +\language_package default +\inputencoding auto +\fontencoding global +\font_roman lmodern +\font_sans default +\font_typewriter default +\font_default_family rmdefault +\use_non_tex_fonts false +\font_sc false +\font_osf false +\font_sf_scale 100 +\font_tt_scale 100 + +\graphics default +\default_output_format default +\output_sync 0 +\bibtex_command default +\index_command default +\paperfontsize default +\spacing onehalf +\use_hyperref false +\papersize a4paper +\use_geometry false +\use_amsmath 1 +\use_esint 1 +\use_mhchem 1 +\use_mathdots 1 +\cite_engine natbib_authoryear +\use_bibtopic false +\use_indices false +\paperorientation portrait +\suppress_date false +\use_refstyle 0 +\index Index +\shortcut idx +\color #008000 +\end_index +\paperwidth 11in +\paperheight 8.5in +\leftmargin 1.25in +\topmargin 0in +\rightmargin 1in +\bottommargin 1.7in +\secnumdepth 2 +\tocdepth 2 +\paragraph_separation indent +\paragraph_indentation default +\quotes_language english +\papercolumns 1 +\papersides 1 +\paperpagestyle empty +\tracking_changes false +\output_changes false +\html_math_output 0 +\html_css_as_file 0 +\html_be_strict false +\end_header + +\begin_body + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{textblock*}{ +\backslash +paperwidth}(0mm,40mm) +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{center} +\end_layout + +\begin_layout Plain Layout + + +\backslash +includegraphics[width= +\backslash +paperwidth/2]{graphics/logo} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{center} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{textblock*} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Title +A Reliable Generic Game Server +\end_layout + +\begin_layout Author +Niklas Landin +\begin_inset Newline newline +\end_inset + +Richard Pannek +\begin_inset Newline newline +\end_inset + +Mattias Pettersson +\begin_inset Newline newline +\end_inset + +Jonatan Pålsson +\end_layout + +\begin_layout Abstract +This is the abstract! +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +pagenumbering{roman} +\end_layout + +\begin_layout Plain Layout + + +\backslash +setcounter{page}{3} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +contentsname{Table of Contents} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand{ +\backslash +cfttoctitlefont}{ +\backslash +hfill +\backslash +Large} +\backslash +renewcommand{ +\backslash +cftaftertoctitle}{ +\backslash +hfill} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +cftpartdotsep{6.6} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +cftchapdotsep{6.6} +\end_layout + +\end_inset + + +\begin_inset CommandInset toc +LatexCommand tableofcontents + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Newpage newpage +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +pagenumbering{arabic} +\end_layout + +\begin_layout Plain Layout + + +\backslash +setcounter{page}{1} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Chapter +Introduction +\end_layout + +\begin_layout Standard +Online gaming, and computer gaming in general has become an important part + in many peoples day-to day lives. + A few years ago, computer games were not at all as popular as they are + today. + With the advances in computer graphics and computer hardware today's games + are much more sophisticated then they were in the days of +\emph on +NetHack +\emph default +, +\emph on +Zork, +\emph default +or +\emph on +Pacman. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Zork}}{A textual computer game developed by students at MIT} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Pacman}}{An early graphical computer game developed by Namco} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{NetHack}}{An early computer game developed by the NetHack team, arguably + the oldest computer game still in development} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The early computer games featured simple, or no graphics at all +\begin_inset CommandInset citation +LatexCommand citet +key "nethack:website" + +\end_inset + +. + The games often took place in a textual world, leaving the task of picturing + the world up to the player. + Multiplayer games were not as common as they are today, whereas most games + today are expected to have a multiplayer mode, most early games did not. +\end_layout + +\begin_layout Standard +Since these early games, the gaming industry have become much more influential + in many ways. + Many advanced in computer hardware are thought to come from pressure from + the computer game industry. + More powerful games require more powerful, and more easily available hardware +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Drop a reference to the gaming industry pressuring more advanced hardware +\end_layout + +\end_inset + +. + Due to the high entertainment value of modern computer games, gaming has + become a huge industry, where large amounts of money are invested. + The gaming industry is today, in some places even larger than the motion + picture industry. + +\begin_inset CommandInset citation +LatexCommand citet +key "esa:website,thenumbers:website" + +\end_inset + + +\end_layout + +\begin_layout Standard +Due to the increasing importance of computer gaming, more focus should be + spent on improving the quality of the gaming service. + As more and more computer games are gaining multiplayer capabilities, the + demands for multiplayer networking software rises. + This thesis is about techniques for improving the quality of this networking + software. +\end_layout + +\begin_layout Standard +The reliable generic game server, hereafter known as GGS +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{GGS}}{Generic Game Server, a software for reliably hosting network + games. + The subject of this thesis.} +\end_layout + +\end_inset + +, is a computer program designed to +\emph on +host +\emph default + network games on one or more server computers. + Hosting, in a network software setting, means allowing client software + connect to the server software, for the purpose of utilizing services provided + by the server. + The GGS software provides games as a service, and the clients connecting + to the GGS can play these games on the GGS. +\end_layout + +\begin_layout Standard +The idea of game servers is not new, network games have been played for + decades. + Early, popular examples of network games include the +\emph on +Quake +\emph default + series, or the +\emph on +Doom +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout + +\emph on +Come up w/ better game +\end_layout + +\end_inset + + +\emph default + games. + Newer examples of network games include +\emph on +World of Warcraft +\emph default +, and +\emph on +Counter-Strike +\emph default +. + The difference between the GGS and the servers for these games is that + the servers for Doom, Quake, and the others listed, were designed with + these specific games in mind. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Quake}}{A first person shooter series developed by ID software. + The series consists of four games.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Doom}}{A first person shooter series developed by ID software. + The series consists of three games.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Counter-Strike}}{A multiplayer first person shooter game, popular + in E-Sports.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Counter-Strike}}{A multiplayer first person shooter game, popular + in E-Sports.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Framework}}{A supporting structure, the GGS is a framework for developing + network games} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{First-person shooter}}{A game in which centers around gun combat + from the first person perspective.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{MMORPG}}{Massively multiplayer online role playing game. + An online game with several thousand participants.} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +What GGS does is to provide a +\emph on +generic +\emph default + framework for developing network games. + The framework is generic in the sense that it is not bound to a specific + game. + There are many different types of games, some are inherently more time + sensitive than others, strategy games are examples of games which are not + very sensitive to time delays, first-person shooters however, can be very + sensitive. +\end_layout + +\begin_layout Standard +The generic nature of the GGS allows the creation of many different types + of games, the motivation behind this is to remove the necessity of writing + new game servers when developing new games. +\end_layout + +\begin_layout Standard +The GGS is in addition to being generic, also +\emph on +reliable +\emph default + in the sense that the gaming service provided is consistent and available. + A consistent and available server is a server that handles hardware failures + and software failures gracefully. + In the event of a component breaking within the GGS, the error is handled + by fault recovery processes, thereby creating a more reliable system. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Hardware failiure}}{A failiure in hardware (hard drive, memory, processor +, etc) which causes a system to stop functioning} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Software failiure}}{A failiure in software (the GGS, the operating + system, etc) which causes a system to stop functioning} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Background +\end_layout + +\begin_layout Standard +The game industry is a quickly growing industry where the need for new technique +s are large. + One specific section where the development has stalled is the game server + section. +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + + The existing game servers are functional but they lack good fault tolerance + and the ability to scale well +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + +. + Users will notice this in low uptime and many crashes. + This is a problem that has existed and been resolved in other industries. + In the telecom industry solutions to similar problems have been found. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{The nine nines}}{A common goal for availability in the telecom business. + A system with nine nines of availability is available 99.999999999% of the + time} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Downtime}}{The amount of time a system is unavailable and does not + function} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Uptime}}{The amount of time a system is available and functions} +\end_layout + +\end_inset + +A common figure often used in telecoms is that of +\emph on +the nine nines +\emph default +, referring to +\begin_inset Formula $99.999999999\%$ +\end_inset + + of availability, or roughly +\begin_inset Formula $15ms$ +\end_inset + + downtime in a year +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + +. + The level of instability and bad fault tolerance seen in the game server + industry would not have been accepted in the telecoms industry. + This level of instability should not be accepted in the game server industry + either. + An unavailable phone system could potentially have life threatening consequence +s, leaving the public unable to contact emergency services. + The same can not be said about an unavailable game server. + The statement that game servers are less important than phone systems is + not a reason not to draw wisdom from what the telecoms have already learned. +\end_layout + +\begin_layout Standard +Moving back to the gaming industry. + The main reason to develop reliable servers are monetary, it is important + for game companies to expand its customer base. + Reliable game servers are one improvement that will create a good image + of a company. + In general the downtime of game servers is much higher than the downtime + of telecom system +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed... +\end_layout + +\end_inset + +. + The structure of the system is similar in many ways and it should be possible + to reuse solutions from the telecom system to improve game servers. + +\end_layout + +\begin_layout Standard +In the current state game servers are developed on a per-game basis, in + many cases this seems like a bad solution. + Developers of network game need to understand network programming. + A way to change this is a generic game server which give the game developers + a server which they implement their game towards. + This approach would not only make it easier to develop network games, it + would also allow games in different programming languages to be implemented + using the same server. +\end_layout + +\begin_layout Standard +Some factors key to the development of GGS have been isolated. + Many of these come from the telecom sector. + The factors are +\emph on +scalability, fault tolerance +\emph default +and being +\emph on +generic +\emph default +. + These terms are defined below. +\end_layout + +\begin_layout Standard +Scalability (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Scalability" + +\end_inset + +) in computer science is a large topic and is commonly divided into sub-fields, + two of which are +\emph on +structural scalability +\emph default + and +\emph on +load scalability +\emph default + +\begin_inset CommandInset citation +LatexCommand citet +key "Bondi:2000:CSI:350391.350432" + +\end_inset + +. + These two issues are addressed in this thesis. + Structural scalability means expanding an architecture, e.g. + adding nodes to a system without requiring modification of the system. + Load scalability means using the available resources in a way which allows + handling increasing load, e.g more users, gracefully. +\end_layout + +\begin_layout Standard +Fault tolerance (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Fault-Tolerance" + +\end_inset + +) is used to raise the level of +\emph on +dependability +\emph default + in a system, so that the dependability is high even in presence of errors. + Dependability is defined as the statistical probability of the system functioni +ng as intended at a given point in time. + Fault tolerance is defined as the property of a system to always follow + a specification, even in the presence of errors. + The specification could take the form of error handling procedures which + activate when an error occurs. + This means that a fault tolerant, dependable system, will have a very high + probability of functioning at a given point in time, and is exactly what + is desired. + +\begin_inset CommandInset citation +LatexCommand citet +key "Gartner:1999:FFD:311531.311532" + +\end_inset + + +\end_layout + +\begin_layout Standard +A generic (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Generic" + +\end_inset + +) game server has to be able to run different client-server network games + regardless of the platform the clients are running on. + It runs network games of different type. + A very rough separation of games is real time games and turn based games. +\end_layout + +\begin_layout Standard +The server behaves in a way similar to an application server, but is designed + to help running games. + An application server provides processing ability and time, therefore it + is different from a file- or print-server, which only serves resources + to the clients. +\end_layout + +\begin_layout Standard +The most common type of application servers are web servers, where you run + a web application within the server. + The application server provides an environment and interfaces to the outer + world, in which applications run. + Hooks and helpers are provided to use the resources of the server. + Some examples for web application servers are the +\emph on +Glassfish +\emph default + server which allows running applications written in Java or the +\emph on +Google App Engine +\emph default + where you can run applications written in Python or some language which + runs in the +\emph on +Java Virtual Machine +\emph default +. + An example of an application server not powering web applications, but + instead regular business logic, is Oracle’s +\emph on +TUXEDO +\emph default + application server, which can be used to run applications written in COBOL, + C++ and other languages. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SQL}}{Structured Query Language, a computer language common in querying + certain databases} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{JavaScript}}{A programming language originally developed by Netscape, + common in web programming} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{COBOL}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{C++}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Java}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{AXD301}}{Telephone switch developed by Ericsson} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Erlang}}{A concurrent programming language, often used for telecom + applications. + The main language of the GGS} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +A database server can also be seen as an application server. + Scripts, for example SQL queries or JavaScript, are sent to the server, + which runs them and returns the evaluated data to the clients. + +\end_layout + +\begin_layout Standard +One purpose of this thesis is to investigate how we can make a game server + as generic as possible. + Some important helpers are discussed, such as abstraction of the network + layer, data store and game specific features. + +\end_layout + +\begin_layout Standard +As an aid in discussing the theoretical parts of the GGS a prototype has + been developed. + The prototype does not feature all of the characteristics described in + this thesis. + A selection has been made among the features, and the most important ones + have been implemented either full or in part in the prototype. +\end_layout + +\begin_layout Standard +The choice of implementation language for the prototype of the GGS was made + with inspiration from the telecom industry. + The Erlang language was developed by the telecom company Ericsson to develop + highly available and dependable telecom switches. + One of the most reliable systems ever developed by Ericsson, the AXD301 + was developed using Erlang. + The AXD301 is also possibly has the largest code base even written in a + functional language +\begin_inset CommandInset citation +LatexCommand citep +key "Armstrong03" + +\end_inset + +. + The same language is used to develop the prototype of the GGS. + Usage of Erlang in the GGS is discussed in further detail in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:The-usage-of-erlang" + +\end_inset + +. + Chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Implementation-of-a" + +\end_inset + + provides a description of the prototype developed for this thesis. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +We could go on and on about erlang.. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Purpose +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout +The purpose of the GGS project. + What is the purpose of creating a fault tolerant server, why is it generic, + and what good does it do to have a scalable system? In the background, + we should give the motivations behind creating this software, but here + we should outline why the software is needed. + This section should be shortened, and the bulk of the text should be moved + to theory or background. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The purpose of creating a generic and fault tolerant game server is to provide + a good framework for the development of many different types of games. + Allowing the system to scale up and down is a powerful way to maximize + the usage of physical resources. + By scaling up to new machines when load increases, and scaling down from + machines when load decreases costs and energy consumption can be optimized. +\end_layout + +\begin_layout Standard +Fault tolerance is important for the GGS to create a reliable service. + The purpose of a reliable game server is to provide a consistent service + to people using the server. + Going back to the telecom example, the purpose of creating a reliable telecom + system is to allow calls, possibly emergency calls, at any time. + Should the telecom network be unavailable at any time, emergency services + may become unavailable, furthermore the consumer image of the telecom system + degrades. +\end_layout + +\begin_layout Standard +Returning to the game industry, emergency services will not be contacted + using a game server, however an unavailable server will degrade the consumer + image of the system. + Consider an online casino company. + The online casino company's servers must be available at all times to allow + customers to play. + If the servers are unavailable, customers can not play, and the company + loses money. + In this scenario, an unavailable server can be compared to a closed real-world + casino. +\end_layout + +\begin_layout Section +Challenges in developing the prototype +\end_layout + +\begin_layout Standard +The word +\emph on +generic +\emph default + in the name of the GGS implies that the system is able to run a very broad + range of different code, for instance code wrote in different programming + languages, besides a broad range of different game types. + To support this, a virtual machine (VM) for each +\emph on +game development language +\emph default + (hereafter GDL for brevity) is used. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{GDL}}{Game Development Language, the language used to program games + in the GGS} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{VM}}{Virtual Machine} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +No hard limit has been set on which languages can be used for game development + on the GGS, but there are several factors which decide the feasibility + of a language: +\end_layout + +\begin_layout Itemize +How well it integrates with Erlang, which is used in the core the GGS system + +\end_layout + +\begin_layout Itemize +How easy it is to send messages to the virtual machine of the GDL from the + GGS +\end_layout + +\begin_layout Itemize +How easy it is to send messages from the GDL VM to the GGS +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add more like threads, events, etc. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Internally, the GDL VM needs to interface with the GGS to make use of the + helpers and tools that the GGS provides. + Thus an internal API has to be designed for use in interacting with the + GGS. + This API is ideally completely independent of the GDL, and reusable for + any GDL. +\end_layout + +\begin_layout Standard +The communication with gaming clients has to take place over a protocol. + Ideally a standard protocol should be used, in order to shorten the learning + curve for developers, and also make the system as a whole less obscure. + A large challenge during this project is to decide whether an existing + protocol can be used, and if not, how a new protocol can be designed which + performs technically as desired, while still being familiar enough to existing + developers. +\end_layout + +\begin_layout Standard +A great deal of work is devoted to make the GGS +\emph on +reliable +\emph default +. + This includes ensuring that the system scales well, and to make sure it + is fault tolerant. + In order to facilitate scalability, we need a storage platform which is + accessible and consistent among all of the GGS, this is also investigated. +\end_layout + +\begin_layout Section +Limitations of the prototype +\end_layout + +\begin_layout Standard +The implementation of the GGS protocol, together with storage possibilities, + server capacity, and game language support imposes some limitations on + the project. + To get a functional prototype some limits must be set on the types games + that can be played on the prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{UDP}}{User Datagram Protocol, a connectionless networking protocol} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{TCP}}{Transmission Control Protocol, a streaming network protocol} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The UDP protocol is not supported for communication between client and server. + The TCP protocol was chosen in favor of UDP, due to the fact that the implement +ation process using TCP was faster than if UDP would have been used. + UDP is generally considered to be faster than TCP for the transfer of game + (and other) related data, this is discussed in more depth in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Choice-of-network" + +\end_inset + +. + In short, the decision of using TCP means that games that requires a high + speed protocol will not be supported by the GGS prototype. + Another limitation necessary to set on the system is the possibility to + have huge game worlds due to the implementation of the scaling mechanism + in the prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Latency}}{A measure of delay, often measured in milliseconds} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +In real time games all players are playing together at the same time. + Latency is a huge problem in real time games, a typical round trip time + for such games are one of +\begin_inset Formula $50$ +\end_inset + + to +\begin_inset Formula $150ms$ +\end_inset + + and everything above +\begin_inset Formula $200ms$ +\end_inset + + is reported to be intolerable +\begin_inset CommandInset citation +LatexCommand citet +key "Farber:2002:NGT:566500.566508" + +\end_inset + +. + Latency sensitive games include most of the first person shooters with + multiplayer ability, for example +\emph on +Counter Strike +\emph default + or massively multiplayer online role playing games (MMORPGs), for example + +\emph on +World of Warcraft +\emph default +. +\end_layout + +\begin_layout Standard +In turn based games each player has to wait for their turn. + Latency is not a problem since the gameplay does not require fast interactions + among the players, long round trip times will not be noticed. + Examples of turn based games include board and card games, as well as multiplay +er games like +\emph on +Jeopardy +\emph default +. + Both game types have varying difficulties and needs when it comes to implementi +ng them, a Generic Game Server should address all of them and help the developer + to accomplish his goal. +\end_layout + +\begin_layout Standard +Due to the limited capability of threading in many GDL VM:s, the GGS prototype + will not support MMORPG:s. +\end_layout + +\begin_layout Standard +The implementation of the GGS described in this thesis is only a small prototype + and tests will be performed on simple games like pong or chess, thus there + are no need to implement more advanced features in the system. + Note that these limitations only apply for the prototype of the project, + and that further developments to the GGS could be to implement these features. +\end_layout + +\begin_layout Section +Method +\end_layout + +\begin_layout Standard +A prototype was developed early on in the project to carry out experiments. + Using this prototype, the system was divided into modules. + A demand specification was created, using this specification, the modules + were easily identifiable. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Module}}{A part of a larger system} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The first prototype of the GGS consisted of simple modules, however, due + to the separation of concerns among the modules, they were easily independently + modified and improved. + Once the basic structure of the GGS had been established, the first prototype + was removed, remaining was the structure of the modules and the internal + flow of the application. + This could be seen as an iterative workflow, with the first prototype being + the first iteration. + The second iteration later became the final result of the GGS. +\end_layout + +\begin_layout Standard +The layout of the GGS is both layered and modular. + The first layer handles the most primitive data and produces a higher level + representation of the data, passing it along to different modules of the + GGS. + The modular structure of the GGS plays an important role in making the + system fault tolerant. + The approach to fault tolerance is by replication, and restarting the faulting + modules with the last known good data. +\end_layout + +\begin_layout Standard +An informal specification and list of requirements of the system was outlined + early on in the project. + Usability goals for developers were set. + During the project several demo applications were constructed, by constructing + these applications, the usability goals were enforced. +\end_layout + +\begin_layout Chapter +Theory behind the GGS +\begin_inset CommandInset label +LatexCommand label +name "cha:Theory" + +\end_inset + + +\end_layout + +\begin_layout Standard +In this chapter, the theory behind the techniques used in the GGS are discussed. + Performance issues and the measuring of performance is discussed. + Benchmarking techniques are discussed. + The options when choosing network protocols are given, along with a discussion + of each alternative. + Finally, an overview of scalability, fault tolerance and availability are + presented. +\end_layout + +\begin_layout Section +Design of the GGS system +\begin_inset CommandInset label +LatexCommand label +name "sec:Design-of-the" + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS is modeled after a real world system performing much of the same + duties as GGS. + This is common practice +\begin_inset CommandInset citation +LatexCommand citep +key "armstrong2011" + +\end_inset + + in the computer software world, to understand complex problems more easily. + While there may not always be a real world example of a system performing + the exact duties of the system being modeled in the computer, it is often + easier to create and analyze requirements for real world systems and processes + than systems existing solely in a computer. + The requirements and limitations imposed on the real-world system can, + using the proper tools, be transferred in to the software. +\end_layout + +\begin_layout Standard +The real world system chosen for the GGS is a +\begin_inset Quotes eld +\end_inset + +Chess club +\begin_inset Quotes erd +\end_inset + + - a building where chess players can meet and play chess. + Since a real-world scenario is readily available, and to such a large extent + resembles the computer software required for the GGS, the next step in + developing the GGS system is to duplicate this real world scenario in a + software setting. +\end_layout + +\begin_layout Standard +Some requirements, limitations and additions were made to the chess club + system, so that the system would more easily and efficiently be replicated + in a software setting. +\end_layout + +\begin_layout Standard +In the text below, two examples will be presented. + On example is that of a real-world chess club, in which players meet to + play chess against each other, the other example is the GGS, and how it + corresponds to this chess club. + +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/theory_layout.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:theory-layout" + +\end_inset + +The layout of a physical +\begin_inset Quotes eld +\end_inset + +Chess club +\begin_inset Quotes erd +\end_inset + + with two players (P) sitting by each chess table (Table), a coordinator + keeps track of all moves and players in the building. + A player has to pass by the entrance to enter or exit the building. + The building is represented by the outermost box. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +In figure +\begin_inset CommandInset ref +LatexCommand vref +reference "fig:theory-layout" + +\end_inset + + a graphical representation for the chess club is presented. + The club is seen from above. + The outermost box represents the building. + In the GGS setting, the building would represent one instance of GGS. + Several buildings linked together would represent a cluster of GGS instances. + In order for a player (the P symbol in the graphic) to enter the theoretical + chess club, the player must pass by the entrance. + By having each player pass by the entrance, a tally +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Does this mean what I think it does? +\begin_inset Quotes eld +\end_inset + +Räkning +\begin_inset Quotes erd +\end_inset + + ? +\end_layout + +\end_inset + + can be kept, ensuring that there are not too many players within the building. + In the GGS setting, too many players entering would mean too many connections + have been accepted by the GGS system, and that the structure of the system + thus must be modified, adding additional servers. +\end_layout + +\begin_layout Standard +Once a player has been allowed in to the chess club the player is greeted + by the host of the chess club, in the GGS setting represented by the +\emph on +Coordinator +\emph default +, and is seated by a table. + The coordinator keeps track of all the players in the building, and all + moved made by the players. + The information available to the coordinator means that cheating can be + monitored and book keeping can be performed by this entity. +\end_layout + +\begin_layout Standard +Moves by players are made using the tables present in the chess club. + Every game is isolated to a table, just as expected. + This means that communication during a game only has to pass by the players + of that particular game, and the coordinator, making sure that no cheating + takes place. +\end_layout + +\begin_layout Standard +This isolation of the games play an important part in many properties of + the GGS, the isolation means that games can for example be transferred + among different chess clubs, furthermore, if cheating takes place, corruption + can only occur in the particular table where it was found, and can not + spread. +\end_layout + +\begin_layout Standard +Moving chess players from one location to another is one alteration made + to the real world chess club system to make the system more appropriate + for a software setting. + Allowing games to be transferred is not a property usually desired in a + real world chess club, where transferring players would mean moving the + players from one building to another. + In the software setting, moving players means moving the game processes + from one system to another, perhaps to balance the system load. + This transfer of players can occur transparently, without notifying the + players. +\end_layout + +\begin_layout Standard +The simplified life cycle of a game in GGS can be viewed using algorithm + +\begin_inset CommandInset ref +LatexCommand vref +reference "alg:game-lifecycle" + +\end_inset + +. + To make this life cycle as efficient and useful as possible, the scalability, + fault tolerant and generic traits are added to the GGS. + These are not shown in the algorithm, as these traits are tools in making + the algorithm behaves as efficient as possible, and are not the main focus + when studying the life cycle of a game. +\end_layout + +\begin_layout Standard +The limits imposed in +\begin_inset CommandInset ref +LatexCommand vref +reference "alg:game-lifecycle" + +\end_inset + + are arbitrary for this example, there are no limits in the GGS on the number + of players connecting, for example. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{algorithmic}[1] +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +newcommand{ +\backslash +INDSTATE}[1][1]{ +\backslash +STATE +\backslash +hspace{#1 +\backslash +algorithmicindent}} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +while +\series default + +\begin_inset Formula $players<2$ +\end_inset + +: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + +\series bold +if +\series default + a player connects, call +\emph on +connected +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +while +\series default +the game commences: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +call the function +\emph on +game +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +when +\series default + the game has stopped +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +call the function +\emph on +endGame +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +function +\series default +connected: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +assign the new player an id +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +alert the coordinator of the new player +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + +\series bold +if +\series default + a free table does not exist: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE[2] +\end_layout + +\end_inset + +the coordinator creates a new table +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +the coordinator places the player by the table, and begins watching the + player +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +function +\series default + game +\series bold +: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + perform game-specific functions. + In chess, the rules of chess are placed here +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +function +\series default +endGame: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +alert the coordinator, unregistering the players +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +disconnect the players from the system, freeing system resources +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{algorithmic} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:game-lifecycle" + +\end_inset + +A very simple example of the flow through the GGS system when a game played. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Performance +\end_layout + +\begin_layout Standard +There are many ways in which performance could be measured. + For the clients, time and response times are useful measurements in time + critical settings. + In non-time critical settings, the reliability of message delivery may + be an even more important factor than speed. +\end_layout + +\begin_layout Standard +In a first person shooter game, the speed of delivery of messages is essential. + Failure to deliver messages in time results in choppy gameplay for the + players. + In strategy games, the reliability of delivery may be more important than + the speed, since the game is not perceived as choppy even if the messages + are delayed. +\end_layout + +\begin_layout Standard +For someone operating a GGS, it is perhaps more interesting to measure the + system load, memory consumption, energy consumption and network saturation. + These topics are discussed in theory in this section. + The practical results for the prototype is discussed in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Implementation-of-a" + +\end_inset + +. +\end_layout + +\begin_layout Subsection +Performance measurements +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Tue apr 26, 9:15. + Continue from here on. + Discuss which results we may expect in a fully fledged GGS system. + What impedes the speeds, what raises the CPU load (and therefore the temperatur +es & power consumption). + What factors are there in the network saturation problem? +\end_layout + +\begin_layout Plain Layout +Which games are affected by what, and what does this mean for the number + of players a GGS can handle? +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +How many players can we have on a server? Performance differences between + games? e.g can one game have thousands players on a server and another only + have hundreds? Questions +\end_layout + +\begin_layout Standard +In the current state game servers is coded for each game that needs it, + in many cases this seems like a bad solution. + Developers that want to make a network game need to understand network + programming. + A way to change this is a generic game server which give the game developers + a server which they implement their game towards. + This approach would not only make it easier to develop network games, it + would also allow games in different programming languages to be implemented + using the same server. + to be discussed here. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Create a game with several thousand players, see how our server scales, + how can we improve the performance? Sharding isn’t very nice.. + alternatives? Improve the speed of sharding? +\end_layout + +\begin_layout Itemize +See how the server scales +\end_layout + +\begin_deeper +\begin_layout Itemize +When adding many clients +\end_layout + +\begin_deeper +\begin_layout Itemize +Measure in +\begin_inset Formula $ms$ +\end_inset + + (ping to clients) +\end_layout + +\begin_layout Itemize +measure in system load +\end_layout + +\begin_layout Itemize +Measure in loss of messages +\end_layout + +\begin_layout Itemize +Measure in # of timeouts? (if any??) +\end_layout + +\begin_layout Itemize +Measure in time-to-crash +\end_layout + +\end_deeper +\begin_layout Itemize +When adding new machines to the pool +\end_layout + +\begin_deeper +\begin_layout Itemize +% increase of performance per machine +\end_layout + +\end_deeper +\begin_layout Itemize +Single-core CPU vs multi-core CPU +\end_layout + +\begin_deeper +\begin_layout Itemize +It's very important to scale well on multi-core systems, since this is where + the industry is going. + Multicore is the future. +\end_layout + +\end_deeper +\end_deeper +\begin_layout Plain Layout +Find reference on how to benchmark distributed, multiprocess systems +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Choice of network protocol +\begin_inset CommandInset label +LatexCommand label +name "sec:Choice-of-network" + +\end_inset + + +\end_layout + +\begin_layout Standard +There are two main ways in which computer communication over the Internet + usually takes place; TCP, UDP are known network layer protocols and HTTP + is the most prominent application layer protocol. + The transport layer protocols, are commonly used to transport application + layer protocols, such as HTTP. + TCP and UDP can not be used on their own, without an application layer + protocol on top. + Application layer protocols such as HTTP on the other hand needs a transport + layer protocol in order to work. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{HTTP}}{Hyper Text Transport Protocol, a network protocol commonly + used to deliver web pages} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +HTTP +\end_layout + +\begin_layout Standard +Since HTTP is so widely used on the Internet today in web servers, it is + available on most Internet connected devices. + This means that if HTTP is used in the GGS, firewalls will not pose problems, + which is a great benefit. + However, due to the intended usage of HTTP in web servers, the protocol + was designed to be stateless and client-initiated. + In order to maintain a state during a game session using HTTP, some sort + of token would have to be passed between client and server at all times, + much like how a web server works. + These facts combined makes HTTP unsuitable for our purposes, since the + GGS requires a state to be maintained throughout a session, and also needs + to push data from the server to clients without the clients requesting + data. + It should also be mentioned that HTTP uses the TCP protocol for transport, + and what is said about TCP also applies to HTTP. + +\end_layout + +\begin_layout Subsection +UDP +\end_layout + +\begin_layout Standard +Many online games use UDP as the carrier for their application layer protocol. + UDP moves data across a network very quickly, however it does not ensure + that the data transferred arrives in consistent manner. + Data sent via UDP may be repeated, lost or out of order. + To ensure the data transferred is in good shape, some sort of error checking + mechanisms must be implemented. + UDP is a good choice for applications where it is more important that data + arrives in a timely manner than that all data arrives undamaged, it is + thus very suitable for media streaming, for example. + In the GGS reliability of transfer was chosen before the speed of the transfer, + ruling out UDP as the transport later protocol. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Perhaps we should only say that we chose TCP just for our GGS prototype + and why. + If we leave it like that it seems that we think it is not suitable. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +TCP +\end_layout + +\begin_layout Standard +For reliable transfers, TCP is often used on the Internet. + Built in to the protocol are the error checking and correction mechanisms + missing in UDP. + This ensures the consistency of data, but also makes the transfer slower + than if UDP had been used. + In the GGS, data consistency is more important than transfer speeds, and + thus TCP is a better alternative than UDP. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Same here it is simply not true for a generic server to chose one or the + other. + We should rephrase it so it is clear that we only state it about the GGS + prototype. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Generic +\begin_inset CommandInset label +LatexCommand label +name "sec:Generic" + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS is a game server. + It was made with a desire to be suitable for any kind of game. + Any game with a client-server behavior should be perfectly suited for GGS. + A game should not only be able to vary in terms of genre, graphics, gameplay + etc, but also in the way the game is implemented. + Such as different programming languages. + The GGS should be OS independent and run on Windows, OSX and Linux. + The GGS can be run as a listen server on the players computer and host + games locally. + It could also be a dedicated server running on independent hardware. + It is meant to run any game in any environment in any way desired, therefor + being as generic as possible. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Bad name of the chapter, but here we should give the theory of how the server + is generic +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Fault Tolerance +\begin_inset CommandInset label +LatexCommand label +name "sec:Fault-Tolerance" + +\end_inset + + +\end_layout + +\begin_layout Standard +Fault tolerance is an important factor in all servers, a server that is + fault tolerant should be able to follow a given specification when parts + of the system failures. + This means that fault tolerance is different in each system depending on + what specification they have. + A system could be fault tolerant in different aspects, one is where the + system is guaranteed to be available but not safe and it could also be + reversed, that the system is safe but not guaranteed to be available. + Depending on the system one property may be more important(some example + here). + A system could also have non existent fault tolerance or it could be both + safe and guaranteed to be available. + It should be noted that it is not possible to achieve complete fault tolerance, + a system will always have a certain risk of failure. + With this in mind the goal is to make the GGS prototype as fault tolerant + as possible. +\end_layout + +\begin_layout Standard +In order to make the GGS prototype fault tolerant the programming language + Erlang has been used. + Erlang will not guarantee a fault tolerant system but it has features that + support and encourage the development of fault tolerant systems. + In the GGS it is important that the system overall is fault tolerant. + Crashes of the whole system should be avoided as this would make the system + unusable for a time. + By using supervisor structures it is possible to crash and restart small + parts of the system, this is convenient as fault can be handled within + small modules thus never forcing a crash of the system. +\end_layout + +\begin_layout Standard +The need for fault tolerance in game servers is not as obvious as it may + be for other type of servers. + In general all servers strive to be fault tolerant as fault tolerance means + more uptime and a safer system. + This applies to game servers as well, in brief good fault tolerance is + a way of satisfying customers. + In general, game servers differ from many other fault tolerant systems + in that high-availability is more important than the safety of the system. + For example a simple calculation error will not be critical for a game + server but it may be in a life-critical system and then it is better that + the system crashes than works with the faulty data. + There are cases where safety may be critical in game servers, one example + is in games where in-game money exist. +\end_layout + +\begin_layout Subsubsection +Performance penalties +\end_layout + +\begin_layout Section +Availability +\begin_inset CommandInset label +LatexCommand label +name "sec:Availability" + +\end_inset + + +\end_layout + +\begin_layout Standard +One important factor of any server is the availability. + A server to which you are unable to connect to is an useless server. + Other then within telecommunication, their uptime is of about 99,9999999%, + the game developer community has not approached this problem very genuinely + yet so there is much room for improvement. +\end_layout + +\begin_layout Standard +There are several good papers on how to migrate whole virtual machines among + nodes to replicate them +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add more information about that +\end_layout + +\end_inset + + but for the GGS a different approach has been chosen. + Instead of just duplicating a virtual machine, the programming language + Erlang has been used which offers several features to increase the availability. + Some of them are +\emph on +hot code replacement +\emph default +, where code can be updated while the application is running and without + the need to restart it, the +\emph on +supervisor structure +\emph default + provided by +\emph on +OTP +\emph default + and the inter node and process communication via +\emph on +messages +\emph default + instead of shared memory. + We will discuss each of them later on. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Supervisor}}{A process monitoring and hadning crashes in other processes} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Scalability +\begin_inset CommandInset label +LatexCommand label +name "sec:Scalability" + +\end_inset + + +\end_layout + +\begin_layout Standard +Each instance of the GGS contains several tables. + Each table is an isolated instance of a game, for example a chess game + or a poker game. + The way that the GGS scales is to distribute these tables on different + servers. + In many games it is not necessary for a player to move among tables during + games. + This is for example not a common occurrence in chess, where it would be + represented as a player standing up from her current table and sitting + down at a new table, all within the same game session. + Therefore, the main focus of the GGS is not to move players among tables, + but to keep a player in a table, and to start new tables instead. + When a server has reached a certain number of players the performance will + start to decrease. + To avoid this the GGS will start new tables on another server, using this + technique the players will be close to evenly distributed among the servers. + It is important to investigate and find out how many players that are optimal + for each server. + This approach makes it possible to use all resources with moderate load, + instead of having some resources with heavy load and some with almost no + load. +\end_layout + +\begin_layout Standard +As mentioned in the purpose section there are two different types of scalability +, structural scalability and load scalability. + To make the GGS scalable both types of scalability are needed. + Structural scalability means in our case that it should be possible to + add more servers to an existing cluster of servers. + By adding more servers the limits of how many users a system can have is + increased. + Load scalability in contrast to structural scalability is not about how + to increase the actual limits of the system. + Instead it means how good the system handles increased load. + The GGS should be able to scale well in both categories. +\end_layout + +\begin_layout Subsection +Load balancing +\end_layout + +\begin_layout Standard +The need for load balancing varies among different kind of systems. + Small systems that only use one or a couple of servers can cope with a + simple implementation of it, while in large systems it is critical to have + extensive and well working load balancing. + The need also depends on what kind of server structure that the system + works on. + A static structure where the number of servers are predefined or a dynamic + structure where the number varies. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Amazon EC2}}{A cloud computation service} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Load balancing and scaling is difficult in different scenarios. + When running in a separate server park, there are a set number of servers + available, this means that an even distribution on all servers is preferable. + When running the GGS in a cloud, such as Amazon EC2, it is possible to + add an almost infinite number of servers as execution goes on. + In this cloud setting, it may be more important to evenly distribute load + on newly added servers. +\end_layout + +\begin_layout Standard +Two methods of balancing load (increasing structure): +\end_layout + +\begin_layout Itemize +Fill up the capacity of one server completely, and then move over to the + next server +\end_layout + +\begin_layout Itemize +Evenly distribute all clients to all servers from the beginning, when load + becomes too high on all of them, then comes a new problem: +\end_layout + +\begin_deeper +\begin_layout Itemize +How do we distribute load on these new servers? +\end_layout + +\end_deeper +\begin_layout Standard +Load balancing is a key component to achieve scalability in network systems. + The GGS is a good example of a system that needs to be scalable, to attain + this load balancing is necessary. + Optimization of the load balancing for a system is an important task to + provide a stable and fast load balancer. + There are certain persistence problems that can occur with load balancing, + if a player moves from a server to another data loss may occur. + This is an important aspect to consider when the load balancer is designed + and implemented. +\end_layout + +\begin_layout Standard +Load balancing can often be implemented using dedicated software, this means + that in many applications load balancing may not be implemented because + it already exist functional solutions. + This depends on what specific needs the system have and a minor goal of + the project is to analyze whether the GGS project can use existing load + balancing tools or if it is necessary to implement load balancing in the + project. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Because P2P game architectures are a constant goal for cheaters and because + “Cheating is a major concern in network games as it degrades the experience + of the majority of players who are honest” and preventing cheating in P2P + game architectures is very difficult game developers try to use Client + - Server architectures which have a natural problem to scale. + In this paper we want to show some strategies to achieve scalability. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +UUID +\begin_inset CommandInset label +LatexCommand label +name "sub:UUID" + +\end_inset + + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{UUID}}{Universally Unique Identifier} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{algorithmic}[1] +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +newcommand{ +\backslash +INDSTATE}[1][1]{ +\backslash +STATE +\backslash +hspace{#1 +\backslash +algorithmicindent}} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + +global variable +\begin_inset Formula $state:=0$ +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +function +\series default +unique +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + +\begin_inset Formula $state:=state+1$ +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + +\series bold +return +\begin_inset Formula $state$ +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{algorithmic} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-simple-generator" + +\end_inset + +A simple (insufficient) generator for identifiers +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Inside the GGS, everything has a unique identifier. + There are identifiers for players, tables and other resources. + When players communicate amongst each other, or communicate with tables, + they need to be able to uniquely identify all of these resources. + Within one machine, this is mostly not a problem. + A simple system with a counter can be imagined, where each request for + a new ID increments the previous identifier and returns the new identifier + based off the old one, see algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + +. + This solution poses problems when dealing with concurrent and distributed + systems. + In concurrent systems, the simple solution in algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + + may yield non-unique identifiers due to the lack of mutual exclusion. +\end_layout + +\begin_layout Standard +The obvious solution to this problem is to ensure mutual exclusion by using + some sort of lock, which may work well in many concurrent systems. + In a distributed system, this lock, along with the state, would have to + be distributed. + If the lock is not distributed, no guarantee can be made that two nodes + in the distributed system do not generate the same number. + A different approach is to give each node the ability to generate Universally + Unique Identifiers (UUID), where the state of one machine does not interfere + with the state of another. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{MAC Address}}{Media Access Control address, used to identify network + cards} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SHA-1}}{Cryptigraphic hash function, designed by the National Security + Agency (NSA)} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +According to +\begin_inset CommandInset citation +LatexCommand citet +key "Leach98uuidsand" + +\end_inset + +, +\begin_inset Quotes eld +\end_inset + +A UUID is 128 bits long, and if generated according to the one of the mechanisms + in this document, is either guaranteed to be different from all other UUIDs/GUI +Ds generated until 3400 A.D. + or extremely likely to be different +\begin_inset Quotes erd +\end_inset + +. + This is accomplished by gathering several different sources of information, + such as: time, MAC addresses of network cards, and operating system data, + such as percentage of memory in use, mouse cursor position and process + ID:s. + The gathered data is then +\emph on +hashed +\emph default + +\begin_inset space ~ +\end_inset + +using an algorithm such as SHA-1. +\end_layout + +\begin_layout Standard +When using system wide unique identifiers, such as the ones generated by + algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + + with mutual exclusion, it is not possible to have identifier collisions + when recovering from network splits between the GGS clusters. + Consider figure +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:network-split" + +\end_inset + +, where +\emph on +Site A +\emph default + is separated from +\emph on +Site B +\emph default + by a faulty network (illustrated by the cloud and lightening bolt). + When +\emph on + +\emph default +the decoupled node +\emph on + +\emph default +and +\emph on + +\emph default +the rest of the network later re-establish communication, they may have + generated the same ID:s if using algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + +, even when mutual system-wide exclusion is implemented. + This is exactly the problem UUID:s solve. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Network split}}{Separation of two networks, occurs when two networks + can not communicate, commonly because of a hardware or software failiure} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/netsplit2.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add clients on each side, and replace the cloud with pole-landlines being + cut by a pair of scissors +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:network-split" + +\end_inset + +An example of a network split +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Security +\end_layout + +\begin_layout Standard +We only support languages running in a sandboxed environment. + Each game session is started in its own sandbox. + The sandboxing isolates the games in such a way that they can not interfere + with each other. + If sandboxing was not in place, one game could potentially modify the contents + of a different game. + A similar approach is taken with the persistent storage we provide. + In the storage each game has its own namespace, much like a table in a + relational database. + A game is not allowed to venture outside this namespace, and can because + this not modify the persistent data of other games. + of this not modify the persistent data of other games. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Sandbox}}{A protected environment in which computer software can + be run safely} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Encryption +\end_layout + +\begin_layout Section +Game Development Language in a Virtual Machine +\begin_inset CommandInset label +LatexCommand label +name "sec:Game-Development-Language" + +\end_inset + + +\end_layout + +\begin_layout Standard +There is only a very limited number of game developers who would like to + write their games in Erlang, therefore we had to come up with something + to resolve this problem. + The main idea was to offer a replaceable module which would introduce a + interface to different virtual machines which would run the game code. + This way a game developer can write the game in his favorite language while + the server part still is written in Erlang and can benefit from all of + its advantages. +\end_layout + +\begin_layout Subsection +JavaScript +\end_layout + +\begin_layout Standard +JavaScript has gained a lot of popularity lately, it is used in large projects + such as +\emph on +Riak +\emph default + +\begin_inset Foot +status open + +\begin_layout Plain Layout +\begin_inset Flex URL +status collapsed + +\begin_layout Plain Layout + +http://wiki.basho.com/An-Introduction-to-Riak.html +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +, +\emph on +CouchDB +\emph default + +\begin_inset Foot +status open + +\begin_layout Plain Layout +\begin_inset Flex URL +status collapsed + +\begin_layout Plain Layout + +http://couchdb.apache.org +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +. + On the popular social coding site +\emph on +GitHub.com +\emph default +, 18% +\begin_inset Foot +status open + +\begin_layout Plain Layout +during the writing of the thesis the percentage went up to 19% +\begin_inset Flex URL +status collapsed + +\begin_layout Plain Layout + +https://github.com/languages/ +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + of all code is written in JavaScript. + The popularity of JavaScript in the programming community, in combination + with the availability of several different JavaScript virtual machines + was an important influence in choosing JavaScript as the main control language + for our GGS prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{CouchDB}}{Database server} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Riak}}{Database server} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{GitHub.com}}{Social coding website} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{ActionScript}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Lua}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{.NET}}{Software platform} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Other languages +\end_layout + +\begin_layout Standard +Other languages like +\emph on +lua +\emph default +, +\emph on +ActionScript +\emph default + are suitable as well because there is a virtual machine for each of them + which can be +\begin_inset Quotes eld +\end_inset + +plugged in +\begin_inset Quotes erd +\end_inset + + into our GDL VM interface. + With help of the +\emph on +Java Virtual Machine +\emph default + or the +\emph on +.NET +\emph default +environment it is even possible to run nearly every available programming + language in a sandbox as a GDL. +\end_layout + +\begin_layout Standard +Due lack of time we have decided to use just the Erlang <-> JavaScript bridge + with our interface. +\end_layout + +\begin_layout Section +Testing +\end_layout + +\begin_layout Standard +There are several ways in which the GGS can be tested. + The most important aspect has been deemed to be the experience players + have when using the GGS. + In order to test the user experience of the GGS, a realistic usage scenario + has to be set up. +\end_layout + +\begin_layout Standard +The GGS is intended to be used for powering games which have many concurrent + players. + The players need not participate in the same instance of the game, games + such as chess are prime candidates for the GGS. +\end_layout + +\begin_layout Standard +When developing the GGS, two main categories of games exhibiting different + performance demands were identified; real-time games and turn-based games. + The real-time games were deemed more demanding than the turn based games. + Tests were carried out using a real time game, since this is the more demanding + type of games. +\end_layout + +\begin_layout Standard +The real time game chosen for testing the GGS is +\emph on +Pong +\emph default +, a game in which two players play a game involving a all and two paddles. + The goal for each player is to shoot beside the other players paddle while + not allowing the ball to pass by her own paddle. + The game requires real time updates and is quite demanding when played + in several instances concurrently. +\end_layout + +\begin_layout Standard +There has been some work on the area of testing game servers, see +\begin_inset CommandInset citation +LatexCommand citet +key "Lidholt02designand" + +\end_inset + +, who describes a test bench using +\emph on +bots +\emph default + for testing his generic hazard-gaming server. + Lidholt describes how his server, capable of running several different + casino games is tested using artificial players, so called bots. + Performance is measured in +\begin_inset Quotes eld +\end_inset + +number of clients +\begin_inset Quotes erd +\end_inset + + able to connect to the server, and the system load. +\end_layout + +\begin_layout Standard +Similar tests were performed on the GGS, and the results of these tests + are visible in chapter +\begin_inset CommandInset ref +LatexCommand ref +reference "chap:Results-and-discussion" + +\end_inset + +. + The tests were initially performed by starting an operating system process + for each player. + Due to lack of hardware, not enough player processes could be started in + this way. + The bots were re-written in Erlang, and due to Erlang's light weigh threads, + enough processes could be created to successfully test the server. +\end_layout + +\begin_layout Chapter +Implementation of a prototype +\begin_inset CommandInset label +LatexCommand label +name "cha:Implementation-of-a" + +\end_inset + + +\end_layout + +\begin_layout Standard +This chapter contains the realization of much of the principles and techniques + described in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Theory" + +\end_inset + +. + Here the problems and their solutions are discussed in greater detail, + and at times the text becomes more specific to GGS. +\end_layout + +\begin_layout Standard +Much of what is discussed in this chapter has been implemented in the Erlang + GGS prototype. + Specific solutions such as +\emph on +supervisor structures +\emph default +and distribution of erlang nodes on physical nodes. + The different means of communications within the GGS and outside the GGS + with third parties are also discussed here. +\end_layout + +\begin_layout Section +Overview of the prototype +\end_layout + +\begin_layout Standard +The prototype of the GGS was developed using the Erlang language. + The functional and concurrent style of Erlang facilitates development of + software based on a real-world model +\begin_inset CommandInset citation +LatexCommand citep +key "armstrong2011" + +\end_inset + +. + In Erlang, most things are processes. + The software running the Erlang code is known as the Erlang machine, or + an Erlang node. + Each Erlang node is capable of running several +\emph on +threads +\emph default +(also known as +\emph on +Light Weight Processes; LWP +\emph default +) +\emph on +, +\emph default +much like the threads in an operating system. + Threads in a Linux system, for example, are treated much like operating + system processes in different systems. + Due to the size of data structures related to each process, swapping one + process for another (known as +\emph on +context switching +\emph default +) is an expensive task in many systems +\begin_inset CommandInset citation +LatexCommand citep +after "pg 80" +key "McKusick:2004:DIF:1014910" + +\end_inset + +. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{LWP}}{Light Weight Process} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Context switch}}{The act of switching from one context, commonly + a process, to another. + Used by operating systems to achieve multi tasking} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The cost of swapping operating system processes becomes a problem when many + processes are involved. + If the GGS system had been developed using regular operating system processes, + it would have had to be designed in a way to minimize the number of processes. + Using Erlang, which is capable of running very many processes, several + times more than an operating system can, the mapping between the real world + system (described in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Design-of-the" + +\end_inset + +) becomes clearer. +\end_layout + +\begin_layout Standard +Erlang allows the GGS to create several process for each player connecting, + these processes can handle a multitude of different tasks, parsing data + for example. + Since each task is handled by a different process, the tasks are clearly + separated and the failure of one is easily recovered without affecting + the others. +\end_layout + +\begin_layout Standard +In addition to creating (or +\emph on +spawning +\emph default +) processes specifically to handle new players connecting, the GGS has more + permanent processes running at all times. + The constantly running processes in the GGS system are called +\emph on +modules +\emph default +. + An example of a module in the GGS is the +\emph on +dispatcher module +\emph default +, which handles the initial connection made by a client, passing the connection + along further in to the system. +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/Chess_no_text.eps + width 100text% + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:The-layout-of" + +\end_inset + +The layout of the GGS. + The circles marked with 'C' topmost in the picture represent clients. + The cloud marked 'network' pictured directly below the clients can be any + network, for example the Internet. + The barell figure marked 'backup' is a process being fed backup data from + the coordinator. + The barell marked 'State' contains the state of a table, and this is fed + into the box marked 'Mnesia' which is database. + Finally the figure shaped as a shield marked 'GameVM' contains the actual + game process. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +In figure +\begin_inset CommandInset ref +LatexCommand vref +reference "fig:The-layout-of" + +\end_inset + + the entire GGS system is represented graphically. + The circles marked with 'C' topmost in the picture represent game clients. + These circles represent processes running on gamers computers, and not + on the GGS machine. + If a game of chess is to be played on the server, the clients on the gamers + machines will be chess game clients. + Clients connect through a network, pictured as a cloud, to the dispatcher + process in the GGS. + The dispatcher process and all other modules are discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:The-modular-structure" + +\end_inset + +. + For each connection, a new player process is spawned, which immediately + after spawning is integrated in to the GGS by the coordinator process. +\end_layout + +\begin_layout Section +The usage of Erlang in the GGS +\begin_inset CommandInset label +LatexCommand label +name "sec:The-usage-of-erlang" + +\end_inset + + +\end_layout + +\begin_layout Standard +Erlang was designed by Ericsson, beginning in 1986, for the purpose of creating + concurrent applications and improving telecom software. + Features essential for the telecom industry to achieve high availability + in telecom switches were added to the language. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Mutex}}{A construct for achieving mutial exclusion, used to avoid + simultaneous access to shared resources in computer systems} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Erlang uses message passing in favor of shared memory, mutexes and locks, + something which at the time was controversial among fellow developers +\begin_inset CommandInset citation +LatexCommand citet +key "Armstrong:2010:ERL:1810891.1810910" + +\end_inset + +. + The reason for using message passing, according to Armstrong, was that + applications should operate correctly before optimizations are done, where + efficient internal communication within the Erlang machine was considered + a later optimization. +\end_layout + +\begin_layout Standard +In using message passing in favor of the methods commonly used at the time, + the issues commonly associated with shared memory and locking were avoided. + In Erlang, everything is a process, and everything operates in its own + memory space. + Memory can not be shared among processes, which prohibits a process from + corrupting the memory of a different process. +\end_layout + +\begin_layout Standard +Messages are sent between the processes in an asynchronous manner, and each + process has a mailbox in which these messages can be retrieved. +\end_layout + +\begin_layout Standard +Processes in Erlang are also called +\emph on +Light Weight Processes. + +\emph default +The Erlang processes are very cheaply created. + Processes exist within an Erlang machine, or Erlang node. + The Erlang machine has its own scheduler and does not rely on the operating + system's scheduler, this is a main reason of Erlang's capability of running + many concurrent processes +\begin_inset CommandInset citation +LatexCommand citet +key "Armstrong03" + +\end_inset + +. +\end_layout + +\begin_layout Standard +The strong isolation of Erlang processes make them ideal for multi-core + and distributed systems. + Distribution of software is included as a fundamental part in the Erlang + language. + The 'physical' location of a process, e.g. + which computer the process runs on, is not important when communicating + with the process. + Processes can communicate regardless of whether they run on the same system + of not, transparently. +\end_layout + +\begin_layout Standard +The distributed nature of Erlang is something the GGS makes use of when + scaling across several computers in order to achieve higher performance. + The distribution is also important in creating redundancy. + Erlang promotes a non-defensive programming style in which processes are + allowed to crash and be restarted in favor of having the processes recover + from errors. + The distributed nature of Erlang means supervisor processes (discussed + in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Supervisor-structure" + +\end_inset + +) can reside on remote systems, thereby increasing the reliability of the + system as a whole. +\end_layout + +\begin_layout Standard +A very important feature of Erlang, used in the GGS, is the ability to interface + with external hardware and software. + Erlang allows communication with external resources through +\emph on +ports +\emph default + and +\emph on +NIF +\emph default +:s (Native implemented functions) +\emph on +. + +\emph default + Through ports communication can take place much in the same way communication + is performed over sockets. + NIF:s are called like any other functions without any difference to the + caller but are implemented in C. +\end_layout + +\begin_layout Standard +The GGS uses Erlang ports for generating UUID:s +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +UUID:s are discussed in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:UUID" + +\end_inset + + +\end_layout + +\end_inset + + and NIF:s for interfacing with the virtual machines of games +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +Virtual machines of games are discussed in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Game-Development-Language" + +\end_inset + + +\end_layout + +\end_inset + +. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{OTP}}{Open Telecom Platform, a software suite for Erlang} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Behaviour}}{A design pattern in OTP} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Development of the GGS would have been hard if not impossible had it not + been for the +\emph on +OTP +\emph default + supplied with the standard Erlang distribution. + The OTP (Open Telecom Platform) is a set of standard libraries and design + patterns, called +\emph on +behaviors +\emph default +, which are used when developing Erlang systems. +\end_layout + +\begin_layout Standard +The GGS makes heavy use of the behaviors supplied in the OTP. + The behaviors impose a programming style suitable for distributed and concurren +t applications, perfectly suitable for the GGS. + In particular, the GGS uses the following behaviors: +\end_layout + +\begin_layout Itemize +The +\emph on +supervisor +\emph default + behavior, which is used when creating a supervisor. + Supervisors are used when monitoring processes in the Erlang system. + When a process exits wrongfully, the supervisor monitoring the process + in question decides which action to take. + In the GGS, the most common action is simply to restart the faulting process. + A more thorough discussion on supervisors can be found in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Supervisor-structure" + +\end_inset + +. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_tcp +\emph default +behavior, which is used to work with TCP sockets for network communication. + Using the gen_tcp behavior, network messages are converted to internal + Erlang messages and passed to a protocol parser, where the messages are + processed further. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_server +\emph default + behavior, which is used when constructing OTP servers in Erlang. + Using this behavior, a state can easily be kept in a server process, greatly + increasing the usefulness of the server process. + There are many gen_servers in the GGS, it is the most widely used behavior + in the project. + In addition to introducing a state to the server, the gen_server behavior + also imposes patterns for synchronous and asynchronous communication between + other gen_servers and other OTP behaviors. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_fsm +\emph default + behavior is used in the protocol parser module in the GGS. + Using the gen_fsm behavior, finite state machines are easily developed. + Protocol parsers are an ideal example of where to use finite state machines, + which are widely used for parsing strings of text. +\end_layout + +\begin_layout Standard +In addition to supplying behaviors, the OTP also has a style for packaging + and running Erlang applications. + By packaging the GGS as an +\emph on +application +\emph default +the GGS can be started in a way uniform to most erlang software, providing + familiarity for other Erlang users, and eases the incorporation of the + GGS in other applications. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Application}}{A way of packaging Erlang software in a uniform way} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Short introduction to the Erlang syntax +\end_layout + +\begin_layout Standard +In order to understand examples in this thesis, a small subset of Erlang + must be understood. + In this section, the very syntactic basics of Erlang are given. +\end_layout + +\begin_layout Itemize + +\series bold +Variables +\series default + start with an uppercase letter, examples include +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt X, Var}, and { +\backslash +tt Global} +\end_layout + +\end_inset + +. + A variable can only be assigned once. +\end_layout + +\begin_layout Itemize + +\series bold +Atoms +\emph on + +\series default +\emph default +start with lower case letters, for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + + { +\backslash +tt atom, a} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Functions +\series default + are defined starting with an atom for the name, parenthesis containing + parameters, an arrow, a function body and finally a dot marking the end + of a function. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt square(X) -> X*X.} +\end_layout + +\end_inset + + is an example of a function producing the square of X. +\end_layout + +\begin_layout Itemize +Functions are +\series bold +called +\series default + by suffixing an atom with the function name with parenthesis, for example + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt square(10)} +\end_layout + +\end_inset + +. + Qualified names can be specified using ':', for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt math:square(10)} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Tuples +\series default + are containers of fixed type for Erlang data types. + They are constructed using curly brackets, for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt +\backslash +{atom1, atom2, atom3 +\backslash +}}. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Itemize + +\series bold +Lists +\series default + are constructed using [ and ], for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt [1,2,3]} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Strings +\series default + doubly quoted lists of characters, for example +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt "Hello world"} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Records +\series default + are erlang tuples coupled with a tag for each tuple element. + This allows referring to elements by name instead of by position. + An example of a record looks like this: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt +\backslash +#myRecord{}} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Section +Communication with external systems and applications +\begin_inset CommandInset label +LatexCommand label +name "sec:Communication-with-external" + +\end_inset + + +\end_layout + +\begin_layout Standard +A game launched on the GGS is run within a virtual machine. + For each programming language supported, there is a virtual machine that + interprets the game. + Furthermore an interface for communication between the GGS, the game and + the players playing the game must be present. +\end_layout + +\begin_layout Standard +The reason for the GGS requiring a communication channel between the game + VM and Erlang is in part because the GGS makes heavy use of callbacks. + Callbacks written in Erlang are registered to the VM for the interface + to work. + It is only with the help of the interface that the game developer can access + the game state and send messages between players. + The interface provides access to three objects called +\emph on +world +\emph default +, +\emph on +player +\emph default + and +\emph on +localstorage +\emph default +. + The game state is safely stored in a database and retrieved for manipulation + by a call for the world object. + Interaction with the players is done the same way using the player object + instead. + The localstorage is a convenient way to store global data and other data + separated from the game state. + In section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Exposing-Erlang-functionality" + +\end_inset + + a concrete example of the implementation of the localstorage and world + objects is given. +\begin_inset Note Note +status open + +\begin_layout Plain Layout + Unique id:s called gametokens are generated for hosted games so that they + are not mixed up. + -- good text, integrate more. +\end_layout + +\end_inset + + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{WebStorage}}{A new standard for letting websites store data on visitors' + computers} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Exposing Erlang functionality to the GDL VM +\begin_inset CommandInset label +LatexCommand label +name "sub:Exposing-Erlang-functionality" + +\end_inset + + +\end_layout + +\begin_layout Standard +This section contains a concrete example of how the localstorage and world + objects are exposed to a GDL VM. + The example comes from the GGS prototype, which uses JavaScript powered + by Google V8 as its GDL VM. +\end_layout + +\begin_layout Standard +The code given in +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:exposing-erlang" + +\end_inset + + is specific to V8 and JavaScript, however implementations for different + GDL:s, or different JavaScript VM:s should be similar. +\end_layout + +\begin_layout Standard +In JavaScript is is common to use a top level object, called a global object, + to establish a global scope. + This allows declaration of global variables and functions. + To gain access to the global object in the GGS, the +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt erlv8 +\backslash +_vm:global(..)} +\end_layout + +\end_inset + + function on line 2 of the example is used. + Using the global object, declarations of the world and GGS object can be + placed in the global scope. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt Global:set +\backslash +_value(..)} +\end_layout + +\end_inset + + is a call to the global object, declaring new objects in the global scope. + On line 4 the GGS object is declared. + By accessing +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt GGS.localStorage } +\end_layout + +\end_inset + + from within the GDL, access to the localstorage is provided, thus the localstor +age must be connected to the GGS object, this can be seen in line 5. +\end_layout + +\begin_layout Standard +Both the GGS and localstorage objects are dummy objects, which provide no + functionality, these two objects are simply placed in the GDL for the purpose + clearing up the code. + In order to perform an action using the GGS and localstorage objects, the + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt getItem} and { +\backslash +tt setItem} +\end_layout + +\end_inset + + functions must be used. + These items are directly connected to the database module of the GGS, which + is discussed in more detail in +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:The-database-module" + +\end_inset + +. +\end_layout + +\begin_layout Standard +Similarly the functions +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt sendCommand, sendCommandToAll} and { +\backslash +tt setTimeout} +\end_layout + +\end_inset + + are directly connected to a piece of code in the GGS which performs the + desired action. + The +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt sendCommand} +\end_layout + +\end_inset + + functions are used to send commands or text to participants of the table. + The +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt setTimeout} +\end_layout + +\end_inset + + function introduces timeouts to the V8 engine, which are not available + per default. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +language=Erlang, +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting}[language=Erlang] +\end_layout + +\begin_layout Plain Layout + +% @doc Exposes some GGS functions to JavaScript +\end_layout + +\begin_layout Plain Layout + +expose(GameVM, Table) -> +\end_layout + +\begin_layout Plain Layout + + Global = erlv8_vm:global(GameVM), +\end_layout + +\begin_layout Plain Layout + + Global:set_value("GGS", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"localStorage", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:setItem(Table, local_storage, Key, Val) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:getItem(Table, local_storage, Key) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])}, +\end_layout + +\begin_layout Plain Layout + + {"world", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:setItem(Table, world, Key, Val), +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command_to_all( +\end_layout + +\begin_layout Plain Layout + + Table, {"world_set", Key ++ "=" ++ Val} +\end_layout + +\begin_layout Plain Layout + + ) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:getItem(Table, world, Key), +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])}, +\end_layout + +\begin_layout Plain Layout + + {"sendCommand", fun(#erlv8_fun_invocation{}, [Player, Command, Args])-> +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command(Table, Player, {Command, Args}) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"sendCommandToAll", fun(#erlv8_fun_invocation{}, [Command, Args])-> +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command_to_all(Table, {Command, Args}) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + {"setTimeout", fund(#erlv8_fun_invocation{}, [Time, Function])-> +\end_layout + +\begin_layout Plain Layout + + timer:apply_after(Time, ?MODULE, call_js, [GameVM, Function]) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])). +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:exposing-erlang" + +\end_inset + +An example of how Erlang functionality is exposed to a Javascript GDL +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +TODO: Go in to more detail about how the world, player and localstorage + objects are implemented. + Also discuss localstorage and how it derives from the webstorage standard + in detail. + This is a great point on how we try to follow standards. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +My idea here is that we describe the erlang-js (which failed, but nonetheless), + v8, UUID and other external communication. + We shouldn't describe sockets here though.. + or.. + maybe? +\end_layout + +\begin_layout Plain Layout +Also discuss how we allow GDLs to communicate with Erlang, this is +\begin_inset Quotes eld +\end_inset + +external +\begin_inset Quotes erd +\end_inset + + to three GDL. + Discuss the GGS world object (there is a reference to this secxtion for + that purpose) +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +The modular structure of the GGS prototype +\begin_inset CommandInset label +LatexCommand label +name "sec:The-modular-structure" + +\end_inset + + +\end_layout + +\begin_layout Standard +The separation of concerns, and principle of single responsibility +\begin_inset Foot +status open + +\begin_layout Plain Layout +More information on the SRP is available at: +\begin_inset CommandInset href +LatexCommand href +target "http://www.objectmentor.com/resources/articles/srp.pdf" + +\end_inset + + +\end_layout + +\end_inset + + are widely respected as good practices in the world of software engineering + and development. + By dividing the GGS up into modules each part of the GGS can be modified + without damaging the rest of the system. +\end_layout + +\begin_layout Standard +The responsibility and concern of each module comes from the responsibility + and concern of the real-world entity the model represents. + The modeling of the GGS after a real world system was discussed in chapter + +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Theory" + +\end_inset + +. +\end_layout + +\begin_layout Standard +In the text below the word module refers to the actual code of the discussed + feature, while the word process is used when referring to a running instance + of the code. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SRP}}{Single Responsibility Principle} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Object Oriented Programming}}{A programming paradigm focusing on + objects} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +The dispatcher module +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +The discussion of the modules is divided into the following parts: +\end_layout + +\begin_layout Itemize +What does the module do? +\end_layout + +\begin_layout Itemize +What happens when the module fails? +\end_layout + +\begin_layout Itemize +How does the module correspond to the real-world scenario of the chess club? +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The dispatcher module is the first module to have contact with a player. + When a player connects to the GGS, it is first greeted by the dispatcher + module, which sets up an accepting socket for each player. + +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout +Is this the proper way to day the dispatcher greets connecting players? +\end_layout + +\end_inset + + The dispatcher is the module which handles the interfacing to the operating + system when working with sockets. + Operating system limits concerning the number of open files, or number + of open sockets are handled here. + The operating system limits can impose problems on the GGS, this is discussed + more in detail in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Problems-of-implementation" + +\end_inset + +. +\end_layout + +\begin_layout Standard +Should the dispatcher module fail to function, no new connections to the + GGS can be made. + In the event of a crash in the dispatcher module, a supervisor process + immediately restarts the dispatcher. + There exists a window of time between the crashing of the dispatcher and + the restarting of the dispatcher, this window is very short, and only during + this window is the GGS unable to process new connection requests. + Due to the modular structure of the GGS, the rest of the system is not + harmed by the dispatcher process not functioning. + The process does not contain a state, therefore a simple restart of the + process is sufficient in restoring the GGS to a pristine state after a + dispatcher crash +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Well.. + In theory.. +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Standard +Returning to scenario of the chess club, the dispatcher module is the doorman + of the club. + When a player enters the chess club, the player is greeted by the doorman, + letting the player in to the club. + The actual letting in to the club is in the GGS represented by the creation + of a player process discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-player-module" + +\end_inset + +. + The newly created player process is handed, and granted rights to, the + socket of the newly connected player. +\end_layout + +\begin_layout Subsection +The player module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-player-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +The player module is responsible for representing a player in the system. + Each connected player has its own player process. + The player process has access to the connection of the player it represents, + and can communicate with this player. + In order to communicate with a player, the data to and from the player + object must pass through a protocol parser module, discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-protocol-parser" + +\end_inset + +. + Raw communication, without passing the data through a protocol parser is + in theory possible, but is not useful. +\end_layout + +\begin_layout Standard +In the creation of a player process, the coordinator process, discussed + in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-coordinator-module" + +\end_inset + +, is notified by the newly connected process. +\end_layout + +\begin_layout Standard +In the event of a crash in a player process, several things happen. + +\end_layout + +\begin_layout Enumerate +The player process, which is the only process with a reference to the socket + leading to the remote client software, passes this reference of the socket + to the coordinator process temporarily. +\end_layout + +\begin_layout Enumerate +The player process exits. +\end_layout + +\begin_layout Enumerate +The coordinator spawns a new player process, with the same socket reference + as the old player process had. +\end_layout + +\begin_layout Enumerate +The player process resumes operation, immediately starting a new protocol + parser process, and begins to receive and send network messages again. +\end_layout + +\begin_layout Standard +The window of time between the crash of the player process and the starting + of a new player process is, as with the dispatcher, very short. + Since the connection changes owners for a short period of time, but is + never dropped, the implications of a crash are only noticed, at worst, + as choppy gameplay for the client. + Note however that this crash recovery scheme is not implemented in the + GGS prototype. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Can we do this..? Seems a bit sneaky. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Moving back to the real world example, the player process represent an actual + person in the chess club. + When a person sits down at a table in the chess club, the person does so + by requesting a seat from some coordinating person, and is then seated + by the same coordinator. + Once seated, the player may make moves on the table he or she is seated + by, this corresponds clearly to how the GGS is structured, as can be seen + in the following sections. +\end_layout + +\begin_layout Subsection +The protocol parser module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-protocol-parser" + +\end_inset + + +\end_layout + +\begin_layout Standard +The protocol parser is an easily interchangeable module in the GGS, handling + the client-to-server, and server-to-client protocol parsing. + In the GGS prototype, there is only one protocol supported, namely the + +\emph on +GGS Protocol +\emph default +. + The role of the protocol parser is to translate the meaning of packets + sent using the protocol in use to internal messages of the GGS system. + The GGS protocol, discussed below is used as a sample protocol in order + to explain how protocol parsers can be built for the GGS. +\end_layout + +\begin_layout Subsubsection +The structure of the GGS Protocol +\begin_inset CommandInset label +LatexCommand label +name "sub:The-structure-of" + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS protocol is modeled after the HTTP protocol. + The main reason for this is the familiarity many developers already have + with HTTP due to its presence in internet software. + Each GGS protocol packet contains a headers section. + The headers section is followed by a data section. + In the headers section, parameters concerning the packet is placed. + In the data section, the actual data payload of the packet is placed. +\end_layout + +\begin_layout Standard +There is no requirement of any specific order of the parameters in the headers + section, however the data section must always follow directly after the + headers section. +\end_layout + +\begin_layout Standard +In the example below, line 1 contains a Game-Command parameter. + This parameter is used to determine which game-specific command the client + is trying to perform. + The handling of this parameter is specific to each game, and can be anything. +\end_layout + +\begin_layout Standard +Line 2 specifies a game token. + This is a UUID which is generated for each client upon authentication with + the GGS. + The GGS uses this token in case a client is disconnected and the new connection + created when the client reconnects must be re-paired with the player object + inside the GGS. + The UUID is also used as a unique ID within GDL VMs. +\end_layout + +\begin_layout Standard +Line 3 specifies the content type of the payload of this particular packet. + This parameter allows the GGS to invoke special parsers, should the data + be encoded or encrypted. + When encryption is employed, only the payload is encrypted, not the header + section. + This is a scheme which does not allow for strong encryption, but is deemed + feasible for gaming purposes. +\end_layout + +\begin_layout Standard +Line 4 specifies the content length of the payload following immediately + after the headers section. +\end_layout + +\begin_layout Standard +The parser of the GGS protocol implemented in the GGS prototype is designed + as a finite state machine using the gen_fsm behavior. + When a full message has been parsed by the parser, the message is converted + into the internal structure of the GGS messages, and sent in to the system + from the protocol parser using message passing. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Packet below is not an algorithm, but I don't know how to change that label.. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting} +\end_layout + +\begin_layout Plain Layout + +Game-Command: chat +\end_layout + +\begin_layout Plain Layout + +Token: e30174d4-185e-493b-a21a-832e2d9d7a1a +\end_layout + +\begin_layout Plain Layout + +Content-Type: text +\end_layout + +\begin_layout Plain Layout + +Content-Length: 18 +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + +Hello world, guys! +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-sample-packet" + +\end_inset + +A sample packet sent from a client to the GGS during a chat session +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Mention that the protocol is heavily influenced bye HTTP, is parsed using + a FSM, perhaps give a sample packet. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +The coordinator module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-coordinator-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +The coordinator module is responsible for keeping track of all players, + their seats and tables. + Players register with the coordinator process when first connecting to + the server, and the coordinator places each player by their respective + table. +\end_layout + +\begin_layout Standard +The coordinator keeps mappings between each player and table, therefore + it is used to perform lookups on tables and players to find out which are + connected. + The connectivity of players and tables is important when sending messages + to all participants in a game. + A lookup in the coordinator process is performed prior to notifying all + players in a game to ensure the message reaches all players. + The lookup can be performed either using internal identification codes + or using the UUID associated with each client and table. +\end_layout + +\begin_layout Standard +The coordinator process contains important state, therefore a backup process + is kept at allt times. + All good data processed by the coordinator is stored for safekeeping in + the backup process as well. + Data which is potentisally harmful is not stored in the backup process. +\end_layout + +\begin_layout Standard +Upon a crash, the coordinator process recovers the prior good state from + the backup process and continues where it left off. + A supervisor process monitors the coordinator process and restarts the + process when it malfunctions. + There is a window of time between the crash of the coordinator and the + restarting of the coordinator, during this time, players can not be seated + by new tables, and can not disconnect from the server. + This window of time is very small, and the unavailability of the coordinator + process should not be noticed by more than a short time lag for the clients. +\end_layout + +\begin_layout Standard +Moving back to the example of the chess club, the coordinator process can + be seen as a judge, monitoring all moves of the players. + At the same time as acting as a judge, the coordinator process is also + a host in the chess club, seating players by their tables and offering + services to the players. +\end_layout + +\begin_layout Subsection +The table module +\end_layout + +\begin_layout Standard +The table module is mostly a hub used for communication. + New table processes are created by the coordinator on demand. + The table module does not contain any business logic, however each process + contains information concerning which players are seated by that particular + table. +\end_layout + +\begin_layout Standard +The information about which players are seated by each table is used when + notifying all players by a table of an action. + Consider a game of chess, each player notifies the table of its actions, + the table then notifies the rest of the participants of these actions after + having had the ac tions processed by the game VM, where an action could + be moving a playing piece. +\end_layout + +\begin_layout Standard +Each table is associated with a game VM. + The actions sent to a table are processed by the game VM, this is where + the game logic is implemented. +\end_layout + +\begin_layout Standard +After a crash in a table process, the entire table must be rebuilt and the + players must be re-associated with the table. + Data concerning players is kept in the coordinator process, and is restored + from there. + Data kept in the actual game is not automatically corrupted by the crash + in a table, however the table must be re-associated with the game VM is + was associated with prior to the crash of the table. + The table process maps well into the setting of the real-world chess club + scenario previously discussed. + A table works in the same way in a real world setting as in the GGS setting. +\end_layout + +\begin_layout Subsection +The game virtual machine module +\end_layout + +\begin_layout Standard +This module holds the game logic of a game and is responsible for the VM + associated with each game. + +\end_layout + +\begin_layout Standard +The game VM contains the state of the VM and a table token associated with + a running game. + GameVM is started by the table module. + The table module hands over a token to the game VM during initialization. + During initialization a new VM instance and various objects associated + to the VM instance will be created. + Callbacks to Erlang are registered into the VM and then the source code + of a game is loaded into the VM and the game is ready for startup. + The only means for a game to communicate with the VM is through usage of + a provided interface. + +\end_layout + +\begin_layout Standard +The VM itself makes it possible for the game developer to program in the + programming language covered by the VM. + In future releases, more game VM:s will be added to support more programming + languages. + Because the game VM keeps track of the correct table, the game developer + does not need to take this into consideration when programming a game. + If a method within the game sends data to a player, it will be delivered + to the player in the correct running game. + The same game token is used to store the game state in the database. + Therefore, no game states will be mixed up either. +\end_layout + +\begin_layout Standard +This module does not affect game runtime but evaluates a new game state + and handles communication between the game and the players. + A closer look at the structure of this model is given in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Communication-with-the-GDL-VM" + +\end_inset + +. +\end_layout + +\begin_layout Subsection +The database module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-database-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +Game data from all games on the GGS are stored in the database backend of + the database module. +\end_layout + +\begin_layout Standard +In the GGS prototype the database module is using a database management + system called Mnesia. + Mnesia ships with the standard Erlang distribution and is a key-value store + type database. + Mnesia is designed to handle the stress of telecoms systems, and has some + features specifically tailored for telecoms which are not commonly found + in other databases. + Key features of the Mnesia database are: +\end_layout + +\begin_layout Itemize +Fast key/value lookups +\end_layout + +\begin_layout Itemize +Distribution of the database system +\end_layout + +\begin_layout Itemize +Fault tolerance +\end_layout + +\begin_layout Standard +\begin_inset CommandInset citation +LatexCommand citet +key "667766" + +\end_inset + + +\end_layout + +\begin_layout Standard +The features of Mnesia originally intended for telecoms prove very useful + for the purposes of the GGS as well. + The fault tolerance and speed of Mnesia are very valuable tools, the fast + key/value lookups permit many lookups per second to the database. +\end_layout + +\begin_layout Standard +Game data will not be lost when a game is stopped or has gone down for unknown + reasons. + This makes it possible to continue a game just before the failure without + having to start the game from the beginning. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Mnesia}}{Database server used in the GGS} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS stores the game state in the distributed Mnesia database, from which + the state can be restored in the event of a crash. +\end_layout + +\begin_layout Standard +Each game is uniquely identified by a table token and the data of each game + is stored within two different namespaces. + The namespaces are named World and Localstorage. + The World is used contain all game data related to the game state. + This sort of game data may change during the runtime of the game. + The Localstorage should contain data independent of the game state. + Game resources, constants and global variables are all examples of data + that could reside within the Localstorage. + To store a value within the database, not only is the table token and the + name of the namespace required, but a unique key so that the value can + be successfully retrieved or modified later. + The key is fully decidable by the game developer. + +\end_layout + +\begin_layout Standard +The interface of the database module is an implementation of the upcoming + W3C Web Storage specification. + Web Storage is intended for use in web browsers, providing a persistent + storage on the local machine for web applications. + The storage can be used to communicate in between browser windows (which + is difficult when using cookies), and to store larger chunks of data +\begin_inset CommandInset citation +LatexCommand citet +key "webstorage:website" + +\end_inset + +. + Usage of the web storage standard in the GGS provides a well documented + interface to the database backend. +\end_layout + +\begin_layout Section +Techniques for ensuring reliability +\end_layout + +\begin_layout Standard +One of the main goals of the project is to achieve high reliability. + The term +\begin_inset Quotes eld +\end_inset + +reliable system +\begin_inset Quotes erd +\end_inset + + is defined by the IEEE as a system with +\begin_inset Quotes eld +\end_inset + +the ability of a system or component to perform its required functions under + stated conditions for a specified period of time +\begin_inset Quotes erd +\end_inset + + +\begin_inset CommandInset citation +LatexCommand citet +key "ieee_90" + +\end_inset + +. + There are some tools for creating reliable applications built in to Erlang. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Reliability}}{The ability of a system or component to perform its + required functions under stated conditions for a specified period of time} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{IEEE}}{Institute of Electrical and Electronics Engineers, read "I-triple- +E"} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Itemize +Links between processes. + When a process spawns a new child process, and the child process later + exits, the parent process is notified of the exit. + +\end_layout + +\begin_layout Itemize +Transparent distribution over a network of processors. + When several nodes participate in a network, it does not matter on which + of these machines a process is run. + Communication between processes does not depend on the node in which each + process is run. + +\end_layout + +\begin_layout Itemize +Hot code replacements. + Two versions of the same module can reside in the memory of Erlang at any + time. + This means that a simple swap between these versions can take place very + quickly, and without stopping the machine. +\end_layout + +\begin_layout Standard +These three features are some of the basic building blocks for more sophisticate +d reliability systems in Erlang. + Many times it is not necessary to use these features directly, but rather + through the design patterns described below. +\end_layout + +\begin_layout Subsection +Supervisor structure +\begin_inset CommandInset label +LatexCommand label +name "sub:Supervisor-structure" + +\end_inset + + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +This entire section is bad. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +By linking processes together and notifying parents when children exit, + supervisors are created. + A supervisor is a common approach in ensuring that an application functions + in the way it was intended +\begin_inset CommandInset citation +LatexCommand citet +key "Savor:1997:HSA:851010.856089" + +\end_inset + +. + When a process misbehaves, the supervisor takes some action to restore + the process to a functional state. + +\end_layout + +\begin_layout Standard +There are several approaches to supervisor design in general (when not just + considering how they work in Erlang). + One common approach is to have the supervisor look in to the state of the + process(es) it supervises, and let the supervisor make decisions based + on this state. + The supervisor has a specification of how the process it supervises should + function, and this is how it makes decisions. + +\end_layout + +\begin_layout Standard +In Erlang, we have a simple version of supervisors. + We do not inspect the state of the processes being supervised. + We do have a specification of how the supervised processes should behave, + but on a higher level. + The specification describes things such as how many times in a given time + interval a child process may crash, which processes need restarting when + crashes occur, and so forth. + +\end_layout + +\begin_layout Standard +When the linking of processes in order to monitor exit behavior is coupled + with the transparent distribution of Erlang, a very powerful supervision + system is created. + For instance, we can restart a failing process on a different, new node, + with minimal impact on the system as a whole. + +\end_layout + +\begin_layout Standard +In the GGS, we have separated the system in to two large supervised parts. + We try to restart a crashing child separately, if this fails too many +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +Exactly how many +\begin_inset Quotes eld +\end_inset + +too many +\begin_inset Quotes erd +\end_inset + + is depends on a setting in the supervisor, ten crashes per second is a + reasonable upper limit. +\end_layout + +\end_inset + + times, we restart the nearest supervisor of this child. + This ensures separation of the subsystems so that a crash is as isolated + as possible. +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset Note Note +status open + +\begin_layout Plain Layout +We should really do this graphic in EPS instead of PNG +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/Supervisor_tree_GGS.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +The supervisor structure of GGS +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The graphic above shows our two subsystems, the coordinator subsystem and + the dispatcher subsystem. + Since these two systems perform very different tasks they have been separated. + Each subsystem has one worker process, the coordinator or the dispatcher. + The worker process keeps a state which should not be lost upon a crash. +\end_layout + +\begin_layout Standard +We have chosen to let faulty processes crash very easily when they receive + bad data, or something unexpected happens. + The alternative to crashing would have been to try and fix this faulty + data, or to foresee the unexpected events. + We chose not to do this because it is so simple to monitor and restart + processes, and so difficult to try and mend broken states. + This approach is something widely deployed in the Erlang world, and developers + are often encouraged to “Let it crash”. +\end_layout + +\begin_layout Standard +To prevent any data loss, the good state of the worker processes is stored + in their respective backup processes. + When a worker process (re)starts, it asks the backup process for any previous + state, if there is any that state is loaded in to the worker and it proceeds + where it left off. + If on the other hand no state is available, a special message is delivered + instead, making the worker create a new state, this is what happens when + the workers are first created. +\end_layout + +\begin_layout Subsection +Redundancy +\end_layout + +\begin_layout Standard +The modules in the GGS are built to be capable of redundant operation. + By adding a backup process to sensitive processes, the state can be kept + in the event of a crash. + The coordinator of the GGS prototype has this backup feature built in. + The coordinator passes state along to the backup process which keeps the + data safe. + In the event of a crash, the coordinator recovers the state from the backup + process. + Figure +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:redundancy" + +\end_inset + + depicts the redundancy built in to the coordinator process. +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/redundancy.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:redundancy" + +\end_inset + +To the left normal execution is pictured; the server state is backed up. + To the right; the exceptional execution, where the state is retrieved from + the backup to repopulate the server. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Hot code replacement +\end_layout + +\begin_layout Standard +Hot code replacement is a technique used to update systems while they are + running. + The main use of hot code replacement are in critical systems that require + low downtime, such as telecom systems. + By using hot code replacement system can be able to achieve as high uptime + as possible and thus improving the reliability of the system. + Code replacement is a feature that exist in Erlang which means that with + some work it could be implemented into the GGS. +\end_layout + +\begin_layout Section +Example of a GGS server application in Javascript +\end_layout + +\begin_layout Standard +Below is a concrete example of a simple chat server application written + using the GGS. + The language chosen for this chat server is JavaScript. + The GGS processes all incoming data through a protocol parser, which interprets + the data and parses it into an internal format for the GGS. +\end_layout + +\begin_layout Standard +When the GGS receives a +\emph on +Game-Command +\emph default + from a client, it is passed along to the game VM through a function called + +\emph on +playerCommand +\emph default + which is the entry point for each game and has to be implemented by the + developer; one can think of it like the +\emph on +main() +\emph default + function of a C or Java program +\emph on +. + +\emph default + Typically the +\emph on +playerCommand +\emph default + function contains conditional constructs which decide the next action to + take. + In +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-concrete-example" + +\end_inset + + an example of the +\emph on +playerCommand +\emph default + function can be seen. +\end_layout + +\begin_layout Standard +In +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-concrete-example" + +\end_inset + + the +\emph on +playerCommand +\emph default + function accepts two different commands. + The first command is a command which allows chat clients connected to the + chat server to change nicknames, which are used when chatting. + In order to change the nickname, a client must send a Game-Command +\begin_inset Quotes eld +\end_inset + +nick +\begin_inset Quotes erd +\end_inset + + with the actual new nickname as a argument. + When a message arrives to the GGS which has the form corresponding to the + nickname change, the +\emph on +playerCommand +\emph default + function is called with the parameters +\emph on +player_id, command, +\emph default +and +\emph on +args +\emph default + filled in appropriately. +\end_layout + +\begin_layout Standard +The +\emph on +playerCommand +\emph default + function is responsible for calling the helper functions responsibly for + carrying out the actions of each message received. + +\emph on +changeNick +\emph default + is a function which is called when the +\begin_inset Quotes eld +\end_inset + +nick +\begin_inset Quotes erd +\end_inset + + message is received. + The +\emph on +changeNick +\emph default +function uses a feature of the GGS called localstorage (see section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Communication-with-the-GDL-VM" + +\end_inset + +), which is an interface to the database backend contained in the database + module (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:The-database-module" + +\end_inset + +). + The database can be used as any key-value store, however the syntax for + insertions and fetch operations is tighty integrated in the GDL of the + GGS. +\end_layout + +\begin_layout Standard +Access to the localStorage is provided through the +\emph on +GGS object +\emph default +, which also can be used to communicate with the rest of the system from + the GDL. + Implementation specifics of the GGS object are provided in +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Communication-with-the-GDL-VM" + +\end_inset + +. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +language=JavaScript, +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting}[language=JavaScript] +\end_layout + +\begin_layout Plain Layout + +function playerCommand(player_id, command, args) { +\end_layout + +\begin_layout Plain Layout + + if(command == "nick") { +\end_layout + +\begin_layout Plain Layout + + changeNick(player_id, args); +\end_layout + +\begin_layout Plain Layout + + } else if(command == "message") { +\end_layout + +\begin_layout Plain Layout + + message(player_id, args); +\end_layout + +\begin_layout Plain Layout + + } +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + +function changeNick(player_id, nick) { +\end_layout + +\begin_layout Plain Layout + + var old_nick = GGS.localStorage.getItem("nick_" + player_id); +\end_layout + +\begin_layout Plain Layout + + GGS.localStorage.setItem("nick_" + player_id, nick); +\end_layout + +\begin_layout Plain Layout + + if (!old_nick) { +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll("notice", nick + " joined"); +\end_layout + +\begin_layout Plain Layout + + } else { +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll("notice", old_nick + " is now called " + nick); +\end_layout + +\begin_layout Plain Layout + + } +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + +function message(player_id, message) { +\end_layout + +\begin_layout Plain Layout + + var nick = GGS.localStorage.getItem("nick_" + player_id); +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll('message', nick + "> " + message); +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-concrete-example" + +\end_inset + +A concrete example of a simple chat server written in JavaScript, running + on the GGS +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Chapter +Problems of implementation +\begin_inset CommandInset label +LatexCommand label +name "cha:Problems-of-implementation" + +\end_inset + + +\end_layout + +\begin_layout Standard +This chapter contains specific problems encountered when implementing the + GGS prototype. + Some of the problems described have solutions attached, however some problems + were not solved, therefore only ideas for slutions have been attached. +\end_layout + +\begin_layout Standard +The integration of JavaScript as a GDL in the GGS prototype was particularily + difficult, and is handled in this section. + Unique identification is also handled, as is the design of the GGS protocol. +\end_layout + +\begin_layout Section +JavaScript engine +\end_layout + +\begin_layout Standard +The GGS prototype uses a vistual machine to sandbox each game. + JavaScript was chosen for the prototype due to its commonality in web applicati +ons and the flexibility of the language. + Any language with the proper bindings to Erlang could have been used in + theory. +\end_layout + +\begin_layout Standard +There are two main JavaScript virtual machines, or +\emph on +engines +\emph default + available at the time of the writing of this thesis. + There is a group of machines developed by Mozilla called +\emph on +TraceMonkey, JaegerMonkey, SpiderMonkey +\emph default +and +\emph on +IonMonkey +\emph default +, and also there is Google V8. + The group of Mozilla machines are largely the same, and are referred to + as the same machine for simplicity. +\end_layout + +\begin_layout Standard +For the Mozilla machines, there exists an Erlang binding called erlang_js, + and for the V8 machine a binding called erlv8 exists. +\end_layout + +\begin_layout Subsection +erlang_js +\end_layout + +\begin_layout Standard +Erlang_js provides direct communication with the JavaScript VM. + Which is exactly what is desired, however also required is thee possibility + to communicate from erlang_js to Erlang. + The ability to communicate from JavaScript to Erlang functionality is not + yet implemented in erlang_js, due to lack of time on the behalf of the + erlang_js developers. +\end_layout + +\begin_layout Standard +There were two possible solutions to the problem of the JavaScript to Erlang + communication path missing, the path could be implemented by the GGS project, + or a switch from erlang_js for some other JavaScript engine could be made. + +\end_layout + +\begin_layout Standard +Attempts at creating the communication path from JavaScript to Erlang were + initially made, however the communication path never became stable enough + for usage in the GGS and the erlang_js software was abandoned. +\end_layout + +\begin_layout Subsection +erlv8 +\end_layout + +\begin_layout Standard +erlv8 is powered by the V8 engine developed by Google rather than the engines + developed by Mozilla. + The ability to communicate with Erlang from JavaScript using callbacks + is available in the erlv8 bindings, therefore this feature does not have + to be added to the bindings in order to be used in the GGS. +\end_layout + +\begin_layout Standard +Initial releases of the erlv8 bindings had stability issues, these were + however solved by the erlv8 developers during the usage of erlv8 in the + GGS. + erlv8 is the JavaScript engine powering JavaScript as a GDL in the GGS. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{V8}}{JavaScript engine developed by Google} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SpiderMonkey}}{JavaScript engine developed by Mozilla} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +UUID +\end_layout + +\begin_layout Standard +Erlang identifies processes uniquely throughout the entire Erlang network + using process IDs (PID). + When we wish to refer to erlang processes from outside our erlang system, + for example in a virtual machine for a different language, possibly on + a different machine, these PID:s are no longer useful. + +\end_layout + +\begin_layout Standard +This problem is not new, and a common solution is to use a Universally Unique + Identifier, a UUID. + These identifiers are generated both using randomization and using time. + A reasonably large number of UUID:s can be generated before a collision + should occur. + There are standard tools in many UNIX systems to generate UUID:s, we chose + to use the uuidgen command, which employs an equidistributed combined Tausworth +e generator. +\end_layout + +\begin_layout Section +Protocol design +\end_layout + +\begin_layout Standard +Initially the GGS protocol was designed to use the UDP protocol for transport. + Due to the lack of error checking in the UDP protocol, the UDP protocol + is faster than the TCP protocol, this was a main reason to use UDP. + The GGS does however need error checking to be as reliable as possible, + therefore an error checking layer would have to be placed on top of UDP. +\end_layout + +\begin_layout Standard +The development of an error checking layer was weighed against the implementatio +n of TCP instead of UDP, thus losing some speed. + Even though speed was lost, TCP was chosen due to the relative ease of + implementation compared to UDP. + Due to the modularity of the GGS, a UDP extension is possible by replacing + the network parts of the GGS. +\end_layout + +\begin_layout Standard +Furthermore, in a move to increase the speed of the GGS protocol the binary + BSON protocol +\begin_inset CommandInset citation +LatexCommand citet +key "bson:website" + +\end_inset + + was initially considered. + BSON is a protocol which can be used for very fast traversal of data. + The BSON protocol is however rather difficult to read in its plain format, + and no implementation has been bade for the GGS. +\end_layout + +\begin_layout Standard +The Apache Thrift +\begin_inset CommandInset citation +LatexCommand citep +key "Slee2007" + +\end_inset + + was also an alternative. + Using Thrift would mean the GGS would feature a standard protocol for network + communication. + Before finding out about Thrift, an implementation of the GGS protocol + had already been made, moving to Thrift would mean too much work. +\end_layout + +\begin_layout Standard +The use of Thrift, BSON, or other protocols can be supported quite easily + by developing protocol modules for each protocol. + No protocol modules for these protocols have however been developed during + the writing of this thesis +\end_layout + +\begin_layout Section +Design choices +\begin_inset Note Note +status open + +\begin_layout Plain Layout +This section is wrongly placed +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +When designing concurrent applications, it is useful to picture them as + real world scenarios, and to model each actor as a real world process. + A real world process is a process which performs some action in the real + world, such as a mailbox receiving a letter, a door being opened, a person + translating a text, a soccer player kicking the ball, just to name a few + examples. + Since we focus on games in this project, it is suitable to model our system + as a place where games take place. + We imagined a chess club. + +\end_layout + +\begin_layout Standard +The clients pictured as green circles can be thought of as the physical + chess players. +\end_layout + +\begin_layout Standard +When a player wants to enter the our particular chess club, he must first + be let in by the doorman, called the +\emph on +Dispatcher +\emph default + in the GGS. +\end_layout + +\begin_layout Standard +He then gets a name badge, and thus becomes a +\emph on +Player +\emph default + process in the system. + He is also guided in to the lobby by the +\emph on +Coordinator +\emph default +, which has the role of the host of the chess club. +\end_layout + +\begin_layout Standard +When players wish to play against each other, they talk to the +\emph on +Coordinator +\emph default + who pairs them up, and places them at a table. + Once they have sat down at the table, they no longer need the assistance + of the +\emph on +Coordinator +\emph default +, all further communication takes place via the table. + This can be thought of as the actual chess game commencing. + +\end_layout + +\begin_layout Standard +All the moves made in the game are recorded by the table, such that the + table can restore the game in case something would happen, such as the + table tipping over, which would represent the table process crashing. +\end_layout + +\begin_layout Standard +Once a player wishes to leave a game, or the entire facility, he should + contact the +\emph on +Coordinator +\emph default +, who revokes his name badge and the +\emph on +Dispatcher +\emph default + will let the player out. +\end_layout + +\begin_layout Standard +With the information kept in the tables and the +\emph on +Coordinator +\emph default + combined, we can rebuild the entire state of the server at a different + location. + This can be thought of the chess club catching fire, and the +\emph on +Coordinator +\emph default + rounding up all the tables, running to a new location and building the + club up in the exact state it was prior to the fire. +\end_layout + +\begin_layout Chapter +Results and discussion +\begin_inset CommandInset label +LatexCommand label +name "chap:Results-and-discussion" + +\end_inset + + +\end_layout + +\begin_layout Section +Statistics +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Mention the hardware which the GGS was run on; A Thinkpad T410 wityh a core + i5 and 4GB of ram. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Important things to note are that the number of clients is not a good way + of measuring the performance of the server because the server is possible + to have a large number of clients on the server but it can not handle all + the information. + Instead the performance of the server should be measured in the number + of messages it can handle per second. +\end_layout + +\begin_layout Standard +We were able to reach 6000 messages per second on the server, which corresponds + to around 350 clients. + However soon after this mnesia printed some warnings and the clients started + to lag. + With this in mind one thing to investigate is if mnesia is the bottleneck + in the system. + Current game servers do not use databases to save their state and maybe + we can see the reason here. + Other possible bottlenecks may be the protocol, but this seems less likely + than mnesia. + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/msg_per_sec.eps + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout + +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/ping.eps + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout + +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/msg_per_secoutput.eps + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout + +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Future improvements +\end_layout + +\begin_layout Standard +The specification of the GGS prototype is huge and like many other software + projects relying on outside technologies, in time it would require a lot + of maintenance. + Therefore there are a lot of areas in which the GGS could be improved such + as performance, compatibility, ease of setup and usage. +\end_layout + +\begin_layout Subsection +Performance +\end_layout + +\begin_layout Subsubsection +Protocols +\end_layout + +\begin_layout Standard +Because of TCP being a connection oriented protocol, it is not suited for + all types of game data transfers. + Each transmission will consume more network bandwidth than connectionless + protocols like UDP and cause unnecessary load on the processor. + Therefore support for UDP would mean that more games could be run simultaneousl +y on the GGS. + Another advantage of UDP is latency being reduced. + Without having to setup a connection for each group packets of data being + sent, they will be sent instantly and therefore arrive earlier. + Latency is of highest importance in real-time games as it improves realism + and fairness in gameplay and many game developers requires the freedom + to take care of safety issues as packet losses themselves. + This concludes that UDP would be a benefit for the GGS, game developers + and players alike. +\end_layout + +\begin_layout Subsubsection +Database +\end_layout + +\begin_layout Standard +Currently Mnesia is used for game data storage. + During stress tests, Mnesia has turned out to be the bottleneck due to + data losses when too many games are played on the GGS simultaneously. + This could be prevented by replacing Mnesia with another database management + system or use Mnesia in combination with the ETS module of erlang. + ETS provides fast access to the RAM and thus Mnesia could be used less + frequently. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{ETS}}{Erlang Term Storage} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Compatibility +\end_layout + +\begin_layout Standard +GGS relies on modern technologies. + This includes the virtual machines(VM) that the GGS uses for communication + between Erlang and the GDL:s. + These specific VM:s are crucial for game developers to be able to write + games in other languages than Erlang. + Therefore it would be best for the GGS to have as many of these VM:s implemente +d as possible. + The VM:s taken into consideration so far have been unstable or incomplete + and it is possible to search for more VM:s, testing them and integrate + them into the GGS prototype. +\end_layout + +\begin_layout Subsection +Setup +\end_layout + +\begin_layout Standard +The GGS prototype installation procedure requires different configuration + and building steps and thus it is not in an acceptable release state. + An executable installation file for each supported platform would be optimal. +\end_layout + +\begin_layout Subsection* +5.3.4 Usage +\end_layout + +\begin_layout Subsubsection +Programming languages +\end_layout + +\begin_layout Standard +The GGS does not support many programming languages. + For a programming language to be compatible with the GGS, not only does + it require a VM for that specific language, but the VM must have the ability + to communicate to Erlang. + More research is needed to find VM:s with this built in functionality. + +\end_layout + +\begin_layout Subsubsection +Documentation +\end_layout + +\begin_layout Standard +To start the GGS is not self explanatory. + This together with overall usage of GGS should be documented. + The interface for usage of game developers is also in need of documentation. + Features and requirements with respect to the GGS would assist users to + know what they need in order to use the GGS and how they would benefit + of it. + The GGS does not support many programming languages nor does it have a + complete documentation. + This needs to be taken care of in future versions. +\end_layout + +\begin_layout Chapter +Conclusion +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +addcontentsline{toc}{section}{Glossary} +\end_layout + +\begin_layout Plain Layout + + +\backslash +printnomenclature +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard + +\end_layout + +\begin_layout Standard +\begin_inset CommandInset bibtex +LatexCommand bibtex +bibfiles "bibliography" +options "plainnat" + +\end_inset + + +\end_layout + +\end_body +\end_document diff --git a/not-working.lyx b/not-working.lyx new file mode 100644 index 0000000..579d6b8 --- /dev/null +++ b/not-working.lyx @@ -0,0 +1,7817 @@ +#LyX 2.0 created this file. For more info see http://www.lyx.org/ +\lyxformat 413 +\begin_document +\begin_header +\textclass report +\begin_preamble +\usepackage{indentfirst} +\usepackage{tocloft} +\usepackage{calc} +\date{} +\usepackage[section] {placeins} +\def\myClearpage{% + \ifvmode + \ifnum \@dbltopnum =\m@ne + \ifdim \pagetotal <\topskip + \hbox{}% + \fi + \fi + \fi +% \newpage + \write\m@ne{}% + \vbox{}% + \penalty -\@Mi +} +\def\myCleardoublepage{\myClearpage\if@twoside \ifodd\c@page\else + \hbox{}\if@twocolumn\hbox{}\fi\fi\fi} +\usepackage{morefloats} +\usepackage{graphicx} +\usepackage{subfig} +\usepackage{tocloft} +\renewcommand{\cftchapfont}{\bfseries} +\renewcommand{\cftchappagefont}{\bfseries} +\renewcommand{\cftchappresnum}{Chapter } +\renewcommand{\cftchapnumwidth}{6em} + +\oddsidemargin 0.5in +\textwidth 6in +\topmargin 0.0in +\textheight 8.0in +\setlength\topskip{24pt} +\footskip 0.75in + +\usepackage[compact]{titlesec} + + +\titleformat{\chapter}[display] +{\vskip-8em\normalfont\bfseries} +{\LARGE\raggedright\thechapter} +{14ex} +{\vspace{-20ex}% +\LARGE\raggedleft} +[\vspace{1ex}% +{\titlerule[1pt]}] + +\usepackage[absolute]{textpos} + +\usepackage{fancyheadings} +\pagestyle{fancy} +\lhead{\thechapter} + +\usepackage[hmargin=3cm,vmargin=3.5cm]{geometry} +\usepackage{algorithmic} +\usepackage{listings} + +\usepackage{color} +\definecolor{lightgray}{rgb}{.9,.9,.9} +\definecolor{darkgray}{rgb}{.4,.4,.4} +\definecolor{purple}{rgb}{0.65, 0.12, 0.82} + +\lstdefinelanguage{JavaScript}{ + keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break}, + keywordstyle=\color{blue}\bfseries, + ndkeywords={class, export, boolean, throw, implements, import, this}, + ndkeywordstyle=\color{darkgray}\bfseries, + identifierstyle=\color{black}, + sensitive=false, + comment=[l]{//}, + morecomment=[s]{/*}{*/}, + commentstyle=\color{purple}\ttfamily, + stringstyle=\color{red}\ttfamily, + morestring=[b]', + morestring=[b]" +} + +\lstdefinelanguage{Erlang}{ + keywords={typeof, true, false, catch, return, null, catch, switch, var, if, in, while, do, else, case, break, expose}, + keywordstyle=\color{blue}\bfseries, + ndkeywords={class, export, boolean, throw, implements, import, this,erlv8_vm, erlv8_fun_invocation +,erlv8_object}, + ndkeywordstyle=\color{darkgray}\bfseries, + identifierstyle=\color{black}, + sensitive=false, + comment=[l]{\%}, + morecomment=[s]{/*}{*/}, + commentstyle=\color{purple}\ttfamily, + stringstyle=\color{red}\ttfamily, + morestring=[b]', + morestring=[b]" +} + +\usepackage{float} + +\floatstyle{ruled} +\newfloat{code}{thp}{lop} +\floatname{code}{Code} + +\usepackage{nomencl} +\makenomenclature +\renewcommand{\nomname}{Glossary} +\end_preamble +\use_default_options true +\maintain_unincluded_children false +\language english +\language_package default +\inputencoding auto +\fontencoding global +\font_roman lmodern +\font_sans default +\font_typewriter default +\font_default_family rmdefault +\use_non_tex_fonts false +\font_sc false +\font_osf false +\font_sf_scale 100 +\font_tt_scale 100 + +\graphics default +\default_output_format default +\output_sync 0 +\bibtex_command default +\index_command default +\paperfontsize default +\spacing onehalf +\use_hyperref false +\papersize a4paper +\use_geometry false +\use_amsmath 1 +\use_esint 1 +\use_mhchem 1 +\use_mathdots 1 +\cite_engine natbib_authoryear +\use_bibtopic false +\use_indices false +\paperorientation portrait +\suppress_date false +\use_refstyle 0 +\index Index +\shortcut idx +\color #008000 +\end_index +\paperwidth 11in +\paperheight 8.5in +\leftmargin 1.25in +\topmargin 0in +\rightmargin 1in +\bottommargin 1.7in +\secnumdepth 2 +\tocdepth 2 +\paragraph_separation indent +\paragraph_indentation default +\quotes_language english +\papercolumns 1 +\papersides 1 +\paperpagestyle empty +\tracking_changes false +\output_changes false +\html_math_output 0 +\html_css_as_file 0 +\html_be_strict false +\end_header + +\begin_body + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{textblock*}{ +\backslash +paperwidth}(0mm,40mm) +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{center} +\end_layout + +\begin_layout Plain Layout + + +\backslash +includegraphics[width= +\backslash +paperwidth/2]{graphics/logo} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{center} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{textblock*} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Title +A Reliable Generic Game Server +\end_layout + +\begin_layout Author +Niklas Landin +\begin_inset Newline newline +\end_inset + +Richard Pannek +\begin_inset Newline newline +\end_inset + +Mattias Pettersson +\begin_inset Newline newline +\end_inset + +Jonatan Pålsson +\end_layout + +\begin_layout Abstract +This is the abstract! +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +pagenumbering{roman} +\end_layout + +\begin_layout Plain Layout + + +\backslash +setcounter{page}{3} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +contentsname{Table of Contents} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand{ +\backslash +cfttoctitlefont}{ +\backslash +hfill +\backslash +Large} +\backslash +renewcommand{ +\backslash +cftaftertoctitle}{ +\backslash +hfill} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +cftpartdotsep{6.6} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +cftchapdotsep{6.6} +\end_layout + +\end_inset + + +\begin_inset CommandInset toc +LatexCommand tableofcontents + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Newpage newpage +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +pagenumbering{arabic} +\end_layout + +\begin_layout Plain Layout + + +\backslash +setcounter{page}{1} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Chapter +Introduction +\end_layout + +\begin_layout Standard +Online gaming, and computer gaming in general has become an important part + in many peoples day-to day lives. + A few years ago, computer games were not at all as popular as they are + today. + With the advances in computer graphics and computer hardware today's games + are much more sophisticated then they were in the days of +\emph on +NetHack +\emph default +, +\emph on +Zork, +\emph default +or +\emph on +Pacman. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Zork}}{A textual computer game developed by students at MIT} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Pacman}}{An early graphical computer game developed by Namco} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{NetHack}}{An early computer game developed by the NetHack team, arguably + the oldest computer game still in development} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The early computer games featured simple, or no graphics at all +\begin_inset CommandInset citation +LatexCommand citet +key "nethack:website" + +\end_inset + +. + The games often took place in a textual world, leaving the task of picturing + the world up to the player. + Multi-player games were not as common as they are today, whereas most games + today are expected to have a multi-player mode, most early games did not. +\end_layout + +\begin_layout Standard +Since these early games, the gaming industry have become much more influential + in many ways. + Many advanced in computer hardware are thought to come from pressure from + the computer game industry. + More powerful games require more powerful, and more easily available hardware +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Drop a reference to the gaming industry pressuring more advanced hardware +\end_layout + +\end_inset + +. + Due to the high entertainment value of modern computer games, gaming has + become a huge industry, where large amounts of money are invested. + The gaming industry is today, in some places even larger than the motion + picture industry. + +\begin_inset CommandInset citation +LatexCommand citet +key "esa:website,thenumbers:website" + +\end_inset + + +\end_layout + +\begin_layout Standard +Due to the increasing importance of computer gaming, more focus should be + spent on improving the quality of the gaming service. + As more and more computer games are gaining multi-player capabilities, + the demands for multiplayer networking software rises. + This thesis is about techniques for improving the quality of this networking + software. +\end_layout + +\begin_layout Standard +The reliable generic game server, hereafter known as GGS +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{GGS}}{Generic Game Server, a software for reliably hosting network + games. + The subject of this thesis.} +\end_layout + +\end_inset + +, is a computer program designed to +\emph on +host +\emph default + network games on one or more server computers. + Hosting, in a network software setting, means allowing client software + connect to the server software, for the purpose of utilizing services provided + by the server. + The GGS software provides games as a service, and the clients connecting + to the GGS can play these games on the GGS. +\end_layout + +\begin_layout Standard +The idea of game servers is not new, network games have been played for + decades. + Early, popular examples of network games include the +\emph on +Quake +\emph default + series, or the +\emph on +Doom +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout + +\emph on +Come up w/ better game +\end_layout + +\end_inset + + +\emph default + games. + Newer examples of network games include +\emph on +World of Warcraft +\emph default +, and +\emph on +Counter-Strike +\emph default +. + The difference between the GGS and the servers for these games is that + the servers for Doom, Quake, and the others listed, were designed with + these specific games in mind. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Quake}}{A first person shooter series developed by ID software. + The series consists of four games.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Doom}}{A first person shooter series developed by ID software. + The series consists of three games.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{World of Warcraft}}{A MMORPG game developed by Blizzard. + The world's most popular MMORPG by subscriber count.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Counter-Strike}}{A multiplayer first person shooter game, popular + in E-Sports.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Framework}}{A supporting structure, the GGS is a framework for developing + network games} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{First-person shooter}}{A game in which centers around gun combat + from the first person perspective.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{MMORPG}}{Massively multiplayer online role playing game. + An online game with several thousand participants.} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +What GGS does is to provide a +\emph on +generic +\emph default + framework for developing network games. + The framework is generic in the sense that it is not bound to a specific + game. + There are many different types of games, some are inherently more time + sensitive than others, strategy games are examples of games which are not + very sensitive to time delays, first-person shooters however, can be very + sensitive. +\end_layout + +\begin_layout Standard +The generic nature of the GGS allows the creation of many different types + of games, the motivation behind this is to remove the necessity of writing + new game servers when developing new games. +\end_layout + +\begin_layout Standard +The GGS is in addition to being generic, also +\emph on +reliable +\emph default + in the sense that the gaming service provided is consistent and available. + A consistent and available server is a server that handles hardware failures + and software failures gracefully. + In the event of a component breaking within the GGS, the error is handled + by fault recovery processes, thereby creating a more reliable system. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Hardware failiure}}{A failiure in hardware (hard drive, memory, processor +, etc) which causes a system to stop functioning} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Software failiure}}{A failiure in software (the GGS, the operating + system, etc) which causes a system to stop functioning} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Background +\end_layout + +\begin_layout Standard +The game industry is a quickly growing industry where the need for new technique +s are large. + One specific section where the development has stalled is the game server + section. +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + + The existing game servers are functional but they lack good fault tolerance + and the ability to scale well +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + +. + Users will notice this in low uptime and many crashes. + This is a problem that has existed and been resolved in other industries. + In the telecom industry solutions to similar problems have been found. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{The nine nines}}{A common goal for availability in the telecom business. + A system with nine nines of availability is available 99.999999999% of the + time} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Downtime}}{The amount of time a system is unavailable and does not + function} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Uptime}}{The amount of time a system is available and functions} +\end_layout + +\end_inset + +A common figure often used in telecoms is that of +\emph on +the nine nines +\emph default +, referring to +\begin_inset Formula $99.999999999\%$ +\end_inset + + of availability, or rougly +\begin_inset Formula $15ms$ +\end_inset + + downtime in a year +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + +. + The level of instability and bad fault tolerance seen in the game server + industry would not have been accepted in the telecoms industry. + This level of instability should not be accepted in the game server industry + either. + An unavailabvle phone system could potentially have life threatening consequenc +es, leaving the public unable to contant emergency services. + The same can not be said about an unavailable game server. + The statement that game servers are less important than phone systems is + not a reason not to draw wisdom from what the telecoms have already learnt. +\end_layout + +\begin_layout Standard +Moving back to the gaming industry. + The main reason to develop reliable servers are monetary, it is important + for game companies to expand its customer base. + Reliable game servers are one improvement that will create a good image + of a company. + In general the downtime of game servers is much higher than the downtime + of telecom system +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed... +\end_layout + +\end_inset + +. + The structure of the system is similar in many ways and it should be possible + to reuse solutions from the telecom system to improve game servers. + +\end_layout + +\begin_layout Standard +In the current state game servers are developed on a per-game basis, in + many cases this seems like a bad solution. + Developers of network game need to understand network programming. + A way to change this is a generic game server which give the game developers + a server which they implement their game towards. + This approach would not only make it easier to develop network games, it + would also allow games in different programming languages to be implemented + using the same server. +\end_layout + +\begin_layout Standard +Some factors key to the development of GGS have been isolated. + Many of these come from the telecom sector. + The factors are +\emph on +scalability, fault tolerance +\emph default +and being +\emph on +generic +\emph default +. + These terms are defined below. +\end_layout + +\begin_layout Standard +Scalability (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Scalability" + +\end_inset + +) in computer science is a large topic and is commonly divided into sub-fields, + two of which are +\emph on +structural scalability +\emph default + and +\emph on +load scalability +\emph default + +\begin_inset CommandInset citation +LatexCommand citet +key "Bondi:2000:CSI:350391.350432" + +\end_inset + +. + These two issues are addressed in this thesis. + Structural scalability means expanding an architecture, e.g. + adding nodes to a system without requiring modification of the system. + Load scalability means using the available resources in a way which allows + handling increasing load, e.g more users, gracefully. +\end_layout + +\begin_layout Standard +Fault tolerance (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Fault-Tolerance" + +\end_inset + +) is used to raise the level of +\emph on +dependability +\emph default + in a system, so that the dependability is high even in presence of errors. + Dependability is defined as the statistical probability of the system functioni +ng as intended at a given point in time. + Fault tolerance is defined as the property of a system to always follow + a specification, even in the presence of errors. + The specification could take the form of error handling procedures which + activate when an error occurs. + This means that a fault tolerant, dependable system, will have a very high + probability of functioning at a given point in time, and is exactly what + is desired. + +\begin_inset CommandInset citation +LatexCommand citet +key "Gartner:1999:FFD:311531.311532" + +\end_inset + + +\end_layout + +\begin_layout Standard +A generic (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Generic" + +\end_inset + +) game server has to be able to run different client-server network games + regardless of the platform the clients are running on. + It runs network games of different type. + A very rough separation of games is real time games and turn based games. +\end_layout + +\begin_layout Standard +The server behaves in a way similar to an application server, but is designed + to help running games. + An application server provides processing ability and time, therefore it + is different from a file- or print-server, which only serves resources + to the clients. +\end_layout + +\begin_layout Standard +The most common type of application servers are web servers, where you run + a web application within the server. + The application server provides an environment and interfaces to the outer + world, in which applications run. + Hooks and helpers are provided to use the resources of the server. + Some examples for web application servers are the +\emph on +Glassfish +\emph default + server which allows running applications written in Java or the +\emph on +Google App Engine +\emph default + where you can run applications written in Python or some language which + runs in the +\emph on +Java Virtual Machine +\emph default +. + An example of an application server not powering web applications, but + instead regular business logic, is Oracle’s +\emph on +TUXEDO +\emph default + application server, which can be used to run applications written in COBOL, + C++ and other languages. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SQL}}{Structured Query Language, a computer language common in querying + certain databases} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{JavaScript}}{A programming language originally developed by Netscape, + common in web programming} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{COBOL}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{C++}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Java}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{AXD301}}{Telephone switch developed by Ericsson} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Erlang}}{A concurrent programming language, often used for telecom + applications. + The main language of the GGS} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +A database server can also be seen as an application server. + Scripts, for example SQL queries or JavaScript, are sent to the server, + which runs them and returns the evaluated data to the clients. + +\end_layout + +\begin_layout Standard +One purpose of this thesis is to investigate how we can make a game server + as generic as possible. + Some important helpers are discussed, such as abstraction of the network + layer, data store and game specific features. + +\end_layout + +\begin_layout Standard +As an aid in discussing the theoretical parts of the GGS a prototype has + been developed. + The prototype does not feature all of the characteristics described in + this thesis. + A selection has been made among the features, and the most important ones + have been implemented either full or in part in the prototype. +\end_layout + +\begin_layout Standard +The choice of implementation language for the prototype of the GGS was made + with inspiration from the telecom industry. + The Erlang language was developed by the telecom company Ericsson to develop + highly available and dependable telecom switches. + One of the most reliable systems ever developed by Ericsson, the AXD301 + was developed using Erlang. + The AXD301 is also possibly has the largest code base even written in a + functional language +\begin_inset CommandInset citation +LatexCommand citep +key "Armstrong03" + +\end_inset + +. + The same language is used to develop the prototype of the GGS. + Usage of Erlang in the GGS is discussed in further detail in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:The-usage-of-erlang" + +\end_inset + +. + Chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Implementation-of-a" + +\end_inset + + provides a description of the prototype developed for this thesis. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +We could go on and on about erlang.. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Purpose +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout +The purpose of the GGS project. + What is the purpose of creating a fault tolerant server, why is it generic, + and what good does it do to have a scalable system? In the background, + we should give the motivations behind creating this software, but here + we should outline why the software is needed. + This section should be shortened, and the bulk of the text should be moved + to theory or background. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The purpose of creating a generic and fault tolerant game server is to provide + a good framework for the development of many different types of games. + Allowing the system to scale up and down is a powerful way to maximize + the usage of physical resources. + By scaling up to new machines when load increases, and scaling down from + machines when load decreases costs and energy consumption can be optimized. +\end_layout + +\begin_layout Standard +Fault tolerance is important for the GGS to create a reliable service. + The purpose of a reliable game server is to provide a consistent service + to people using the server. + Going back to the telecom example, the purpose of creating a reliable telecom + system is to allow calls, possibly emergency calls, at any time. + Should the telecom network be unavailable at any time, emergency services + may become unavailable, furthermore the consumer image of the telecom system + degrades. +\end_layout + +\begin_layout Standard +Returning to the game industry, emergency services will not be contacted + using a game server, however an unavailable server will degrade the consumer + image of the system. + Consider an online casino company. + The online casino company's servers must be available at all times to allow + customers to play. + If the servers are unavailable, customers can not play, and the company + loses money. + In this scenario, an unavailable server can be compared to a closed real-world + casino. +\end_layout + +\begin_layout Section +Challenges in developing the prototype +\end_layout + +\begin_layout Standard +The word +\emph on +generic +\emph default + in the name of the GGS implies that the system is able to run a very broad + range of different code, for instance code wrote in different programming + languages, besides a broad range of different game types. + To support this, a virtual machine (VM) for each +\emph on +game development language +\emph default + (hereafter GDL for brevity) is used. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{GDL}}{Game Development Language, the language used to program games + in the GGS} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{VM}}{Virtual Machine} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +No hard limit has been set on which languages can be used for game development + on the GGS, but there are several factors which decide the feasibility + of a language: +\end_layout + +\begin_layout Itemize +How well it integrates with Erlang, which is used in the core the GGS system + +\end_layout + +\begin_layout Itemize +How easy it is to send messages to the virtual machine of the GDL from the + GGS +\end_layout + +\begin_layout Itemize +How easy it is to send messages from the GDL VM to the GGS +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add more like threads, events, etc. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Internally, the GDL VM needs to interface with the GGS to make use of the + helpers and tools that the GGS provides. + Thus an internal API has to be designed for use in interacting with the + GGS. + This API is ideally completely independent of the GDL, and reusable for + any GDL. +\end_layout + +\begin_layout Standard +The communication with gaming clients has to take place over a protocol. + Ideally a standard protocol should be used, in order to shorten the learning + curve for developers, and also make the system as a whole less obscure. + A large challenge during this project is to decide whether an existing + protocol can be used, and if not, how a new protocol can be designed which + performs technically as desired, while still being familiar enough to existing + developers. +\end_layout + +\begin_layout Standard +A great deal of work is devoted to make the GGS +\emph on +reliable +\emph default +. + This includes ensuring that the system scales well, and to make sure it + is fault tolerant. + In order to facilitate scalability, we need a storage platform which is + accessible and consistent among all of the GGS, this is also investigated. +\end_layout + +\begin_layout Section +Limitations of the prototype +\end_layout + +\begin_layout Standard +The implementation of the GGS protocol, together with storage possibilities, + server capacity, and game language support imposes some limitations on + the project. + To get a functional prototype some limits must be set on the types games + that can be played on the prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{UDP}}{User Datagram Protocol, a connectionless networking protocol} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{TCP}}{Transmission Control Protocol, a streaming network protocol} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The UDP protocol is not supported for communication between client and server. + The TCP protocol was chosen in favour of UDP, due to the fact that the + implementation process using TCP was faster than if UDP would have been + used. + UDP is generally considered to be faster than TCP for the transfer of game + (and other) related data, this is discussed in more depth in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Choice-of-network" + +\end_inset + +. + In short, the decision of using TCP means that games that requires a high + speed protocol will not be supported by the GGS prototype. + Another limitation necessary to set on the system is the possibility to + have huge game worlds due to the implementation of the scaling mechanism + in the prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Latency}}{A measure of delay, often measured in milliseconds} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +In real time games all players are playing together at the same time. + Latency is a huge problem in real time games, a typical round trip time + for such games are one of +\begin_inset Formula $50$ +\end_inset + + to +\begin_inset Formula $150ms$ +\end_inset + + and everything above +\begin_inset Formula $200ms$ +\end_inset + + is reported to be intolerable +\begin_inset CommandInset citation +LatexCommand citet +key "Farber:2002:NGT:566500.566508" + +\end_inset + +. + Latency sensitive games include most of the first person shooters with + multiplayer ability, for example +\emph on +Counter Strike +\emph default + or massively multiplayer online role playing games (MMORPG:s), for example + +\emph on +World of Warcraft +\emph default +. +\end_layout + +\begin_layout Standard +In turn based games each player has to wait for their turn. + Latency is not a problem since the gameplay does not require fast interactions + among the players, long round trip times will not be noticed. + Examples of turn based games include board and card games, as well as multiplay +er games like +\emph on +Jeopardy +\emph default +. + Both game types have varying difficulties and needs when it comes to implementi +ng them, a Generic Game Server should address all of them and help the developer + to accomplish his goal. +\end_layout + +\begin_layout Standard +Due to the limited capability of threading in many GDL VM:s, the GGS prototype + will not support MMORPG:s. +\end_layout + +\begin_layout Standard +The implementation of the GGS described in this thesis is only a small prototype + and tests will be performed on simple games like pong or chess, thus there + are no need to implement more advanced features in the system. + Note that these limitations only apply for the prototype of the project, + and that further developments to the GGS could be to implement these features. +\end_layout + +\begin_layout Section +Method +\end_layout + +\begin_layout Standard +A prototype was developed early on in the project to carry out experiments. + Using this prototype, the system was divided into modules. + A demand specification was created, using this specification, the modules + were easily identifiable. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Module}}{A part of a larger system} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The first prototype of the GGS consisted of simple modules, however, due + to the separation of concerns among the modules, they were easily independently + modified and improved. +\end_layout + +\begin_layout Standard +Once the basic structure of the GGS had been established, the first prototype + was removed, remaining was the structure of the modules and the internal + flow of the application. + This could be seen as an interative workflow, with the first prototype + being the first iteration. + The second iteration later became the final result of the GGS. +\end_layout + +\begin_layout Standard +The layout of the GGS is both layered and modular. + The first layer handles the most primitive data and produces a higher level + representation of the data, passing it along to different modules of the + GGS. + The modular structure of the GGS plays an important role in making the + system fault tolerant. + The approach to fault tolerance is by replication, and restarting the faulting + modules with the last known good data. +\end_layout + +\begin_layout Standard +An informal specification and list of requirements of the system was outlined + early on in the project. + Usaility goals for developers were set. + During the project several demo applications were constructed, by constructing + these applications, the usability goals were enforced. +\end_layout + +\begin_layout Chapter +Theory behind the GGS +\begin_inset CommandInset label +LatexCommand label +name "cha:Theory" + +\end_inset + + +\end_layout + +\begin_layout Standard +In this chapter, the theory behind the techniques used in the GGS are discussed. + Performance issues and the measuring of performance is discussed. + Benchmarking techniques are discussed. + The options when choosing network protocols are given, along with a discussion + of each alternative. + Finally, an overview of scalability, fault tolerance and availability are + presented. +\end_layout + +\begin_layout Section +Design of the GGS system +\begin_inset CommandInset label +LatexCommand label +name "sec:Design-of-the" + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS is modeled after a real world system performing much of the same + duties as GGS. + This is common practice +\begin_inset CommandInset citation +LatexCommand citep +key "armstrong2011" + +\end_inset + + in the computer software world, to understand complex problems more easily. + While there may not always be a real world example of a system performing + the exact duties of the system being modeled in the computer, it is often + easier to create and analyze requirements for real world systems and processes + than systems existing solely in a computer. + The requirements and limitations imposed on the real-world system can, + using the proper tools, be transferred in to the software. +\end_layout + +\begin_layout Standard +The real world system chosen for the GGS is a +\begin_inset Quotes eld +\end_inset + +Chess club +\begin_inset Quotes erd +\end_inset + + - a building where chess players can meet and play chess. + Since a real-world scenario is readily available, and to such a large extent + resembles the computer software required for the GGS, the next step in + developing the GGS system is to duplicate this real world scenario in a + software setting. +\end_layout + +\begin_layout Standard +Some requirements, limitations and additions were made to the chess club + system, so that the system would more easily and efficiently be replicated + in a software setting. +\end_layout + +\begin_layout Standard +In the text below, two examples will be presented. + On example is that of a real-world chess club, in which players meet to + play chess against each other, the other example is the GGS, and how it + corresponds to this chess club. + +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/theory_layout.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:theory-layout" + +\end_inset + +The layout of a physical +\begin_inset Quotes eld +\end_inset + +Chess club +\begin_inset Quotes erd +\end_inset + + with two players (P) sitting by each chess table (Table), a coordinator + keeps track of all moves and players in the building. + A player has to pass by the entrance to enter or exit the building. + The building is represented by the outermost box. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +In figure +\begin_inset CommandInset ref +LatexCommand vref +reference "fig:theory-layout" + +\end_inset + + a graphical representation for the chess club is presented. + The club is seen from above. + The outermost box represents the building. + In the GGS setting, the building would represent one instance of GGS. + Several buildings linked together would represent a cluster of GGS instances. + In order for a player (the P symbol in the graphic) to enter the theoretical + chess club, the player must pass by the entrance. + By having each player pass by the entrance, a tally +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Does this mean what I think it does? +\begin_inset Quotes eld +\end_inset + +Räkning +\begin_inset Quotes erd +\end_inset + + ? +\end_layout + +\end_inset + + can be kept, ensuring that there are not too many players within the building. + In the GGS setting, too many players entering would mean too many connections + have been accepted by the GGS system, and that the structure of the system + thus must be modified, adding additional servers. +\end_layout + +\begin_layout Standard +Once a player has been allowed in to the chess club the player is greeted + by the host of the chess club, in the GGS setting represented by the +\emph on +Coordinator +\emph default +, and is seated by a table. + The coordinator keeps track of all the players in the building, and all + moved made by the players. + The information available to the coordinator means that cheating can be + monitored and book keeping can be performed by this entity. +\end_layout + +\begin_layout Standard +Moves by players are made using the tables present in the chess club. + Every game is isolated to a table, just as expected. + This means that communication during a game only has to pass by the players + of that particular game, and the coordinator, making sure that no cheating + takes place. +\end_layout + +\begin_layout Standard +This isolation of the games play an important part in many properties of + the GGS, the isolation means that games can for example be transferred + among different chess clubs, furthermore, if cheating takes place, corruption + can only occur in the particular table where it was found, and can not + spread. +\end_layout + +\begin_layout Standard +Moving chess players from one location to another is one alteration made + to the real world chess club system to make the system more appropriate + for a software setting. + Allowing games to be transferred is not a property usually desired in a + real world chess club, where transferring players would mean moving the + players from one building to another. + In the software setting, moving players means moving the game processes + from one system to another, perhaps to balance the system load. + This transfer of players can occur transparently, without notifying the + players. +\end_layout + +\begin_layout Standard +The simplified life cycle of a game in GGS can be viewed using algorithm + +\begin_inset CommandInset ref +LatexCommand vref +reference "alg:game-lifecycle" + +\end_inset + +. + To make this life cycle as efficient and useful as possible, the scalability, + fault tolerant and generic traits are added to the GGS. + These are not shown in the algorithm, as these traits are tools in making + the algorithm behaves as efficient as possible, and are not the main focus + when studying the life cycle of a game. +\end_layout + +\begin_layout Standard +The limits imposed in +\begin_inset CommandInset ref +LatexCommand vref +reference "alg:game-lifecycle" + +\end_inset + + are arbitrary for this example, there are no limits in the GGS on the number + of players connecting, for example. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{algorithmic}[1] +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +newcommand{ +\backslash +INDSTATE}[1][1]{ +\backslash +STATE +\backslash +hspace{#1 +\backslash +algorithmicindent}} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +while +\series default + +\begin_inset Formula $players<2$ +\end_inset + +: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + +\series bold +if +\series default + a player connects, call +\emph on +connected +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +while +\series default +the game commences: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +call the function +\emph on +game +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +when +\series default + the game has stopped +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +call the function +\emph on +endGame +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +function +\series default +connected: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +assign the new player an id +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +alert the coordinator of the new player +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + +\series bold +if +\series default + a free table does not exist: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE[2] +\end_layout + +\end_inset + +the coordinator creates a new table +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +the coordinator places the player by the table, and begins watching the + player +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +function +\series default + game +\series bold +: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + perform game-specific functions. + In chess, the rules of chess are placed here +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +function +\series default +endGame: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +alert the coordinator, de-registering the players +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +disconnect the players from the system, freeing system resources +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{algorithmic} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:game-lifecycle" + +\end_inset + +A very simple example of the flow through the GGS system when a game played. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Performance +\end_layout + +\begin_layout Standard +There are many ways in which performance could be measured. + For the clients, time and response times are useful measurements in time + critical settings. + In non-time critical settings, the reliability of message delivery may + be an even more important factor than speed. +\end_layout + +\begin_layout Standard +In a first person shooter game, the speed of delivery of messages is essential. + Failure to deliver messages in time results in choppy gameplay for the + players. + In strategy games, the reliability of delivery may be more important than + the speed, since the game is not perceieved as choppy even if the messages + are delayed. +\end_layout + +\begin_layout Standard +For someone operating a GGS, it is perhaps more interesting to measure the + system load, memory consumption, energy consumption and network saturation. + These topics are discussed in theory in this section. + The practical results for the prototype is discussed in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Implementation-of-a" + +\end_inset + +. +\end_layout + +\begin_layout Subsection +Performance measurements +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Tue apr 26, 9:15. + Continue from here on. + Discuss which results we may expect in a fully fledged GGS system. + What impedes the speeds, what raises the CPU load (and therefore the temperetur +es & power consumption). + What factors are there in the network saturation problem? +\end_layout + +\begin_layout Plain Layout +Which games are affected by what, and what does this mean for the number + of players a GGS can handle? +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +How many players can we have on a server? Performance differences between + games? e.g can one game have thousands players on a server and another only + have hundreds? Questions +\end_layout + +\begin_layout Standard +In the current state game servers is coded for each game that needs it, + in many cases this seems like a bad solution. + Developers that want to make a network game need to understand network + programming. + A way to change this is a generic game server which give the game developers + a server which they implement their game towards. + This approach would not only make it easier to develop network games, it + would also allow games in different programming languages to be implemented + using the same server. + to be discussed here. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Create a game with several thousand players, see how our server scales, + how can we improve the performance? Sharding isn’t very nice.. + alternatives? Improve the speed of sharding? +\end_layout + +\begin_layout Itemize +See how the server scales +\end_layout + +\begin_deeper +\begin_layout Itemize +When adding many clients +\end_layout + +\begin_deeper +\begin_layout Itemize +Measure in +\begin_inset Formula $ms$ +\end_inset + + (ping to clients) +\end_layout + +\begin_layout Itemize +measure in system load +\end_layout + +\begin_layout Itemize +Measure in loss of messages +\end_layout + +\begin_layout Itemize +Measure in # of timeouts? (if any??) +\end_layout + +\begin_layout Itemize +Measure in time-to-crash +\end_layout + +\end_deeper +\begin_layout Itemize +When adding new machines to the pool +\end_layout + +\begin_deeper +\begin_layout Itemize +% increase of performance per machine +\end_layout + +\end_deeper +\begin_layout Itemize +Single-core CPU vs multi-core CPU +\end_layout + +\begin_deeper +\begin_layout Itemize +It's very important to scale well on multi-core systems, since this is where + the industry is going. + Multicore is the future. +\end_layout + +\end_deeper +\end_deeper +\begin_layout Plain Layout +Find reference on how to benchmark distributed, multiprocess systems +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Choice of network protocol +\begin_inset CommandInset label +LatexCommand label +name "sec:Choice-of-network" + +\end_inset + + +\end_layout + +\begin_layout Standard +There are two main ways in which computer communication over the Internet + usually takes place; TCP, UDP are known network layer protocols and HTTP + is the most prominent application layer protocol. + The transport layer protocols, are commonly used to transport application + layer protocols, such as HTTP. + TCP and UDP can not be used on their own, without an application layer + protocol on top. + Application layer protocols such as HTTP on the other hand needs a transport + layer protocol in order to work. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{HTTP}}{Hyper Text Transport Protocol, a network protocol commonly + used to deliver web pages} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +HTTP +\end_layout + +\begin_layout Standard +Since HTTP is so widely used on the Internet today in web servers, it is + available on most Internet connected devices. + This means that if HTTP is used in the GGS, firewalls will not pose problems, + which is a great benefit. + However, due to the intended usage of HTTP in web servers, the protocol + was designed to be stateless and client-initiated. + In order to maintain a state during a game session using HTTP, some sort + of token would have to be passed between client and server at all times, + much like how a web server works. + These facts combined makes HTTP unsuitable for our purposes, since the + GGS requires a state to be maintained throughout a session, and also needs + to push data from the server to clients without the clients requesting + data. + It should also be mentioned that HTTP uses the TCP protocol for transport, + and what is said about TCP also applies to HTTP. + +\end_layout + +\begin_layout Subsection +UDP +\end_layout + +\begin_layout Standard +Many online games use UDP as the carrier for their application layer protocol. + UDP moves data across a network very quickly, however it does not ensure + that the data transferred arrives in consistent manner. + Data sent via UDP may be repeated, lost or out of order. + To ensure the data transferred is in good shape, some sort of error checking + mechanisms must be implemented. + UDP is a good choice for applications where it is more important that data + arrives in a timely manner than that all data arrives undamaged, it is + thus very suitable for media streaming, for example. + In the GGS reliability of transfer was chosen before the speed of the transfer, + ruling out UDP as the transport later protocol. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Perhaps we should only say that we chose TCP just for our GGS prototype + and why. + If we leave it like that it seems that we think it is not suitable. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +TCP +\end_layout + +\begin_layout Standard +For reliable transfers, TCP is often used on the Internet. + Built in to the protocol are the error checking and correction mechanisms + missing in UDP. + This ensures the consistency of data, but also makes the transfer slower + than if UDP had been used. + In the GGS, data consistency is more important than transfer speeds, and + thus TCP is a better alternative than UDP. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Same here it is simply not true for a generic server to chose one or the + other. + We should rephrase it so it is clear that we only state it about the GGS + prototype. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Generic +\begin_inset CommandInset label +LatexCommand label +name "sec:Generic" + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS is a game server. + It was made with a desire to be suitable for any kind of game. + Any game with a client-server behaviour should be perfectly suited for + GGS. + A game should not only be able to vary in terms of genre, graphics, gameplay + etc, but also in the way the game is implemented. + Such as different programming languages. + The GGS should be OS independent and run on Windows, OSX and Linux. + The GGS can be run as a listen server on the players computer and host + games locally. + It could also be a dedicated server running on independent hardware. + It is meant to run any game in any environment in any way desired, therefor + being as generic as possible. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Bad name of the chapter, but here we should give the theory of how the server + is generic +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Fault Tolerance +\begin_inset CommandInset label +LatexCommand label +name "sec:Fault-Tolerance" + +\end_inset + + +\end_layout + +\begin_layout Standard +Fault tolerance is an important factor in all servers, a server that is + fault tolerant should be able to follow a given specification when parts + of the system failures. + This means that fault tolerance is different in each system depending on + what specification they have. + A system could be fault tolerant in different aspects, one is where the + system is guaranteed to be available but not safe and it could also be + reversed, that the system is safe but not guaranteed to be available. + Depending on the system one property may be more important(some example + here). + A system could also have non existent fault tolerance or it could be both + safe and guaranteed to be available. + It should be noted that it is not possible to achieve complete fault tolerance, + a system will always have a certain risk of failure. + With this in mind the goal is to make the GGS prototype as fault tolerant + as possible. +\end_layout + +\begin_layout Standard +In order to make the GGS prototype fault tolerant the programming language + Erlang has been used. + Erlang will not guarantee a fault tolerant system but it has features that + support and encourage the development of fault tolerant systems. + In the GGS it is important that the system overall is fault tolerant. + Crashes of the whole system should be avoided as this would make the system + unusable for a time. + By using supervisor structures it is possible to crash and restart small + parts of the system, this is convenient as fault can be handled within + small modules thus never forcing a crash of the system. +\end_layout + +\begin_layout Standard +The need for fault tolerance in game servers is not as obvious as it may + be for other typ of servers. + In general all servers strive to be fault tolerant as fault tolerance means + more uptime and a safer system. + This applies to game servers as well, in brief good fault tolerance is + a way of satisfying customers. + In general, game servers differ from many other fault tolerant systems + in that high-availability is more important than the safety of the system. + For example a simple calculation error will not be critical for a game + server but it may be in a life-critical system and then it is better that + the system crashes than works with the faulty data. + There are cases where safety may be critical in game servers, one example + is in games where in-game money exist. +\end_layout + +\begin_layout Subsubsection +Performance penalties +\end_layout + +\begin_layout Section +Availability +\begin_inset CommandInset label +LatexCommand label +name "sec:Availability" + +\end_inset + + +\end_layout + +\begin_layout Standard +One important factor of any server is the availability. + A server to which you are unable to connect to is an useless server. + Other then within telecommunication, their uptime is of about 99,9999999%, + the game developer community has not approached this problem very genuinely + yet so there is much room for improvement. +\end_layout + +\begin_layout Standard +There are several good papers on how to migrate whole virtual machines among + nodes to replicate them +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add more information about that +\end_layout + +\end_inset + + but for the GGS a different approach has been chosen. + Instead of just duplicating a virtual machine, the programming language + Erlang has been used which offers several features to increase the availability. + Some of them are +\emph on +hot code replacement +\emph default +, where code can be updated while the application is running and without + the need to restart it, the +\emph on +supervisor structure +\emph default + provided by +\emph on +OTP +\emph default + and the inter node and process communication via +\emph on +messages +\emph default + instead of shared memory. + We will discuss each of them later on. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Supervisor}}{A process monitoring and hadning crashes in other processes} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Scalability +\begin_inset CommandInset label +LatexCommand label +name "sec:Scalability" + +\end_inset + + +\end_layout + +\begin_layout Standard +Each instance of the GGS contains several tables. + Each table is an isolated instance of a game, for example a chess game + or a poker game. + The way that the GGS scales is to distribute these tables on different + servers. + In many games it is not necessary for a player to move among tables during + games. + This is for example not a common occurrence in chess, where it would be + represented as a player standing up from her current table and sitting + down at a new table, all within the same game session. + Therefore, the main focus of the GGS is not to move players among tables, + but to keep a player in a table, and to start new tables instead. + When a server has reached a certain number of players the performance will + start to decrease. + To avoid this the GGS will start new tables on another server, using this + technique the players will be close to evenly distributed among the servers. + It is important to investigate and find out how many players that are optimal + for each server. + This approach makes it possible to use all resources with moderate load, + instead of having some resources with heavy load and some with almost no + load. +\end_layout + +\begin_layout Standard +As mentioned in the purpose section there are two different types of scalability +, structural scalability and load scalability. + To make the GGS scalable both types of scalability are needed. + Structural scalability means in our case that it should be possible to + add more servers to an existing cluster of servers. + By adding more servers the limits of how many users a system can have is + increased. + Load scalability in contrast to structural scalability is not about how + to increase the actual limits of the system. + Instead it means how good the system handles increased load. + The GGS should be able to scale well in both categories. +\end_layout + +\begin_layout Subsection +Load balancing +\end_layout + +\begin_layout Standard +The need for load balancing varies among different kind of systems. + Small systems that only use one or a couple of servers can cope with a + simple implementation of it, while in large systems it is critical to have + extensive and well working load balancing. + The need also depends on what kind of server structure that the system + works on. + A static structure where the number of servers are predefined or a dynamic + structure where the number varies. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Amazon EC2}}{A cloud computation service} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Load balancing and scaling is difficult in different scenarios. + When running in a separate server park, there are a set number of servers + available, this means that an even distribution on all servers is preferable. + When running the GGS in a cloud, such as Amazon EC2, it is possible to + add an almost infinite number of servers as execution goes on. + In this cloud setting, it may be more important to evenly distribute load + on newly added servers. +\end_layout + +\begin_layout Standard +Two methods of balancing load (increasing structure): +\end_layout + +\begin_layout Itemize +Fill up the capacity of one server completely, and then move over to the + next server +\end_layout + +\begin_layout Itemize +Evenly distribute all clients to all servers from the beginning, when load + becomes too high on all of them, then comes a new problem: +\end_layout + +\begin_deeper +\begin_layout Itemize +How do we distribute load on these new servers? +\end_layout + +\end_deeper +\begin_layout Standard +Load balancing is a key component to achieve scalability in network systems. + The GGS is a good example of a system that needs to be scalable, to attain + this load balancing is necessary. + Optimization of the load balancing for a system is an important task to + provide a stable and fast load balancer. + There are certain persistence problems that can occur with load balancing, + if a player moves from a server to another data loss may occur. + This is an important aspect to consider when the load balancer is designed + and implemented. +\end_layout + +\begin_layout Standard +Load balancing can often be implemented using dedicated software, this means + that in many applications load balancing may not be implemented because + it already exist functional solutions. + This depends on what specific needs the system have and a minor goal of + the project is to analyze whether the GGS project can use existing load + balancing tools or if it is necessary to implement load balancing in the + project. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Because P2P game architectures are a constant goal for cheaters and because + “Cheating is a major concern in network games as it degrades the experience + of the majority of players who are honest” and preventing cheating in P2P + game architectures is very difficult game developers try to use Client + - Server architectures which have a natural problem to scale. + In this paper we want to show some strategies to achieve scalability. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +UUID +\begin_inset CommandInset label +LatexCommand label +name "sub:UUID" + +\end_inset + + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{UUID}}{Universally Unique Identifier} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{algorithmic}[1] +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +newcommand{ +\backslash +INDSTATE}[1][1]{ +\backslash +STATE +\backslash +hspace{#1 +\backslash +algorithmicindent}} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + +global variable +\begin_inset Formula $state:=0$ +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +function +\series default +unique +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + +\begin_inset Formula $state:=state+1$ +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + +\series bold +return +\begin_inset Formula $state$ +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{algorithmic} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-simple-generator" + +\end_inset + +A simple (insufficient) generator for identifiers +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Inside the GGS, everything has a unique identifier. + There are identifiers for players, tables and other resources. + When players communicate amongst each other, or communicate with tables, + they need to be able to uniquely identify all of these resources. + Within one machine, this is mostly not a problem. + A simple system with a counter can be imagined, where each request for + a new ID increments the previous identifier and returns the new identifier + based off the old one, see algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + +. + This solution poses problems when dealing with concurrent and distributed + systems. + In concurrent systems, the simple solution in algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + + may yield non-unique identifiers due to the lack of mutual exclusion. +\end_layout + +\begin_layout Standard +The obvious solution to this problem is to ensure mutual exclusion by using + some sort of lock, which may work well in many concurrent systems. + In a distributed system, this lock, along with the state, would have to + be distributed. + If the lock is not distributed, no guarantee can be made that two nodes + in the distributed system do not generate the same number. + A different approach is to give each node the ability to generate Universally + Unique Identifiers (UUID), where the state of one machine does not interfere + with the state of another. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{MAC Address}}{Media Access Control address, used to identify network + cards} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SHA-1}}{Cryptigraphic hash function, designed by the National Security + Agency (NSA)} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +According to +\begin_inset CommandInset citation +LatexCommand citet +key "Leach98uuidsand" + +\end_inset + +, +\begin_inset Quotes eld +\end_inset + +A UUID is 128 bits long, and if generated according to the one of the mechanisms + in this document, is either guaranteed to be different from all other UUIDs/GUI +Ds generated until 3400 A.D. + or extremely likely to be different +\begin_inset Quotes erd +\end_inset + +. + This is accomplished by gathering several different sources of information, + such as: time, MAC addresses of network cards, and operating system data, + such as percentage of memory in use, mouse cursor position and process + ID:s. + The gathered data is then +\emph on +hashed +\emph default + +\begin_inset space ~ +\end_inset + +using an algorithm such as SHA-1. +\end_layout + +\begin_layout Standard +When using system wide unique identifiers, such as the ones generated by + algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + + with mutual exclusion, it is not possible to have identifier collisions + when recovering from network splits between the GGS clusters. + Consider figure +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:network-split" + +\end_inset + +, where +\emph on +Site A +\emph default + is separated from +\emph on +Site B +\emph default + by a faulty network (illustrated by the cloud and lightening bolt). + When +\emph on + +\emph default +the decoupled node +\emph on + +\emph default +and +\emph on + +\emph default +the rest of the network later re-establish communication, they may have + generated the same ID:s if using algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + +, even when mutual system-wide exclusion is implemented. + This is exactly the problem UUID:s solve. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Network split}}{Separation of two networks, occurs when two networks + can not communicate, commonly because of a hardware or software failiure} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/netsplit2.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add clients on each side, and replace the cloud with phole-landlines being + cut by a pair of scissors +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:network-split" + +\end_inset + +An example of a network split +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Security +\end_layout + +\begin_layout Standard +We only support languages running in a sandboxed environment. + Each game session is started in its own sandbox. + The sandboxing isolates the games in such a way that they can not interfere + with each other. + If sandboxing was not in place, one game could potentially modify the contents + of a different game. + A similar approach is taken with the persistent storage we provide. + In the storage each game has its own namespace, much like a table in a + relational database. + A game is not allowed to venture outside this namespace, and can because + this not modify the persistent data of other games. + of this not modify the persistent data of other games. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Sandbox}}{A protected environment in which computer software can + be run safely} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Encryption +\end_layout + +\begin_layout Section +Game Development Language in a Virtual Machine +\begin_inset CommandInset label +LatexCommand label +name "sec:Game-Development-Language" + +\end_inset + + +\end_layout + +\begin_layout Standard +There is only a very limited number of game developers who would like to + write their games in Erlang, therefore we had to come up with something + to resolve this problem. + The main idea was to offer a replacable module which would introduce a + interface to different virtual machines which would run the game code. + This way a game developer can write the game in his favourite language + while the server part still is written in Erlang and can benefit from all + of its advantages. +\end_layout + +\begin_layout Subsection +JavaScript +\end_layout + +\begin_layout Standard +JavaScript has gained a lot of popularity lately, it is used in large projects + such as +\emph on +Riak +\emph default + +\begin_inset Foot +status open + +\begin_layout Plain Layout +\begin_inset Flex URL +status collapsed + +\begin_layout Plain Layout + +http://wiki.basho.com/An-Introduction-to-Riak.html +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +, +\emph on +CouchDB +\emph default + +\begin_inset Foot +status open + +\begin_layout Plain Layout +\begin_inset Flex URL +status collapsed + +\begin_layout Plain Layout + +http://couchdb.apache.org +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +. + On the popular social coding site +\emph on +GitHub.com +\emph default +, 18% +\begin_inset Foot +status open + +\begin_layout Plain Layout +during the writing of the thesis the percentage went up to 19% +\begin_inset Flex URL +status collapsed + +\begin_layout Plain Layout + +https://github.com/languages/ +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + of all code is written in JavaScript. + The popularity of JavaScript in the programming community, in combination + with the availability of several different JavaScript virtual machines + was an important influence in choosing JavaScript as the main control language + for our GGS prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{CouchDB}}{Database server} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Riak}}{Database server} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{GitHub.com}}{Social coding website} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{ActionScript}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Lua}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{.NET}}{Software platform} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Other languages +\end_layout + +\begin_layout Standard +Other languages like +\emph on +lua +\emph default +, +\emph on +ActionScript +\emph default + are suitable as well because there is a virtual machine for each of them + which can be +\begin_inset Quotes eld +\end_inset + +plugged in +\begin_inset Quotes erd +\end_inset + + into our GDL VM interface. + With help of the +\emph on +Java Virtual Machine +\emph default + or the +\emph on +.NET +\emph default +environment it is even possible to run nearly every available programming + language in a sandbox as a GDL. +\end_layout + +\begin_layout Standard +Due lack of time we have decided to use just the Erlang <-> JavaScript bridge + with our interface. +\end_layout + +\begin_layout Section +Testing +\end_layout + +\begin_layout Standard +There are several ways in which the GGS can be tested. + The most important aspect has been deemed to be the experience players + have when using the GGS. + In order to test the user experience of the GGS, a realistic usage scenario + has to be set up. +\end_layout + +\begin_layout Standard +The GGS is intended to be used for powering games which have many concurrent + players. + The players need not participate in the same instance of the game, games + such as chess are prime candidates for the GGS. +\end_layout + +\begin_layout Standard +When developing the GGS, two main categories of games exhibiting different + performance demands were identified; real-time games and turn-based games. + The real-time games were deemed more demanding than the turn based games. + Tests were carried out using a real time game, since this is the more demanding + type of games. +\end_layout + +\begin_layout Standard +The real time game chosen for testing the GGS is +\emph on +Pong +\emph default +, a game in which two players play a game involving a all and two paddles. + The goal for each player is to shoot eside the othre player's paddle while + not allowing the ball to pass by her own paddle. + The game requires real time updates and is quite demanding when played + in several instances concurrently. +\end_layout + +\begin_layout Standard +There has been some work on the area of testing game servers, see +\begin_inset CommandInset citation +LatexCommand citet +key "Lidholt02designand" + +\end_inset + +, who describes a test bench using +\emph on +bots +\emph default + for testing his generic hazard-gaming server. + Lidholt describes how his server, capable of running several different + casino games is tested using artificial players, so called bots. + Performance is measured in +\begin_inset Quotes eld +\end_inset + +number of clients +\begin_inset Quotes erd +\end_inset + + able to connect to the server, and the system load. +\end_layout + +\begin_layout Standard +Similar tests were performed on the GGS, and the results of these tests + are visible in chapter +\begin_inset CommandInset ref +LatexCommand ref +reference "chap:Results-and-discussion" + +\end_inset + +. + The tests were initially performed by starting an operating system process + for each player. + Due to lack of hardware, not enough player processes could be started in + this way. + The bots were re-written in Erlang, and due to Erlang's light weigh threads, + enough processes could be created to successfully test the server. +\end_layout + +\begin_layout Chapter +Implementation of a prototype +\begin_inset CommandInset label +LatexCommand label +name "cha:Implementation-of-a" + +\end_inset + + +\end_layout + +\begin_layout Standard +This chapter contains the realization of much of the principles and techniques + described in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Theory" + +\end_inset + +. + Here the problems and their solutions are discussed in greater detail, + and at times the text becomes more specific to GGS. +\end_layout + +\begin_layout Standard +Much of what is discussed in this chapter has been implemented in the Erlang + GGS prototype. + Specific solutions such as +\emph on +supervisor structures +\emph default +and distribution of erlang nodes on physical nodes. + The different means of communications within the GGS and outside the GGS + with third parties are also discussed here. +\end_layout + +\begin_layout Section +Overview of the prototype +\end_layout + +\begin_layout Standard +The prototype of the GGS was developed using the Erlang language. + The functional and concurrent style of Erlang facilitates devlopment of + software based on a real-world model +\begin_inset CommandInset citation +LatexCommand citep +key "armstrong2011" + +\end_inset + +. + In Erlang, most things are processes. + The software running the Erlang code is known as the Erlang machine, or + an Erlang node. + Each Erlang node is capable of running several +\emph on +threads +\emph default +(also known as +\emph on +Light Weight Processes; LWP +\emph default +) +\emph on +, +\emph default +much like the threads in an operating system. + Threads in a Linux system, for example, are treated much like operating + system processes in different systems. + Due to the size of datastructures related to each process, swapping one + process for another (known as +\emph on +context switching +\emph default +) is an expensive task in many systems +\begin_inset CommandInset citation +LatexCommand citep +after "pg 80" +key "McKusick:2004:DIF:1014910" + +\end_inset + +. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{LWP}}{Light Weight Process} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Context switch}}{The act of switching from one context, commonly + a process, to another. + Used by operating systems to achieve multi tasking} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The cost of swapping operating system processes becomes a problem when many + processes are involved. + If the GGS system had been developed using regular operating system processes, + it would have had to be designed in a way to minimize the number of processes. + Using Erlang, which is capable of running very many processes, several + times more than an operating system can, the mapping between the real world + system (described in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Design-of-the" + +\end_inset + +) becomes clearer. +\end_layout + +\begin_layout Standard +Erlang allows the GGS to create several process for each player connecting, + these processes can handle a multitude of different tasks, parsing data + for example. + Since each task is handled by a different process, the tasks are clearly + separated and the failiure of one is easily recovered without affecting + the others. +\end_layout + +\begin_layout Standard +In addition to creating (or +\emph on +spawning +\emph default +) processes specifically to handle new players connecting, the GGS has more + permanent processes running at all times. + The constantly running processes in the GGS system are called +\emph on +modules +\emph default +. + An example of a module in the GGS is the +\emph on +dispatcher module +\emph default +, which handles the initial connection made by a client, passing the connection + along further in to the system. +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/Chess_no_text.eps + width 100text% + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:The-layout-of" + +\end_inset + +The layout of the GGS. + The circles marked with 'C' topmost in the picture represent clients. + The cloud marked 'network' pictured directly below the clients can be any + network, for example the Internet. + The barell figure marked 'backup' is a process being fed backup data from + the coordinator. + The barell marked 'State' contains the state of a table, and this is fed + into the box marked 'Mnesia' which is database. + Finally the figure shaped as a shield marked 'GameVM' contains the actual + game process. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +In figure +\begin_inset CommandInset ref +LatexCommand vref +reference "fig:The-layout-of" + +\end_inset + + the entire GGS system is represented graphically. + The circles marked with 'C' topmost in the picture represent game clients. + These circles represent processes running on gamers' computers, and not + on the GGS machine. + If a game of chess is to be played on the server, the clients on the gamers' + machines will be chess game clients. + Clients connect through a network, pictured as a cloud, to the dispatcher + process in the GGS. + The dispatcher process and all other modules are discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:The-modular-structure" + +\end_inset + +. + For each connection, a new player process is spawned, which immediately + after spawning is integrated in to the GGS by the coordinator process. +\end_layout + +\begin_layout Section +The usage of Erlang in the GGS +\begin_inset CommandInset label +LatexCommand label +name "sec:The-usage-of-erlang" + +\end_inset + + +\end_layout + +\begin_layout Standard +Erlang was designed by Ericsson, beginning in 1986, for the purpose of creating + concurrent applications and improving telecom software. + Features essential for the telecom instustry to achieve high availability + in telecom switches were added to the language. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Mutex}}{A construct for achieving mutial exclusion, used to avoid + simultaneous access to shared resources in computer systems} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Erlang uses message passing in favour of shared memory, mutextes and locks, + something which at the time was controversial among fellow developers +\begin_inset CommandInset citation +LatexCommand citet +key "Armstrong:2010:ERL:1810891.1810910" + +\end_inset + +. + The reason for using message passing, according to Armstrong, was that + applications should operate correctly before optimizations are done, where + efficient internal communication within the Erlang machine was considered + a later optimization. +\end_layout + +\begin_layout Standard +In using message passing in favour of the methods commonly used at the time, + the issues commonly associated with shared memory and locking were avoided. + In Erlang, everything is a process, and everything operates in its own + memory space. + Memory can not be shared among processes, which prohibits a process from + corrupting the memory of a different process. +\end_layout + +\begin_layout Standard +Messages are sent between the processes in an asynchronous manner, and each + process has a mailbox in which these messages can be retrieved. +\end_layout + +\begin_layout Standard +Processes in Erlang are also called +\emph on +Light Weight Processes. + +\emph default +The Erlang processes are very cheaply created. + Processes exist within an Erlang machine, or Erlang node. + The Erlang machine has its own scheduler and does not rely on the operating + system's scheduler, this is a main reason of Erlang's capability of running + many concurrent processes +\begin_inset CommandInset citation +LatexCommand citet +key "Armstrong03" + +\end_inset + +. +\end_layout + +\begin_layout Standard +The strong isolation of Erlang processes make them ideal for multicore and + distributed systems. + Distribution of software is included as a fundamental part in the Erlang + language. + The 'physical' location of a process, e.g. + which computer the process runs on, is not important when communicating + with the process. + Processes can communicate regardless of whether they run on the same system + of not, transparently. +\end_layout + +\begin_layout Standard +The distributed nature of Erlang is something the GGS makes use of when + scaling across several computers in order to achieve higher performance. + The distribution is also important in creating redundancy. + Erlang promotes a non-defensive programming style in which processes are + allowed to crash and be restarted in favour of having the processes recover + from errors. + The distributed nature of Erlang means supervisor processes (discussed + in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Supervisor-structure" + +\end_inset + +) can reside on remote systems, thereby increasing the reliability of the + system as a whole. +\end_layout + +\begin_layout Standard +A very important feature of Erlang, used in the GGS, is the ability to interface + with external hardware and software. + Erlang allows communication with external resources through +\emph on +ports +\emph default + and +\emph on +NIF +\emph default +:s (Native implemented functions) +\emph on +. + +\emph default + Through ports communication can take place much in the same way communication + is performed over sockets. + NIF:s are called like any other functions without any difference to the + caller but are implemented in C. +\end_layout + +\begin_layout Standard +The GGS uses Erlang ports for generating UUID:s +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +UUID:s are discussed in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:UUID" + +\end_inset + + +\end_layout + +\end_inset + + and NIF:s for interfacing with the virtual machines of games +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +Virtual machines of games are discussed in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Game-Development-Language" + +\end_inset + + +\end_layout + +\end_inset + +. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{OTP}}{Open Telecom Platform, a software suite for Erlang} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Behaviour}}{A design pattern in OTP} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Development of the GGS would have been hard if not impossible had it not + been for the +\emph on +OTP +\emph default + supplied with the standard Erlang distribution. + The OTP (Open Telecom Platform) is a set of standard libraries and design + patterns, called +\emph on +behaviours +\emph default +, which are used when developing Erlang systems. +\end_layout + +\begin_layout Standard +The GGS makes heavy use of the behaviours supplied in the OTP. + The behaviours impose a programming style suitable for distributed and + concurrent applications, perfectly suitable for the GGS. + In particular, the GGS uses the following behaviours: +\end_layout + +\begin_layout Itemize +The +\emph on +supervisor +\emph default + behaviour, which is used when creating a supervisor. + Supervisors are used when monitoring processes in the Erlang system. + When a process exits wrongfully, the supervisor monitoring the process + in question decides which action to take. + In the GGS, the most common action is simply to restart the faulting process. + A more thorough discussion on supervisors can be found in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Supervisor-structure" + +\end_inset + +. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_tcp +\emph default +behaviour, which is used to work with TCP sockets for network communication. + Using the gen_tcp behaviour, network messages are converted to internal + Erlang messages and passed to a protocol parser, where the messages are + processed further. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_server +\emph default + behaviour, which is used when constructing OTP servers in Erlang. + Using this behaviour, a state can easily be kept in a server process, greatly + increasing the usefulness of the server process. + There are many gen_servers in the GGS, it is the most widely used behaviour + in the project. + In addition to intruducing a state to the server, the gen_server behaviour + also imposes patterns for synchronous and asynchronous communication between + other gen_servers and other OTP behaviours. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_fsm +\emph default + behaviour is used in the protocol parser module in the GGS. + Using the gen_fsm behaviour, finite state machines are easily developed. + Protocol parsers are an ideal example of where to use finite state machines, + which are widely used for parsing strings of text. +\end_layout + +\begin_layout Standard +In addition to supplying behaviours, the OTP also has a style for packaging + and running Erlang applications. + By packaging the GGS as an +\emph on +application +\emph default +the GGS can be started in a way uniform to most erlang software, providing + familiarity for other Erlang users, and eases the incorporation of the + GGS in other applications. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Application}}{A way of packaging Erlang software in a uniform way} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Short introduction to the Erlang syntax +\end_layout + +\begin_layout Standard +In order to understand examples in this thesis, a small subset of Erlang + must be understood. + In this section, the very syntactic basics of Erlang are given. +\end_layout + +\begin_layout Itemize + +\series bold +Variables +\series default + start with an uppercase letter, examples include +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt X, Var}, and { +\backslash +tt Global} +\end_layout + +\end_inset + +. + A variable can only be assigned once. +\end_layout + +\begin_layout Itemize + +\series bold +Atoms +\emph on + +\series default +\emph default +start with lower case letters, for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + + { +\backslash +tt atom, a} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Functions +\series default + are defined starting with an atom for the name, parenthesis containing + parameters, an arrow, a function body and finally a dot marking the end + of a function. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt square(X) -> X*X.} +\end_layout + +\end_inset + + is an example of a function producing the square of X. +\end_layout + +\begin_layout Itemize +Functions are +\series bold +called +\series default + by suffixing an atom with the function name with parenthesis, for example + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt square(10)} +\end_layout + +\end_inset + +. + Qualified names can be specified using ':', for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt math:square(10)} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Tuples +\series default + are containers of fixed type for Erlang data types. + They are constructed using curly brackets, for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt +\backslash +{atom1, atom2, atom3 +\backslash +}}. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Itemize + +\series bold +Lists +\series default + are constructed using [ and ], for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt [1,2,3]} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Strings +\series default + doubly qouted lists of characters, for example +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt "Hello world"} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Records +\series default + are erlang tuples coupled with a tag for each tuple element. + This allows refering to elements by name instead of by position. + An example of a record looks like this: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt +\backslash +#myRecord{}} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Section +Communication with external systems and applications +\begin_inset CommandInset label +LatexCommand label +name "sec:Communication-with-external" + +\end_inset + + +\end_layout + +\begin_layout Standard +A game launched on the GGS is run within a virtual machine. + For each programming language supported, there is a virtual machine that + interprets the game. + Furthermore an interface for communication between the GGS, the game and + the players playing the game must be present. +\end_layout + +\begin_layout Standard +The reason for the GGS requiring a communication channel between the game + VM and Erlang is in part because the GGS makes heavy use of callbacks. + Callbacks written in Erlang are registered to the VM for the interface + to work. + It is only with the help of the interface that the game developer can access + the game state and send messages between players. + The interface provides access to three objects called +\emph on +world +\emph default +, +\emph on +player +\emph default + and +\emph on +localstorage +\emph default +. + The game state is safely stored in a database and retrieved for manipulation + by a call for the world object. + Interaction with the players is done the same way using the player object + instead. + The localstorage is a convenient way to store globals and other data seperated + from the game state. + In section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Exposing-Erlang-functionality" + +\end_inset + + a concrete example of the implementation of the localStorage and world + objects is given. +\begin_inset Note Note +status open + +\begin_layout Plain Layout + Unique id:s called gametokens are generated for hosted games so that they + are not mixed up. + -- good text, integrate more. +\end_layout + +\end_inset + + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{WebStorage}}{A new standard for letting websites store data on visitors' + computers} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Exposing Erlang functionality to the GDL VM +\begin_inset CommandInset label +LatexCommand label +name "sub:Exposing-Erlang-functionality" + +\end_inset + + +\end_layout + +\begin_layout Standard +This section contains a concrete example of how the localStorage and world + objects are exposed to a GDL VM. + The example comes from the GGS prototype, which uses JavaScript powered + by Google V8 as its GDL VM. +\end_layout + +\begin_layout Standard +The code given in +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:exposing-erlang" + +\end_inset + + is specific to V8 and JavaScript, however implementations for different + GDL:s, or different JavaScript VM:s should be similar. +\end_layout + +\begin_layout Standard +In JavaScript is is common to use a top level object, called a global object, + to establish a global scope. + This allows declaration of global variables and functions. + To gain access to the global object in the GGS, the +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt erlv8 +\backslash +_vm:global(..)} +\end_layout + +\end_inset + + function on line 2 of the example is used. + Using the global object, declarations of the world and GGS object can be + placed in the global scope. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt Global:set +\backslash +_value(..)} +\end_layout + +\end_inset + + is a call to the global object, declaring new objects in the global scope. + On line 4 the GGS object is declared. + By accessing +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt GGS.localStorage } +\end_layout + +\end_inset + + from within the GDL, access to the localstorage is provided, thus the localstor +age must be connected to the GGS object, this can be seen in line 5. +\end_layout + +\begin_layout Standard +Both the GGS and localStorage objects are dummy objects, which provide no + functionality, these two objects are simply placed in the GDL for the purpose + clearing up the code. + In order to perform an action using the GGS and localStorage objects, the + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt getItem} and { +\backslash +tt setItem} +\end_layout + +\end_inset + + functions must be used. + These items are directly connected to the database module of the GGS, which + is discussed in more detail in +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:The-database-module" + +\end_inset + +. +\end_layout + +\begin_layout Standard +Similarly the functions +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt sendCommand, sendCommandToAll} and { +\backslash +tt setTimeout} +\end_layout + +\end_inset + + are directly connected to a piece of code in the GGS which performs the + desired action. + The +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt sendCommand} +\end_layout + +\end_inset + + functions are used to send commands or text to participants of the table. + The +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt setTimeout} +\end_layout + +\end_inset + + function introduces timeouts to the V8 engine, which are not available + per default. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +language=Erlang, +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting}[language=Erlang] +\end_layout + +\begin_layout Plain Layout + +% @doc Exposes some GGS functions to JavaScript +\end_layout + +\begin_layout Plain Layout + +expose(GameVM, Table) -> +\end_layout + +\begin_layout Plain Layout + + Global = erlv8_vm:global(GameVM), +\end_layout + +\begin_layout Plain Layout + + Global:set_value("GGS", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"localStorage", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:setItem(Table, local_storage, Key, Val) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:getItem(Table, local_storage, Key) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])}, +\end_layout + +\begin_layout Plain Layout + + {"world", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:setItem(Table, world, Key, Val), +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command_to_all( +\end_layout + +\begin_layout Plain Layout + + Table, {"world_set", Key ++ "=" ++ Val} +\end_layout + +\begin_layout Plain Layout + + ) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:getItem(Table, world, Key), +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])}, +\end_layout + +\begin_layout Plain Layout + + {"sendCommand", fun(#erlv8_fun_invocation{}, [Player, Command, Args])-> +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command(Table, Player, {Command, Args}) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"sendCommandToAll", fun(#erlv8_fun_invocation{}, [Command, Args])-> +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command_to_all(Table, {Command, Args}) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + {"setTimeout", fund(#erlv8_fun_invocation{}, [Time, Function])-> +\end_layout + +\begin_layout Plain Layout + + timer:apply_after(Time, ?MODULE, call_js, [GameVM, Function]) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])). +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:exposing-erlang" + +\end_inset + +An example of how Erlang functionality is exposed to a Javascript GDL +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +TODO: Go in to more detail about how the world, player and localstorage + objects are implemented. + Also discuss localstorage and how it derives from the webstorage standard + in detail. + This is a great point on how we try to follow standards. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +My idea here is that we describe the erlang-js (which failed, but nontheless), + v8, UUID and other external communication. + We shouldn't describe sockets here though.. + or.. + maybe? +\end_layout + +\begin_layout Plain Layout +Also discuss how we allow GDLs to communicate with Erlang, this is +\begin_inset Quotes eld +\end_inset + +external +\begin_inset Quotes erd +\end_inset + + to thre GDL. + Discuss the GGS world object (there is a reference to this secxtion for + that purpose) +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +The modular structure of the GGS prototype +\begin_inset CommandInset label +LatexCommand label +name "sec:The-modular-structure" + +\end_inset + + +\end_layout + +\begin_layout Standard +The separation of concerns, and principle of single responsibility +\begin_inset Foot +status open + +\begin_layout Plain Layout +More information on the SRP is available at: +\begin_inset CommandInset href +LatexCommand href +target "http://www.objectmentor.com/resources/articles/srp.pdf" + +\end_inset + + +\end_layout + +\end_inset + + are widely respected as good practices in the world of software engineering + and development. + By dividing the GGS up into modules each part of the GGS can be modified + without damaging the rest of the system. +\end_layout + +\begin_layout Standard +The responsibility and concern of each module comes from the responsibility + and concern of the real-world entity the model represents. + The modelling of the GGS after a real world system was discussed in chapter + +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Theory" + +\end_inset + +. +\end_layout + +\begin_layout Standard +In the text below the word module refers to the actual code of the discussed + feature, while the word process is used when referring to a running instance + of the code. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SRP}}{Single Responsibility Principle} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Object Oriented Programming}}{A programming paradigm focusing on + objects} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +The dispatcher module +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +The discussion of the modules is divided into the following parts: +\end_layout + +\begin_layout Itemize +What does the module do? +\end_layout + +\begin_layout Itemize +What happens when the module fails? +\end_layout + +\begin_layout Itemize +How does the module correspond to the real-world scenario of the chess club? +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The dispatcher module is the first module to have contact with a player. + When a player connects to the GGS, it is first greeted by the dispatcher + module, which sets up an accepting socket for each player. + +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout +Is this the proper way to day the dispatcher greets connecting players? +\end_layout + +\end_inset + + The dispatcher is the module which handles the interfacing to the operating + system when working with sockets. + Operating system limits concering the number of open files, or number of + open sockets are handled here. + The operating system limits can impose problems on the GGS, this is discussed + more in detail in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Problems-of-implementation" + +\end_inset + +. +\end_layout + +\begin_layout Standard +Should the dispatcher module fail to function, no new connections to the + GGS can be made. + In the event of a crash in the dispatcher module, a supervisor process + immediately restarts the dispatcher. + There exists a window of time between the crashing of the dispatcher and + the restarting of the dispatcher, this window is very short, and only during + this window is the GGS unable to process new connection requests. + Due to the modular structure of the GGS, the rest of the system is not + harmed by the dispatcher process not functioning. + The process does not contain a state, therefore a simple restart of the + process is sufficient in restoring the GGS to a pristine state after a + dispatcher crash +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Well.. + In theory.. +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Standard +Returning to scenario of the chess club, the dispatcher module is the doorman + of the club. + When a player enters the chess club, the player is greeted by the doorman, + letting the player in to the club. + The actual letting in to the club is in the GGS represented by the creation + of a player process discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-player-module" + +\end_inset + +. + The newly created player process is handed, and granted rights to, the + socket of the newly connected player. +\end_layout + +\begin_layout Subsection +The player module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-player-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +The player module is responsible for representing a player in the system. + Each connected player has its own player process. + The player process has access to the connection of the player it represents, + and can communicate with this player. + In order to communicate with a player, the data to and from the player + object must pass through a protocol parser module, discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-protocol-parser" + +\end_inset + +. + Raw communication, witout passing the data through a protocol parser is + in theory possible, but is not useful. +\end_layout + +\begin_layout Standard +In the creation of a player process, the coordinator process, discussed + in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-coordinator-module" + +\end_inset + +, is notified by the newly connected process. +\end_layout + +\begin_layout Standard +In the event of a crash in a player process, several things happen. + +\end_layout + +\begin_layout Enumerate +The player process, which is the only process with a reference to the socket + leading to the remote client software, passes this reference of the socket + to the coordinator process temporarily. +\end_layout + +\begin_layout Enumerate +The player process exits. +\end_layout + +\begin_layout Enumerate +The coordinator spawns a new player process, with the same socket reference + as the old player process had. +\end_layout + +\begin_layout Enumerate +The player process resumes operation, immediately starting a new protocol + parser process, and begind receiving and sending network messaged again. +\end_layout + +\begin_layout Standard +The window of time between the crash of the player process and the starting + of a new player process is, as with the dispatcher, very short. + Since the connection changes owners for a short period of time, but is + never dropped, the implications of a crash are only noticed, at worst, + as choppy gameplay for the client. + Note however that this crash recovery scheme is not implemented in the + GGS prototype. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Can we do this..? Seems a bit sneaky. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Moving back to the real world example, the player process represent an actual + person in the chess club. + When a person sits down at a table in the chess club, the person does so + by requesting a seat from some coordinating person, and is then seated + by the same coordinator. + Once seated, the player may make moves on the table he or she is seated + by, this corresponds clearly to how the GGS is structured, as can be seen + in the following sections. +\end_layout + +\begin_layout Subsection +The protocol parser module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-protocol-parser" + +\end_inset + + +\end_layout + +\begin_layout Standard +The protocol parser is an easily interchangable module in the GGS, handling + the client-to-server, and server-to-client protocol parsing. + In the GGS prototype, there is only one protocol supported, namely the + +\emph on +GGS Protocol +\emph default +. + The role of the protocol parser is to translate the meaning of packets + sent using the prototocol in use to internal messages of the GGS system. + The GGS protocol, discussed below is used as a sample protocol in order + to explain how protocol parsers can be built for the GGS. +\end_layout + +\begin_layout Subsubsection +The structure of the GGS Protocol +\begin_inset CommandInset label +LatexCommand label +name "sub:The-structure-of" + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS protocol is modelled after the HTTP protocol. + The main reason for this is the familiarity many developers already have + with HTTP due to its presence in internet software. + Each GGS protocol packet contains a headers section. + The headers section is followed by a data section. + In the headers section, parameters concerning the packet is placed. + In the data section, the actual data payload of the packet is placed. +\end_layout + +\begin_layout Standard +There is no requirement of any specific order of the parameters in the headers + section, however the data section must always follow directly after the + headers section. +\end_layout + +\begin_layout Standard +In the example below, line 1 contains a Game-Command parameter. + This parameter is used to determine which game-specific command the client + is trying to perform. + The handling of this parameter is specific to each game, and can be anything. +\end_layout + +\begin_layout Standard +Line 2 specifies a game token. + This is a UUID which is generated for each client upon authentication with + the GGS. + The GGS uses this token in case a client is disconnected and the new connection + created when the client reconnects must be re-paired with the player object + inside the GGS. + The UUID is also used as a unique ID within GDL VMs. +\end_layout + +\begin_layout Standard +Line 3 specifies the content type of the payload of this particular packet. + This parameter allows the GGS to invoke special parsers, should the data + be encoded or encrypted. + When encryption is employed, only the payload is encrypted, not the header + section. + This is a scheme which does not allow for strong encryption, but is deemed + feasible for gaming purposes. +\end_layout + +\begin_layout Standard +Line 4 specifies the content length of the payload following immediately + after the headers section. +\end_layout + +\begin_layout Standard +The parser of the GGS protocol implemented in the GGS prototype is designed + as a finite state machine using the gen_fsm behaviour. + When a full message has been parsed by the parser, the message is converted + into the internal structure of the GGS messages, and sent in to the system + from the protocol paser using message passing. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Packet below is not an algorithm, but I don't know how to change that label.. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting} +\end_layout + +\begin_layout Plain Layout + +Game-Command: chat +\end_layout + +\begin_layout Plain Layout + +Token: e30174d4-185e-493b-a21a-832e2d9d7a1a +\end_layout + +\begin_layout Plain Layout + +Content-Type: text +\end_layout + +\begin_layout Plain Layout + +Content-Length: 18 +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + +Hello world, guys! +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-sample-packet" + +\end_inset + +A sample packet sent from a client to the GGS during a chat session +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Mention that the protocol is heavily influenced bye HTTP, is parsed using + a FSM, perhaps give a sample packet. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +The coordinator module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-coordinator-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +The coordinator module is responsible for keeping track of all players, + their seats and tables. + Players register with the coordinator process when first connecting to + the server, and the coordinator places each player by their respective + table. +\end_layout + +\begin_layout Standard +The coordinator keeps mappings between each player and table, therefore + it is used to perform lookups on tables and players to find out which are + connected. + The connectivity of players and tables is important when sending messages + to all participants in a game. + A lookup in the coordinator process is performed prior to notifying all + players in a game to ensure the message reaches all players. + The lookup can be performed either using internal identification codes + or using the UUID associated with each client and table. +\end_layout + +\begin_layout Standard +The coordinator process contains important state, therefore a backup process + is kept at allt times. + All good data processed by the coordinator is stored for safekeeping in + the backup process as well. + Data which is potentisally harmful is not stored in the backup process. +\end_layout + +\begin_layout Standard +Upon a crash, the coordinator process recovers the prior good state from + the backup process and continues where it left off. + A supervisor process monitors the coordinator process and restarts the + process when it malfunctions. + There is a window of time between the crash of the coordinator and the + restarting of the coordinator, during this time, players can not be seated + by new tables, and can not disconnect from the server. + This window of time is very small, and the unavailability of the coordinator + process should not be noticed by more than a short time lag for the clients. +\end_layout + +\begin_layout Standard +Moving back to the example of the chess club, the coordinator process can + be seen as a judge, monitoring all moves of the players. + At the same time as acting as a judge, the coordinator process is also + a host in the chess club, seating players by their tables and offering + services to the players. +\end_layout + +\begin_layout Subsection +The table module +\end_layout + +\begin_layout Standard +The table module is mostly a hub used for communication. + New table processes are created by the coordinator on demand. + The table module does not contain any business logic, however each process + contains information concerning which players are seated by that particular + table. +\end_layout + +\begin_layout Standard +The information about which players are seated by each table is used when + notifying all players by a table of an action. + Consider a game of chess, each player notifies the table of its actions, + the table then notifies the rest of the participants of these actions after + having had the ac tions processed by the game VM, where an action could + be moving a playing piece. +\end_layout + +\begin_layout Standard +Each table is associated with a game VM. + The actions sent to a table are processed by the game VM, this is where + the game logic is implemented. +\end_layout + +\begin_layout Standard +After a crash in a table process, the entire table must be rebuilt and the + players must be re-associated with the table. + Data concerning players is kept in the coordinator process, and is restored + from there. + Data kept in the actual game is not automatically corrupted by the crash + in a table, however the table must be re-associated with the game VM is + was associated with prior to the crash of the table. + The table process maps well into the setting of the real-world chess club + scenario previously discussed. + A table works in the same way in a real world setting as in the GGS setting. +\end_layout + +\begin_layout Subsection +The game virtual machine module +\end_layout + +\begin_layout Standard +This module holds the game logic of a game and is responsible for the VM + associated with each game. + +\end_layout + +\begin_layout Standard +The game VM contains the state of the VM and a table token associated with + a running game. + GameVM is started by the table module. + The table module hands over a token to the game VM during initialization. + During initialization a new VM instance and various objects associated + to the VM instance will be created. + Callbacks to Erlang are registered into the VM and then the source code + of a game is loaded into the VM and the game is ready for startup. + The only means for a game to communicate with the VM is through usage of + a provided interface. + +\end_layout + +\begin_layout Standard +The VM itself makes it possible for the game developer to program in the + prograimming language covered by the VM. + In future releases, more game VM:s will be added to support more programming + languages. + Because the game VM keeps track of the correct table, the game developer + doesn't need to take this into consideration when programming a game. + If a method within the game sends data to a player, it will be delivered + to the player in the correct running game. + The same game token is used to store the game state in the database. + Therefore, no game states will be mixed up either. +\end_layout + +\begin_layout Standard +This module does not affect game runtime but evaluates a new game state + and handles communication between the game and the players. + A closer look at the structure of this model is given in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Communication-with-the-GDL-VM" + +\end_inset + +. +\end_layout + +\begin_layout Subsection +The database module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-database-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +Game data from all games on the GGS are stored in the database backend of + the database module. +\end_layout + +\begin_layout Standard +In the GGS prototype the database module is using a database management + system called Mnesia. + Mnesia ships with the standard Erlang distribution and is a key-value store + type database. + Mnesia is designed to handle the stress of telecoms systems, and has some + features specifically tailored for telecoms which are not commonly found + in other databases. + Key features of the Mnesia database are: +\end_layout + +\begin_layout Itemize +Fast key/value lookups +\end_layout + +\begin_layout Itemize +Distribution of the database system +\end_layout + +\begin_layout Itemize +Fault tolerance +\end_layout + +\begin_layout Standard +\begin_inset CommandInset citation +LatexCommand citet +key "667766" + +\end_inset + + +\end_layout + +\begin_layout Standard +The features of Mnesia originally intended for telecoms prove very useful + for the purposes of the GGS as well. + The fault tolerance and speed of Mnesia are very valueable tools, the fast + key/value lookups permit many lookups per second to the database. +\end_layout + +\begin_layout Standard +Game data will not be lost when a game is stopped or has gone down for unknown + reasons. + This makes it possible to continue a game just before the failure without + having to start the game from the beginning. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Mnesia}}{Database server used in the GGS} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS stores the game state in the distributed Mnesia database, from which + the state can be restored in the event of a crash. +\end_layout + +\begin_layout Standard +Each game is uniquely identified by a table token and the data of each game + is stored within two different namespaces. + The namespaces are named World and Localstorage. + The World is used contain all game data related to the game state. + This sort of game data may change during the runtime of the game. + The Localstorage should contain data independent of the game state. + Game resources, constants and globals are all examples of data that could + reside within the Localstorage. + To store a value within the database, not only is the table token and the + name of the namespace required, but a unique key so that the value can + be successfully retrieved or modified later. + The key is fully decidable by the game developer. + +\end_layout + +\begin_layout Standard +The interface of the database module is an implementation of the upcoming + W3C Web Storage specification. + Web Storage is intended for use in web browsers, providing a persistant + storage on the local machine for web applications. + The storage can be used to communicate in between browser windows (which + is difficult when using cookies), and to store larger chunks of data +\begin_inset CommandInset citation +LatexCommand citet +key "webstorage:website" + +\end_inset + +. + Usage of the web storage standard in the GGS provides a well documented + interface to the database backend. +\end_layout + +\begin_layout Subsection +A case study +\end_layout + +\begin_layout Standard +So what happens when a client sends a typical game command? Let us look + at one particular example of a chat client sending the message to change + the nick of a user (we will discuss a example implementation in JavaScript + in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Example-of-a-GGS-server-application-in-JavaScript" + +\end_inset + +). + Every communication between modules happens asynchronously, nothing is + blocking, which is very important in concurrent systems. + It is probably much easier to follow the steps by following them on +\begin_inset CommandInset ref +LatexCommand vref +reference "fig:The-layout-of" + +\end_inset + +. +\end_layout + +\begin_layout Enumerate +Client packages a Game-Command into a package which conforms to the protocol + structure the GGS is using and sends it over the network +\end_layout + +\begin_layout Enumerate +The player module, which is coupled to the TCP-module to react on incoming + messages accepts the message and forwards the raw data to the protocol + parser module +\end_layout + +\begin_layout Enumerate +The protocol parser parses the message and brings it into the format of + the internal GGS presentation of such a message, which is just a specialized + Erlang touple +\end_layout + +\begin_layout Enumerate +The protocol parser sends this Erlang touple back to the player module +\end_layout + +\begin_layout Enumerate +The player module checks if it is a Server-Command or a Game-Commane. + In our example it is a Game-Command and it sends the message to the table + module +\end_layout + +\begin_layout Enumerate +The table module sends it to its own Game VM +\end_layout + +\begin_layout Enumerate +The Game VM module calls the function +\emph on +playerCommand( +\begin_inset Quotes eld +\end_inset + +278d5002-77d6-11e0-b772-af884def5349 +\begin_inset Quotes erd +\end_inset + +, +\begin_inset Quotes eld +\end_inset + +nick +\begin_inset Quotes erd +\end_inset + +, +\begin_inset Quotes eld +\end_inset + +Peter +\begin_inset Quotes erd +\end_inset + +) +\emph default + within the JavaScript VM +\end_layout + +\begin_layout Enumerate +The JavaScript VM (JSVM) - at this stage Googles V8 JavaScript Engine - + evaluates the function within the sandboxed game context which has been + established earlier during the setup of the game. +\end_layout + +\begin_layout Enumerate +In the example ( +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Example-of-a-GGS-server-application-in-JavaScript" + +\end_inset + +) we see that the GGS-functios +\emph on +GGS.localStorage.setItem(key, value) +\emph default + and +\emph on +GGS.localStorage(key) +\emph default + are used. + Both are callbacks coupled to the database module functions. +\end_layout + +\begin_layout Enumerate +Data is being read from and written to the database and handed over to the + JSVM via the database module +\end_layout + +\begin_layout Enumerate +In the example the +\emph on +GGS.sendCommandToAll() +\emph default + is beeing called then which is a callback to a function of the table module + which iterates thrugh its player list and sends the command to every player +\end_layout + +\begin_layout Enumerate +The table module sends every player instance the message to send the message + with the change of a nickname of a particular user to its own client. +\end_layout + +\begin_layout Enumerate +The player module asks the protocol module to create a message conforming + to the protocol which is being used +\end_layout + +\begin_layout Enumerate +The protocol module creates a string according to the protocol and returns + it to the player module +\end_layout + +\begin_layout Enumerate +The player module sends the message with help of the gen_tcp module to the + client +\end_layout + +\begin_layout Section +Communication with the GDL VM +\begin_inset CommandInset label +LatexCommand label +name "sec:Communication-with-the-GDL-VM" + +\end_inset + + +\end_layout + +\begin_layout Standard +A game launched on the GGS is run within a virtual machine. + For each programming language supported, there is a virtual machine that + interprets the game. + Furthermore an interface for communication between the GGS, the game and + the players playing the game is present. +\end_layout + +\begin_layout Standard +Callbacks written in Erlang are registered to the VM for the interface to + work. + It is only with the help of the interface that the game developer can access + the game state and send messages to the clients. + The interface provides access to three objects called +\emph on +world, players +\emph default + and +\emph on +localStorage +\emph default +. + The game state is safely stored in a database and retrieved for manipulation + by a call for the world object. + Interaction with the players is done by using the +\emph on +GGS.sendCommand(player_id, command, args) +\emph default + and +\emph on +GGS. +\emph default +sendCommandToAll(command, args). + The localStorage is a convenient way to store globals and other variables + seperated from the game state. + Unique id:s called gametokens are generated for hosted games so that they + are not mixed up. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{WebStorage}}{A new standard for letting websites store data on visitors' + computers} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Exposing Erlang functionality to the GDL VM +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Prior to this section, the Erlang syntax has to be briefly explained. + I think the 'usage of erlang' section is a good place to do this in. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +language=Erlang, +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting}[language=Erlang] +\end_layout + +\begin_layout Plain Layout + +% @doc Exposes some GGS functions to JavaScript +\end_layout + +\begin_layout Plain Layout + +expose(GameVM, Table) -> +\end_layout + +\begin_layout Plain Layout + + Global = erlv8_vm:global(GameVM), +\end_layout + +\begin_layout Plain Layout + + Global:set_value("GGS", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"localStorage", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:setItem(Table, local_storage, Key, Val) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:getItem(Table, local_storage, Key) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])}, +\end_layout + +\begin_layout Plain Layout + + {"world", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:setItem(Table, world, Key, Val), +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command_to_all( +\end_layout + +\begin_layout Plain Layout + + Table, {"world_set", Key ++ "=" ++ Val} +\end_layout + +\begin_layout Plain Layout + + ) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:getItem(Table, world, Key), +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])}, +\end_layout + +\begin_layout Plain Layout + + {"sendCommand", fun(#erlv8_fun_invocation{}, [Player, Command, Args])-> +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command(Table, Player, {Command, Args}) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"sendCommandToAll", fun(#erlv8_fun_invocation{}, [Command, Args])-> +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command_to_all(Table, {Command, Args}) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + {"setTimeout", fun(#erlv8_fun_invocation{}, [Time, Function])-> +\end_layout + +\begin_layout Plain Layout + + timer:apply_after(Time, ?MODULE, call_js, [GameVM, Function]) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])). +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:exposing-erlang" + +\end_inset + +An example of how Erlang functionality is exposed to a JavaScript GDL +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +TODO: Go in to more detail about how the world, player and localstorage + objects are implemented. + Also discuss localstorage and how it derives from the webstorage standard + in detail. + This is a great point on how we try to follow standards. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +My idea here is that we describe the erlang-js (which failed, but nontheless), + v8, UUID and other external communication. + We shouldn't describe sockets here though.. + or.. + maybe? +\end_layout + +\begin_layout Plain Layout +Also discuss how we allow GDLs to communicate with Erlang, this is +\begin_inset Quotes eld +\end_inset + +external +\begin_inset Quotes erd +\end_inset + + to thre GDL. + Discuss the GGS world object (there is a reference to this secxtion for + that purpose) +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Techniques for ensuring reliability +\end_layout + +\begin_layout Standard +One of the main goals of the project is to achieve high reliability. + The term +\begin_inset Quotes eld +\end_inset + +reliable system +\begin_inset Quotes erd +\end_inset + + is defined by the IEEE as a system with +\begin_inset Quotes eld +\end_inset + +the ability of a system or component to perform its required functions under + stated conditions for a specified period of time +\begin_inset Quotes erd +\end_inset + + +\begin_inset CommandInset citation +LatexCommand citet +key "ieee_90" + +\end_inset + +. + There are some tools for creating reliable applications built in to Erlang. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Reliability}}{The ability of a system or component to perform its + required functions under stated conditions for a specified period of time} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{IEEE}}{Institute of Electrical and Electronics Engineers, read "I-triple- +E"} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Itemize +Links between processes. + When a process spawns a new child process, and the child process later + exits, the parent process is notified of the exit. + +\end_layout + +\begin_layout Itemize +Transparent distribution over a network of processors. + When several nodes participate in a network, it does not matter on which + of these machines a process is run. + Communication between processes does not depend on the node in which each + process is run. + +\end_layout + +\begin_layout Itemize +Hot code replacements. + Two versions of the same module can reside in the memory of Erlang at any + time. + This means that a simple swap between these versions can take place very + quickly, and without stopping the machine. +\end_layout + +\begin_layout Standard +These three features are some of the basic building blocks for more sophisticate +d reliability systems in Erlang. + Many times it is not necessary to use these features directly, but rather + through the design patterns described below. +\end_layout + +\begin_layout Subsection +Supervisor structure +\begin_inset CommandInset label +LatexCommand label +name "sub:Supervisor-structure" + +\end_inset + + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +This entire section is bad. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +By linking processes together and notifying parents when children exit, + supervisors are created. + A supervisor is a common approach in ensuring that an application functions + in the way it was intended +\begin_inset CommandInset citation +LatexCommand citet +key "Savor:1997:HSA:851010.856089" + +\end_inset + +. + When a process misbehaves, the supervisor takes some action to restore + the process to a functional state. + +\end_layout + +\begin_layout Standard +There are several approaches to supervisor design in general (when not just + considering how they work in Erlang). + One common approach is to have the supervisor look in to the state of the + process(es) it supervises, and let the supervisor make decisions based + on this state. + The supervisor has a specification of how the process it supervises should + function, and this is how it makes decisions. + +\end_layout + +\begin_layout Standard +In Erlang, we have a simple version of supervisors. + We do not inspect the state of the processes being supervised. + We do have a specification of how the supervised processes should behave, + but on a higher level. + The specification describes things such as how many times in a given time + interval a child process may crash, which processes need restarting when + crashes occur, and so forth. + +\end_layout + +\begin_layout Standard +When the linking of processes in order to monitor exit behaviour is coupled + with the transparent distribution of Erlang, a very powerful supervision + system is created. + For instance, we can restart a failing process on a different, new node, + with minimal impact on the system as a whole. + +\end_layout + +\begin_layout Standard +In the GGS, we have separated the system in to two large supervised parts. + We try to restart a crashing child separately, if this fails too many +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +Exactly how many +\begin_inset Quotes eld +\end_inset + +too many +\begin_inset Quotes erd +\end_inset + + is depends on a setting in the supervisor, ten crashes per second is a + reasonable upper limit. +\end_layout + +\end_inset + + times, we restart the nearest supervisor of this child. + This ensures separation of the subsystems so that a crash is as isolated + as possible. +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset Note Note +status open + +\begin_layout Plain Layout +We should really do this graphic in EPS instead of PNG +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/Supervisor_tree_GGS.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +The supervisor structure of GGS +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The graphic above shows our two subsystems, the coordinator subsystem and + the dispatcher subsystem. + Since these two systems perform very different tasks they have been separated. + Each subsystem has one worker process, the coordinator or the dispatcher. + The worker process keeps a state which should not be lost upon a crash. +\end_layout + +\begin_layout Standard +We have chosen to let faulty processes crash very easily when they receive + bad data, or something unexpected happens. + The alternative to crashing would have been to try and fix this faulty + data, or to foresee the unexpected events. + We chose not to do this because it is so simple to monitor and restart + processes, and so difficult to try and mend broken states. + This approach is something widely deployed in the Erlang world, and developers + are often encouraged to “Let it crash”. +\end_layout + +\begin_layout Standard +To prevent any data loss, the good state of the worker processes is stored + in their respective backup processes. + When a worker process (re)starts, it asks the backup process for any previous + state, if there is any that state is loaded in to the worker and it proceeds + where it left off. + If on the other hand no state is available, a special message is delivered + instead, making the worker create a new state, this is what happens when + the workers are first created. +\end_layout + +\begin_layout Subsection +Reduncancy +\end_layout + +\begin_layout Standard +The modules in the GGS are built to be capable of redundant operation. + By adding a backup process to sensitive processes, the state can be kept + in the event of a crash. + The coordinator of the GGS prototype has this backup feature built in. + The coordinator passes state along to the backup process which keeps the + data safe. + In the event of a crash, the coordinator recovers the state from the backup + process. + Figure +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:redundancy" + +\end_inset + + depicts the redundancy built in to the coordinator process. +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/redundancy.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:redundancy" + +\end_inset + +To the left normal execution is pictured; the server state is backed up. + To the left; the exceptional excution, where the state is retrieved from + the backup to repopulate the server. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Hot code replacement +\end_layout + +\begin_layout Standard +Hot code replacement is a technique used to update systems while they are + running. + The main use of hot code replacement are in critical systems that require + low downtime, such as telecom systems. + By using hot code replacement system can be able to achieve as high uptime + as possible and thus improving the reliability of the system. + Code replacement is a feature that exist in Erlang which means that with + some work it could be implemented into the GGS. +\end_layout + +\begin_layout Section +Example of a GGS server application in Javascript +\end_layout + +\begin_layout Standard +Below is a concrete example of a simple chat server application written + using the GGS. + The language chosen for this chat server is JavaScript. + The GGS processes all incoming data through a protocol parser, which interprets + the data and parses it into an internal format for the GGS. +\end_layout + +\begin_layout Standard +When the GGS receives a +\emph on +Game-Command +\emph default + from a client, it is passed along to the game VM through a function called + +\emph on +playerCommand +\emph default + which is the entry point for each game and has to be implemented by the + developer; one can think of it like the +\emph on +main() +\emph default + function of a C or Java programm +\emph on +. + +\emph default + Typically the +\emph on +playerCommand +\emph default + function contains conditional constructs which decide the next action to + take. + In +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-concrete-example" + +\end_inset + + an example of the +\emph on +playerCommand +\emph default + function can be seen. +\end_layout + +\begin_layout Standard +In +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-concrete-example" + +\end_inset + + the +\emph on +playerCommand +\emph default + function accepts two different commands. + The first command is a command which allows chat clients connected to the + chat server to change nicknames, which are used when chatting. + In order to change the nickname, a client must send a Game-Command +\begin_inset Quotes eld +\end_inset + +nick +\begin_inset Quotes erd +\end_inset + + with the actuall new nickname as a argument. + When a message arrives to the GGS which has the form corresponding to the + nickname change, the +\emph on +playerCommand +\emph default + function is called with the parameters +\emph on +player_id, command, +\emph default +and +\emph on +args +\emph default + filled in appropriately. +\end_layout + +\begin_layout Standard +The +\emph on +playerCommand +\emph default + function is responsible for calling the helper functions responsibly for + carrying out the actions of each message received. + +\emph on +changeNick +\emph default + is a function which is called when the +\begin_inset Quotes eld +\end_inset + +nick +\begin_inset Quotes erd +\end_inset + + message is received. + The +\emph on +changeNick +\emph default +function uses a feature of the GGS called localStorage (see section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Communication-with-the-GDL-VM" + +\end_inset + +), which is an interface to the database backend contained in the database + module (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:The-database-module" + +\end_inset + +). + The database can be used as any key-value store, however the syntax for + insertions and fetch operations is tighty integrated in the GDL of the + GGS. +\end_layout + +\begin_layout Standard +Access to the localStorage is provided through the +\emph on +GGS object +\emph default +, which also can be used to communicate with the rest of the system from + the GDL. + Implementation specifics of the GGS object are provided in +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Communication-with-the-GDL-VM" + +\end_inset + +. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +language=JavaScript, +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting}[language=JavaScript] +\end_layout + +\begin_layout Plain Layout + +function playerCommand(player_id, command, args) { +\end_layout + +\begin_layout Plain Layout + + if(command == "nick") { +\end_layout + +\begin_layout Plain Layout + + changeNick(player_id, args); +\end_layout + +\begin_layout Plain Layout + + } else if(command == "message") { +\end_layout + +\begin_layout Plain Layout + + message(player_id, args); +\end_layout + +\begin_layout Plain Layout + + } +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + +function changeNick(player_id, nick) { +\end_layout + +\begin_layout Plain Layout + + var old_nick = GGS.localStorage.getItem("nick_" + player_id); +\end_layout + +\begin_layout Plain Layout + + GGS.localStorage.setItem("nick_" + player_id, nick); +\end_layout + +\begin_layout Plain Layout + + if (!old_nick) { +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll("notice", nick + " joined"); +\end_layout + +\begin_layout Plain Layout + + } else { +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll("notice", old_nick + " is now called " + nick); +\end_layout + +\begin_layout Plain Layout + + } +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + +function message(player_id, message) { +\end_layout + +\begin_layout Plain Layout + + var nick = GGS.localStorage.getItem("nick_" + player_id); +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll('message', nick + "> " + message); +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-concrete-example" + +\end_inset + +A concrete example of a simple chat server written in JavaScript, running + on the GGS +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Chapter +Problems of implementation +\begin_inset CommandInset label +LatexCommand label +name "cha:Problems-of-implementation" + +\end_inset + + +\end_layout + +\begin_layout Standard +This chapter contains specific problems encountered when implementing the + GGS prototype. + Some of the problems described have solutions attached, however some problems + were not solved, therefore only ideas for slutions have been attached. +\end_layout + +\begin_layout Standard +The integration of JavaScript as a GDL in the GGS prototype was particularily + difficult, and is handled in this section. + Unique identification is also handled, as is the design of the GGS protocol. +\end_layout + +\begin_layout Section +JavaScript engine +\end_layout + +\begin_layout Standard +The GGS prototype uses a vistual machine to sandbox each game. + JavaScript was chosen for the prototype due to its commonality in web applicati +ons and the flexibility of the language. + Any language with the proper bindings to Erlang could have been used in + theory. +\end_layout + +\begin_layout Standard +There are two main JavaScript virtual machines, or +\emph on +engines +\emph default + available at the time of the writing of this thesis. + There is a group of machines developed by Mozilla called +\emph on +TraceMonkey, JaegerMonkey, SpiderMonkey +\emph default +and +\emph on +IonMonkey +\emph default +, and also there is Google V8. + The group of Mozilla machines are largely the same, and are referred to + as the same machine for simplicity. +\end_layout + +\begin_layout Standard +For the Mozilla machines, there exists an Erlang binding called erlang_js, + and for the V8 machine a binding called erlv8 exists. +\end_layout + +\begin_layout Subsection +erlang_js +\end_layout + +\begin_layout Standard +Erlang_js provides direct communication with the JavaScript VM. + Which is exactly what is desired, however also required is thee possibility + to communicate from erlang_js to Erlang. + The ability to communicate from JavaScript to Erlang functionality is not + yet implemented in erlang_js, due to lack of time on the behalf of the + erlang_js developers. +\end_layout + +\begin_layout Standard +There were two possible solutions to the problem of the JavaScript to Erlang + communication path missing, the path could be implemented by the GGS project, + or a switch from erlang_js for some other JavaScript engine could be made. + +\end_layout + +\begin_layout Standard +Attempts at creating the communication path from JavaScript to Erlang were + initially made, however the communiucation path never became stable enough + for usage in the GGS and the erlang_js software was abandoned. +\end_layout + +\begin_layout Subsection +erlv8 +\end_layout + +\begin_layout Standard +erlv8 is powered by the V8 engine developed by Google rather than the engines + developed by Mozilla. + The ability to communicate with Erlang from JavaScript using callbacks + is available in the erlv8 bindings, therefore this feature does not have + to be added to the bindings in order to be used in the GGS. +\end_layout + +\begin_layout Standard +Initial releases of the erlv8 bindings had stability issues, these were + however solved by the erlv8 developers during the usage of erlv8 in the + GGS. + erlv8 is the JavaScript engine powering JavaScript as a GDL in the GGS. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{V8}}{JavaScript engine developed by Google} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SpiderMonkey}}{JavaScript engine developed by Mozilla} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +UUID +\end_layout + +\begin_layout Standard +Erlang identifies processes uniquely throughout the entire Erlang network + using process IDs (PID). + When we wish to refer to erlang processes from outside our erlang system, + for example in a virtual machine for a different language, possibly on + a different machine, these PID:s are no longer useful. + +\end_layout + +\begin_layout Standard +This problem is not new, and a common solution is to use a Universally Unique + Identifier, a UUID. + These identifiers are generated both using randomization and using time. + A reasonably large number of UUID:s can be generated before a collision + should occur. + There are standard tools in many UNIX systems to generate UUID:s, we chose + to use the uuidgen command, which employs an equidistributed combined Tausworth +e generator. +\end_layout + +\begin_layout Subsection +Protocol design +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Discuss how the early GGS protocol were going to use both UDP and binary + plists to be as fast as possible. + Then discuss how complex these solutions were going to be to implement + in the prototype. + Mention that the modular structure of the GGS allows these features to + be implemented later on, but are not currently implemented. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Design choices +\begin_inset Note Note +status open + +\begin_layout Plain Layout +This section is wrongly placed +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +When designing concurrent applications, it is useful to picture them as + real world scenarios, and to model each actor as a real world process. + A real world process is a process which performs some action in the real + world, such as a mailbox receiving a letter, a door being opened, a person + translating a text, a soccer player kicking the ball, just to name a few + examples. + Since we focus on games in this project, it is suitable to model our system + as a place where games take place. + We imagined a chess club. + +\end_layout + +\begin_layout Standard +The clients pictured as green circles can be thought of as the physical + chess players. +\end_layout + +\begin_layout Standard +When a player wants to enter the our particular chess club, he must first + be let in by the doorman, called the +\emph on +Dispatcher +\emph default + in the GGS. +\end_layout + +\begin_layout Standard +He then gets a name badge, and thus becomes a +\emph on +Player +\emph default + process in the system. + He is also guided in to the lobby by the +\emph on +Coordinator +\emph default +, which has the role of the host of the chess club. +\end_layout + +\begin_layout Standard +When players wish to play against each other, they talk to the +\emph on +Coordinator +\emph default + who pairs them up, and places them at a table. + Once they have sat down at the table, they no longer need the assistance + of the +\emph on +Coordinator +\emph default +, all further communication takes place via the table. + This can be thought of as the actual chess game commencing. + +\end_layout + +\begin_layout Standard +All the moves made in the game are recorded by the table, such that the + table can restore the game in case something would happen, such as the + table tipping over, which would represent the table process crashing. +\end_layout + +\begin_layout Standard +Once a player wishes to leave a game, or the entire facility, he should + contact the +\emph on +Coordinator +\emph default +, who revokes his name badge and the +\emph on +Dispatcher +\emph default + will let the player out. +\end_layout + +\begin_layout Standard +With the information kept in the tables and the +\emph on +Coordinator +\emph default + combined, we can rebuild the entire state of the server at a different + location. + This can be thought of the chess club catching fire, and the +\emph on +Coordinator +\emph default + rounding up all the tables, running to a new location and building the + club up in the exact state it was prior to the fire. +\end_layout + +\begin_layout Section +Usability +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Discuss how the GGS can be difficult to use for people not versed with Erlang +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Chapter +Results and discussion +\begin_inset CommandInset label +LatexCommand label +name "chap:Results-and-discussion" + +\end_inset + + +\end_layout + +\begin_layout Section +Software development methodology +\end_layout + +\begin_layout Standard +The project has not followed any specific software development methodology. + All work has been based on a predefined schedule and the specifications + are made by team members rather than an outside customer or stakeholder. + The process can be described as a plan-driven development method going + from brainstorming to design, then implementation and finally testing. + Yet there has been cycles in the process in form of redesign and code refactori +ng. +\end_layout + +\begin_layout Section +Statistics +\end_layout + +\begin_layout Standard +Important things to note are that the number of clients is not a good way + of measuring the performance of the server because the server is possible + to have a large number of clients on the server but it can not handle all + the information. + Instead the performance of the server should be measured in the number + of messages it can handle per second. +\end_layout + +\begin_layout Standard +We were able to reach 6000 messages per second on the server, which corresponds + to around 350 clients. + However soon after this mnesia printed some warnings and the clients started + to lag. + With this in mind one thing to investigate is if mnesia is the bottleneck + in the system. + Current game servers do not use databases to save their state and maybe + we can see the reason here. + Other possible bottlenecks may be the protocol, but this seems less likely + than mnesia. + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/msg_per_sec.eps + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout + +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/ping.eps + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout + +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/msg_per_secoutput.eps + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout + +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Future improvements +\end_layout + +\begin_layout Standard +The specification of the GGS prototype is huge and like many other software + projects relying on outside technologies, in time it would require a lot + of maintanance. + Therefore there are a lot of areas in which the GGS could be improved such + as performance, compatibility, ease of setup and usage. +\end_layout + +\begin_layout Subsection +Performance +\end_layout + +\begin_layout Subsubsection +Protocols +\end_layout + +\begin_layout Standard +Because of TCP being a connection oriented protocol, it is not suited for + all types of game data transfers. + Each transmission will consume more network bandwith than connectionless + protocols like UDP and cause uneccessary load on the processor. + Therefore support for UDP would mean that more games could be run simultaneousl +y on the GGS. + Another advantage of UDP is latency being reduced. + Without having to setup a connection for each group packets of data being + sent, they will be sent instantly and therefore arrive earlier. + Latency is of highest importance in realtime games as it improves realism + and fairness in gameplay and many game developers requires the freedom + to take care of safety issues as packet losses themselves. + This concludes that UDP would be a benefit for the GGS, game developers + and players alike. +\end_layout + +\begin_layout Subsubsection +Database +\end_layout + +\begin_layout Standard +Currently Mnesia is used for game data storage. + During stress tests, Mnesia has turned out to be the bottleneck due to + data losses when too many games are played on the GGS simultaneously. + This could be prevented by replacing Mnesia with another database management + system or use Mnesia in combination with the ETS module of erlang. + ETS provides fast access to the RAM and thus Mnesia could be used less + frequently. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{ETS}}{Erlang Term Storage} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Compatibility +\end_layout + +\begin_layout Standard +GGS relies on modern technologies. + This includes the virtual machines(VM) that the GGS uses for communication + between Erlang and the GDL:s. + These specific VM:s are crucial for game developers to be able to write + games in other languages than Erlang. + Therefore it would be best for the GGS to have as many of these VM:s implemente +d as possible. + The VM:s taken into consideration so far have been unstable or incomplete + and it is possible to search for more VM:s, testing them and intergrate + them into the GGS prototype. +\end_layout + +\begin_layout Subsection +Setup +\end_layout + +\begin_layout Standard +The GGS prototype installation procedure requires different configuring + and building steps and thus it isn't in an acceptable release state. + An executable installation file for each supported platform would be optimal. +\end_layout + +\begin_layout Subsection* +5.3.4 Usage +\end_layout + +\begin_layout Subsubsection +Programming languages +\end_layout + +\begin_layout Standard +The GGS does not support many programming languages. + For a programming language to be compatible with the GGS, not only does + it require a VM for that specific language, but the VM must have the ability + to communicate to Erlang. + More research is needed to find VM:s with this built in functionality. + +\end_layout + +\begin_layout Subsubsection +Documentation +\end_layout + +\begin_layout Standard +To start the GGS is not self explanatory. + This together with overall usage of GGS should be documented. + The interface for usage of game developers is also in need of documentation. + Features and requirements with respect to the GGS would assist users to + know what they need in order to use the GGS and how they would benefit + of it. + The GGS does not support many programming languages nor does it have a + complete documentation. + This needs to be taken care of in future versions. +\end_layout + +\begin_layout Chapter +Conclusion +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +addcontentsline{toc}{section}{Glossary} +\end_layout + +\begin_layout Plain Layout + + +\backslash +printnomenclature +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard + +\end_layout + +\begin_layout Standard +\begin_inset CommandInset bibtex +LatexCommand bibtex +bibfiles "bibliography" +options "plainnat" + +\end_inset + + +\end_layout + +\end_body +\end_document diff --git a/report.lyx b/report.lyx index e3e7d06..c99883f 100644 --- a/report.lyx +++ b/report.lyx @@ -5797,14 +5797,14 @@ The JavaScript VM (JSVM) - at this stage Googles V8 JavaScript Engine - \end_layout \begin_layout Enumerate -In the example ( +In the example in section \begin_inset CommandInset ref LatexCommand ref -reference "sec:Example-of-a-GGS-server-application-in-JavaScript" +reference "sec:Example-of-a-GGS-app" \end_inset -) we see that the GGS-functions + we see that the GGS-functions \emph on GGS.localStorage.setItem(key, value) \emph default @@ -6703,7 +6703,14 @@ Hot code replacement is a technique used to update systems while they are \end_layout \begin_layout Section -Example of a GGS server application in Javascript +Example of a GGS server application in JavaScript +\begin_inset CommandInset label +LatexCommand label +name "sec:Example-of-a-GGS-app" + +\end_inset + + \end_layout \begin_layout Standard diff --git a/working.lyx b/working.lyx new file mode 100644 index 0000000..bdc12ed --- /dev/null +++ b/working.lyx @@ -0,0 +1,7223 @@ +#LyX 2.0 created this file. For more info see http://www.lyx.org/ +\lyxformat 413 +\begin_document +\begin_header +\textclass report +\begin_preamble +\usepackage{indentfirst} +\usepackage{tocloft} +\usepackage{calc} +\date{} +\usepackage[section] {placeins} +\def\myClearpage{% + \ifvmode + \ifnum \@dbltopnum =\m@ne + \ifdim \pagetotal <\topskip + \hbox{}% + \fi + \fi + \fi +% \newpage + \write\m@ne{}% + \vbox{}% + \penalty -\@Mi +} +\def\myCleardoublepage{\myClearpage\if@twoside \ifodd\c@page\else + \hbox{}\if@twocolumn\hbox{}\fi\fi\fi} +\usepackage{morefloats} +\usepackage{graphicx} +\usepackage{subfig} +\usepackage{tocloft} +\renewcommand{\cftchapfont}{\bfseries} +\renewcommand{\cftchappagefont}{\bfseries} +\renewcommand{\cftchappresnum}{Chapter } +\renewcommand{\cftchapnumwidth}{6em} + +\oddsidemargin 0.5in +\textwidth 6in +\topmargin 0.0in +\textheight 8.0in +\setlength\topskip{24pt} +\footskip 0.75in + +\usepackage[compact]{titlesec} + + +\titleformat{\chapter}[display] +{\vskip-8em\normalfont\bfseries} +{\LARGE\raggedright\thechapter} +{14ex} +{\vspace{-20ex}% +\LARGE\raggedleft} +[\vspace{1ex}% +{\titlerule[1pt]}] + +\usepackage[absolute]{textpos} + +\usepackage{fancyheadings} +\pagestyle{fancy} +\lhead{\thechapter} + +\usepackage[hmargin=3cm,vmargin=3.5cm]{geometry} +\usepackage{algorithmic} +\usepackage{listings} + +\usepackage{color} +\definecolor{lightgray}{rgb}{.9,.9,.9} +\definecolor{darkgray}{rgb}{.4,.4,.4} +\definecolor{purple}{rgb}{0.65, 0.12, 0.82} + +\lstdefinelanguage{JavaScript}{ + keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break}, + keywordstyle=\color{blue}\bfseries, + ndkeywords={class, export, boolean, throw, implements, import, this}, + ndkeywordstyle=\color{darkgray}\bfseries, + identifierstyle=\color{black}, + sensitive=false, + comment=[l]{//}, + morecomment=[s]{/*}{*/}, + commentstyle=\color{purple}\ttfamily, + stringstyle=\color{red}\ttfamily, + morestring=[b]', + morestring=[b]" +} + +\lstdefinelanguage{Erlang}{ + keywords={typeof, true, false, catch, return, null, catch, switch, var, if, in, while, do, else, case, break, expose}, + keywordstyle=\color{blue}\bfseries, + ndkeywords={class, export, boolean, throw, implements, import, this,erlv8_vm, erlv8_fun_invocation +,erlv8_object}, + ndkeywordstyle=\color{darkgray}\bfseries, + identifierstyle=\color{black}, + sensitive=false, + comment=[l]{\%}, + morecomment=[s]{/*}{*/}, + commentstyle=\color{purple}\ttfamily, + stringstyle=\color{red}\ttfamily, + morestring=[b]', + morestring=[b]" +} + +\usepackage{float} + +\floatstyle{ruled} +\newfloat{code}{thp}{lop} +\floatname{code}{Code} + +\usepackage{nomencl} +\makenomenclature +\renewcommand{\nomname}{Glossary} +\end_preamble +\use_default_options true +\maintain_unincluded_children false +\language english +\language_package default +\inputencoding auto +\fontencoding global +\font_roman lmodern +\font_sans default +\font_typewriter default +\font_default_family rmdefault +\use_non_tex_fonts false +\font_sc false +\font_osf false +\font_sf_scale 100 +\font_tt_scale 100 + +\graphics default +\default_output_format default +\output_sync 0 +\bibtex_command default +\index_command default +\paperfontsize default +\spacing onehalf +\use_hyperref false +\papersize a4paper +\use_geometry false +\use_amsmath 1 +\use_esint 1 +\use_mhchem 1 +\use_mathdots 1 +\cite_engine natbib_authoryear +\use_bibtopic false +\use_indices false +\paperorientation portrait +\suppress_date false +\use_refstyle 0 +\index Index +\shortcut idx +\color #008000 +\end_index +\paperwidth 11in +\paperheight 8.5in +\leftmargin 1.25in +\topmargin 0in +\rightmargin 1in +\bottommargin 1.7in +\secnumdepth 2 +\tocdepth 2 +\paragraph_separation indent +\paragraph_indentation default +\quotes_language english +\papercolumns 1 +\papersides 1 +\paperpagestyle empty +\tracking_changes false +\output_changes false +\html_math_output 0 +\html_css_as_file 0 +\html_be_strict false +\end_header + +\begin_body + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{textblock*}{ +\backslash +paperwidth}(0mm,40mm) +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{center} +\end_layout + +\begin_layout Plain Layout + + +\backslash +includegraphics[width= +\backslash +paperwidth/2]{graphics/logo} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{center} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{textblock*} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Title +A Reliable Generic Game Server +\end_layout + +\begin_layout Author +Niklas Landin +\begin_inset Newline newline +\end_inset + +Richard Pannek +\begin_inset Newline newline +\end_inset + +Mattias Pettersson +\begin_inset Newline newline +\end_inset + +Jonatan Pålsson +\end_layout + +\begin_layout Abstract +This is the abstract! +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +pagenumbering{roman} +\end_layout + +\begin_layout Plain Layout + + +\backslash +setcounter{page}{3} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +contentsname{Table of Contents} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand{ +\backslash +cfttoctitlefont}{ +\backslash +hfill +\backslash +Large} +\backslash +renewcommand{ +\backslash +cftaftertoctitle}{ +\backslash +hfill} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +cftpartdotsep{6.6} +\end_layout + +\begin_layout Plain Layout + + +\backslash +renewcommand +\backslash +cftchapdotsep{6.6} +\end_layout + +\end_inset + + +\begin_inset CommandInset toc +LatexCommand tableofcontents + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Newpage newpage +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +pagenumbering{arabic} +\end_layout + +\begin_layout Plain Layout + + +\backslash +setcounter{page}{1} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Chapter +Introduction +\end_layout + +\begin_layout Standard +Online gaming, and computer gaming in general has become an important part + in many peoples day-to day lives. + A few years ago, computer games were not at all as popular as they are + today. + With the advances in computer graphics and computer hardware today's games + are much more sophisticated then they were in the days of +\emph on +NetHack +\emph default +, +\emph on +Zork, +\emph default +or +\emph on +Pacman. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Zork}}{A textual computer game developed by students at MIT} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Pacman}}{An early graphical computer game developed by Namco} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{NetHack}}{An early computer game developed by the NetHack team, arguably + the oldest computer game still in development} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The early computer games featured simple, or no graphics at all +\begin_inset CommandInset citation +LatexCommand citet +key "nethack:website" + +\end_inset + +. + The games often took place in a textual world, leaving the task of picturing + the world up to the player. + Multi-player games were not as common as they are today, whereas most games + today are expected to have a multi-player mode, most early games did not. +\end_layout + +\begin_layout Standard +Since these early games, the gaming industry have become much more influential + in many ways. + Many advanced in computer hardware are thought to come from pressure from + the computer game industry. + More powerful games require more powerful, and more easily available hardware +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Drop a reference to the gaming industry pressuring more advanced hardware +\end_layout + +\end_inset + +. + Due to the high entertainment value of modern computer games, gaming has + become a huge industry, where large amounts of money are invested. + The gaming industry is today, in some places even larger than the motion + picture industry. + +\begin_inset CommandInset citation +LatexCommand citet +key "esa:website,thenumbers:website" + +\end_inset + + +\end_layout + +\begin_layout Standard +Due to the increasing importance of computer gaming, more focus should be + spent on improving the quality of the gaming service. + As more and more computer games are gaining multi-player capabilities, + the demands for multiplayer networking software rises. + This thesis is about techniques for improving the quality of this networking + software. +\end_layout + +\begin_layout Standard +The reliable generic game server, hereafter known as GGS +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{GGS}}{Generic Game Server, a software for reliably hosting network + games. + The subject of this thesis.} +\end_layout + +\end_inset + +, is a computer program designed to +\emph on +host +\emph default + network games on one or more server computers. + Hosting, in a network software setting, means allowing client software + connect to the server software, for the purpose of utilizing services provided + by the server. + The GGS software provides games as a service, and the clients connecting + to the GGS can play these games on the GGS. +\end_layout + +\begin_layout Standard +The idea of game servers is not new, network games have been played for + decades. + Early, popular examples of network games include the +\emph on +Quake +\emph default + series, or the +\emph on +Doom +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout + +\emph on +Come up w/ better game +\end_layout + +\end_inset + + +\emph default + games. + Newer examples of network games include +\emph on +World of Warcraft +\emph default +, and +\emph on +Counter-Strike +\emph default +. + The difference between the GGS and the servers for these games is that + the servers for Doom, Quake, and the others listed, were designed with + these specific games in mind. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Quake}}{A first person shooter series developed by ID software. + The series consists of four games.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Doom}}{A first person shooter series developed by ID software. + The series consists of three games.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{World of Warcraft}}{A MMORPG game developed by Blizzard. + The world's most popular MMORPG by subscriber count.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Counter-Strike}}{A multiplayer first person shooter game, popular + in E-Sports.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Framework}}{A supporting structure, the GGS is a framework for developing + network games} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{First-person shooter}}{A game in which centers around gun combat + from the first person perspective.} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{MMORPG}}{Massively multiplayer online role playing game. + An online game with several thousand participants.} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +What GGS does is to provide a +\emph on +generic +\emph default + framework for developing network games. + The framework is generic in the sense that it is not bound to a specific + game. + There are many different types of games, some are inherently more time + sensitive than others, strategy games are examples of games which are not + very sensitive to time delays, first-person shooters however, can be very + sensitive. +\end_layout + +\begin_layout Standard +The generic nature of the GGS allows the creation of many different types + of games, the motivation behind this is to remove the necessity of writing + new game servers when developing new games. +\end_layout + +\begin_layout Standard +The GGS is in addition to being generic, also +\emph on +reliable +\emph default + in the sense that the gaming service provided is consistent and available. + A consistent and available server is a server that handles hardware failures + and software failures gracefully. + In the event of a component breaking within the GGS, the error is handled + by fault recovery processes, thereby creating a more reliable system. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Hardware failiure}}{A failiure in hardware (hard drive, memory, processor +, etc) which causes a system to stop functioning} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Software failiure}}{A failiure in software (the GGS, the operating + system, etc) which causes a system to stop functioning} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Background +\end_layout + +\begin_layout Standard +The game industry is a quickly growing industry where the need for new technique +s are large. + One specific section where the development has stalled is the game server + section. +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + + The existing game servers are functional but they lack good fault tolerance + and the ability to scale well +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + +. + Users will notice this in low uptime and many crashes. + This is a problem that has existed and been resolved in other industries. + In the telecom industry solutions to similar problems have been found. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{The nine nines}}{A common goal for availability in the telecom business. + A system with nine nines of availability is available 99.999999999% of the + time} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Downtime}}{The amount of time a system is unavailable and does not + function} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Uptime}}{The amount of time a system is available and functions} +\end_layout + +\end_inset + +A common figure often used in telecoms is that of +\emph on +the nine nines +\emph default +, referring to +\begin_inset Formula $99.999999999\%$ +\end_inset + + of availability, or rougly +\begin_inset Formula $15ms$ +\end_inset + + downtime in a year +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed +\end_layout + +\end_inset + +. + The level of instability and bad fault tolerance seen in the game server + industry would not have been accepted in the telecoms industry. + This level of instability should not be accepted in the game server industry + either. + An unavailabvle phone system could potentially have life threatening consequenc +es, leaving the public unable to contant emergency services. + The same can not be said about an unavailable game server. + The statement that game servers are less important than phone systems is + not a reason not to draw wisdom from what the telecoms have already learnt. +\end_layout + +\begin_layout Standard +Moving back to the gaming industry. + The main reason to develop reliable servers are monetary, it is important + for game companies to expand its customer base. + Reliable game servers are one improvement that will create a good image + of a company. + In general the downtime of game servers is much higher than the downtime + of telecom system +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Citation needed... +\end_layout + +\end_inset + +. + The structure of the system is similar in many ways and it should be possible + to reuse solutions from the telecom system to improve game servers. + +\end_layout + +\begin_layout Standard +In the current state game servers are developed on a per-game basis, in + many cases this seems like a bad solution. + Developers of network game need to understand network programming. + A way to change this is a generic game server which give the game developers + a server which they implement their game towards. + This approach would not only make it easier to develop network games, it + would also allow games in different programming languages to be implemented + using the same server. +\end_layout + +\begin_layout Standard +Some factors key to the development of GGS have been isolated. + Many of these come from the telecom sector. + The factors are +\emph on +scalability, fault tolerance +\emph default +and being +\emph on +generic +\emph default +. + These terms are defined below. +\end_layout + +\begin_layout Standard +Scalability (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Scalability" + +\end_inset + +) in computer science is a large topic and is commonly divided into sub-fields, + two of which are +\emph on +structural scalability +\emph default + and +\emph on +load scalability +\emph default + +\begin_inset CommandInset citation +LatexCommand citet +key "Bondi:2000:CSI:350391.350432" + +\end_inset + +. + These two issues are addressed in this thesis. + Structural scalability means expanding an architecture, e.g. + adding nodes to a system without requiring modification of the system. + Load scalability means using the available resources in a way which allows + handling increasing load, e.g more users, gracefully. +\end_layout + +\begin_layout Standard +Fault tolerance (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Fault-Tolerance" + +\end_inset + +) is used to raise the level of +\emph on +dependability +\emph default + in a system, so that the dependability is high even in presence of errors. + Dependability is defined as the statistical probability of the system functioni +ng as intended at a given point in time. + Fault tolerance is defined as the property of a system to always follow + a specification, even in the presence of errors. + The specification could take the form of error handling procedures which + activate when an error occurs. + This means that a fault tolerant, dependable system, will have a very high + probability of functioning at a given point in time, and is exactly what + is desired. + +\begin_inset CommandInset citation +LatexCommand citet +key "Gartner:1999:FFD:311531.311532" + +\end_inset + + +\end_layout + +\begin_layout Standard +A generic (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Generic" + +\end_inset + +) game server has to be able to run different client-server network games + regardless of the platform the clients are running on. + It runs network games of different type. + A very rough separation of games is real time games and turn based games. +\end_layout + +\begin_layout Standard +The server behaves in a way similar to an application server, but is designed + to help running games. + An application server provides processing ability and time, therefore it + is different from a file- or print-server, which only serves resources + to the clients. +\end_layout + +\begin_layout Standard +The most common type of application servers are web servers, where you run + a web application within the server. + The application server provides an environment and interfaces to the outer + world, in which applications run. + Hooks and helpers are provided to use the resources of the server. + Some examples for web application servers are the +\emph on +Glassfish +\emph default + server which allows running applications written in Java or the +\emph on +Google App Engine +\emph default + where you can run applications written in Python or some language which + runs in the +\emph on +Java Virtual Machine +\emph default +. + An example of an application server not powering web applications, but + instead regular business logic, is Oracle’s +\emph on +TUXEDO +\emph default + application server, which can be used to run applications written in COBOL, + C++ and other languages. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SQL}}{Structured Query Language, a computer language common in querying + certain databases} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{JavaScript}}{A programming language originally developed by Netscape, + common in web programming} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{COBOL}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{C++}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Java}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{AXD301}}{Telephone switch developed by Ericsson} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Erlang}}{A concurrent programming language, often used for telecom + applications. + The main language of the GGS} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +A database server can also be seen as an application server. + Scripts, for example SQL queries or JavaScript, are sent to the server, + which runs them and returns the evaluated data to the clients. + +\end_layout + +\begin_layout Standard +One purpose of this thesis is to investigate how we can make a game server + as generic as possible. + Some important helpers are discussed, such as abstraction of the network + layer, data store and game specific features. + +\end_layout + +\begin_layout Standard +As an aid in discussing the theoretical parts of the GGS a prototype has + been developed. + The prototype does not feature all of the characteristics described in + this thesis. + A selection has been made among the features, and the most important ones + have been implemented either full or in part in the prototype. +\end_layout + +\begin_layout Standard +The choice of implementation language for the prototype of the GGS was made + with inspiration from the telecom industry. + The Erlang language was developed by the telecom company Ericsson to develop + highly available and dependable telecom switches. + One of the most reliable systems ever developed by Ericsson, the AXD301 + was developed using Erlang. + The AXD301 is also possibly has the largest code base even written in a + functional language +\begin_inset CommandInset citation +LatexCommand citep +key "Armstrong03" + +\end_inset + +. + The same language is used to develop the prototype of the GGS. + Usage of Erlang in the GGS is discussed in further detail in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:The-usage-of-erlang" + +\end_inset + +. + Chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Implementation-of-a" + +\end_inset + + provides a description of the prototype developed for this thesis. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +We could go on and on about erlang.. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Purpose +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout +The purpose of the GGS project. + What is the purpose of creating a fault tolerant server, why is it generic, + and what good does it do to have a scalable system? In the background, + we should give the motivations behind creating this software, but here + we should outline why the software is needed. + This section should be shortened, and the bulk of the text should be moved + to theory or background. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The purpose of creating a generic and fault tolerant game server is to provide + a good framework for the development of many different types of games. + Allowing the system to scale up and down is a powerful way to maximize + the usage of physical resources. + By scaling up to new machines when load increases, and scaling down from + machines when load decreases costs and energy consumption can be optimized. +\end_layout + +\begin_layout Standard +Fault tolerance is important for the GGS to create a reliable service. + The purpose of a reliable game server is to provide a consistent service + to people using the server. + Going back to the telecom example, the purpose of creating a reliable telecom + system is to allow calls, possibly emergency calls, at any time. + Should the telecom network be unavailable at any time, emergency services + may become unavailable, furthermore the consumer image of the telecom system + degrades. +\end_layout + +\begin_layout Standard +Returning to the game industry, emergency services will not be contacted + using a game server, however an unavailable server will degrade the consumer + image of the system. + Consider an online casino company. + The online casino company's servers must be available at all times to allow + customers to play. + If the servers are unavailable, customers can not play, and the company + loses money. + In this scenario, an unavailable server can be compared to a closed real-world + casino. +\end_layout + +\begin_layout Section +Challenges in developing the prototype +\end_layout + +\begin_layout Standard +The word +\emph on +generic +\emph default + in the name of the GGS implies that the system is able to run a very broad + range of different code, for instance code wrote in different programming + languages, besides a broad range of different game types. + To support this, a virtual machine (VM) for each +\emph on +game development language +\emph default + (hereafter GDL for brevity) is used. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{GDL}}{Game Development Language, the language used to program games + in the GGS} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{VM}}{Virtual Machine} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +No hard limit has been set on which languages can be used for game development + on the GGS, but there are several factors which decide the feasibility + of a language: +\end_layout + +\begin_layout Itemize +How well it integrates with Erlang, which is used in the core the GGS system + +\end_layout + +\begin_layout Itemize +How easy it is to send messages to the virtual machine of the GDL from the + GGS +\end_layout + +\begin_layout Itemize +How easy it is to send messages from the GDL VM to the GGS +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add more like threads, events, etc. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Internally, the GDL VM needs to interface with the GGS to make use of the + helpers and tools that the GGS provides. + Thus an internal API has to be designed for use in interacting with the + GGS. + This API is ideally completely independent of the GDL, and reusable for + any GDL. +\end_layout + +\begin_layout Standard +The communication with gaming clients has to take place over a protocol. + Ideally a standard protocol should be used, in order to shorten the learning + curve for developers, and also make the system as a whole less obscure. + A large challenge during this project is to decide whether an existing + protocol can be used, and if not, how a new protocol can be designed which + performs technically as desired, while still being familiar enough to existing + developers. +\end_layout + +\begin_layout Standard +A great deal of work is devoted to make the GGS +\emph on +reliable +\emph default +. + This includes ensuring that the system scales well, and to make sure it + is fault tolerant. + In order to facilitate scalability, we need a storage platform which is + accessible and consistent among all of the GGS, this is also investigated. +\end_layout + +\begin_layout Section +Limitations of the prototype +\end_layout + +\begin_layout Standard +The implementation of the GGS protocol, together with storage possibilities, + server capacity, and game language support imposes some limitations on + the project. + To get a functional prototype some limits must be set on the types games + that can be played on the prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{UDP}}{User Datagram Protocol, a connectionless networking protocol} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{TCP}}{Transmission Control Protocol, a streaming network protocol} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The UDP protocol is not supported for communication between client and server. + The TCP protocol was chosen in favour of UDP, due to the fact that the + implementation process using TCP was faster than if UDP would have been + used. + UDP is generally considered to be faster than TCP for the transfer of game + (and other) related data, this is discussed in more depth in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Choice-of-network" + +\end_inset + +. + In short, the decision of using TCP means that games that requires a high + speed protocol will not be supported by the GGS prototype. + Another limitation necessary to set on the system is the possibility to + have huge game worlds due to the implementation of the scaling mechanism + in the prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Latency}}{A measure of delay, often measured in milliseconds} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +In real time games all players are playing together at the same time. + Latency is a huge problem in real time games, a typical round trip time + for such games are one of +\begin_inset Formula $50$ +\end_inset + + to +\begin_inset Formula $150ms$ +\end_inset + + and everything above +\begin_inset Formula $200ms$ +\end_inset + + is reported to be intolerable +\begin_inset CommandInset citation +LatexCommand citet +key "Farber:2002:NGT:566500.566508" + +\end_inset + +. + Latency sensitive games include most of the first person shooters with + multiplayer ability, for example +\emph on +Counter Strike +\emph default + or massively multiplayer online role playing games (MMORPG:s), for example + +\emph on +World of Warcraft +\emph default +. +\end_layout + +\begin_layout Standard +In turn based games each player has to wait for their turn. + Latency is not a problem since the gameplay does not require fast interactions + among the players, long round trip times will not be noticed. + Examples of turn based games include board and card games, as well as multiplay +er games like +\emph on +Jeopardy +\emph default +. + Both game types have varying difficulties and needs when it comes to implementi +ng them, a Generic Game Server should address all of them and help the developer + to accomplish his goal. +\end_layout + +\begin_layout Standard +Due to the limited capability of threading in many GDL VM:s, the GGS prototype + will not support MMORPG:s. +\end_layout + +\begin_layout Standard +The implementation of the GGS described in this thesis is only a small prototype + and tests will be performed on simple games like pong or chess, thus there + are no need to implement more advanced features in the system. + Note that these limitations only apply for the prototype of the project, + and that further developments to the GGS could be to implement these features. +\end_layout + +\begin_layout Section +Method +\end_layout + +\begin_layout Standard +A prototype was developed early on in the project to carry out experiments. + Using this prototype, the system was divided into modules. + A demand specification was created, using this specification, the modules + were easily identifiable. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Module}}{A part of a larger system} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The first prototype of the GGS consisted of simple modules, however, due + to the separation of concerns among the modules, they were easily independently + modified and improved. +\end_layout + +\begin_layout Standard +Once the basic structure of the GGS had been established, the first prototype + was removed, remaining was the structure of the modules and the internal + flow of the application. +\end_layout + +\begin_layout Standard +Design This could be seen as an interative workflow, with the first prototype + being the first iteration. + The second iteration later became the final result of the GGS. +\end_layout + +\begin_layout Standard +The layout of the GGS is both layered and modular. + The first layer handles the most primitive data and produces a higher level + representation of the data, passing it along to different modules of the + GGS. + The modular structure of the GGS plays an important role in making the + system fault tolerant. + The approach to fault tolerance is by replication, and restarting the faulting + modules with the last known good data. +\end_layout + +\begin_layout Standard +An informal specification and list of requirements of the system was outlined + early on in the project. + Usaility goals for developers were set. + During the project several demo applications were constructed, by constructing + these applications, the usability goals were enforced. +\end_layout + +\begin_layout Chapter +Theory behind the GGS +\begin_inset CommandInset label +LatexCommand label +name "cha:Theory" + +\end_inset + + +\end_layout + +\begin_layout Standard +In this chapter, the theory behind the techniques used in the GGS are discussed. + Performance issues and the measuring of performance is discussed. + Benchmarking techniques are discussed. + The options when choosing network protocols are given, along with a discussion + of each alternative. + Finally, an overview of scalability, fault tolerance and availability are + presented. +\end_layout + +\begin_layout Section +Design of the GGS system +\begin_inset CommandInset label +LatexCommand label +name "sec:Design-of-the" + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS is modeled after a real world system performing much of the same + duties as GGS. + This is common practice +\begin_inset CommandInset citation +LatexCommand citep +key "armstrong2011" + +\end_inset + + in the computer software world, to understand complex problems more easily. + While there may not always be a real world example of a system performing + the exact duties of the system being modeled in the computer, it is often + easier to create and analyze requirements for real world systems and processes + than systems existing solely in a computer. + The requirements and limitations imposed on the real-world system can, + using the proper tools, be transferred in to the software. +\end_layout + +\begin_layout Standard +The real world system chosen for the GGS is a +\begin_inset Quotes eld +\end_inset + +Chess club +\begin_inset Quotes erd +\end_inset + + - a building where chess players can meet and play chess. + Since a real-world scenario is readily available, and to such a large extent + resembles the computer software required for the GGS, the next step in + developing the GGS system is to duplicate this real world scenario in a + software setting. +\end_layout + +\begin_layout Standard +Some requirements, limitations and additions were made to the chess club + system, so that the system would more easily and efficiently be replicated + in a software setting. +\end_layout + +\begin_layout Standard +In the text below, two examples will be presented. + On example is that of a real-world chess club, in which players meet to + play chess against each other, the other example is the GGS, and how it + corresponds to this chess club. + +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/theory_layout.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:theory-layout" + +\end_inset + +The layout of a physical +\begin_inset Quotes eld +\end_inset + +Chess club +\begin_inset Quotes erd +\end_inset + + with two players (P) sitting by each chess table (Table), a coordinator + keeps track of all moves and players in the building. + A player has to pass by the entrance to enter or exit the building. + The building is represented by the outermost box. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +In figure +\begin_inset CommandInset ref +LatexCommand vref +reference "fig:theory-layout" + +\end_inset + + a graphical representation for the chess club is presented. + The club is seen from above. + The outermost box represents the building. + In the GGS setting, the building would represent one instance of GGS. + Several buildings linked together would represent a cluster of GGS instances. + In order for a player (the P symbol in the graphic) to enter the theoretical + chess club, the player must pass by the entrance. + By having each player pass by the entrance, a tally +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Does this mean what I think it does? +\begin_inset Quotes eld +\end_inset + +Räkning +\begin_inset Quotes erd +\end_inset + + ? +\end_layout + +\end_inset + + can be kept, ensuring that there are not too many players within the building. + In the GGS setting, too many players entering would mean too many connections + have been accepted by the GGS system, and that the structure of the system + thus must be modified, adding additional servers. +\end_layout + +\begin_layout Standard +Once a player has been allowed in to the chess club the player is greeted + by the host of the chess club, in the GGS setting represented by the +\emph on +Coordinator +\emph default +, and is seated by a table. + The coordinator keeps track of all the players in the building, and all + moved made by the players. + The information available to the coordinator means that cheating can be + monitored and book keeping can be performed by this entity. +\end_layout + +\begin_layout Standard +Moves by players are made using the tables present in the chess club. + Every game is isolated to a table, just as expected. + This means that communication during a game only has to pass by the players + of that particular game, and the coordinator, making sure that no cheating + takes place. +\end_layout + +\begin_layout Standard +This isolation of the games play an important part in many properties of + the GGS, the isolation means that games can for example be transferred + among different chess clubs, furthermore, if cheating takes place, corruption + can only occur in the particular table where it was found, and can not + spread. +\end_layout + +\begin_layout Standard +Moving chess players from one location to another is one alteration made + to the real world chess club system to make the system more appropriate + for a software setting. + Allowing games to be transferred is not a property usually desired in a + real world chess club, where transferring players would mean moving the + players from one building to another. + In the software setting, moving players means moving the game processes + from one system to another, perhaps to balance the system load. + This transfer of players can occur transparently, without notifying the + players. +\end_layout + +\begin_layout Standard +The simplified life cycle of a game in GGS can be viewed using algorithm + +\begin_inset CommandInset ref +LatexCommand vref +reference "alg:game-lifecycle" + +\end_inset + +. + To make this life cycle as efficient and useful as possible, the scalability, + fault tolerant and generic traits are added to the GGS. + These are not shown in the algorithm, as these traits are tools in making + the algorithm behaves as efficient as possible, and are not the main focus + when studying the life cycle of a game. +\end_layout + +\begin_layout Standard +The limits imposed in +\begin_inset CommandInset ref +LatexCommand vref +reference "alg:game-lifecycle" + +\end_inset + + are arbitrary for this example, there are no limits in the GGS on the number + of players connecting, for example. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{algorithmic}[1] +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +newcommand{ +\backslash +INDSTATE}[1][1]{ +\backslash +STATE +\backslash +hspace{#1 +\backslash +algorithmicindent}} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +while +\series default + +\begin_inset Formula $players<2$ +\end_inset + +: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + +\series bold +if +\series default + a player connects, call +\emph on +connected +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +while +\series default +the game commences: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +call the function +\emph on +game +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +when +\series default + the game has stopped +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +call the function +\emph on +endGame +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +function +\series default +connected: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +assign the new player an id +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +alert the coordinator of the new player +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + +\series bold +if +\series default + a free table does not exist: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE[2] +\end_layout + +\end_inset + +the coordinator creates a new table +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +the coordinator places the player by the table, and begins watching the + player +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +function +\series default + game +\series bold +: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + perform game-specific functions. + In chess, the rules of chess are placed here +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +function +\series default +endGame: +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +alert the coordinator, de-registering the players +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + +disconnect the players from the system, freeing system resources +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{algorithmic} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:game-lifecycle" + +\end_inset + +A very simple example of the flow through the GGS system when a game played. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Performance +\end_layout + +\begin_layout Standard +There are many ways in which performance could be measured. + For the clients, time and response times are useful measurements in time + critical settings. + In non-time critical settings, the reliability of message delivery may + be an even more important factor than speed. +\end_layout + +\begin_layout Standard +In a first person shooter game, the speed of delivery of messages is essential. + Failure to deliver messages in time results in choppy gameplay for the + players. + In strategy games, the reliability of delivery may be more important than + the speed, since the game is not perceieved as choppy even if the messages + are delayed. +\end_layout + +\begin_layout Standard +For someone operating a GGS, it is perhaps more interesting to measure the + system load, memory consumption, energy consumption and network saturation. + These topics are discussed in theory in this section. + The practical results for the prototype is discussed in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Implementation-of-a" + +\end_inset + +. +\end_layout + +\begin_layout Subsection +Performance measurements +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Tue apr 26, 9:15. + Continue from here on. + Discuss which results we may expect in a fully fledged GGS system. + What impedes the speeds, what raises the CPU load (and therefore the temperetur +es & power consumption). + What factors are there in the network saturation problem? +\end_layout + +\begin_layout Plain Layout +Which games are affected by what, and what does this mean for the number + of players a GGS can handle? +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +How many players can we have on a server? Performance differences between + games? e.g can one game have thousands players on a server and another only + have hundreds? Questions +\end_layout + +\begin_layout Standard +In the current state game servers is coded for each game that needs it, + in many cases this seems like a bad solution. + Developers that want to make a network game need to understand network + programming. + A way to change this is a generic game server which give the game developers + a server which they implement their game towards. + This approach would not only make it easier to develop network games, it + would also allow games in different programming languages to be implemented + using the same server. + to be discussed here. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Create a game with several thousand players, see how our server scales, + how can we improve the performance? Sharding isn’t very nice.. + alternatives? Improve the speed of sharding? +\end_layout + +\begin_layout Itemize +See how the server scales +\end_layout + +\begin_deeper +\begin_layout Itemize +When adding many clients +\end_layout + +\begin_deeper +\begin_layout Itemize +Measure in +\begin_inset Formula $ms$ +\end_inset + + (ping to clients) +\end_layout + +\begin_layout Itemize +measure in system load +\end_layout + +\begin_layout Itemize +Measure in loss of messages +\end_layout + +\begin_layout Itemize +Measure in # of timeouts? (if any??) +\end_layout + +\begin_layout Itemize +Measure in time-to-crash +\end_layout + +\end_deeper +\begin_layout Itemize +When adding new machines to the pool +\end_layout + +\begin_deeper +\begin_layout Itemize +% increase of performance per machine +\end_layout + +\end_deeper +\begin_layout Itemize +Single-core CPU vs multi-core CPU +\end_layout + +\begin_deeper +\begin_layout Itemize +It's very important to scale well on multi-core systems, since this is where + the industry is going. + Multicore is the future. +\end_layout + +\end_deeper +\end_deeper +\begin_layout Plain Layout +Find reference on how to benchmark distributed, multiprocess systems +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Choice of network protocol +\begin_inset CommandInset label +LatexCommand label +name "sec:Choice-of-network" + +\end_inset + + +\end_layout + +\begin_layout Standard +There are three main ways in which computer communication over the Internet + usually takes place; TCP, UDP and HTTP. + The first two is transport layer protocols, which are commonly used to + transport application layer protocols, such as HTTP. + TCP and UDP can not be used on their own, without an application layer + protocol on top. + Application layer protocols such as HTTP on the other hand needs a transport + layer protocol to work. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{HTTP}}{Hyper Text Transport Protocol, a network protocol commonly + used to deliver web pages} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +HTTP +\end_layout + +\begin_layout Standard +Since HTTP is so widely used on the Internet today in web servers, it is + available on most Internet connected devices. + This means that if HTTP is used in the GGS, firewalls will not pose problems, + which is a great benefit. + However, due to the intended usage of HTTP in web servers, the protocol + was designed to be stateless and client-initiated. + In order to maintain a state during a game session using HTTP, some sort + of token would have to be passed between client and server at all times, + much like how a web server works. + These facts combined makes HTTP unsuitable for our purposes, since the + GGS requires a state to be maintained throughout a session, and also needs + to push data from the server to clients without the clients requesting + data. + It should also be mentioned that HTTP uses the TCP protocol for transport, + and what is said about TCP also applies to HTTP. + +\end_layout + +\begin_layout Subsection +UDP +\end_layout + +\begin_layout Standard +Many online games use UDP as the carrier for their application layer protocol. + UDP moves data across a network very quickly, however it does not ensure + that the data transferred arrives in consistent manner. + Data sent via UDP may be repeated, lost or out of order. + To ensure the data transferred is in good shape, some sort of error checking + mechanisms must be implemented. + UDP is a good choice for applications where it is more important that data + arrives in a timely manner than that all data arrives undamaged, it is + thus very suitable for media streaming, for example. + In the GGS reliability of transfer was chosen before the speed of the transfer, + ruling out UDP as the transport later protocol. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Perhaps we should only say that we chose TCP just for our GGS prototype + and why. + If we leave it like that it seems that we think it is not suitable. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +TCP +\end_layout + +\begin_layout Standard +For reliable transfers, TCP is often used on the Internet. + Built in to the protocol is the error checking and correction mechanisms + missing in UDP. + This ensures the consistency of data, but also makes the transfer slower + than if UDP had been used. + In the GGS, data consistency is more important than transfer speeds, and + thus TCP is a better alternative than UDP. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Same here it is simply not true for a generic server to chose one or the + other. + We should rephrase it so it is clear that we only state it about the GGS + prototype. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Generic +\begin_inset CommandInset label +LatexCommand label +name "sec:Generic" + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS is a game server. + It was made with a desire to be suitable for any kind of game. + Any game with a client-server behaviour should be perfectly suited for + GGS. + A game should not only be able to vary in terms of genre, graphics, gameplay + etc, but also in the way the game is implemented. + Such as different programming languages. + The GGS should be OS independent and run on Windows, OSX and Linux. + The GGS can be run as a listen server on the players computer and host + games locally. + It could also be a dedicated server running on independent hardware. + It is meant to run any game in any environment in any way desired, therefor + being as generic as possible. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Bad name of the chapter, but here we should give the theory of how the server + is generic +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Fault Tolerance +\begin_inset CommandInset label +LatexCommand label +name "sec:Fault-Tolerance" + +\end_inset + + +\end_layout + +\begin_layout Standard +Fault tolerance is an important factor in all servers, a server that is + fault tolerant should be able to follow a given specification when parts + of the system failures. + This means that fault tolerance is different in each system depending on + what specification they have. + A system could be fault tolerant in different aspects, one is where the + system is guaranteed to be available but not safe and it could also be + reversed, that the system is safe but not guaranteed to be available. + Depending on the system one property may be more important(some example + here). + A system could also have non existent fault tolerance or it could be both + safe and guaranteed to be available. + It should be noted that it is not possible to achieve complete fault tolerance, + a system will always have a certain risk of failure. + Therefore the goal is to make the GGS prototype as fault tolerant as possible. +\end_layout + +\begin_layout Standard +To make the GGS prototype fault tolerant the programming language Erlang + has been used. + Erlang will not guarantee a fault tolerant system but it has features that + support and encourage the development of fault tolerant systems. + In the GGS it is important that the system overall is fault tolerant. + Crashes of the whole system should be avoided as this would make the system + unusable for a time. + By using supervisor structures it is possible to crash and restart small + parts of the system, this is convenient as fault can be handled within + small modules thus never forcing a crash of the system. +\end_layout + +\begin_layout Standard +The need for fault tolerance in game servers are not as obvious as it may + be for other type of servers. + In general all servers strive to be fault tolerant as fault tolerance means + more uptime and a safer system. + This applies to game servers as well, in brief good fault tolerance is + a way of satisfying customers. + In general, game servers differ from many other fault tolerant systems + in that high-availability is more important than the safety of the system. + For example a simple calculation error will not be critical for a game + server but it may be in a life-critical system and then it is better that + the system crashes than works with the faulty data. + There are cases where safety may be critical in game servers, one example + is in games where in-game money exist. +\end_layout + +\begin_layout Subsubsection +Performance penalties +\end_layout + +\begin_layout Section +Availability +\begin_inset CommandInset label +LatexCommand label +name "sec:Availability" + +\end_inset + + +\end_layout + +\begin_layout Standard +One important factor of any server is the availability. + A server to which you are unable to connect to is an useless server. + Other then within telecommunication, their uptime is of about 99,9999999%, + the game developer community has not approached this problem very genuinely + yet so there is much room for improvement. +\end_layout + +\begin_layout Standard +There are several good papers on how to migrate whole virtual machines among + nodes to replicate them +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add more information about that +\end_layout + +\end_inset + + but for the GGS a different approach has been chosen. + Instead of just duplicating a virtual machine, the programming language + Erlang has been used which offers several features to increase the availability. + Some of them are +\emph on +hot code replacement +\emph default +, where code can be updated while the application is running and without + the need to restart it, the +\emph on +supervisor structure +\emph default + provided by +\emph on +OTP +\emph default + and the inter node and process communication via +\emph on +messages +\emph default + instead of shared memory. + We will discuss each of them later on. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Supervisor}}{A process monitoring and hadning crashes in other processes} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Scalability +\begin_inset CommandInset label +LatexCommand label +name "sec:Scalability" + +\end_inset + + +\end_layout + +\begin_layout Standard +Each instance of the GGS contains several tables. + Each table is an isolated instance of a game, for example a chess game + or a poker game. + The way that the GGS scales is to distribute these tables on different + servers. + In many games it is not necessary for a player to move among tables during + games. + This is for example not a common occurrence in chess, where it would be + represented as a player standing up from her current table and sitting + down at a new table, all within the same game session. + Therefore, the main focus of the GGS is not to move players among tables, + but to keep a player in a table, and to start new tables instead. + When a server has reached a certain number of players the performance will + start to decrease. + To avoid this the GGS will start new tables on another server, using this + technique the players will be close to evenly distributed among the servers. + It is important to investigate and find out how many players that are optimal + for each server. + This approach makes it possible to use all resources with moderate load, + instead of having some resources with heavy load and some with almost no + load. +\end_layout + +\begin_layout Standard +As mentioned in the purpose section there are two different types of scalability +, structural scalability and load scalability. + To make the GGS scalable both types of scalability are needed. + Structural scalability means in our case that it should be possible to + add more servers to an existing cluster of servers. + By adding more servers the limits of how many users a system can have is + increased. + Load scalability in contrast to structural scalability is not about how + to increase the actual limits of the system. + Instead it means how good the system handles increased load. + The GGS should be able to scale well in both categories. +\end_layout + +\begin_layout Subsection +Load balancing +\end_layout + +\begin_layout Standard +The need for load balancing varies among different kind of systems. + Small systems that only use one or a couple of servers can cope with a + simple implementation of it, while in large systems it is critical to have + extensive and well working load balancing. + The need also depends on what kind of server structure that the system + works on. + A static structure where the number of servers are predefined or a dynamic + structure where the number varies. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Amazon EC2}}{A cloud computation service} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Load balancing and scaling is difficult in different scenarios. + When running in a separate server park, there are a set number of servers + available, this means that an even distribution on all servers are preferable. + When running the GGS in a cloud, such as Amazon EC2, it is possible to + add an almost infinite number of servers as execution goes on. + In this cloud setting, it may be more important to distribute evenly load + on newly added servers. +\end_layout + +\begin_layout Standard +Two methods of balancing load (increasing structure): +\end_layout + +\begin_layout Itemize +Fill up the capacity for one server completely, and then move over to the + next server +\end_layout + +\begin_layout Itemize +Evenly distribute all clients to all servers from the beginning, when load + becomes too high on all of them, then comes a new problem: +\end_layout + +\begin_deeper +\begin_layout Itemize +How do we distribute load on these new servers? +\end_layout + +\end_deeper +\begin_layout Standard +Load balancing is a key component to achieve scalability in network systems. + The GGS is a good example of a system that needs to be scalable, to attain + this load balancing is necessary. + Optimization of the load balancing for a system is an important task to + provide a stable and fast load balancer. + There are certain persistence problems that can occur with load balancing, + if a player moves from a server to another data loss may occur. + This is an important aspect to consider when the load balancer is designed + and implemented. +\end_layout + +\begin_layout Standard +Load balancing can often be implemented using dedicated software, this means + that in many applications load balancing may not be implemented because + it already exist functional solutions. + This depends on what specific needs the system has and a minor goal of + the project is to analyze whether the GGS project can use existing load + balancing tools or if it is necessary to implement load balancing in the + project. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Because P2P game architectures are a constant goal for cheaters and because + “Cheating is a major concern in network games as it degrades the experience + of the majority of players who are honest” and preventing cheating in P2P + game architectures is very difficult game developers try to use Client + - Server architectures which have a natural problem to scale. + In this paper we want to show some strategies to achieve scalability. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +UUID +\begin_inset CommandInset label +LatexCommand label +name "sub:UUID" + +\end_inset + + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{UUID}}{Universally Unique Identifier} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{algorithmic}[1] +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +newcommand{ +\backslash +INDSTATE}[1][1]{ +\backslash +STATE +\backslash +hspace{#1 +\backslash +algorithmicindent}} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + +global variable +\begin_inset Formula $state:=0$ +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +STATE +\end_layout + +\end_inset + + +\series bold +function +\series default +unique +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + +\begin_inset Formula $state:=state+1$ +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +INDSTATE +\end_layout + +\end_inset + + +\series bold +return +\begin_inset Formula $state$ +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{algorithmic} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-simple-generator" + +\end_inset + +A simple (insufficient) generator for identifiers +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Inside the GGS, everything has an unique identifier. + There are identifiers for players, tables and other resources. + When players communicate amongst one another, or communicate with tables, + they need to be able to uniquely identify all these resources. + Within one machine, this is mostly not a problem. + A simple system with a counter can be imagined, where each request for + a new ID increments the previous identifier and returns the new identifier + based off the old one, see algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + +. + This solution poses problems when dealing with concurrent and distributed + systems. + In concurrent systems, the simple solution in algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + + may yield non-unique identifiers due to the lack of mutual exclusion. +\end_layout + +\begin_layout Standard +The obvious solution to this problem is to ensure mutual exclusion by using + some sort of lock, which may work well in many concurrent systems. + In a distributed system, this lock, along with the state, would have to + be distributed. + If the lock is not distributed, no guarantee can be made that two nodes + in the distributed system do not generate the same number. + A different approach is to give each node the ability to generate Universally + Unique Identifiers (UUID), where the state of one machine does not interfere + with the state of another. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{MAC Address}}{Media Access Control address, used to identify network + cards} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SHA-1}}{Cryptigraphic hash function, designed by the National Security + Agency (NSA)} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +According to +\begin_inset CommandInset citation +LatexCommand citet +key "Leach98uuidsand" + +\end_inset + +, +\begin_inset Quotes eld +\end_inset + +A UUID is 128 bits long, and if generated according to the one of the mechanisms + in this document, is either guaranteed to be different from all other UUIDs/GUI +Ds generated until 3400 A.D. + or extremely likely to be different +\begin_inset Quotes erd +\end_inset + +. + This is accomplished by gathering several different sources of information, + such as: time, MAC addresses of network cards, and operating system data, + such as percentage of memory in use, mouse cursor position and process + ID:s. + The gathered data is then +\emph on +hashed +\emph default + +\begin_inset space ~ +\end_inset + +using an algorithm such as SHA-1. +\end_layout + +\begin_layout Standard +When using system wide unique identifiers, such as the ones generated by + algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + + with mutual exclusion, it is not possible to have identifier collisions + when recovering from network splits between the GGS clusters. + Consider figure +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:network-split" + +\end_inset + +, where +\emph on +Site A +\emph default + is separated from +\emph on +Site B +\emph default + by a faulty network (illustrated by the cloud and lightening bolt). + When +\emph on + +\emph default +the decoupled node +\emph on + +\emph default +and +\emph on + +\emph default +the rest of the network later re-establish communication, they may have + generated the same ID:s if using algorithm +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-simple-generator" + +\end_inset + +, even when mutual system-wide exclusion is implemented. + This is exactly the problem UUID:s solve. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Network split}}{Separation of two networks, occurs when two networks + can not communicate, commonly because of a hardware or software failiure} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/netsplit2.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Add clients on each side, and replace the cloud with phole-landlines being + cut by a pair of scissors +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:network-split" + +\end_inset + +An example of a network split +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Security +\end_layout + +\begin_layout Standard +We only support languages running in a sandboxed environment. + Each game session is started in its own sandbox. + The sandboxing isolates the games in such a way that they can not interfere + with each other. + If sandboxing was not in place, one game could potentially modify the contents + of a different game. + A similar approach is taken with the persistent storage we provide. + In the storage each game has its own namespace, much like a table in a + relational database. + A game is not allowed to venture outside this namespace, and can because + this not modify the persistent data of other games. + of this not modify the persistent data of other games. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Sandbox}}{A protected environment in which computer software can + be run safely} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Encryption +\end_layout + +\begin_layout Section +Game Development Language in a Virtual Machine +\begin_inset CommandInset label +LatexCommand label +name "sec:Game-Development-Language" + +\end_inset + + +\end_layout + +\begin_layout Standard +There is only a very limited number of game developers who would like to + write their games in Erlang, therefore we had to come up with something + to resolve this problem. + The main idea was to offer a replacable module which would introduce a + interface to different virtual machines which would run the game code. + This way a game developer can write the game in his favourite language + while the server part still is written in Erlang and can benefit from all + of its advantages. +\end_layout + +\begin_layout Subsection +JavaScript +\end_layout + +\begin_layout Standard +JavaScript has gained a lot of popularity lately, it is used in large projects + such as +\emph on +Riak +\emph default + +\begin_inset Foot +status open + +\begin_layout Plain Layout +\begin_inset Flex URL +status collapsed + +\begin_layout Plain Layout + +http://wiki.basho.com/An-Introduction-to-Riak.html +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +, +\emph on +CouchDB +\emph default + +\begin_inset Foot +status open + +\begin_layout Plain Layout +\begin_inset Flex URL +status collapsed + +\begin_layout Plain Layout + +http://couchdb.apache.org +\end_layout + +\end_inset + + +\end_layout + +\end_inset + +. + On the popular social coding site +\emph on +GitHub.com +\emph default +, 18% +\begin_inset Foot +status open + +\begin_layout Plain Layout +during the writing of the thesis the percentage went up to 19% +\begin_inset Flex URL +status collapsed + +\begin_layout Plain Layout + +https://github.com/languages/ +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + of all code is written in JavaScript. + The popularity of JavaScript in the programming community, in combination + with the availability of several different JavaScript virtual machines + was an important influence in choosing JavaScript as the main control language + for our GGS prototype. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{CouchDB}}{Database server} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Riak}}{Database server} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{GitHub.com}}{Social coding website} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{ActionScript}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Lua}}{Programming language} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{.NET}}{Software platform} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Other languages +\end_layout + +\begin_layout Standard +Other languages like +\emph on +lua +\emph default +, +\emph on +ActionScript +\emph default + are suitable as well because there is a virtual machine for each of them + which can be +\begin_inset Quotes eld +\end_inset + +plugged in +\begin_inset Quotes erd +\end_inset + + into our GDL VM interface. + With help of the +\emph on +Java Virtual Machine +\emph default + or the +\emph on +.NET +\emph default +environment it is even possible to run nearly every available programming + language in a sandbox as a GDL. +\end_layout + +\begin_layout Standard +Due lack of time we have decided to use just the Erlang <-> JavaScript bridge + with our interface. +\end_layout + +\begin_layout Section +Testing +\end_layout + +\begin_layout Standard +There are several ways in which the GGS can be tested. + The most important aspect has been deemed to be the experience players + have when using the GGS. + In order to test the user experience of the GGS, a realistic usage scenario + has to be set up. +\end_layout + +\begin_layout Standard +The GGS is intended to be used for powering games which have many concurrent + players. + The players need not participate in the same instance of the game, games + such as chess are prime candidates for the GGS. +\end_layout + +\begin_layout Standard +When developing the GGS, two main categories of games exhibiting different + performance demands were identified; real-time games and turn-based games. + The real-time games were deemed more demanding than the turn based games. + Tests were carried out using a real time game, since this is the more demanding + type of games. +\end_layout + +\begin_layout Standard +The real time game chosen for testing the GGS is +\emph on +Pong +\emph default +, a game in which two players play a game involving a all and two paddles. + The goal for each player is to shoot eside the othre player's paddle while + not allowing the ball to pass by her own paddle. + The game requires real time updates and is quite demanding when played + in several instances concurrently. +\end_layout + +\begin_layout Standard +There has been some work on the area of testing game servers, see +\begin_inset CommandInset citation +LatexCommand citet +key "Lidholt02designand" + +\end_inset + +, who describes a test bench using +\emph on +bots +\emph default + for testing his generic hazard-gaming server. + Lidholt describes how his server, capable of running several different + casino games is tested using artificial players, so called bots. + Performance is measured in +\begin_inset Quotes eld +\end_inset + +number of clients +\begin_inset Quotes erd +\end_inset + + able to connect to the server, and the system load. +\end_layout + +\begin_layout Standard +Similar tests were performed on the GGS, and the results of these tests + are visible in chapter +\begin_inset CommandInset ref +LatexCommand ref +reference "chap:Results-and-discussion" + +\end_inset + +. + The tests were initially performed by starting an operating system process + for each player. + Due to lack of hardware, not enough player processes could be started in + this way. + The bots were re-written in Erlang, and due to Erlang's light weigh threads, + enough processes could be created to successfully test the server. +\end_layout + +\begin_layout Chapter +Implementation of a prototype +\begin_inset CommandInset label +LatexCommand label +name "cha:Implementation-of-a" + +\end_inset + + +\end_layout + +\begin_layout Standard +This chapter contains the realization of much of the principles and techniques + described in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Theory" + +\end_inset + +. + Here the problems and solutions are discussed in greater detail, and at + times the text becomes more specific to the GGS. +\end_layout + +\begin_layout Standard +Much of what is discussed in this chapter has been implemented in the Erlang + GGS prototype. + Specific solutions such as +\emph on +supervisor structures +\emph default +and distribution of erlang nodes on physical nodes. + The different means of communications within the GGS and outside the GGS + with third parties are also discussed here. +\end_layout + +\begin_layout Section +Overview of the prototype +\end_layout + +\begin_layout Standard +The prototype of the GGS was developed using the Erlang language. + The functional and concurrent style of Erlang facilitates devlopment of + software based on a real-world model +\begin_inset CommandInset citation +LatexCommand citep +key "armstrong2011" + +\end_inset + +. + In Erlang, most things are processes. + The software running the Erlang code is known as the Erlang machine, or + an Erlang node. + Each Erlang node is capable of running several +\emph on +threads +\emph default +(also known as +\emph on +Light Weight Processes; LWP +\emph default +) +\emph on +, +\emph default +much like the threads in an operating system. + Threads in a Linux system, for example, are treated much like operating + system processes in different systems. + Due to the size of datastructures related to each process, swapping one + process for another (known as +\emph on +context switching +\emph default +) is an expensive task in many systems +\begin_inset CommandInset citation +LatexCommand citep +after "pg 80" +key "McKusick:2004:DIF:1014910" + +\end_inset + +. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{LWP}}{Light Weight Process} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Context switch}}{The act of switching from one context, commonly + a process, to another. + Used by operating systems to achieve multi tasking} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The cost of swapping operating system processes becomes a problem when many + processes are involved. + If the GGS system had been developed using regular operating system processes, + it would have had to be designed in a way to minimize the number of processes. + Using Erlang, which is capable of running very many processes, several + times more than an operating system can, the mapping between the real world + system (described in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:Design-of-the" + +\end_inset + +) becomes clearer. +\end_layout + +\begin_layout Standard +Erlang allows the GGS to create several process for each player connecting, + these processes can handle a multitude of different tasks, parsing data + for example. + Since each task is handled by a different process, the tasks are clearly + separated and the failiure of one is easily recovered without affecting + the others. +\end_layout + +\begin_layout Standard +In addition to creating (or +\emph on +spawning +\emph default +) processes specifically to handle new players connecting, the GGS has more + permanent processes running at all times. + The constantly running processes in the GGS system are called +\emph on +modules +\emph default +. + An example of a module in the GGS is the +\emph on +dispatcher module +\emph default +, which handles the initial connection made by a client, passing the connection + along further in to the system. +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/Chess_no_text.eps + width 100text% + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:The-layout-of" + +\end_inset + +The layout of the GGS. + The circles marked with 'C' topmost in the picture represent clients. + The cloud marked 'network' pictured directly below the clients can be any + network, for example the Internet. + The barell figure marked 'backup' is a process being fed backup data from + the coordinator. + The barell marked 'State' contains the state of a table, and this is fed + into the box marked 'Mnesia' which is database. + Finally the figure shaped as a shield marked 'GameVM' contains the actual + game process. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +In figure +\begin_inset CommandInset ref +LatexCommand vref +reference "fig:The-layout-of" + +\end_inset + + the entire GGS system is represented graphically. + The circles marked with 'C' topmost in the picture represent game clients. + These circles represent processes running on gamers' computers, and not + on the GGS machine. + If a game of chess is to be played on the server, the clients on the gamers' + machines will be chess game clients. + Clients connect through a network, pictured as a cloud, to the dispatcher + process in the GGS. + The dispatcher process and all other modules are discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sec:The-modular-structure" + +\end_inset + +. + For each connection, a new player process is spawned, which immediately + after spawning is integrated in to the GGS by the coordinator process. +\end_layout + +\begin_layout Section +The usage of Erlang in the GGS +\begin_inset CommandInset label +LatexCommand label +name "sec:The-usage-of-erlang" + +\end_inset + + +\end_layout + +\begin_layout Standard +Erlang was designed by Ericsson, beginning in 1986, for the purpose of creating + concurrent applications and improving telecom software. + Features essential for the telecom instustry to achieve high availability + in telecom switches were added to the language. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Mutex}}{A construct for achieving mutial exclusion, used to avoid + simultaneous access to shared resources in computer systems} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Erlang uses message passing in favour of shared memory, mutextes and locks, + something which at the time was controversial among fellow developers +\begin_inset CommandInset citation +LatexCommand citet +key "Armstrong:2010:ERL:1810891.1810910" + +\end_inset + +. + The reason for using message passing, according to Armstrong, was that + applications should operate correctly before optimizations are done, where + efficient internal communication within the Erlang machine was considered + a later optimization. +\end_layout + +\begin_layout Standard +In using message passing in favour of the methods commonly used at the time, + the issues commonly associated with shared memory and locking were avoided. + In Erlang, everything is a process, and everything operates in its own + memory space. + Memory can not be shared among processes, which prohibits a process from + corrupting the memory of a different process. +\end_layout + +\begin_layout Standard +Messages are sent between the processes in an asynchronous manner, and each + process has a mailbox in which these messages can be retrieved. +\end_layout + +\begin_layout Standard +Processes in Erlang are also called +\emph on +Light Weight Processes. + +\emph default +The Erlang processes are very cheaply created. + Processes exist within an Erlang machine, or Erlang node. + The Erlang machine has its own scheduler and does not rely on the operating + system's scheduler, this is a main reason of Erlang's capability of running + many concurrent processes +\begin_inset CommandInset citation +LatexCommand citet +key "Armstrong03" + +\end_inset + +. +\end_layout + +\begin_layout Standard +The strong isolation of Erlang processes make them ideal for multicore and + distributed systems. + Distribution of software is included as a fundamental part in the Erlang + language. + The 'physical' location of a process, e.g. + which computer the process runs on, is not important when communicating + with the process. + Processes can communicate regardless of whether they run on the same system + of not, transparently. +\end_layout + +\begin_layout Standard +The distributed nature of Erlang is something the GGS makes use of when + scaling across several computers in order to achieve higher performance. + The distribution is also important in creating redundancy. + Erlang promotes a non-defensive programming style in which processes are + allowed to crash and be restarted in favour of having the processes recover + from errors. + The distributed nature of Erlang means supervisor processes (discussed + in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Supervisor-structure" + +\end_inset + +) can reside on remote systems, thereby increasing the reliability of the + system as a whole. +\end_layout + +\begin_layout Standard +A very important feature of Erlang, used in the GGS, is the ability to interface + with external hardware and software. + Erlang allows communication with external resources through +\emph on +ports. + +\emph default + Through ports communication can take place much in the same way communication + is performed over sockets. +\end_layout + +\begin_layout Standard +The GGS uses Erlang ports for generating UUID:s +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +UUID:s are discussed in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:UUID" + +\end_inset + + +\end_layout + +\end_inset + + and for interfacing with the virtual machines of games +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +Virtual machines of games are discussed in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Game-Development-Language" + +\end_inset + + +\end_layout + +\end_inset + +. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{OTP}}{Open Telecom Platform, a software suite for Erlang} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Behaviour}}{A design pattern in OTP} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Development of the GGS would have been hard if not impossible had it not + been for the +\emph on +OTP +\emph default + supplied with the standard Erlang distribution. + The OTP (Open Telecom Platform) is a set of standard libraries and design + patterns, called +\emph on +behaviours +\emph default +, which are used when developing Erlang systems. +\end_layout + +\begin_layout Standard +The GGS makes heavy use of the behaviours supplied in the OTP. + The behaviours impose a programming style suitable for distributed and + concurrent applications, perfectly suitable for the GGS. + In particular, the GGS uses the following behaviours: +\end_layout + +\begin_layout Itemize +The +\emph on +supervisor +\emph default + behaviour, which is used when creating a supervisor. + Supervisors are used when monitoring processes in the Erlang system. + When a process exits wrongfully, the supervisor monitoring the process + in question decides which action to take. + In the GGS, the most common action is simply to restart the faulting process. + A more thorough discussion on supervisors can be found in section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Supervisor-structure" + +\end_inset + +. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_tcp +\emph default +behaviour, which is used to work with TCP sockets for network communication. + Using the gen_tcp behaviour, network messages are converted to internal + Erlang messages and passed to a protocol parser, where the messages are + processed further. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_server +\emph default + behaviour, which is used when constructing OTP servers in Erlang. + Using this behaviour, a state can easily be kept in a server process, greatly + increasing the usefulness of the server process. + There are many gen_servers in the GGS, it is the most widely used behaviour + in the project. + In addition to intruducing a state to the server, the gen_server behaviour + also imposes patterns for synchronous and asynchronous communication between + other gen_servers and other OTP behaviours. +\end_layout + +\begin_layout Itemize +The +\emph on +gen_fsm +\emph default + behaviour is used in one module in the GGS, the protocol parser. + Using the gen_fsm behaviour, finite state machines are easily developed. + Protocol parsers are an ideal example of where to use finite state machines, + which are widely used for parsing strings of text. +\end_layout + +\begin_layout Standard +In addition to supplying behaviours, the OTP also has a style for packaging + and running Erlang applications. + By packaging the GGS as an +\emph on +application +\emph default +the GGS can be started in a way uniform to most erlang software, providing + familiarity for other Erlang users, and eases the incorporation of the + GGS in other applications. +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Application}}{A way of packaging Erlang software in a uniform way} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Short introduction to the Erlang syntax +\end_layout + +\begin_layout Standard +In order to understand examples in this thesis, a small subset of Erlang + must be understood. + In this section, the very syntactic basics of Erlang are given. +\end_layout + +\begin_layout Itemize + +\series bold +Variables +\series default + start with an uppercase letter, examples include +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt X, Var}, and { +\backslash +tt Global} +\end_layout + +\end_inset + +. + A variable can only be assigned once. +\end_layout + +\begin_layout Itemize + +\series bold +Atoms +\emph on + +\series default +\emph default +start with lower case letters, for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + + { +\backslash +tt atom, a} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Functions +\series default + are defined starting with an atom for the name, parenthesis containing + parameters, an arrow, a function body and finally a dot marking the end + of a function. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt square(X) -> X*X.} +\end_layout + +\end_inset + + is an example of a function producing the square of X. +\end_layout + +\begin_layout Itemize +Functions are +\series bold +called +\series default + by suffixing an atom with the function name with parenthesis, for example + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt square(10)} +\end_layout + +\end_inset + +. + Qualified names can be specified using ':', for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt math:square(10)} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Tuples +\series default + are containers of fixed type for Erlang data types. + They are constructed using curly brackets, for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt +\backslash +{atom1, atom2, atom3 +\backslash +}}. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Itemize + +\series bold +Lists +\series default + are constructed using [ and ], for example: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt [1,2,3]} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Strings +\series default + doubly qouted lists of characters, for example +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt "Hello world"} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Itemize + +\series bold +Records +\series default + are erlang tuples coupled with a tag for each tuple element. + This allows refering to elements by name instead of by position. + An example of a record looks like this: +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt +\backslash +#myRecord{}} +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Section +Communication with external systems and applications +\begin_inset CommandInset label +LatexCommand label +name "sec:Communication-with-external" + +\end_inset + + +\end_layout + +\begin_layout Standard +A game launched on the GGS is run within a virtual machine. + For each programming language supported, there is a virtual machine that + interprets the game. + Furthermore an interface for communication between the GGS, the game and + the players playing the game must be present. +\end_layout + +\begin_layout Standard +The reason for the GGS requiring a communication channel between the game + VM and Erlang is in part because the GGS makes heavy use of callbacks. + Callbacks written in Erlang are registered to the VM for the interface + to work. + It is only with the help of the interface that the game developer can access + the game state and send messages between players. + The interface provides access to three objects called +\emph on +world +\emph default +, +\emph on +player +\emph default + and +\emph on +localstorage +\emph default +. + The game state is safely stored in a database and retrieved for manipulation + by a call for the world object. + Interaction with the players is done the same way using the player object + instead. + The localstorage is a convenient way to store globals and other data seperated + from the game state. + In section +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:Exposing-Erlang-functionality" + +\end_inset + + a concrete example of the implementation of the localStorage and world + objects is given. +\begin_inset Note Note +status open + +\begin_layout Plain Layout + Unique id:s called gametokens are generated for hosted games so that they + are not mixed up. + -- good text, integrate more. +\end_layout + +\end_inset + + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{WebStorage}}{A new standard for letting websites store data on visitors' + computers} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Exposing Erlang functionality to the GDL VM +\begin_inset CommandInset label +LatexCommand label +name "sub:Exposing-Erlang-functionality" + +\end_inset + + +\end_layout + +\begin_layout Standard +This section contains a concrete example of how the localStorage and world + objects are exposed to a GDL VM. + The example comes from the GGS prototype, which uses JavaScript powered + by Google V8 as its GDL VM. +\end_layout + +\begin_layout Standard +The code given in +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:exposing-erlang" + +\end_inset + + is specific to V8 and JavaScript, however implementations for different + GDL:s, or different JavaScript VM:s should be similar. +\end_layout + +\begin_layout Standard +In JavaScript is is common to use a top level object, called a global object, + to establish a global scope. + This allows declaration of global variables and functions. + To gain access to the global object in the GGS, the +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt erlv8 +\backslash +_vm:global(..)} +\end_layout + +\end_inset + + function on line 2 of the example is used. + Using the global object, declarations of the world and GGS object can be + placed in the global scope. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt Global:set +\backslash +_value(..)} +\end_layout + +\end_inset + + is a call to the global object, declaring new objects in the global scope. + On line 4 the GGS object is declared. + By accessing +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt GGS.localStorage } +\end_layout + +\end_inset + + from within the GDL, access to the localstorage is provided, thus the localstor +age must be connected to the GGS object, this can be seen in line 5. +\end_layout + +\begin_layout Standard +Both the GGS and localStorage objects are dummy objects, which provide no + functionality, these two objects are simply placed in the GDL for the purpose + clearing up the code. + In order to perform an action using the GGS and localStorage objects, the + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt getItem} and { +\backslash +tt setItem} +\end_layout + +\end_inset + + functions must be used. + These items are directly connected to the database module of the GGS, which + is discussed in more detail in +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:The-database-module" + +\end_inset + +. +\end_layout + +\begin_layout Standard +Similarly the functions +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt sendCommand, sendCommandToAll} and { +\backslash +tt setTimeout} +\end_layout + +\end_inset + + are directly connected to a piece of code in the GGS which performs the + desired action. + The +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt sendCommand} +\end_layout + +\end_inset + + functions are used to send commands or text to participants of the table. + The +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt setTimeout} +\end_layout + +\end_inset + + function introduces timeouts to the V8 engine, which are not available + per default. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +language=Erlang, +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting}[language=Erlang] +\end_layout + +\begin_layout Plain Layout + +% @doc Exposes some GGS functions to JavaScript +\end_layout + +\begin_layout Plain Layout + +expose(GameVM, Table) -> +\end_layout + +\begin_layout Plain Layout + + Global = erlv8_vm:global(GameVM), +\end_layout + +\begin_layout Plain Layout + + Global:set_value("GGS", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"localStorage", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:setItem(Table, local_storage, Key, Val) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:getItem(Table, local_storage, Key) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])}, +\end_layout + +\begin_layout Plain Layout + + {"world", erlv8_object:new([ +\end_layout + +\begin_layout Plain Layout + + {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:setItem(Table, world, Key, Val), +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command_to_all( +\end_layout + +\begin_layout Plain Layout + + Table, {"world_set", Key ++ "=" ++ Val} +\end_layout + +\begin_layout Plain Layout + + ) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> +\end_layout + +\begin_layout Plain Layout + + ggs_db:getItem(Table, world, Key), +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])}, +\end_layout + +\begin_layout Plain Layout + + {"sendCommand", fun(#erlv8_fun_invocation{}, [Player, Command, Args])-> +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command(Table, Player, {Command, Args}) +\end_layout + +\begin_layout Plain Layout + + end}, +\end_layout + +\begin_layout Plain Layout + + {"sendCommandToAll", fun(#erlv8_fun_invocation{}, [Command, Args])-> +\end_layout + +\begin_layout Plain Layout + + ggs_table:send_command_to_all(Table, {Command, Args}) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + {"setTimeout", fund(#erlv8_fun_invocation{}, [Time, Function])-> +\end_layout + +\begin_layout Plain Layout + + timer:apply_after(Time, ?MODULE, call_js, [GameVM, Function]) +\end_layout + +\begin_layout Plain Layout + + end} +\end_layout + +\begin_layout Plain Layout + + % more functions ... +\end_layout + +\begin_layout Plain Layout + + ])). +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:exposing-erlang" + +\end_inset + +An example of how Erlang functionality is exposed to a Javascript GDL +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +TODO: Go in to more detail about how the world, player and localstorage + objects are implemented. + Also discuss localstorage and how it derives from the webstorage standard + in detail. + This is a great point on how we try to follow standards. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +My idea here is that we describe the erlang-js (which failed, but nontheless), + v8, UUID and other external communication. + We shouldn't describe sockets here though.. + or.. + maybe? +\end_layout + +\begin_layout Plain Layout +Also discuss how we allow GDLs to communicate with Erlang, this is +\begin_inset Quotes eld +\end_inset + +external +\begin_inset Quotes erd +\end_inset + + to thre GDL. + Discuss the GGS world object (there is a reference to this secxtion for + that purpose) +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +The modular structure of the GGS prototype +\begin_inset CommandInset label +LatexCommand label +name "sec:The-modular-structure" + +\end_inset + + +\end_layout + +\begin_layout Standard +The separation of concerns, and principle of single responsibility +\begin_inset Foot +status open + +\begin_layout Plain Layout +More information on the SRP is available at: +\begin_inset CommandInset href +LatexCommand href +target "http://www.objectmentor.com/resources/articles/srp.pdf" + +\end_inset + + +\end_layout + +\end_inset + + are widely respected as good practices in the world of software engineering + and development. + By dividing the GGS up into modules each part of the GGS can be modified + without damaging the rest of the system. +\end_layout + +\begin_layout Standard +The responsibility and concern of each module comes from the responsibility + and concern of the real-world entity the model represents. + The modelling of the GGS after a real world system was discussed in chapter + +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Theory" + +\end_inset + +. +\end_layout + +\begin_layout Standard +In the text below the word module refers to the actual code of the discussed + feature, while the word process is used when referring to a running instance + of the code. + Those familiar to object oriented programming may be helped by thinking + in the lines of classes and objects. +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Am I right here? +\end_layout + +\end_inset + + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SRP}}{Single Responsibility Principle} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Object Oriented Programming}}{A programming paradigm focusing on + objects} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +The dispatcher module +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +The discussion of the modules is divided into the following parts: +\end_layout + +\begin_layout Itemize +What does the module do? +\end_layout + +\begin_layout Itemize +What happens when the module fails? +\end_layout + +\begin_layout Itemize +How does the module correspond to the real-world scenario of the chess club? +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The dispatcher module is the first module to have contact with a player. + When a player connects to the GGS, it is first greeted by the dispatcher + module, which sets up an accepting socket for each player. + +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout +Is this the proper way to day the dispatcher greets connecting players? +\end_layout + +\end_inset + + The dispatcher is the module which handles the interfacing to the operating + system when working with sockets. + Operating system limits concering the number of open files, or number of + open sockets are handled here. + The operating system limits can impose problems on the GGS, this is discussed + more in detail in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Problems-of-implementation" + +\end_inset + +. +\end_layout + +\begin_layout Standard +Should the dispatcher module fail to function, no new connections to the + GGS can be made. + In the event of a crash in the dispatcher module, a supervisor process + immediately restarts the dispatcher. + There exists a window of time between the crashing of the dispatcher and + the restarting of the dispatcher, this window is very short, and only during + this window is the GGS unable to process new connection requests. + Due to the modular structure of the GGS, the rest of the system is not + harmed by the dispatcher process not functioning. + The process does not contain a state, therefore a simple restart of the + process is sufficient in restoring the GGS to a pristine state after a + dispatcher crash +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Well.. + In theory.. +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Standard +Returning to scenario of the chess club, the dispatcher module is the doorman + of the club. + When a player enters the chess club, the player is greeted by the doorman, + letting the player in to the club. + The actual letting in to the club is in the GGS represented by the creation + of a player process discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-player-module" + +\end_inset + +. + The newly created player process is handed, and granted rights to, the + socket of the newly connected player. +\end_layout + +\begin_layout Subsection +The player module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-player-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +The player module is responsible for representing a player in the system. + Each connected player has its own player process. + The player process has access to the connection of the player it represents, + and can communicate with this player. + In order to communicate with a player, the data to and from the player + object must pass through a protocol parser module, discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-protocol-parser" + +\end_inset + +. + Raw communication, witout passing the data through a protocol parser is + in theory possible, but is not useful. +\end_layout + +\begin_layout Standard +In the creation of a player process, the coordinator process, discussed + in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-coordinator-module" + +\end_inset + +, is notified by the newly connected process. +\end_layout + +\begin_layout Standard +In the event of a crash in a player process, several things happen. + +\end_layout + +\begin_layout Enumerate +The player process, which is the only process with a reference to the socket + leading to the remote client software, passes this reference of the socket + to the coordinator process temporarily. +\end_layout + +\begin_layout Enumerate +The player process exits. +\end_layout + +\begin_layout Enumerate +The coordinator spawns a new player process, with the same socket reference + as the old player process had. +\end_layout + +\begin_layout Enumerate +The player process resumes operation, immediately starting a new protocol + parser process, and begind receiving and sending network messaged again. +\end_layout + +\begin_layout Standard +The window of time between the crash of the player process and the starting + of a new player process is, as with the dispatcher, very short. + Since the connection changes owners for a short period of time, but is + never dropped, the implications of a crash are only noticed, at worst, + as choppy gameplay for the client. + Note however that this crash recovery scheme is not implemented in the + GGS prototype. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Can we do this..? Seems a bit sneaky. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Moving back to the real world example, the player process represent an actual + person in the chess club. + When a person sits down at a table in the chess club, the person does so + by requesting a seat from some coordinating person, and is then seated + by the same coordinator. + Once seated, the player may make moves on the table he or she is seated + by, this corresponds clearly to how the GGS is structured, as can be seen + in the following sections. +\end_layout + +\begin_layout Subsection +The protocol parser module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-protocol-parser" + +\end_inset + + +\end_layout + +\begin_layout Standard +The protocol parser is an easily interchangable module in the GGS, handling + the client-to-server, and server-to-client protocol parsing. + In the GGS prototype, there is only one protocol supported, namely the + +\emph on +GGS Protocol +\emph default +. + The role of the protocol parser is to translate the meaning of packets + sent using the prototocol in use to internal messages of the GGS system. + The GGS protocol, discussed below is used as a sample protocol in order + to explain how protocol parsers can be built for the GGS. +\end_layout + +\begin_layout Subsubsection +The structure of the GGS Protocol +\begin_inset CommandInset label +LatexCommand label +name "sub:The-structure-of" + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS protocol is modelled after the HTTP protocol. + The main reason for this is the familiarity many developers already have + with HTTP due to its presence in internet software. + Each GGS protocol packet contains a headers section. + The headers section is followed by a data section. + In the headers section, parameters concerning the packet is placed. + In the data section, the actual data payload of the packet is placed. +\end_layout + +\begin_layout Standard +There is no requirement of any specific order of the parameters in the headers + section, however the data section must always follow directly after the + headers section. +\end_layout + +\begin_layout Standard +In the example below, line 1 contains a Game-Command parameter. + This parameter is used to determine which game-specific command the client + is trying to perform. + The handling of this parameter is specific to each game, and can be anything. +\end_layout + +\begin_layout Standard +Line 2 specifies a game token. + This is a UUID which is generated for each client upon authentication with + the GGS. + The GGS uses this token in case a client is disconnected and the new connection + created when the client reconnects must be re-paired with the player object + inside the GGS. + The UUID is also used as a unique ID within GDL VMs. +\end_layout + +\begin_layout Standard +Line 3 specifies the content type of the payload of this particular packet. + This parameter allows the GGS to invoke special parsers, should the data + be encoded or encrypted. + When encryption is employed, only the payload is encrypted, not the header + section. + This is a scheme which does not allow for strong encryption, but is deemed + feasible for gaming purposes. +\end_layout + +\begin_layout Standard +Line 4 specifies the content length of the payload following immediately + after the headers section. +\end_layout + +\begin_layout Standard +The parser of the GGS protocol implemented in the GGS prototype is designed + as a finite state machine using the gen_fsm behaviour. + When a full message has been parsed by the parser, the message is converted + into the internal structure of the GGS messages, and sent in to the system + from the protocol paser using message passing. +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Packet below is not an algorithm, but I don't know how to change that label.. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting} +\end_layout + +\begin_layout Plain Layout + +Game-Command: chat +\end_layout + +\begin_layout Plain Layout + +Token: e30174d4-185e-493b-a21a-832e2d9d7a1a +\end_layout + +\begin_layout Plain Layout + +Content-Type: text +\end_layout + +\begin_layout Plain Layout + +Content-Length: 18 +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + +Hello world, guys! +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-sample-packet" + +\end_inset + +A sample packet sent from a client to the GGS during a chat session +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Mention that the protocol is heavily influenced bye HTTP, is parsed using + a FSM, perhaps give a sample packet. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +The coordinator module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-coordinator-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +The coordinator module is responsible for keeping track of all players, + their seats and tables. + Players register with the coordinator process when first connecting to + the server, and the coordinator places each player by their respective + table. +\end_layout + +\begin_layout Standard +The coordinator keeps mappings between each player and table, therefore + it is used to perform lookups on tables and players to find out which are + connected. + The connectivity of players and tables is important when sending messages + to all participants in a game. + A lookup in the coordinator process is performed prior to notifying all + players in a game to ensure the message reaches all players. + The lookup can be performed either using internal identification codes + or using the UUID associated with each client and table. +\end_layout + +\begin_layout Standard +The coordinator process contains important state, therefore a backup process + is kept at allt times. + All good data processed by the coordinator is stored for safekeeping in + the backup process as well. + Data which is potentisally harmful is not stored in the backup process. +\end_layout + +\begin_layout Standard +Upon a crash, the coordinator process recovers the prior good state from + the backup process and continues where it left off. + A supervisor process monitors the coordinator process and restarts the + process when it malfunctions. + There is a window of time between the crash of the coordinator and the + restarting of the coordinator, during this time, players can not be seated + by new tables, and can not disconnect from the server. + This window of time is very small, and the unavailability of the coordinator + process should not be noticed by more than a short time lag for the clients. +\end_layout + +\begin_layout Standard +Moving back to the example of the chess club, the coordinator process can + be seen as a judge, monitoring all moves of the players. + At the same time as acting as a judge, the coordinator process is also + a host in the chess club, seating players by their tables and offering + services to the players. +\end_layout + +\begin_layout Subsection +The table module +\end_layout + +\begin_layout Standard +The table module is mostly a hub used for communication. + New table processes are created by the coordinator on demand. + The table module does not contain any business logic, however each process + contains information concerning which players are seated by that particular + table. +\end_layout + +\begin_layout Standard +The information about which players are seated by each table is used when + notifying all players by a table of an action. + Consider a game of chess, each player notifies the table of its actions, + the table then notifies the rest of the participants of these actions after + having had the ac tions processed by the game VM, where an action could + be moving a playing piece. +\end_layout + +\begin_layout Standard +Each table is associated with a game VM. + The actions sent to a table are processed by the game VM, this is where + the game logic is implemented. +\end_layout + +\begin_layout Standard +After a crash in a table process, the entire table must be rebuilt and the + players must be re-associated with the table. + Data concerning players is kept in the coordinator process, and is restored + from there. + Data kept in the actual game is not automatically corrupted by the crash + in a table, however the table must be re-associated with the game VM is + was associated with prior to the crash of the table. + The table process maps well into the setting of the real-world chess club + scenario previously discussed. + A table works in the same way in a real world setting as in the GGS setting. +\end_layout + +\begin_layout Subsection +The game virtual machine module +\end_layout + +\begin_layout Standard +This module holds the game logic of a game and is responsible for the VM + associated with each game. + +\end_layout + +\begin_layout Standard +The game VM contains the state of the VM and a table token associated with + a running game. + GameVM is started by the table module. + The table module hands over a token to the game VM during initialization. + During initialization a new VM instance and various objects associated + to the VM instance will be created. + Callbacks to Erlang are registered into the VM and then the source code + of a game is loaded into the VM and the game is ready for startup. + The only means for a game to communicate with the VM is through usage of + a provided interface. + +\end_layout + +\begin_layout Standard +The VM itself makes it possible for the game developer to program in the + prograimming language covered by the VM. + In future releases, more game VM:s will be added to support more programming + languages. + Because the game VM keeps track of the correct table, the game developer + doesn't need to take this into consideration when programming a game. + If a method within the game sends data to a player, it will be delivered + to the player in the correct running game. + The same game token is used to store the game state in the database. + Therefore, no game states will be mixed up either. +\end_layout + +\begin_layout Standard +This module does not affect game runtime but evaluates a new game state + and handles communication between the game and the players. +\end_layout + +\begin_layout Subsection +The database module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-database-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +Game data from all games on the GGS are stored in the database backend of + the database module. +\end_layout + +\begin_layout Standard +In the GGS prototype the database module is using a database management + system called Mnesia. + Mnesia ships with the standard Erlang distribution and is a key-value store + type database. + Mnesia is designed to handle the stress of telecoms systems, and has some + features specifically tailored for telecoms which are not commonly found + in other databases. + Key features of the Mnesia database are: +\end_layout + +\begin_layout Itemize +Fast key/value lookups +\end_layout + +\begin_layout Itemize +Distribution of the database system +\end_layout + +\begin_layout Itemize +Fault tolerance +\end_layout + +\begin_layout Standard +\begin_inset CommandInset citation +LatexCommand citet +key "667766" + +\end_inset + + +\end_layout + +\begin_layout Standard +The features of Mnesia originally intended for telecoms prove very useful + for the purposes of the GGS as well. + The fault tolerance and speed of Mnesia are very valueable tools, the fast + key/value lookups permit many lookups per second to the database. +\end_layout + +\begin_layout Standard +Game data will not be lost when a game is stopped or has gone down for unknown + reasons. + This makes it possible to continue a game just before the failure without + having to start the game from the beginning. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Mnesia}}{Database server used in the GGS} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The GGS stores the game state in the distributed Mnesia database, from which + the state can be restored in the event of a crash. +\end_layout + +\begin_layout Standard +Each game is uniquely identified by a table token and the data of each game + is stored within two different namespaces. + The namespaces are named World and Localstorage. + The World is used contain all game data related to the game state. + This sort of game data may change during the runtime of the game. + The Localstorage should contain data independent of the game state. + Game resources, constants and globals are all examples of data that could + reside within the Localstorage. + To store a value within the database, not only is the table token and the + name of the namespace required, but a unique key so that the value can + be successfully retrieved or modified later. + The key is fully decidable by the game developer. + +\end_layout + +\begin_layout Standard +The interface of the database module is an implementation of the upcoming + W3C Web Storage specification. + Web Storage is intended for use in web browsers, providing a persistant + storage on the local machine for web applications. + The storage can be used to communicate in between browser windows (which + is difficult when using cookies), and to store larger chunks of data +\begin_inset CommandInset citation +LatexCommand citet +key "webstorage:website" + +\end_inset + +. + Usage of the web storage standard in the GGS provides a well documented + interface to the database backend. +\end_layout + +\begin_layout Section +Techniques for ensuring reliability +\end_layout + +\begin_layout Standard +One of the main goals of the project is to achieve high reliability. + The term +\begin_inset Quotes eld +\end_inset + +reliable system +\begin_inset Quotes erd +\end_inset + + is defined by the IEEE as a system with +\begin_inset Quotes eld +\end_inset + +the ability of a system or component to perform its required functions under + stated conditions for a specified period of time +\begin_inset Quotes erd +\end_inset + + +\begin_inset CommandInset citation +LatexCommand citet +key "ieee_90" + +\end_inset + +. + There are some tools for creating reliable applications built in to Erlang. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{Reliability}}{The ability of a system or component to perform its + required functions under stated conditions for a specified period of time} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{IEEE}}{Institute of Electrical and Electronics Engineers, read "I-triple- +E"} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Itemize +Links between processes. + When a process spawns a new child process, and the child process later + exits, the parent process is notified of the exit. + +\end_layout + +\begin_layout Itemize +Transparent distribution over a network of processors. + When several nodes participate in a network, it does not matter on which + of these machines a process is run. + Communication between processes does not depend on the node in which each + process is run. + +\end_layout + +\begin_layout Itemize +Hot code replacements. + Two versions of the same module can reside in the memory of Erlang at any + time. + This means that a simple swap between these versions can take place very + quickly, and without stopping the machine. +\end_layout + +\begin_layout Standard +These three features are some of the basic building blocks for more sophisticate +d reliability systems in Erlang. + Many times it is not necessary to use these features directly, but rather + through the design patterns described below. +\end_layout + +\begin_layout Subsection +Supervisor structure +\begin_inset CommandInset label +LatexCommand label +name "sub:Supervisor-structure" + +\end_inset + + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +This entire section is bad. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +By linking processes together and notifying parents when children exit, + supervisors are created. + A supervisor is a common approach in ensuring that an application functions + in the way it was intended +\begin_inset CommandInset citation +LatexCommand citet +key "Savor:1997:HSA:851010.856089" + +\end_inset + +. + When a process misbehaves, the supervisor takes some action to restore + the process to a functional state. + +\end_layout + +\begin_layout Standard +There are several approaches to supervisor design in general (when not just + considering how they work in Erlang). + One common approach is to have the supervisor look in to the state of the + process(es) it supervises, and let the supervisor make decisions based + on this state. + The supervisor has a specification of how the process it supervises should + function, and this is how it makes decisions. + +\end_layout + +\begin_layout Standard +In Erlang, we have a simple version of supervisors. + We do not inspect the state of the processes being supervised. + We do have a specification of how the supervised processes should behave, + but on a higher level. + The specification describes things such as how many times in a given time + interval a child process may crash, which processes need restarting when + crashes occur, and so forth. + +\end_layout + +\begin_layout Standard +When the linking of processes in order to monitor exit behaviour is coupled + with the transparent distribution of Erlang, a very powerful supervision + system is created. + For instance, we can restart a failing process on a different, new node, + with minimal impact on the system as a whole. + +\end_layout + +\begin_layout Standard +In the GGS, we have separated the system in to two large supervised parts. + We try to restart a crashing child separately, if this fails too many +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +Exactly how many +\begin_inset Quotes eld +\end_inset + +too many +\begin_inset Quotes erd +\end_inset + + is depends on a setting in the supervisor, ten crashes per second is a + reasonable upper limit. +\end_layout + +\end_inset + + times, we restart the nearest supervisor of this child. + This ensures separation of the subsystems so that a crash is as isolated + as possible. +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset Note Note +status open + +\begin_layout Plain Layout +We should really do this graphic in EPS instead of PNG +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/Supervisor_tree_GGS.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +The supervisor structure of GGS +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The graphic above shows our two subsystems, the coordinator subsystem and + the dispatcher subsystem. + Since these two systems perform very different tasks they have been separated. + Each subsystem has one worker process, the coordinator or the dispatcher. + The worker process keeps a state which should not be lost upon a crash. +\end_layout + +\begin_layout Standard +We have chosen to let faulty processes crash very easily when they receive + bad data, or something unexpected happens. + The alternative to crashing would have been to try and fix this faulty + data, or to foresee the unexpected events. + We chose not to do this because it is so simple to monitor and restart + processes, and so difficult to try and mend broken states. + This approach is something widely deployed in the Erlang world, and developers + are often encouraged to “Let it crash”. +\end_layout + +\begin_layout Standard +To prevent any data loss, the good state of the worker processes is stored + in their respective backup processes. + When a worker process (re)starts, it asks the backup process for any previous + state, if there is any that state is loaded in to the worker and it proceeds + where it left off. + If on the other hand no state is available, a special message is delivered + instead, making the worker create a new state, this is what happens when + the workers are first created. +\end_layout + +\begin_layout Subsection +Reduncancy +\end_layout + +\begin_layout Standard +The modules in the GGS are built to be capable of redundant operation. + By adding a backup process to sensitive processes, the state can be kept + in the event of a crash. + The coordinator of the GGS prototype has this backup feature built in. + The coordinator passes state along to the backup process which keeps the + data safe. + In the event of a crash, the coordinator recovers the state from the backup + process. + Figure +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:redundancy" + +\end_inset + + depicts the redundancy built in to the coordinator process. +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/redundancy.eps + scale 40 + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "fig:redundancy" + +\end_inset + +To the left normal execution is pictured; the server state is backed up. + To the right; the exceptional excution, where the state is retrieved from + the backup to repopulate the server. +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Hot code replacement +\end_layout + +\begin_layout Standard +Hot code replacement is a technique used to update systems while they are + running. + The main use of hot code replacement are in critical systems that require + low downtime, such as telecom systems. + By using hot code replacement system can be able to achieve as high uptime + as possible and thus improving the reliability of the system. + Code replacement is a feature that exist in Erlang which means that with + some work it could be implemented into the GGS. +\end_layout + +\begin_layout Section +Example of a GGS server application in Javascript +\end_layout + +\begin_layout Standard +Below is a concrete example of a simple chat server application written + using the GGS. + The language chosen for this chat server is JavaScript. + The GGS processes all incoming data through a protocol parser, which interprets + the data and parses it into an internal format for the GGS. +\end_layout + +\begin_layout Standard +When the GGS receives a command from a client, it is passed along to the + game VM in a function called +\emph on +playerCommand. + +\emph default + The +\emph on +playerCommand +\emph default + function is responsible for accepting the command into the VM. + Typically the +\emph on +playerCommand +\emph default + function contains conditional constructs which decide the next action to + take. + In +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-concrete-example" + +\end_inset + + an example of the +\emph on +playerCommand +\emph default + function can be seen. +\end_layout + +\begin_layout Standard +In +\begin_inset CommandInset ref +LatexCommand ref +reference "alg:A-concrete-example" + +\end_inset + + the +\emph on +playerCommand +\emph default + function accepts two different commands. + The first command is a command which allows chat clients connected to the + chat server to change nicknames, which are used when chatting. + In order to change nickname, a client must send +\begin_inset Quotes eld +\end_inset + +/nick +\begin_inset Quotes erd +\end_inset + + immediately followed by a nickname. + When a message arrives to the GGS which has the form corresponding to the + nickname change, the +\emph on +playerCommand +\emph default + function is called with the parameters +\emph on +player_id, command, +\emph default +and +\emph on +args +\emph default + filled in appropriately. +\end_layout + +\begin_layout Standard +The +\emph on +playerCommand +\emph default + function is responsible for calling the helper functions responsibly for + carrying out the actions of each message received. + +\emph on +changeNick +\emph default + is a function which is called when the +\begin_inset Quotes eld +\end_inset + +/nick +\begin_inset Quotes erd +\end_inset + + message is received. + The +\emph on +changeNick +\emph default +function uses a feature of the GGS called localStorage (see section +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Communication-with-external" + +\end_inset + +), which is an interface to the database backend contained in the database + module (see +\begin_inset CommandInset ref +LatexCommand ref +reference "sub:The-database-module" + +\end_inset + +). + The database can be used as any key-value store, however the syntax for + insertions and fetch operations is tighty integrated in the GDL of the + GGS. +\end_layout + +\begin_layout Standard +Access to the localStorage is provided through the +\emph on +GGS object +\emph default +, which also can be used to communicate with the rest of the system from + the GDL. + Implementation specifics of the GGS object are provided in +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:Communication-with-external" + +\end_inset + +. +\end_layout + +\begin_layout Standard +\begin_inset Float algorithm +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +lstset{ +\end_layout + +\begin_layout Plain Layout + +language=JavaScript, +\end_layout + +\begin_layout Plain Layout + +backgroundcolor= +\backslash +color{white}, +\end_layout + +\begin_layout Plain Layout + +extendedchars=true, +\end_layout + +\begin_layout Plain Layout + +basicstyle= +\backslash +footnotesize +\backslash +ttfamily, +\end_layout + +\begin_layout Plain Layout + +showstringspaces=false, +\end_layout + +\begin_layout Plain Layout + +showspaces=false, +\end_layout + +\begin_layout Plain Layout + +numbers=left, +\end_layout + +\begin_layout Plain Layout + +numberstyle= +\backslash +footnotesize, +\end_layout + +\begin_layout Plain Layout + +numbersep=9pt, +\end_layout + +\begin_layout Plain Layout + +tabsize=2, +\end_layout + +\begin_layout Plain Layout + +breaklines=true, +\end_layout + +\begin_layout Plain Layout + +showtabs=false, +\end_layout + +\begin_layout Plain Layout + +captionpos=b +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +begin{lstlisting}[language=JavaScript] +\end_layout + +\begin_layout Plain Layout + +function playerCommand(player_id, command, args) { +\end_layout + +\begin_layout Plain Layout + + if(command == "/nick") { +\end_layout + +\begin_layout Plain Layout + + changeNick(player_id, args); +\end_layout + +\begin_layout Plain Layout + + } else if(command == "message") { +\end_layout + +\begin_layout Plain Layout + + message(player_id, args); +\end_layout + +\begin_layout Plain Layout + + } +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + +function changeNick(player_id, nick) { +\end_layout + +\begin_layout Plain Layout + + var old_nick = GGS.localStorage.getItem("nick_" + player_id); +\end_layout + +\begin_layout Plain Layout + + GGS.localStorage.setItem("nick_" + player_id, nick); +\end_layout + +\begin_layout Plain Layout + + if (!old_nick) { +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll("notice", nick + " joined"); +\end_layout + +\begin_layout Plain Layout + + } else { +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll("notice", old_nick + " is now called " + nick); +\end_layout + +\begin_layout Plain Layout + + } +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + +function message(player_id, message) { +\end_layout + +\begin_layout Plain Layout + + var nick = GGS.localStorage.getItem("nick_" + player_id); +\end_layout + +\begin_layout Plain Layout + + GGS.sendCommandToAll('message', nick + "> " + message); +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\begin_layout Plain Layout + + +\backslash +end{lstlisting} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout +\begin_inset CommandInset label +LatexCommand label +name "alg:A-concrete-example" + +\end_inset + +A concrete example of a simple chat server written in Javascript, running + on the GGS +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Chapter +Problems of implementation +\begin_inset CommandInset label +LatexCommand label +name "cha:Problems-of-implementation" + +\end_inset + + +\end_layout + +\begin_layout Standard +This chapter contains specific problems encountered when implementing the + GGS prototype. + Some of the problems described have solutions attached, however some problems + were not solved, therefore only ideas for slutions have been attached. +\end_layout + +\begin_layout Standard +The integration of JavaScript as a GDL in the GGS prototype was particularily + difficult, and is handled in this section. + Unique identification is also handled, as is the design of the GGS protocol. +\end_layout + +\begin_layout Section +JavaScript engine +\end_layout + +\begin_layout Standard +The GGS prototype uses a vistual machine to sandbox each game. + JavaScript was chosen for the prototype due to its commonality in web applicati +ons and the flexibility of the language. + Any language with the proper bindings to Erlang could have been used in + theory. +\end_layout + +\begin_layout Standard +There are two main JavaScript virtual machines, or +\emph on +engines +\emph default + available at the time of the writing of this thesis. + There is a group of machines developed by Mozilla called +\emph on +TraceMonkey, JaegerMonkey, SpiderMonkey +\emph default +and +\emph on +IonMonkey +\emph default +, and also there is Google V8. + The group of Mozilla machines are largely the same, and are referred to + as the same machine for simplicity. +\end_layout + +\begin_layout Standard +For the Mozilla machines, there exists an Erlang binding called erlang_js, + and for the V8 machine a binding called erlv8 exists. +\end_layout + +\begin_layout Subsection +erlang_js +\end_layout + +\begin_layout Standard +Erlang_js provides direct communication with the JavaScript VM. + Which is exactly what is desired, however also required is thee possibility + to communicate from erlang_js to Erlang. + The ability to communicate from JavaScript to Erlang functionality is not + yet implemented in erlang_js, due to lack of time on the behalf of the + erlang_js developers. +\end_layout + +\begin_layout Standard +There were two possible solutions to the problem of the JavaScript to Erlang + communication path missing, the path could be implemented by the GGS project, + or a switch from erlang_js for some other JavaScript engine could be made. + +\end_layout + +\begin_layout Standard +Attempts at creating the communication path from JavaScript to Erlang were + initially made, however the communiucation path never became stable enough + for usage in the GGS and the erlang_js software was abandoned. +\end_layout + +\begin_layout Subsection +erlv8 +\end_layout + +\begin_layout Standard +erlv8 is powered by the V8 engine developed by Google rather than the engines + developed by Mozilla. + The ability to communicate with Erlang from JavaScript using callbacks + is available in the erlv8 bindings, therefore this feature does not have + to be added to the bindings in order to be used in the GGS. +\end_layout + +\begin_layout Standard +Initial releases of the erlv8 bindings had stability issues, these were + however solved by the erlv8 developers during the usage of erlv8 in the + GGS. + erlv8 is the JavaScript engine powering JavaScript as a GDL in the GGS. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{V8}}{JavaScript engine developed by Google} +\end_layout + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{SpiderMonkey}}{JavaScript engine developed by Mozilla} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +UUID +\end_layout + +\begin_layout Standard +Erlang identifies processes uniquely throughout the entire Erlang network + using process IDs (PID). + When we wish to refer to erlang processes from outside our erlang system, + for example in a virtual machine for a different language, possibly on + a different machine, these PID:s are no longer useful. + +\end_layout + +\begin_layout Standard +This problem is not new, and a common solution is to use a Universally Unique + Identifier, a UUID. + These identifiers are generated both using randomization and using time. + A reasonably large number of UUID:s can be generated before a collision + should occur. + There are standard tools in many UNIX systems to generate UUID:s, we chose + to use the uuidgen command, which employs an equidistributed combined Tausworth +e generator. +\end_layout + +\begin_layout Section +Protocol design +\end_layout + +\begin_layout Standard +Initially the GGS protocol was designed to use the UDP protocol for transport. + Due to the lack of error checking in the UDP protocol, the UDP protocol + is faster than the TCP protocol, this was a main reason to use UDP. + The GGS does however need error checking to be as reliable as possible, + therefore an error checking layer would have to be placed on top of UDP. +\end_layout + +\begin_layout Standard +The development of an error checking layer was weighed against the implementatio +n of TCP instead of UDP, thus losing some speed. + Even though speed was lost, TCP was chosen due to the relative ease of + implementation compared to UDP. + Due to the modularity of the GGS, a UDP extension is possible by replacing + the network parts of the GGS. +\end_layout + +\begin_layout Standard +Furthermore, in a move to increase the speed of the GGS prototcol the binary + BSON protocol +\begin_inset CommandInset citation +LatexCommand citet +key "bson:website" + +\end_inset + + was initially considered. + BSON is a protocol which can be used for vert fast traversal of data. + The BSON protocol is however rather difficult to read in its plain format, + and no implementation has been bade for the GGS. +\end_layout + +\begin_layout Standard +The Apache Thrift +\begin_inset CommandInset citation +LatexCommand citep +key "Slee2007" + +\end_inset + + was also an alternative. + Using Thrift would mean the GGS would feature a standard protocol for network + communication. + Before finding out about Thrift, an implementation of the GGS protocol + had already been made, moving to Thrift would mean too much work. +\end_layout + +\begin_layout Standard +The use of Thrift, BSON, or other protocols can be supported quite easily + by develpping protocol modules for each protocol. + No protocol modules for these protocols have however been developed during + the writing of this thesis +\end_layout + +\begin_layout Section +Design choices +\begin_inset Note Note +status open + +\begin_layout Plain Layout +This section is wrongly placed +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +When designing concurrent applications, it is useful to picture them as + real world scenarios, and to model each actor as a real world process. + A real world process is a process which performs some action in the real + world, such as a mailbox receiving a letter, a door being opened, a person + translating a text, a soccer player kicking the ball, just to name a few + examples. + Since we focus on games in this project, it is suitable to model our system + as a place where games take place. + We imagined a chess club. + +\end_layout + +\begin_layout Standard +The clients pictured as green circles can be thought of as the physical + chess players. +\end_layout + +\begin_layout Standard +When a player wants to enter the our particular chess club, he must first + be let in by the doorman, called the +\emph on +Dispatcher +\emph default + in the GGS. +\end_layout + +\begin_layout Standard +He then gets a name badge, and thus becomes a +\emph on +Player +\emph default + process in the system. + He is also guided in to the lobby by the +\emph on +Coordinator +\emph default +, which has the role of the host of the chess club. +\end_layout + +\begin_layout Standard +When players wish to play against each other, they talk to the +\emph on +Coordinator +\emph default + who pairs them up, and places them at a table. + Once they have sat down at the table, they no longer need the assistance + of the +\emph on +Coordinator +\emph default +, all further communication takes place via the table. + This can be thought of as the actual chess game commencing. + +\end_layout + +\begin_layout Standard +All the moves made in the game are recorded by the table, such that the + table can restore the game in case something would happen, such as the + table tipping over, which would represent the table process crashing. +\end_layout + +\begin_layout Standard +Once a player wishes to leave a game, or the entire facility, he should + contact the +\emph on +Coordinator +\emph default +, who revokes his name badge and the +\emph on +Dispatcher +\emph default + will let the player out. +\end_layout + +\begin_layout Standard +With the information kept in the tables and the +\emph on +Coordinator +\emph default + combined, we can rebuild the entire state of the server at a different + location. + This can be thought of the chess club catching fire, and the +\emph on +Coordinator +\emph default + rounding up all the tables, running to a new location and building the + club up in the exact state it was prior to the fire. +\end_layout + +\begin_layout Chapter +Results and discussion +\begin_inset CommandInset label +LatexCommand label +name "chap:Results-and-discussion" + +\end_inset + + +\end_layout + +\begin_layout Section +Software development methodology +\end_layout + +\begin_layout Standard +The project has not followed any specific software development methodology. + All work has been based on a predefined schedule and the specifications + are made by team members rather than an outside customer or stakeholder. + The process can be described as a plan-driven development method going + from brainstorming to design, then implementation and finally testing. + Yet there has been cycles in the process in form of redesign and code refactori +ng. +\end_layout + +\begin_layout Section +Statistics +\end_layout + +\begin_layout Standard +Important things to note are that the number of clients is not a good way + of measuring the performance of the server because the server is possible + to have a large number of clients on the server but it can not handle all + the information. + Instead the performance of the server should be measured in the number + of messages it can handle per second. +\end_layout + +\begin_layout Standard +We were able to reach 6000 messages per second on the server, which corresponds + to around 350 clients. + However soon after this mnesia printed some warnings and the clients started + to lag. + With this in mind one thing to investigate is if mnesia is the bottleneck + in the system. + Current game servers do not use databases to save their state and maybe + we can see the reason here. + Other possible bottlenecks may be the protocol, but this seems less likely + than mnesia. + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status collapsed + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/msg_per_sec.eps + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout + +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/ping.eps + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout + +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset Float figure +wide false +sideways false +status open + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +begin{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Graphics + filename graphics/msg_per_secoutput.eps + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +end{centering} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Plain Layout +\begin_inset Caption + +\begin_layout Plain Layout + +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Section +Future improvements +\end_layout + +\begin_layout Standard +The specification of the GGS prototype is huge and like many other software + projects relying on outside technologies, in time it would require a lot + of maintanance. + Therefore there are a lot of areas in which the GGS could be improved such + as performance, compatibility, ease of setup and usage. +\end_layout + +\begin_layout Subsection +Performance +\end_layout + +\begin_layout Subsubsection +Protocols +\end_layout + +\begin_layout Standard +Because of TCP being a connection oriented protocol, it is not suited for + all types of game data transfers. + Each transmission will consume more network bandwith than connectionless + protocols like UDP and cause uneccessary load on the processor. + Therefore support for UDP would mean that more games could be run simultaneousl +y on the GGS. + Another advantage of UDP is latency being reduced. + Without having to setup a connection for each group packets of data being + sent, they will be sent instantly and therefore arrive earlier. + Latency is of highest importance in realtime games as it improves realism + and fairness in gameplay and many game developers requires the freedom + to take care of safety issues as packet losses themselves. + This concludes that UDP would be a benefit for the GGS, game developers + and players alike. +\end_layout + +\begin_layout Subsubsection +Database +\end_layout + +\begin_layout Standard +Currently Mnesia is used for game data storage. + During stress tests, Mnesia has turned out to be the bottleneck due to + data losses when too many games are played on the GGS simultaneously. + This could be prevented by replacing Mnesia with another database management + system or use Mnesia in combination with the ETS module of erlang. + ETS provides fast access to the RAM and thus Mnesia could be used less + frequently. + +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +nomenclature{ +\backslash +textbf{ETS}}{Erlang Term Storage} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Subsection +Compatibility +\end_layout + +\begin_layout Standard +GGS relies on modern technologies. + This includes the virtual machines(VM) that the GGS uses for communication + between Erlang and the GDL:s. + These specific VM:s are crucial for game developers to be able to write + games in other languages than Erlang. + Therefore it would be best for the GGS to have as many of these VM:s implemente +d as possible. + The VM:s taken into consideration so far have been unstable or incomplete + and it is possible to search for more VM:s, testing them and intergrate + them into the GGS prototype. +\end_layout + +\begin_layout Subsection +Setup +\end_layout + +\begin_layout Standard +The GGS prototype installation procedure requires different configuring + and building steps and thus it isn't in an acceptable release state. + An executable installation file for each supported platform would be optimal. +\end_layout + +\begin_layout Subsection* +5.3.4 Usage +\end_layout + +\begin_layout Subsubsection +Programming languages +\end_layout + +\begin_layout Standard +The GGS does not support many programming languages. + For a programming language to be compatible with the GGS, not only does + it require a VM for that specific language, but the VM must have the ability + to communicate to Erlang. + More research is needed to find VM:s with this built in functionality. + +\end_layout + +\begin_layout Subsubsection +Documentation +\end_layout + +\begin_layout Standard +To start the GGS is not self explanatory. + This together with overall usage of GGS should be documented. + The interface for usage of game developers is also in need of documentation. + Features and requirements with respect to the GGS would assist users to + know what they need in order to use the GGS and how they would benefit + of it. + The GGS does not support many programming languages nor does it have a + complete documentation. + This needs to be taken care of in future versions. +\end_layout + +\begin_layout Chapter +Conclusion +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +addcontentsline{toc}{section}{Glossary} +\end_layout + +\begin_layout Plain Layout + + +\backslash +printnomenclature +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard + +\end_layout + +\begin_layout Standard +\begin_inset CommandInset bibtex +LatexCommand bibtex +bibfiles "bibliography" +options "plainnat" + +\end_inset + + +\end_layout + +\end_body +\end_document From 9eb4bc2093a8ecaa7c4833163480da7645c4397d Mon Sep 17 00:00:00 2001 From: Jeena Paradies Date: Fri, 6 May 2011 17:55:40 +0200 Subject: [PATCH 11/16] removed unnecessary files --- merge.lyx | 7228 ------------------------------------------- not-working.lyx | 7817 ----------------------------------------------- working.lyx | 7223 ------------------------------------------- 3 files changed, 22268 deletions(-) delete mode 100644 merge.lyx delete mode 100644 not-working.lyx delete mode 100644 working.lyx diff --git a/merge.lyx b/merge.lyx deleted file mode 100644 index 938b4e6..0000000 --- a/merge.lyx +++ /dev/null @@ -1,7228 +0,0 @@ -#LyX 2.0 created this file. For more info see http://www.lyx.org/ -\lyxformat 413 -\begin_document -\begin_header -\textclass report -\begin_preamble -\usepackage{indentfirst} -\usepackage{tocloft} -\usepackage{calc} -\date{} -\usepackage[section] {placeins} -\def\myClearpage{% - \ifvmode - \ifnum \@dbltopnum =\m@ne - \ifdim \pagetotal <\topskip - \hbox{}% - \fi - \fi - \fi -% \newpage - \write\m@ne{}% - \vbox{}% - \penalty -\@Mi -} -\def\myCleardoublepage{\myClearpage\if@twoside \ifodd\c@page\else - \hbox{}\if@twocolumn\hbox{}\fi\fi\fi} -\usepackage{morefloats} -\usepackage{graphicx} -\usepackage{subfig} -\usepackage{tocloft} -\renewcommand{\cftchapfont}{\bfseries} -\renewcommand{\cftchappagefont}{\bfseries} -\renewcommand{\cftchappresnum}{Chapter } -\renewcommand{\cftchapnumwidth}{6em} - -\oddsidemargin 0.5in -\textwidth 6in -\topmargin 0.0in -\textheight 8.0in -\setlength\topskip{24pt} -\footskip 0.75in - -\usepackage[compact]{titlesec} - - -\titleformat{\chapter}[display] -{\vskip-8em\normalfont\bfseries} -{\LARGE\raggedright\thechapter} -{14ex} -{\vspace{-20ex}% -\LARGE\raggedleft} -[\vspace{1ex}% -{\titlerule[1pt]}] - -\usepackage[absolute]{textpos} - -\usepackage{fancyheadings} -\pagestyle{fancy} -\lhead{\thechapter} - -\usepackage[hmargin=3cm,vmargin=3.5cm]{geometry} -\usepackage{algorithmic} -\usepackage{listings} - -\usepackage{color} -\definecolor{lightgray}{rgb}{.9,.9,.9} -\definecolor{darkgray}{rgb}{.4,.4,.4} -\definecolor{purple}{rgb}{0.65, 0.12, 0.82} - -\lstdefinelanguage{JavaScript}{ - keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break}, - keywordstyle=\color{blue}\bfseries, - ndkeywords={class, export, boolean, throw, implements, import, this}, - ndkeywordstyle=\color{darkgray}\bfseries, - identifierstyle=\color{black}, - sensitive=false, - comment=[l]{//}, - morecomment=[s]{/*}{*/}, - commentstyle=\color{purple}\ttfamily, - stringstyle=\color{red}\ttfamily, - morestring=[b]', - morestring=[b]" -} - -\lstdefinelanguage{Erlang}{ - keywords={typeof, true, false, catch, return, null, catch, switch, var, if, in, while, do, else, case, break, expose}, - keywordstyle=\color{blue}\bfseries, - ndkeywords={class, export, boolean, throw, implements, import, this,erlv8_vm, erlv8_fun_invocation -,erlv8_object}, - ndkeywordstyle=\color{darkgray}\bfseries, - identifierstyle=\color{black}, - sensitive=false, - comment=[l]{\%}, - morecomment=[s]{/*}{*/}, - commentstyle=\color{purple}\ttfamily, - stringstyle=\color{red}\ttfamily, - morestring=[b]', - morestring=[b]" -} - -\usepackage{float} - -\floatstyle{ruled} -\newfloat{code}{thp}{lop} -\floatname{code}{Code} - -\usepackage{nomencl} -\makenomenclature -\renewcommand{\nomname}{Glossary} -\end_preamble -\use_default_options true -\maintain_unincluded_children false -\language english -\language_package default -\inputencoding auto -\fontencoding global -\font_roman lmodern -\font_sans default -\font_typewriter default -\font_default_family rmdefault -\use_non_tex_fonts false -\font_sc false -\font_osf false -\font_sf_scale 100 -\font_tt_scale 100 - -\graphics default -\default_output_format default -\output_sync 0 -\bibtex_command default -\index_command default -\paperfontsize default -\spacing onehalf -\use_hyperref false -\papersize a4paper -\use_geometry false -\use_amsmath 1 -\use_esint 1 -\use_mhchem 1 -\use_mathdots 1 -\cite_engine natbib_authoryear -\use_bibtopic false -\use_indices false -\paperorientation portrait -\suppress_date false -\use_refstyle 0 -\index Index -\shortcut idx -\color #008000 -\end_index -\paperwidth 11in -\paperheight 8.5in -\leftmargin 1.25in -\topmargin 0in -\rightmargin 1in -\bottommargin 1.7in -\secnumdepth 2 -\tocdepth 2 -\paragraph_separation indent -\paragraph_indentation default -\quotes_language english -\papercolumns 1 -\papersides 1 -\paperpagestyle empty -\tracking_changes false -\output_changes false -\html_math_output 0 -\html_css_as_file 0 -\html_be_strict false -\end_header - -\begin_body - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{textblock*}{ -\backslash -paperwidth}(0mm,40mm) -\end_layout - -\begin_layout Plain Layout - - -\backslash -begin{center} -\end_layout - -\begin_layout Plain Layout - - -\backslash -includegraphics[width= -\backslash -paperwidth/2]{graphics/logo} -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{center} -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{textblock*} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Title -A Reliable Generic Game Server -\end_layout - -\begin_layout Author -Niklas Landin -\begin_inset Newline newline -\end_inset - -Richard Pannek -\begin_inset Newline newline -\end_inset - -Mattias Pettersson -\begin_inset Newline newline -\end_inset - -Jonatan Pålsson -\end_layout - -\begin_layout Abstract -This is the abstract! -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -pagenumbering{roman} -\end_layout - -\begin_layout Plain Layout - - -\backslash -setcounter{page}{3} -\end_layout - -\begin_layout Plain Layout - - -\backslash -renewcommand -\backslash -contentsname{Table of Contents} -\end_layout - -\begin_layout Plain Layout - - -\backslash -renewcommand{ -\backslash -cfttoctitlefont}{ -\backslash -hfill -\backslash -Large} -\backslash -renewcommand{ -\backslash -cftaftertoctitle}{ -\backslash -hfill} -\end_layout - -\begin_layout Plain Layout - - -\backslash -renewcommand -\backslash -cftpartdotsep{6.6} -\end_layout - -\begin_layout Plain Layout - - -\backslash -renewcommand -\backslash -cftchapdotsep{6.6} -\end_layout - -\end_inset - - -\begin_inset CommandInset toc -LatexCommand tableofcontents - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Newpage newpage -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -pagenumbering{arabic} -\end_layout - -\begin_layout Plain Layout - - -\backslash -setcounter{page}{1} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Chapter -Introduction -\end_layout - -\begin_layout Standard -Online gaming, and computer gaming in general has become an important part - in many peoples day-to day lives. - A few years ago, computer games were not at all as popular as they are - today. - With the advances in computer graphics and computer hardware today's games - are much more sophisticated then they were in the days of -\emph on -NetHack -\emph default -, -\emph on -Zork, -\emph default -or -\emph on -Pacman. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Zork}}{A textual computer game developed by students at MIT} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Pacman}}{An early graphical computer game developed by Namco} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{NetHack}}{An early computer game developed by the NetHack team, arguably - the oldest computer game still in development} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The early computer games featured simple, or no graphics at all -\begin_inset CommandInset citation -LatexCommand citet -key "nethack:website" - -\end_inset - -. - The games often took place in a textual world, leaving the task of picturing - the world up to the player. - Multiplayer games were not as common as they are today, whereas most games - today are expected to have a multiplayer mode, most early games did not. -\end_layout - -\begin_layout Standard -Since these early games, the gaming industry have become much more influential - in many ways. - Many advanced in computer hardware are thought to come from pressure from - the computer game industry. - More powerful games require more powerful, and more easily available hardware -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Drop a reference to the gaming industry pressuring more advanced hardware -\end_layout - -\end_inset - -. - Due to the high entertainment value of modern computer games, gaming has - become a huge industry, where large amounts of money are invested. - The gaming industry is today, in some places even larger than the motion - picture industry. - -\begin_inset CommandInset citation -LatexCommand citet -key "esa:website,thenumbers:website" - -\end_inset - - -\end_layout - -\begin_layout Standard -Due to the increasing importance of computer gaming, more focus should be - spent on improving the quality of the gaming service. - As more and more computer games are gaining multiplayer capabilities, the - demands for multiplayer networking software rises. - This thesis is about techniques for improving the quality of this networking - software. -\end_layout - -\begin_layout Standard -The reliable generic game server, hereafter known as GGS -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{GGS}}{Generic Game Server, a software for reliably hosting network - games. - The subject of this thesis.} -\end_layout - -\end_inset - -, is a computer program designed to -\emph on -host -\emph default - network games on one or more server computers. - Hosting, in a network software setting, means allowing client software - connect to the server software, for the purpose of utilizing services provided - by the server. - The GGS software provides games as a service, and the clients connecting - to the GGS can play these games on the GGS. -\end_layout - -\begin_layout Standard -The idea of game servers is not new, network games have been played for - decades. - Early, popular examples of network games include the -\emph on -Quake -\emph default - series, or the -\emph on -Doom -\begin_inset Note Note -status collapsed - -\begin_layout Plain Layout - -\emph on -Come up w/ better game -\end_layout - -\end_inset - - -\emph default - games. - Newer examples of network games include -\emph on -World of Warcraft -\emph default -, and -\emph on -Counter-Strike -\emph default -. - The difference between the GGS and the servers for these games is that - the servers for Doom, Quake, and the others listed, were designed with - these specific games in mind. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Quake}}{A first person shooter series developed by ID software. - The series consists of four games.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Doom}}{A first person shooter series developed by ID software. - The series consists of three games.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Counter-Strike}}{A multiplayer first person shooter game, popular - in E-Sports.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Counter-Strike}}{A multiplayer first person shooter game, popular - in E-Sports.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Framework}}{A supporting structure, the GGS is a framework for developing - network games} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{First-person shooter}}{A game in which centers around gun combat - from the first person perspective.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{MMORPG}}{Massively multiplayer online role playing game. - An online game with several thousand participants.} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -What GGS does is to provide a -\emph on -generic -\emph default - framework for developing network games. - The framework is generic in the sense that it is not bound to a specific - game. - There are many different types of games, some are inherently more time - sensitive than others, strategy games are examples of games which are not - very sensitive to time delays, first-person shooters however, can be very - sensitive. -\end_layout - -\begin_layout Standard -The generic nature of the GGS allows the creation of many different types - of games, the motivation behind this is to remove the necessity of writing - new game servers when developing new games. -\end_layout - -\begin_layout Standard -The GGS is in addition to being generic, also -\emph on -reliable -\emph default - in the sense that the gaming service provided is consistent and available. - A consistent and available server is a server that handles hardware failures - and software failures gracefully. - In the event of a component breaking within the GGS, the error is handled - by fault recovery processes, thereby creating a more reliable system. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Hardware failiure}}{A failiure in hardware (hard drive, memory, processor -, etc) which causes a system to stop functioning} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Software failiure}}{A failiure in software (the GGS, the operating - system, etc) which causes a system to stop functioning} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Background -\end_layout - -\begin_layout Standard -The game industry is a quickly growing industry where the need for new technique -s are large. - One specific section where the development has stalled is the game server - section. -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Citation needed -\end_layout - -\end_inset - - The existing game servers are functional but they lack good fault tolerance - and the ability to scale well -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Citation needed -\end_layout - -\end_inset - -. - Users will notice this in low uptime and many crashes. - This is a problem that has existed and been resolved in other industries. - In the telecom industry solutions to similar problems have been found. -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{The nine nines}}{A common goal for availability in the telecom business. - A system with nine nines of availability is available 99.999999999% of the - time} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Downtime}}{The amount of time a system is unavailable and does not - function} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Uptime}}{The amount of time a system is available and functions} -\end_layout - -\end_inset - -A common figure often used in telecoms is that of -\emph on -the nine nines -\emph default -, referring to -\begin_inset Formula $99.999999999\%$ -\end_inset - - of availability, or roughly -\begin_inset Formula $15ms$ -\end_inset - - downtime in a year -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Citation needed -\end_layout - -\end_inset - -. - The level of instability and bad fault tolerance seen in the game server - industry would not have been accepted in the telecoms industry. - This level of instability should not be accepted in the game server industry - either. - An unavailable phone system could potentially have life threatening consequence -s, leaving the public unable to contact emergency services. - The same can not be said about an unavailable game server. - The statement that game servers are less important than phone systems is - not a reason not to draw wisdom from what the telecoms have already learned. -\end_layout - -\begin_layout Standard -Moving back to the gaming industry. - The main reason to develop reliable servers are monetary, it is important - for game companies to expand its customer base. - Reliable game servers are one improvement that will create a good image - of a company. - In general the downtime of game servers is much higher than the downtime - of telecom system -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Citation needed... -\end_layout - -\end_inset - -. - The structure of the system is similar in many ways and it should be possible - to reuse solutions from the telecom system to improve game servers. - -\end_layout - -\begin_layout Standard -In the current state game servers are developed on a per-game basis, in - many cases this seems like a bad solution. - Developers of network game need to understand network programming. - A way to change this is a generic game server which give the game developers - a server which they implement their game towards. - This approach would not only make it easier to develop network games, it - would also allow games in different programming languages to be implemented - using the same server. -\end_layout - -\begin_layout Standard -Some factors key to the development of GGS have been isolated. - Many of these come from the telecom sector. - The factors are -\emph on -scalability, fault tolerance -\emph default -and being -\emph on -generic -\emph default -. - These terms are defined below. -\end_layout - -\begin_layout Standard -Scalability (see -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Scalability" - -\end_inset - -) in computer science is a large topic and is commonly divided into sub-fields, - two of which are -\emph on -structural scalability -\emph default - and -\emph on -load scalability -\emph default - -\begin_inset CommandInset citation -LatexCommand citet -key "Bondi:2000:CSI:350391.350432" - -\end_inset - -. - These two issues are addressed in this thesis. - Structural scalability means expanding an architecture, e.g. - adding nodes to a system without requiring modification of the system. - Load scalability means using the available resources in a way which allows - handling increasing load, e.g more users, gracefully. -\end_layout - -\begin_layout Standard -Fault tolerance (see -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Fault-Tolerance" - -\end_inset - -) is used to raise the level of -\emph on -dependability -\emph default - in a system, so that the dependability is high even in presence of errors. - Dependability is defined as the statistical probability of the system functioni -ng as intended at a given point in time. - Fault tolerance is defined as the property of a system to always follow - a specification, even in the presence of errors. - The specification could take the form of error handling procedures which - activate when an error occurs. - This means that a fault tolerant, dependable system, will have a very high - probability of functioning at a given point in time, and is exactly what - is desired. - -\begin_inset CommandInset citation -LatexCommand citet -key "Gartner:1999:FFD:311531.311532" - -\end_inset - - -\end_layout - -\begin_layout Standard -A generic (see -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Generic" - -\end_inset - -) game server has to be able to run different client-server network games - regardless of the platform the clients are running on. - It runs network games of different type. - A very rough separation of games is real time games and turn based games. -\end_layout - -\begin_layout Standard -The server behaves in a way similar to an application server, but is designed - to help running games. - An application server provides processing ability and time, therefore it - is different from a file- or print-server, which only serves resources - to the clients. -\end_layout - -\begin_layout Standard -The most common type of application servers are web servers, where you run - a web application within the server. - The application server provides an environment and interfaces to the outer - world, in which applications run. - Hooks and helpers are provided to use the resources of the server. - Some examples for web application servers are the -\emph on -Glassfish -\emph default - server which allows running applications written in Java or the -\emph on -Google App Engine -\emph default - where you can run applications written in Python or some language which - runs in the -\emph on -Java Virtual Machine -\emph default -. - An example of an application server not powering web applications, but - instead regular business logic, is Oracle’s -\emph on -TUXEDO -\emph default - application server, which can be used to run applications written in COBOL, - C++ and other languages. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{SQL}}{Structured Query Language, a computer language common in querying - certain databases} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{JavaScript}}{A programming language originally developed by Netscape, - common in web programming} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{COBOL}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{C++}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Java}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{AXD301}}{Telephone switch developed by Ericsson} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Erlang}}{A concurrent programming language, often used for telecom - applications. - The main language of the GGS} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -A database server can also be seen as an application server. - Scripts, for example SQL queries or JavaScript, are sent to the server, - which runs them and returns the evaluated data to the clients. - -\end_layout - -\begin_layout Standard -One purpose of this thesis is to investigate how we can make a game server - as generic as possible. - Some important helpers are discussed, such as abstraction of the network - layer, data store and game specific features. - -\end_layout - -\begin_layout Standard -As an aid in discussing the theoretical parts of the GGS a prototype has - been developed. - The prototype does not feature all of the characteristics described in - this thesis. - A selection has been made among the features, and the most important ones - have been implemented either full or in part in the prototype. -\end_layout - -\begin_layout Standard -The choice of implementation language for the prototype of the GGS was made - with inspiration from the telecom industry. - The Erlang language was developed by the telecom company Ericsson to develop - highly available and dependable telecom switches. - One of the most reliable systems ever developed by Ericsson, the AXD301 - was developed using Erlang. - The AXD301 is also possibly has the largest code base even written in a - functional language -\begin_inset CommandInset citation -LatexCommand citep -key "Armstrong03" - -\end_inset - -. - The same language is used to develop the prototype of the GGS. - Usage of Erlang in the GGS is discussed in further detail in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:The-usage-of-erlang" - -\end_inset - -. - Chapter -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Implementation-of-a" - -\end_inset - - provides a description of the prototype developed for this thesis. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -We could go on and on about erlang.. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Purpose -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status collapsed - -\begin_layout Plain Layout -The purpose of the GGS project. - What is the purpose of creating a fault tolerant server, why is it generic, - and what good does it do to have a scalable system? In the background, - we should give the motivations behind creating this software, but here - we should outline why the software is needed. - This section should be shortened, and the bulk of the text should be moved - to theory or background. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The purpose of creating a generic and fault tolerant game server is to provide - a good framework for the development of many different types of games. - Allowing the system to scale up and down is a powerful way to maximize - the usage of physical resources. - By scaling up to new machines when load increases, and scaling down from - machines when load decreases costs and energy consumption can be optimized. -\end_layout - -\begin_layout Standard -Fault tolerance is important for the GGS to create a reliable service. - The purpose of a reliable game server is to provide a consistent service - to people using the server. - Going back to the telecom example, the purpose of creating a reliable telecom - system is to allow calls, possibly emergency calls, at any time. - Should the telecom network be unavailable at any time, emergency services - may become unavailable, furthermore the consumer image of the telecom system - degrades. -\end_layout - -\begin_layout Standard -Returning to the game industry, emergency services will not be contacted - using a game server, however an unavailable server will degrade the consumer - image of the system. - Consider an online casino company. - The online casino company's servers must be available at all times to allow - customers to play. - If the servers are unavailable, customers can not play, and the company - loses money. - In this scenario, an unavailable server can be compared to a closed real-world - casino. -\end_layout - -\begin_layout Section -Challenges in developing the prototype -\end_layout - -\begin_layout Standard -The word -\emph on -generic -\emph default - in the name of the GGS implies that the system is able to run a very broad - range of different code, for instance code wrote in different programming - languages, besides a broad range of different game types. - To support this, a virtual machine (VM) for each -\emph on -game development language -\emph default - (hereafter GDL for brevity) is used. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{GDL}}{Game Development Language, the language used to program games - in the GGS} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{VM}}{Virtual Machine} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -No hard limit has been set on which languages can be used for game development - on the GGS, but there are several factors which decide the feasibility - of a language: -\end_layout - -\begin_layout Itemize -How well it integrates with Erlang, which is used in the core the GGS system - -\end_layout - -\begin_layout Itemize -How easy it is to send messages to the virtual machine of the GDL from the - GGS -\end_layout - -\begin_layout Itemize -How easy it is to send messages from the GDL VM to the GGS -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Add more like threads, events, etc. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Internally, the GDL VM needs to interface with the GGS to make use of the - helpers and tools that the GGS provides. - Thus an internal API has to be designed for use in interacting with the - GGS. - This API is ideally completely independent of the GDL, and reusable for - any GDL. -\end_layout - -\begin_layout Standard -The communication with gaming clients has to take place over a protocol. - Ideally a standard protocol should be used, in order to shorten the learning - curve for developers, and also make the system as a whole less obscure. - A large challenge during this project is to decide whether an existing - protocol can be used, and if not, how a new protocol can be designed which - performs technically as desired, while still being familiar enough to existing - developers. -\end_layout - -\begin_layout Standard -A great deal of work is devoted to make the GGS -\emph on -reliable -\emph default -. - This includes ensuring that the system scales well, and to make sure it - is fault tolerant. - In order to facilitate scalability, we need a storage platform which is - accessible and consistent among all of the GGS, this is also investigated. -\end_layout - -\begin_layout Section -Limitations of the prototype -\end_layout - -\begin_layout Standard -The implementation of the GGS protocol, together with storage possibilities, - server capacity, and game language support imposes some limitations on - the project. - To get a functional prototype some limits must be set on the types games - that can be played on the prototype. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{UDP}}{User Datagram Protocol, a connectionless networking protocol} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{TCP}}{Transmission Control Protocol, a streaming network protocol} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The UDP protocol is not supported for communication between client and server. - The TCP protocol was chosen in favor of UDP, due to the fact that the implement -ation process using TCP was faster than if UDP would have been used. - UDP is generally considered to be faster than TCP for the transfer of game - (and other) related data, this is discussed in more depth in -\begin_inset CommandInset ref -LatexCommand vref -reference "sec:Choice-of-network" - -\end_inset - -. - In short, the decision of using TCP means that games that requires a high - speed protocol will not be supported by the GGS prototype. - Another limitation necessary to set on the system is the possibility to - have huge game worlds due to the implementation of the scaling mechanism - in the prototype. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Latency}}{A measure of delay, often measured in milliseconds} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -In real time games all players are playing together at the same time. - Latency is a huge problem in real time games, a typical round trip time - for such games are one of -\begin_inset Formula $50$ -\end_inset - - to -\begin_inset Formula $150ms$ -\end_inset - - and everything above -\begin_inset Formula $200ms$ -\end_inset - - is reported to be intolerable -\begin_inset CommandInset citation -LatexCommand citet -key "Farber:2002:NGT:566500.566508" - -\end_inset - -. - Latency sensitive games include most of the first person shooters with - multiplayer ability, for example -\emph on -Counter Strike -\emph default - or massively multiplayer online role playing games (MMORPGs), for example - -\emph on -World of Warcraft -\emph default -. -\end_layout - -\begin_layout Standard -In turn based games each player has to wait for their turn. - Latency is not a problem since the gameplay does not require fast interactions - among the players, long round trip times will not be noticed. - Examples of turn based games include board and card games, as well as multiplay -er games like -\emph on -Jeopardy -\emph default -. - Both game types have varying difficulties and needs when it comes to implementi -ng them, a Generic Game Server should address all of them and help the developer - to accomplish his goal. -\end_layout - -\begin_layout Standard -Due to the limited capability of threading in many GDL VM:s, the GGS prototype - will not support MMORPG:s. -\end_layout - -\begin_layout Standard -The implementation of the GGS described in this thesis is only a small prototype - and tests will be performed on simple games like pong or chess, thus there - are no need to implement more advanced features in the system. - Note that these limitations only apply for the prototype of the project, - and that further developments to the GGS could be to implement these features. -\end_layout - -\begin_layout Section -Method -\end_layout - -\begin_layout Standard -A prototype was developed early on in the project to carry out experiments. - Using this prototype, the system was divided into modules. - A demand specification was created, using this specification, the modules - were easily identifiable. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Module}}{A part of a larger system} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The first prototype of the GGS consisted of simple modules, however, due - to the separation of concerns among the modules, they were easily independently - modified and improved. - Once the basic structure of the GGS had been established, the first prototype - was removed, remaining was the structure of the modules and the internal - flow of the application. - This could be seen as an iterative workflow, with the first prototype being - the first iteration. - The second iteration later became the final result of the GGS. -\end_layout - -\begin_layout Standard -The layout of the GGS is both layered and modular. - The first layer handles the most primitive data and produces a higher level - representation of the data, passing it along to different modules of the - GGS. - The modular structure of the GGS plays an important role in making the - system fault tolerant. - The approach to fault tolerance is by replication, and restarting the faulting - modules with the last known good data. -\end_layout - -\begin_layout Standard -An informal specification and list of requirements of the system was outlined - early on in the project. - Usability goals for developers were set. - During the project several demo applications were constructed, by constructing - these applications, the usability goals were enforced. -\end_layout - -\begin_layout Chapter -Theory behind the GGS -\begin_inset CommandInset label -LatexCommand label -name "cha:Theory" - -\end_inset - - -\end_layout - -\begin_layout Standard -In this chapter, the theory behind the techniques used in the GGS are discussed. - Performance issues and the measuring of performance is discussed. - Benchmarking techniques are discussed. - The options when choosing network protocols are given, along with a discussion - of each alternative. - Finally, an overview of scalability, fault tolerance and availability are - presented. -\end_layout - -\begin_layout Section -Design of the GGS system -\begin_inset CommandInset label -LatexCommand label -name "sec:Design-of-the" - -\end_inset - - -\end_layout - -\begin_layout Standard -The GGS is modeled after a real world system performing much of the same - duties as GGS. - This is common practice -\begin_inset CommandInset citation -LatexCommand citep -key "armstrong2011" - -\end_inset - - in the computer software world, to understand complex problems more easily. - While there may not always be a real world example of a system performing - the exact duties of the system being modeled in the computer, it is often - easier to create and analyze requirements for real world systems and processes - than systems existing solely in a computer. - The requirements and limitations imposed on the real-world system can, - using the proper tools, be transferred in to the software. -\end_layout - -\begin_layout Standard -The real world system chosen for the GGS is a -\begin_inset Quotes eld -\end_inset - -Chess club -\begin_inset Quotes erd -\end_inset - - - a building where chess players can meet and play chess. - Since a real-world scenario is readily available, and to such a large extent - resembles the computer software required for the GGS, the next step in - developing the GGS system is to duplicate this real world scenario in a - software setting. -\end_layout - -\begin_layout Standard -Some requirements, limitations and additions were made to the chess club - system, so that the system would more easily and efficiently be replicated - in a software setting. -\end_layout - -\begin_layout Standard -In the text below, two examples will be presented. - On example is that of a real-world chess club, in which players meet to - play chess against each other, the other example is the GGS, and how it - corresponds to this chess club. - -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/theory_layout.eps - scale 40 - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "fig:theory-layout" - -\end_inset - -The layout of a physical -\begin_inset Quotes eld -\end_inset - -Chess club -\begin_inset Quotes erd -\end_inset - - with two players (P) sitting by each chess table (Table), a coordinator - keeps track of all moves and players in the building. - A player has to pass by the entrance to enter or exit the building. - The building is represented by the outermost box. -\end_layout - -\end_inset - - -\end_layout - -\end_inset - -In figure -\begin_inset CommandInset ref -LatexCommand vref -reference "fig:theory-layout" - -\end_inset - - a graphical representation for the chess club is presented. - The club is seen from above. - The outermost box represents the building. - In the GGS setting, the building would represent one instance of GGS. - Several buildings linked together would represent a cluster of GGS instances. - In order for a player (the P symbol in the graphic) to enter the theoretical - chess club, the player must pass by the entrance. - By having each player pass by the entrance, a tally -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Does this mean what I think it does? -\begin_inset Quotes eld -\end_inset - -Räkning -\begin_inset Quotes erd -\end_inset - - ? -\end_layout - -\end_inset - - can be kept, ensuring that there are not too many players within the building. - In the GGS setting, too many players entering would mean too many connections - have been accepted by the GGS system, and that the structure of the system - thus must be modified, adding additional servers. -\end_layout - -\begin_layout Standard -Once a player has been allowed in to the chess club the player is greeted - by the host of the chess club, in the GGS setting represented by the -\emph on -Coordinator -\emph default -, and is seated by a table. - The coordinator keeps track of all the players in the building, and all - moved made by the players. - The information available to the coordinator means that cheating can be - monitored and book keeping can be performed by this entity. -\end_layout - -\begin_layout Standard -Moves by players are made using the tables present in the chess club. - Every game is isolated to a table, just as expected. - This means that communication during a game only has to pass by the players - of that particular game, and the coordinator, making sure that no cheating - takes place. -\end_layout - -\begin_layout Standard -This isolation of the games play an important part in many properties of - the GGS, the isolation means that games can for example be transferred - among different chess clubs, furthermore, if cheating takes place, corruption - can only occur in the particular table where it was found, and can not - spread. -\end_layout - -\begin_layout Standard -Moving chess players from one location to another is one alteration made - to the real world chess club system to make the system more appropriate - for a software setting. - Allowing games to be transferred is not a property usually desired in a - real world chess club, where transferring players would mean moving the - players from one building to another. - In the software setting, moving players means moving the game processes - from one system to another, perhaps to balance the system load. - This transfer of players can occur transparently, without notifying the - players. -\end_layout - -\begin_layout Standard -The simplified life cycle of a game in GGS can be viewed using algorithm - -\begin_inset CommandInset ref -LatexCommand vref -reference "alg:game-lifecycle" - -\end_inset - -. - To make this life cycle as efficient and useful as possible, the scalability, - fault tolerant and generic traits are added to the GGS. - These are not shown in the algorithm, as these traits are tools in making - the algorithm behaves as efficient as possible, and are not the main focus - when studying the life cycle of a game. -\end_layout - -\begin_layout Standard -The limits imposed in -\begin_inset CommandInset ref -LatexCommand vref -reference "alg:game-lifecycle" - -\end_inset - - are arbitrary for this example, there are no limits in the GGS on the number - of players connecting, for example. -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{algorithmic}[1] -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -newcommand{ -\backslash -INDSTATE}[1][1]{ -\backslash -STATE -\backslash -hspace{#1 -\backslash -algorithmicindent}} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -while -\series default - -\begin_inset Formula $players<2$ -\end_inset - -: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - -\series bold -if -\series default - a player connects, call -\emph on -connected -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -while -\series default -the game commences: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -call the function -\emph on -game -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -when -\series default - the game has stopped -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -call the function -\emph on -endGame -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -function -\series default -connected: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -assign the new player an id -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -alert the coordinator of the new player -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - -\series bold -if -\series default - a free table does not exist: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE[2] -\end_layout - -\end_inset - -the coordinator creates a new table -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -the coordinator places the player by the table, and begins watching the - player -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -function -\series default - game -\series bold -: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - perform game-specific functions. - In chess, the rules of chess are placed here -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -function -\series default -endGame: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -alert the coordinator, unregistering the players -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -disconnect the players from the system, freeing system resources -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{algorithmic} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:game-lifecycle" - -\end_inset - -A very simple example of the flow through the GGS system when a game played. -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Performance -\end_layout - -\begin_layout Standard -There are many ways in which performance could be measured. - For the clients, time and response times are useful measurements in time - critical settings. - In non-time critical settings, the reliability of message delivery may - be an even more important factor than speed. -\end_layout - -\begin_layout Standard -In a first person shooter game, the speed of delivery of messages is essential. - Failure to deliver messages in time results in choppy gameplay for the - players. - In strategy games, the reliability of delivery may be more important than - the speed, since the game is not perceived as choppy even if the messages - are delayed. -\end_layout - -\begin_layout Standard -For someone operating a GGS, it is perhaps more interesting to measure the - system load, memory consumption, energy consumption and network saturation. - These topics are discussed in theory in this section. - The practical results for the prototype is discussed in chapter -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Implementation-of-a" - -\end_inset - -. -\end_layout - -\begin_layout Subsection -Performance measurements -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Tue apr 26, 9:15. - Continue from here on. - Discuss which results we may expect in a fully fledged GGS system. - What impedes the speeds, what raises the CPU load (and therefore the temperatur -es & power consumption). - What factors are there in the network saturation problem? -\end_layout - -\begin_layout Plain Layout -Which games are affected by what, and what does this mean for the number - of players a GGS can handle? -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -How many players can we have on a server? Performance differences between - games? e.g can one game have thousands players on a server and another only - have hundreds? Questions -\end_layout - -\begin_layout Standard -In the current state game servers is coded for each game that needs it, - in many cases this seems like a bad solution. - Developers that want to make a network game need to understand network - programming. - A way to change this is a generic game server which give the game developers - a server which they implement their game towards. - This approach would not only make it easier to develop network games, it - would also allow games in different programming languages to be implemented - using the same server. - to be discussed here. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Create a game with several thousand players, see how our server scales, - how can we improve the performance? Sharding isn’t very nice.. - alternatives? Improve the speed of sharding? -\end_layout - -\begin_layout Itemize -See how the server scales -\end_layout - -\begin_deeper -\begin_layout Itemize -When adding many clients -\end_layout - -\begin_deeper -\begin_layout Itemize -Measure in -\begin_inset Formula $ms$ -\end_inset - - (ping to clients) -\end_layout - -\begin_layout Itemize -measure in system load -\end_layout - -\begin_layout Itemize -Measure in loss of messages -\end_layout - -\begin_layout Itemize -Measure in # of timeouts? (if any??) -\end_layout - -\begin_layout Itemize -Measure in time-to-crash -\end_layout - -\end_deeper -\begin_layout Itemize -When adding new machines to the pool -\end_layout - -\begin_deeper -\begin_layout Itemize -% increase of performance per machine -\end_layout - -\end_deeper -\begin_layout Itemize -Single-core CPU vs multi-core CPU -\end_layout - -\begin_deeper -\begin_layout Itemize -It's very important to scale well on multi-core systems, since this is where - the industry is going. - Multicore is the future. -\end_layout - -\end_deeper -\end_deeper -\begin_layout Plain Layout -Find reference on how to benchmark distributed, multiprocess systems -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Choice of network protocol -\begin_inset CommandInset label -LatexCommand label -name "sec:Choice-of-network" - -\end_inset - - -\end_layout - -\begin_layout Standard -There are two main ways in which computer communication over the Internet - usually takes place; TCP, UDP are known network layer protocols and HTTP - is the most prominent application layer protocol. - The transport layer protocols, are commonly used to transport application - layer protocols, such as HTTP. - TCP and UDP can not be used on their own, without an application layer - protocol on top. - Application layer protocols such as HTTP on the other hand needs a transport - layer protocol in order to work. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{HTTP}}{Hyper Text Transport Protocol, a network protocol commonly - used to deliver web pages} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -HTTP -\end_layout - -\begin_layout Standard -Since HTTP is so widely used on the Internet today in web servers, it is - available on most Internet connected devices. - This means that if HTTP is used in the GGS, firewalls will not pose problems, - which is a great benefit. - However, due to the intended usage of HTTP in web servers, the protocol - was designed to be stateless and client-initiated. - In order to maintain a state during a game session using HTTP, some sort - of token would have to be passed between client and server at all times, - much like how a web server works. - These facts combined makes HTTP unsuitable for our purposes, since the - GGS requires a state to be maintained throughout a session, and also needs - to push data from the server to clients without the clients requesting - data. - It should also be mentioned that HTTP uses the TCP protocol for transport, - and what is said about TCP also applies to HTTP. - -\end_layout - -\begin_layout Subsection -UDP -\end_layout - -\begin_layout Standard -Many online games use UDP as the carrier for their application layer protocol. - UDP moves data across a network very quickly, however it does not ensure - that the data transferred arrives in consistent manner. - Data sent via UDP may be repeated, lost or out of order. - To ensure the data transferred is in good shape, some sort of error checking - mechanisms must be implemented. - UDP is a good choice for applications where it is more important that data - arrives in a timely manner than that all data arrives undamaged, it is - thus very suitable for media streaming, for example. - In the GGS reliability of transfer was chosen before the speed of the transfer, - ruling out UDP as the transport later protocol. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Perhaps we should only say that we chose TCP just for our GGS prototype - and why. - If we leave it like that it seems that we think it is not suitable. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -TCP -\end_layout - -\begin_layout Standard -For reliable transfers, TCP is often used on the Internet. - Built in to the protocol are the error checking and correction mechanisms - missing in UDP. - This ensures the consistency of data, but also makes the transfer slower - than if UDP had been used. - In the GGS, data consistency is more important than transfer speeds, and - thus TCP is a better alternative than UDP. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Same here it is simply not true for a generic server to chose one or the - other. - We should rephrase it so it is clear that we only state it about the GGS - prototype. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Generic -\begin_inset CommandInset label -LatexCommand label -name "sec:Generic" - -\end_inset - - -\end_layout - -\begin_layout Standard -The GGS is a game server. - It was made with a desire to be suitable for any kind of game. - Any game with a client-server behavior should be perfectly suited for GGS. - A game should not only be able to vary in terms of genre, graphics, gameplay - etc, but also in the way the game is implemented. - Such as different programming languages. - The GGS should be OS independent and run on Windows, OSX and Linux. - The GGS can be run as a listen server on the players computer and host - games locally. - It could also be a dedicated server running on independent hardware. - It is meant to run any game in any environment in any way desired, therefor - being as generic as possible. -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Bad name of the chapter, but here we should give the theory of how the server - is generic -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Fault Tolerance -\begin_inset CommandInset label -LatexCommand label -name "sec:Fault-Tolerance" - -\end_inset - - -\end_layout - -\begin_layout Standard -Fault tolerance is an important factor in all servers, a server that is - fault tolerant should be able to follow a given specification when parts - of the system failures. - This means that fault tolerance is different in each system depending on - what specification they have. - A system could be fault tolerant in different aspects, one is where the - system is guaranteed to be available but not safe and it could also be - reversed, that the system is safe but not guaranteed to be available. - Depending on the system one property may be more important(some example - here). - A system could also have non existent fault tolerance or it could be both - safe and guaranteed to be available. - It should be noted that it is not possible to achieve complete fault tolerance, - a system will always have a certain risk of failure. - With this in mind the goal is to make the GGS prototype as fault tolerant - as possible. -\end_layout - -\begin_layout Standard -In order to make the GGS prototype fault tolerant the programming language - Erlang has been used. - Erlang will not guarantee a fault tolerant system but it has features that - support and encourage the development of fault tolerant systems. - In the GGS it is important that the system overall is fault tolerant. - Crashes of the whole system should be avoided as this would make the system - unusable for a time. - By using supervisor structures it is possible to crash and restart small - parts of the system, this is convenient as fault can be handled within - small modules thus never forcing a crash of the system. -\end_layout - -\begin_layout Standard -The need for fault tolerance in game servers is not as obvious as it may - be for other type of servers. - In general all servers strive to be fault tolerant as fault tolerance means - more uptime and a safer system. - This applies to game servers as well, in brief good fault tolerance is - a way of satisfying customers. - In general, game servers differ from many other fault tolerant systems - in that high-availability is more important than the safety of the system. - For example a simple calculation error will not be critical for a game - server but it may be in a life-critical system and then it is better that - the system crashes than works with the faulty data. - There are cases where safety may be critical in game servers, one example - is in games where in-game money exist. -\end_layout - -\begin_layout Subsubsection -Performance penalties -\end_layout - -\begin_layout Section -Availability -\begin_inset CommandInset label -LatexCommand label -name "sec:Availability" - -\end_inset - - -\end_layout - -\begin_layout Standard -One important factor of any server is the availability. - A server to which you are unable to connect to is an useless server. - Other then within telecommunication, their uptime is of about 99,9999999%, - the game developer community has not approached this problem very genuinely - yet so there is much room for improvement. -\end_layout - -\begin_layout Standard -There are several good papers on how to migrate whole virtual machines among - nodes to replicate them -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Add more information about that -\end_layout - -\end_inset - - but for the GGS a different approach has been chosen. - Instead of just duplicating a virtual machine, the programming language - Erlang has been used which offers several features to increase the availability. - Some of them are -\emph on -hot code replacement -\emph default -, where code can be updated while the application is running and without - the need to restart it, the -\emph on -supervisor structure -\emph default - provided by -\emph on -OTP -\emph default - and the inter node and process communication via -\emph on -messages -\emph default - instead of shared memory. - We will discuss each of them later on. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Supervisor}}{A process monitoring and hadning crashes in other processes} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Scalability -\begin_inset CommandInset label -LatexCommand label -name "sec:Scalability" - -\end_inset - - -\end_layout - -\begin_layout Standard -Each instance of the GGS contains several tables. - Each table is an isolated instance of a game, for example a chess game - or a poker game. - The way that the GGS scales is to distribute these tables on different - servers. - In many games it is not necessary for a player to move among tables during - games. - This is for example not a common occurrence in chess, where it would be - represented as a player standing up from her current table and sitting - down at a new table, all within the same game session. - Therefore, the main focus of the GGS is not to move players among tables, - but to keep a player in a table, and to start new tables instead. - When a server has reached a certain number of players the performance will - start to decrease. - To avoid this the GGS will start new tables on another server, using this - technique the players will be close to evenly distributed among the servers. - It is important to investigate and find out how many players that are optimal - for each server. - This approach makes it possible to use all resources with moderate load, - instead of having some resources with heavy load and some with almost no - load. -\end_layout - -\begin_layout Standard -As mentioned in the purpose section there are two different types of scalability -, structural scalability and load scalability. - To make the GGS scalable both types of scalability are needed. - Structural scalability means in our case that it should be possible to - add more servers to an existing cluster of servers. - By adding more servers the limits of how many users a system can have is - increased. - Load scalability in contrast to structural scalability is not about how - to increase the actual limits of the system. - Instead it means how good the system handles increased load. - The GGS should be able to scale well in both categories. -\end_layout - -\begin_layout Subsection -Load balancing -\end_layout - -\begin_layout Standard -The need for load balancing varies among different kind of systems. - Small systems that only use one or a couple of servers can cope with a - simple implementation of it, while in large systems it is critical to have - extensive and well working load balancing. - The need also depends on what kind of server structure that the system - works on. - A static structure where the number of servers are predefined or a dynamic - structure where the number varies. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Amazon EC2}}{A cloud computation service} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Load balancing and scaling is difficult in different scenarios. - When running in a separate server park, there are a set number of servers - available, this means that an even distribution on all servers is preferable. - When running the GGS in a cloud, such as Amazon EC2, it is possible to - add an almost infinite number of servers as execution goes on. - In this cloud setting, it may be more important to evenly distribute load - on newly added servers. -\end_layout - -\begin_layout Standard -Two methods of balancing load (increasing structure): -\end_layout - -\begin_layout Itemize -Fill up the capacity of one server completely, and then move over to the - next server -\end_layout - -\begin_layout Itemize -Evenly distribute all clients to all servers from the beginning, when load - becomes too high on all of them, then comes a new problem: -\end_layout - -\begin_deeper -\begin_layout Itemize -How do we distribute load on these new servers? -\end_layout - -\end_deeper -\begin_layout Standard -Load balancing is a key component to achieve scalability in network systems. - The GGS is a good example of a system that needs to be scalable, to attain - this load balancing is necessary. - Optimization of the load balancing for a system is an important task to - provide a stable and fast load balancer. - There are certain persistence problems that can occur with load balancing, - if a player moves from a server to another data loss may occur. - This is an important aspect to consider when the load balancer is designed - and implemented. -\end_layout - -\begin_layout Standard -Load balancing can often be implemented using dedicated software, this means - that in many applications load balancing may not be implemented because - it already exist functional solutions. - This depends on what specific needs the system have and a minor goal of - the project is to analyze whether the GGS project can use existing load - balancing tools or if it is necessary to implement load balancing in the - project. -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Because P2P game architectures are a constant goal for cheaters and because - “Cheating is a major concern in network games as it degrades the experience - of the majority of players who are honest” and preventing cheating in P2P - game architectures is very difficult game developers try to use Client - - Server architectures which have a natural problem to scale. - In this paper we want to show some strategies to achieve scalability. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -UUID -\begin_inset CommandInset label -LatexCommand label -name "sub:UUID" - -\end_inset - - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{UUID}}{Universally Unique Identifier} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{algorithmic}[1] -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -newcommand{ -\backslash -INDSTATE}[1][1]{ -\backslash -STATE -\backslash -hspace{#1 -\backslash -algorithmicindent}} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - -global variable -\begin_inset Formula $state:=0$ -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -function -\series default -unique -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - -\begin_inset Formula $state:=state+1$ -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - -\series bold -return -\begin_inset Formula $state$ -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{algorithmic} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:A-simple-generator" - -\end_inset - -A simple (insufficient) generator for identifiers -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Inside the GGS, everything has a unique identifier. - There are identifiers for players, tables and other resources. - When players communicate amongst each other, or communicate with tables, - they need to be able to uniquely identify all of these resources. - Within one machine, this is mostly not a problem. - A simple system with a counter can be imagined, where each request for - a new ID increments the previous identifier and returns the new identifier - based off the old one, see algorithm -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-simple-generator" - -\end_inset - -. - This solution poses problems when dealing with concurrent and distributed - systems. - In concurrent systems, the simple solution in algorithm -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-simple-generator" - -\end_inset - - may yield non-unique identifiers due to the lack of mutual exclusion. -\end_layout - -\begin_layout Standard -The obvious solution to this problem is to ensure mutual exclusion by using - some sort of lock, which may work well in many concurrent systems. - In a distributed system, this lock, along with the state, would have to - be distributed. - If the lock is not distributed, no guarantee can be made that two nodes - in the distributed system do not generate the same number. - A different approach is to give each node the ability to generate Universally - Unique Identifiers (UUID), where the state of one machine does not interfere - with the state of another. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{MAC Address}}{Media Access Control address, used to identify network - cards} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{SHA-1}}{Cryptigraphic hash function, designed by the National Security - Agency (NSA)} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -According to -\begin_inset CommandInset citation -LatexCommand citet -key "Leach98uuidsand" - -\end_inset - -, -\begin_inset Quotes eld -\end_inset - -A UUID is 128 bits long, and if generated according to the one of the mechanisms - in this document, is either guaranteed to be different from all other UUIDs/GUI -Ds generated until 3400 A.D. - or extremely likely to be different -\begin_inset Quotes erd -\end_inset - -. - This is accomplished by gathering several different sources of information, - such as: time, MAC addresses of network cards, and operating system data, - such as percentage of memory in use, mouse cursor position and process - ID:s. - The gathered data is then -\emph on -hashed -\emph default - -\begin_inset space ~ -\end_inset - -using an algorithm such as SHA-1. -\end_layout - -\begin_layout Standard -When using system wide unique identifiers, such as the ones generated by - algorithm -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-simple-generator" - -\end_inset - - with mutual exclusion, it is not possible to have identifier collisions - when recovering from network splits between the GGS clusters. - Consider figure -\begin_inset CommandInset ref -LatexCommand ref -reference "fig:network-split" - -\end_inset - -, where -\emph on -Site A -\emph default - is separated from -\emph on -Site B -\emph default - by a faulty network (illustrated by the cloud and lightening bolt). - When -\emph on - -\emph default -the decoupled node -\emph on - -\emph default -and -\emph on - -\emph default -the rest of the network later re-establish communication, they may have - generated the same ID:s if using algorithm -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-simple-generator" - -\end_inset - -, even when mutual system-wide exclusion is implemented. - This is exactly the problem UUID:s solve. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Network split}}{Separation of two networks, occurs when two networks - can not communicate, commonly because of a hardware or software failiure} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/netsplit2.eps - scale 40 - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Add clients on each side, and replace the cloud with pole-landlines being - cut by a pair of scissors -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "fig:network-split" - -\end_inset - -An example of a network split -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Security -\end_layout - -\begin_layout Standard -We only support languages running in a sandboxed environment. - Each game session is started in its own sandbox. - The sandboxing isolates the games in such a way that they can not interfere - with each other. - If sandboxing was not in place, one game could potentially modify the contents - of a different game. - A similar approach is taken with the persistent storage we provide. - In the storage each game has its own namespace, much like a table in a - relational database. - A game is not allowed to venture outside this namespace, and can because - this not modify the persistent data of other games. - of this not modify the persistent data of other games. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Sandbox}}{A protected environment in which computer software can - be run safely} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Encryption -\end_layout - -\begin_layout Section -Game Development Language in a Virtual Machine -\begin_inset CommandInset label -LatexCommand label -name "sec:Game-Development-Language" - -\end_inset - - -\end_layout - -\begin_layout Standard -There is only a very limited number of game developers who would like to - write their games in Erlang, therefore we had to come up with something - to resolve this problem. - The main idea was to offer a replaceable module which would introduce a - interface to different virtual machines which would run the game code. - This way a game developer can write the game in his favorite language while - the server part still is written in Erlang and can benefit from all of - its advantages. -\end_layout - -\begin_layout Subsection -JavaScript -\end_layout - -\begin_layout Standard -JavaScript has gained a lot of popularity lately, it is used in large projects - such as -\emph on -Riak -\emph default - -\begin_inset Foot -status open - -\begin_layout Plain Layout -\begin_inset Flex URL -status collapsed - -\begin_layout Plain Layout - -http://wiki.basho.com/An-Introduction-to-Riak.html -\end_layout - -\end_inset - - -\end_layout - -\end_inset - -, -\emph on -CouchDB -\emph default - -\begin_inset Foot -status open - -\begin_layout Plain Layout -\begin_inset Flex URL -status collapsed - -\begin_layout Plain Layout - -http://couchdb.apache.org -\end_layout - -\end_inset - - -\end_layout - -\end_inset - -. - On the popular social coding site -\emph on -GitHub.com -\emph default -, 18% -\begin_inset Foot -status open - -\begin_layout Plain Layout -during the writing of the thesis the percentage went up to 19% -\begin_inset Flex URL -status collapsed - -\begin_layout Plain Layout - -https://github.com/languages/ -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - of all code is written in JavaScript. - The popularity of JavaScript in the programming community, in combination - with the availability of several different JavaScript virtual machines - was an important influence in choosing JavaScript as the main control language - for our GGS prototype. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{CouchDB}}{Database server} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Riak}}{Database server} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{GitHub.com}}{Social coding website} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{ActionScript}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Lua}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{.NET}}{Software platform} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Other languages -\end_layout - -\begin_layout Standard -Other languages like -\emph on -lua -\emph default -, -\emph on -ActionScript -\emph default - are suitable as well because there is a virtual machine for each of them - which can be -\begin_inset Quotes eld -\end_inset - -plugged in -\begin_inset Quotes erd -\end_inset - - into our GDL VM interface. - With help of the -\emph on -Java Virtual Machine -\emph default - or the -\emph on -.NET -\emph default -environment it is even possible to run nearly every available programming - language in a sandbox as a GDL. -\end_layout - -\begin_layout Standard -Due lack of time we have decided to use just the Erlang <-> JavaScript bridge - with our interface. -\end_layout - -\begin_layout Section -Testing -\end_layout - -\begin_layout Standard -There are several ways in which the GGS can be tested. - The most important aspect has been deemed to be the experience players - have when using the GGS. - In order to test the user experience of the GGS, a realistic usage scenario - has to be set up. -\end_layout - -\begin_layout Standard -The GGS is intended to be used for powering games which have many concurrent - players. - The players need not participate in the same instance of the game, games - such as chess are prime candidates for the GGS. -\end_layout - -\begin_layout Standard -When developing the GGS, two main categories of games exhibiting different - performance demands were identified; real-time games and turn-based games. - The real-time games were deemed more demanding than the turn based games. - Tests were carried out using a real time game, since this is the more demanding - type of games. -\end_layout - -\begin_layout Standard -The real time game chosen for testing the GGS is -\emph on -Pong -\emph default -, a game in which two players play a game involving a all and two paddles. - The goal for each player is to shoot beside the other players paddle while - not allowing the ball to pass by her own paddle. - The game requires real time updates and is quite demanding when played - in several instances concurrently. -\end_layout - -\begin_layout Standard -There has been some work on the area of testing game servers, see -\begin_inset CommandInset citation -LatexCommand citet -key "Lidholt02designand" - -\end_inset - -, who describes a test bench using -\emph on -bots -\emph default - for testing his generic hazard-gaming server. - Lidholt describes how his server, capable of running several different - casino games is tested using artificial players, so called bots. - Performance is measured in -\begin_inset Quotes eld -\end_inset - -number of clients -\begin_inset Quotes erd -\end_inset - - able to connect to the server, and the system load. -\end_layout - -\begin_layout Standard -Similar tests were performed on the GGS, and the results of these tests - are visible in chapter -\begin_inset CommandInset ref -LatexCommand ref -reference "chap:Results-and-discussion" - -\end_inset - -. - The tests were initially performed by starting an operating system process - for each player. - Due to lack of hardware, not enough player processes could be started in - this way. - The bots were re-written in Erlang, and due to Erlang's light weigh threads, - enough processes could be created to successfully test the server. -\end_layout - -\begin_layout Chapter -Implementation of a prototype -\begin_inset CommandInset label -LatexCommand label -name "cha:Implementation-of-a" - -\end_inset - - -\end_layout - -\begin_layout Standard -This chapter contains the realization of much of the principles and techniques - described in chapter -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Theory" - -\end_inset - -. - Here the problems and their solutions are discussed in greater detail, - and at times the text becomes more specific to GGS. -\end_layout - -\begin_layout Standard -Much of what is discussed in this chapter has been implemented in the Erlang - GGS prototype. - Specific solutions such as -\emph on -supervisor structures -\emph default -and distribution of erlang nodes on physical nodes. - The different means of communications within the GGS and outside the GGS - with third parties are also discussed here. -\end_layout - -\begin_layout Section -Overview of the prototype -\end_layout - -\begin_layout Standard -The prototype of the GGS was developed using the Erlang language. - The functional and concurrent style of Erlang facilitates development of - software based on a real-world model -\begin_inset CommandInset citation -LatexCommand citep -key "armstrong2011" - -\end_inset - -. - In Erlang, most things are processes. - The software running the Erlang code is known as the Erlang machine, or - an Erlang node. - Each Erlang node is capable of running several -\emph on -threads -\emph default -(also known as -\emph on -Light Weight Processes; LWP -\emph default -) -\emph on -, -\emph default -much like the threads in an operating system. - Threads in a Linux system, for example, are treated much like operating - system processes in different systems. - Due to the size of data structures related to each process, swapping one - process for another (known as -\emph on -context switching -\emph default -) is an expensive task in many systems -\begin_inset CommandInset citation -LatexCommand citep -after "pg 80" -key "McKusick:2004:DIF:1014910" - -\end_inset - -. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{LWP}}{Light Weight Process} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Context switch}}{The act of switching from one context, commonly - a process, to another. - Used by operating systems to achieve multi tasking} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The cost of swapping operating system processes becomes a problem when many - processes are involved. - If the GGS system had been developed using regular operating system processes, - it would have had to be designed in a way to minimize the number of processes. - Using Erlang, which is capable of running very many processes, several - times more than an operating system can, the mapping between the real world - system (described in -\begin_inset CommandInset ref -LatexCommand vref -reference "sec:Design-of-the" - -\end_inset - -) becomes clearer. -\end_layout - -\begin_layout Standard -Erlang allows the GGS to create several process for each player connecting, - these processes can handle a multitude of different tasks, parsing data - for example. - Since each task is handled by a different process, the tasks are clearly - separated and the failure of one is easily recovered without affecting - the others. -\end_layout - -\begin_layout Standard -In addition to creating (or -\emph on -spawning -\emph default -) processes specifically to handle new players connecting, the GGS has more - permanent processes running at all times. - The constantly running processes in the GGS system are called -\emph on -modules -\emph default -. - An example of a module in the GGS is the -\emph on -dispatcher module -\emph default -, which handles the initial connection made by a client, passing the connection - along further in to the system. -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/Chess_no_text.eps - width 100text% - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "fig:The-layout-of" - -\end_inset - -The layout of the GGS. - The circles marked with 'C' topmost in the picture represent clients. - The cloud marked 'network' pictured directly below the clients can be any - network, for example the Internet. - The barell figure marked 'backup' is a process being fed backup data from - the coordinator. - The barell marked 'State' contains the state of a table, and this is fed - into the box marked 'Mnesia' which is database. - Finally the figure shaped as a shield marked 'GameVM' contains the actual - game process. -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -In figure -\begin_inset CommandInset ref -LatexCommand vref -reference "fig:The-layout-of" - -\end_inset - - the entire GGS system is represented graphically. - The circles marked with 'C' topmost in the picture represent game clients. - These circles represent processes running on gamers computers, and not - on the GGS machine. - If a game of chess is to be played on the server, the clients on the gamers - machines will be chess game clients. - Clients connect through a network, pictured as a cloud, to the dispatcher - process in the GGS. - The dispatcher process and all other modules are discussed in -\begin_inset CommandInset ref -LatexCommand vref -reference "sec:The-modular-structure" - -\end_inset - -. - For each connection, a new player process is spawned, which immediately - after spawning is integrated in to the GGS by the coordinator process. -\end_layout - -\begin_layout Section -The usage of Erlang in the GGS -\begin_inset CommandInset label -LatexCommand label -name "sec:The-usage-of-erlang" - -\end_inset - - -\end_layout - -\begin_layout Standard -Erlang was designed by Ericsson, beginning in 1986, for the purpose of creating - concurrent applications and improving telecom software. - Features essential for the telecom industry to achieve high availability - in telecom switches were added to the language. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Mutex}}{A construct for achieving mutial exclusion, used to avoid - simultaneous access to shared resources in computer systems} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Erlang uses message passing in favor of shared memory, mutexes and locks, - something which at the time was controversial among fellow developers -\begin_inset CommandInset citation -LatexCommand citet -key "Armstrong:2010:ERL:1810891.1810910" - -\end_inset - -. - The reason for using message passing, according to Armstrong, was that - applications should operate correctly before optimizations are done, where - efficient internal communication within the Erlang machine was considered - a later optimization. -\end_layout - -\begin_layout Standard -In using message passing in favor of the methods commonly used at the time, - the issues commonly associated with shared memory and locking were avoided. - In Erlang, everything is a process, and everything operates in its own - memory space. - Memory can not be shared among processes, which prohibits a process from - corrupting the memory of a different process. -\end_layout - -\begin_layout Standard -Messages are sent between the processes in an asynchronous manner, and each - process has a mailbox in which these messages can be retrieved. -\end_layout - -\begin_layout Standard -Processes in Erlang are also called -\emph on -Light Weight Processes. - -\emph default -The Erlang processes are very cheaply created. - Processes exist within an Erlang machine, or Erlang node. - The Erlang machine has its own scheduler and does not rely on the operating - system's scheduler, this is a main reason of Erlang's capability of running - many concurrent processes -\begin_inset CommandInset citation -LatexCommand citet -key "Armstrong03" - -\end_inset - -. -\end_layout - -\begin_layout Standard -The strong isolation of Erlang processes make them ideal for multi-core - and distributed systems. - Distribution of software is included as a fundamental part in the Erlang - language. - The 'physical' location of a process, e.g. - which computer the process runs on, is not important when communicating - with the process. - Processes can communicate regardless of whether they run on the same system - of not, transparently. -\end_layout - -\begin_layout Standard -The distributed nature of Erlang is something the GGS makes use of when - scaling across several computers in order to achieve higher performance. - The distribution is also important in creating redundancy. - Erlang promotes a non-defensive programming style in which processes are - allowed to crash and be restarted in favor of having the processes recover - from errors. - The distributed nature of Erlang means supervisor processes (discussed - in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:Supervisor-structure" - -\end_inset - -) can reside on remote systems, thereby increasing the reliability of the - system as a whole. -\end_layout - -\begin_layout Standard -A very important feature of Erlang, used in the GGS, is the ability to interface - with external hardware and software. - Erlang allows communication with external resources through -\emph on -ports -\emph default - and -\emph on -NIF -\emph default -:s (Native implemented functions) -\emph on -. - -\emph default - Through ports communication can take place much in the same way communication - is performed over sockets. - NIF:s are called like any other functions without any difference to the - caller but are implemented in C. -\end_layout - -\begin_layout Standard -The GGS uses Erlang ports for generating UUID:s -\begin_inset Foot -status collapsed - -\begin_layout Plain Layout -UUID:s are discussed in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:UUID" - -\end_inset - - -\end_layout - -\end_inset - - and NIF:s for interfacing with the virtual machines of games -\begin_inset Foot -status collapsed - -\begin_layout Plain Layout -Virtual machines of games are discussed in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Game-Development-Language" - -\end_inset - - -\end_layout - -\end_inset - -. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{OTP}}{Open Telecom Platform, a software suite for Erlang} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Behaviour}}{A design pattern in OTP} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Development of the GGS would have been hard if not impossible had it not - been for the -\emph on -OTP -\emph default - supplied with the standard Erlang distribution. - The OTP (Open Telecom Platform) is a set of standard libraries and design - patterns, called -\emph on -behaviors -\emph default -, which are used when developing Erlang systems. -\end_layout - -\begin_layout Standard -The GGS makes heavy use of the behaviors supplied in the OTP. - The behaviors impose a programming style suitable for distributed and concurren -t applications, perfectly suitable for the GGS. - In particular, the GGS uses the following behaviors: -\end_layout - -\begin_layout Itemize -The -\emph on -supervisor -\emph default - behavior, which is used when creating a supervisor. - Supervisors are used when monitoring processes in the Erlang system. - When a process exits wrongfully, the supervisor monitoring the process - in question decides which action to take. - In the GGS, the most common action is simply to restart the faulting process. - A more thorough discussion on supervisors can be found in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:Supervisor-structure" - -\end_inset - -. -\end_layout - -\begin_layout Itemize -The -\emph on -gen_tcp -\emph default -behavior, which is used to work with TCP sockets for network communication. - Using the gen_tcp behavior, network messages are converted to internal - Erlang messages and passed to a protocol parser, where the messages are - processed further. -\end_layout - -\begin_layout Itemize -The -\emph on -gen_server -\emph default - behavior, which is used when constructing OTP servers in Erlang. - Using this behavior, a state can easily be kept in a server process, greatly - increasing the usefulness of the server process. - There are many gen_servers in the GGS, it is the most widely used behavior - in the project. - In addition to introducing a state to the server, the gen_server behavior - also imposes patterns for synchronous and asynchronous communication between - other gen_servers and other OTP behaviors. -\end_layout - -\begin_layout Itemize -The -\emph on -gen_fsm -\emph default - behavior is used in the protocol parser module in the GGS. - Using the gen_fsm behavior, finite state machines are easily developed. - Protocol parsers are an ideal example of where to use finite state machines, - which are widely used for parsing strings of text. -\end_layout - -\begin_layout Standard -In addition to supplying behaviors, the OTP also has a style for packaging - and running Erlang applications. - By packaging the GGS as an -\emph on -application -\emph default -the GGS can be started in a way uniform to most erlang software, providing - familiarity for other Erlang users, and eases the incorporation of the - GGS in other applications. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Application}}{A way of packaging Erlang software in a uniform way} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Short introduction to the Erlang syntax -\end_layout - -\begin_layout Standard -In order to understand examples in this thesis, a small subset of Erlang - must be understood. - In this section, the very syntactic basics of Erlang are given. -\end_layout - -\begin_layout Itemize - -\series bold -Variables -\series default - start with an uppercase letter, examples include -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt X, Var}, and { -\backslash -tt Global} -\end_layout - -\end_inset - -. - A variable can only be assigned once. -\end_layout - -\begin_layout Itemize - -\series bold -Atoms -\emph on - -\series default -\emph default -start with lower case letters, for example: -\begin_inset ERT -status open - -\begin_layout Plain Layout - - { -\backslash -tt atom, a} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Itemize - -\series bold -Functions -\series default - are defined starting with an atom for the name, parenthesis containing - parameters, an arrow, a function body and finally a dot marking the end - of a function. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt square(X) -> X*X.} -\end_layout - -\end_inset - - is an example of a function producing the square of X. -\end_layout - -\begin_layout Itemize -Functions are -\series bold -called -\series default - by suffixing an atom with the function name with parenthesis, for example - -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt square(10)} -\end_layout - -\end_inset - -. - Qualified names can be specified using ':', for example: -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt math:square(10)} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Itemize - -\series bold -Tuples -\series default - are containers of fixed type for Erlang data types. - They are constructed using curly brackets, for example: -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt -\backslash -{atom1, atom2, atom3 -\backslash -}}. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Itemize - -\series bold -Lists -\series default - are constructed using [ and ], for example: -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt [1,2,3]} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Itemize - -\series bold -Strings -\series default - doubly quoted lists of characters, for example -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt "Hello world"} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Itemize - -\series bold -Records -\series default - are erlang tuples coupled with a tag for each tuple element. - This allows referring to elements by name instead of by position. - An example of a record looks like this: -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt -\backslash -#myRecord{}} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Section -Communication with external systems and applications -\begin_inset CommandInset label -LatexCommand label -name "sec:Communication-with-external" - -\end_inset - - -\end_layout - -\begin_layout Standard -A game launched on the GGS is run within a virtual machine. - For each programming language supported, there is a virtual machine that - interprets the game. - Furthermore an interface for communication between the GGS, the game and - the players playing the game must be present. -\end_layout - -\begin_layout Standard -The reason for the GGS requiring a communication channel between the game - VM and Erlang is in part because the GGS makes heavy use of callbacks. - Callbacks written in Erlang are registered to the VM for the interface - to work. - It is only with the help of the interface that the game developer can access - the game state and send messages between players. - The interface provides access to three objects called -\emph on -world -\emph default -, -\emph on -player -\emph default - and -\emph on -localstorage -\emph default -. - The game state is safely stored in a database and retrieved for manipulation - by a call for the world object. - Interaction with the players is done the same way using the player object - instead. - The localstorage is a convenient way to store global data and other data - separated from the game state. - In section -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:Exposing-Erlang-functionality" - -\end_inset - - a concrete example of the implementation of the localstorage and world - objects is given. -\begin_inset Note Note -status open - -\begin_layout Plain Layout - Unique id:s called gametokens are generated for hosted games so that they - are not mixed up. - -- good text, integrate more. -\end_layout - -\end_inset - - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{WebStorage}}{A new standard for letting websites store data on visitors' - computers} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Exposing Erlang functionality to the GDL VM -\begin_inset CommandInset label -LatexCommand label -name "sub:Exposing-Erlang-functionality" - -\end_inset - - -\end_layout - -\begin_layout Standard -This section contains a concrete example of how the localstorage and world - objects are exposed to a GDL VM. - The example comes from the GGS prototype, which uses JavaScript powered - by Google V8 as its GDL VM. -\end_layout - -\begin_layout Standard -The code given in -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:exposing-erlang" - -\end_inset - - is specific to V8 and JavaScript, however implementations for different - GDL:s, or different JavaScript VM:s should be similar. -\end_layout - -\begin_layout Standard -In JavaScript is is common to use a top level object, called a global object, - to establish a global scope. - This allows declaration of global variables and functions. - To gain access to the global object in the GGS, the -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt erlv8 -\backslash -_vm:global(..)} -\end_layout - -\end_inset - - function on line 2 of the example is used. - Using the global object, declarations of the world and GGS object can be - placed in the global scope. -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt Global:set -\backslash -_value(..)} -\end_layout - -\end_inset - - is a call to the global object, declaring new objects in the global scope. - On line 4 the GGS object is declared. - By accessing -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt GGS.localStorage } -\end_layout - -\end_inset - - from within the GDL, access to the localstorage is provided, thus the localstor -age must be connected to the GGS object, this can be seen in line 5. -\end_layout - -\begin_layout Standard -Both the GGS and localstorage objects are dummy objects, which provide no - functionality, these two objects are simply placed in the GDL for the purpose - clearing up the code. - In order to perform an action using the GGS and localstorage objects, the - -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt getItem} and { -\backslash -tt setItem} -\end_layout - -\end_inset - - functions must be used. - These items are directly connected to the database module of the GGS, which - is discussed in more detail in -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:The-database-module" - -\end_inset - -. -\end_layout - -\begin_layout Standard -Similarly the functions -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt sendCommand, sendCommandToAll} and { -\backslash -tt setTimeout} -\end_layout - -\end_inset - - are directly connected to a piece of code in the GGS which performs the - desired action. - The -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt sendCommand} -\end_layout - -\end_inset - - functions are used to send commands or text to participants of the table. - The -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt setTimeout} -\end_layout - -\end_inset - - function introduces timeouts to the V8 engine, which are not available - per default. -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -lstset{ -\end_layout - -\begin_layout Plain Layout - -language=Erlang, -\end_layout - -\begin_layout Plain Layout - -backgroundcolor= -\backslash -color{white}, -\end_layout - -\begin_layout Plain Layout - -extendedchars=true, -\end_layout - -\begin_layout Plain Layout - -basicstyle= -\backslash -footnotesize -\backslash -ttfamily, -\end_layout - -\begin_layout Plain Layout - -showstringspaces=false, -\end_layout - -\begin_layout Plain Layout - -showspaces=false, -\end_layout - -\begin_layout Plain Layout - -numbers=left, -\end_layout - -\begin_layout Plain Layout - -numberstyle= -\backslash -footnotesize, -\end_layout - -\begin_layout Plain Layout - -numbersep=9pt, -\end_layout - -\begin_layout Plain Layout - -tabsize=2, -\end_layout - -\begin_layout Plain Layout - -breaklines=true, -\end_layout - -\begin_layout Plain Layout - -showtabs=false, -\end_layout - -\begin_layout Plain Layout - -captionpos=b -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - - -\backslash -begin{lstlisting}[language=Erlang] -\end_layout - -\begin_layout Plain Layout - -% @doc Exposes some GGS functions to JavaScript -\end_layout - -\begin_layout Plain Layout - -expose(GameVM, Table) -> -\end_layout - -\begin_layout Plain Layout - - Global = erlv8_vm:global(GameVM), -\end_layout - -\begin_layout Plain Layout - - Global:set_value("GGS", erlv8_object:new([ -\end_layout - -\begin_layout Plain Layout - - {"localStorage", erlv8_object:new([ -\end_layout - -\begin_layout Plain Layout - - {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:setItem(Table, local_storage, Key, Val) -\end_layout - -\begin_layout Plain Layout - - end}, -\end_layout - -\begin_layout Plain Layout - - {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:getItem(Table, local_storage, Key) -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - % more functions ... -\end_layout - -\begin_layout Plain Layout - - ])}, -\end_layout - -\begin_layout Plain Layout - - {"world", erlv8_object:new([ -\end_layout - -\begin_layout Plain Layout - - {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:setItem(Table, world, Key, Val), -\end_layout - -\begin_layout Plain Layout - - ggs_table:send_command_to_all( -\end_layout - -\begin_layout Plain Layout - - Table, {"world_set", Key ++ "=" ++ Val} -\end_layout - -\begin_layout Plain Layout - - ) -\end_layout - -\begin_layout Plain Layout - - end}, -\end_layout - -\begin_layout Plain Layout - - {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:getItem(Table, world, Key), -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - % more functions ... -\end_layout - -\begin_layout Plain Layout - - ])}, -\end_layout - -\begin_layout Plain Layout - - {"sendCommand", fun(#erlv8_fun_invocation{}, [Player, Command, Args])-> -\end_layout - -\begin_layout Plain Layout - - ggs_table:send_command(Table, Player, {Command, Args}) -\end_layout - -\begin_layout Plain Layout - - end}, -\end_layout - -\begin_layout Plain Layout - - {"sendCommandToAll", fun(#erlv8_fun_invocation{}, [Command, Args])-> -\end_layout - -\begin_layout Plain Layout - - ggs_table:send_command_to_all(Table, {Command, Args}) -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - {"setTimeout", fund(#erlv8_fun_invocation{}, [Time, Function])-> -\end_layout - -\begin_layout Plain Layout - - timer:apply_after(Time, ?MODULE, call_js, [GameVM, Function]) -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - % more functions ... -\end_layout - -\begin_layout Plain Layout - - ])). -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{lstlisting} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:exposing-erlang" - -\end_inset - -An example of how Erlang functionality is exposed to a Javascript GDL -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -TODO: Go in to more detail about how the world, player and localstorage - objects are implemented. - Also discuss localstorage and how it derives from the webstorage standard - in detail. - This is a great point on how we try to follow standards. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -My idea here is that we describe the erlang-js (which failed, but nonetheless), - v8, UUID and other external communication. - We shouldn't describe sockets here though.. - or.. - maybe? -\end_layout - -\begin_layout Plain Layout -Also discuss how we allow GDLs to communicate with Erlang, this is -\begin_inset Quotes eld -\end_inset - -external -\begin_inset Quotes erd -\end_inset - - to three GDL. - Discuss the GGS world object (there is a reference to this secxtion for - that purpose) -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -The modular structure of the GGS prototype -\begin_inset CommandInset label -LatexCommand label -name "sec:The-modular-structure" - -\end_inset - - -\end_layout - -\begin_layout Standard -The separation of concerns, and principle of single responsibility -\begin_inset Foot -status open - -\begin_layout Plain Layout -More information on the SRP is available at: -\begin_inset CommandInset href -LatexCommand href -target "http://www.objectmentor.com/resources/articles/srp.pdf" - -\end_inset - - -\end_layout - -\end_inset - - are widely respected as good practices in the world of software engineering - and development. - By dividing the GGS up into modules each part of the GGS can be modified - without damaging the rest of the system. -\end_layout - -\begin_layout Standard -The responsibility and concern of each module comes from the responsibility - and concern of the real-world entity the model represents. - The modeling of the GGS after a real world system was discussed in chapter - -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Theory" - -\end_inset - -. -\end_layout - -\begin_layout Standard -In the text below the word module refers to the actual code of the discussed - feature, while the word process is used when referring to a running instance - of the code. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{SRP}}{Single Responsibility Principle} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Object Oriented Programming}}{A programming paradigm focusing on - objects} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -The dispatcher module -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -The discussion of the modules is divided into the following parts: -\end_layout - -\begin_layout Itemize -What does the module do? -\end_layout - -\begin_layout Itemize -What happens when the module fails? -\end_layout - -\begin_layout Itemize -How does the module correspond to the real-world scenario of the chess club? -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The dispatcher module is the first module to have contact with a player. - When a player connects to the GGS, it is first greeted by the dispatcher - module, which sets up an accepting socket for each player. - -\begin_inset Note Note -status collapsed - -\begin_layout Plain Layout -Is this the proper way to day the dispatcher greets connecting players? -\end_layout - -\end_inset - - The dispatcher is the module which handles the interfacing to the operating - system when working with sockets. - Operating system limits concerning the number of open files, or number - of open sockets are handled here. - The operating system limits can impose problems on the GGS, this is discussed - more in detail in chapter -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Problems-of-implementation" - -\end_inset - -. -\end_layout - -\begin_layout Standard -Should the dispatcher module fail to function, no new connections to the - GGS can be made. - In the event of a crash in the dispatcher module, a supervisor process - immediately restarts the dispatcher. - There exists a window of time between the crashing of the dispatcher and - the restarting of the dispatcher, this window is very short, and only during - this window is the GGS unable to process new connection requests. - Due to the modular structure of the GGS, the rest of the system is not - harmed by the dispatcher process not functioning. - The process does not contain a state, therefore a simple restart of the - process is sufficient in restoring the GGS to a pristine state after a - dispatcher crash -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Well.. - In theory.. -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Standard -Returning to scenario of the chess club, the dispatcher module is the doorman - of the club. - When a player enters the chess club, the player is greeted by the doorman, - letting the player in to the club. - The actual letting in to the club is in the GGS represented by the creation - of a player process discussed in -\begin_inset CommandInset ref -LatexCommand vref -reference "sub:The-player-module" - -\end_inset - -. - The newly created player process is handed, and granted rights to, the - socket of the newly connected player. -\end_layout - -\begin_layout Subsection -The player module -\begin_inset CommandInset label -LatexCommand label -name "sub:The-player-module" - -\end_inset - - -\end_layout - -\begin_layout Standard -The player module is responsible for representing a player in the system. - Each connected player has its own player process. - The player process has access to the connection of the player it represents, - and can communicate with this player. - In order to communicate with a player, the data to and from the player - object must pass through a protocol parser module, discussed in -\begin_inset CommandInset ref -LatexCommand vref -reference "sub:The-protocol-parser" - -\end_inset - -. - Raw communication, without passing the data through a protocol parser is - in theory possible, but is not useful. -\end_layout - -\begin_layout Standard -In the creation of a player process, the coordinator process, discussed - in -\begin_inset CommandInset ref -LatexCommand vref -reference "sub:The-coordinator-module" - -\end_inset - -, is notified by the newly connected process. -\end_layout - -\begin_layout Standard -In the event of a crash in a player process, several things happen. - -\end_layout - -\begin_layout Enumerate -The player process, which is the only process with a reference to the socket - leading to the remote client software, passes this reference of the socket - to the coordinator process temporarily. -\end_layout - -\begin_layout Enumerate -The player process exits. -\end_layout - -\begin_layout Enumerate -The coordinator spawns a new player process, with the same socket reference - as the old player process had. -\end_layout - -\begin_layout Enumerate -The player process resumes operation, immediately starting a new protocol - parser process, and begins to receive and send network messages again. -\end_layout - -\begin_layout Standard -The window of time between the crash of the player process and the starting - of a new player process is, as with the dispatcher, very short. - Since the connection changes owners for a short period of time, but is - never dropped, the implications of a crash are only noticed, at worst, - as choppy gameplay for the client. - Note however that this crash recovery scheme is not implemented in the - GGS prototype. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Can we do this..? Seems a bit sneaky. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Moving back to the real world example, the player process represent an actual - person in the chess club. - When a person sits down at a table in the chess club, the person does so - by requesting a seat from some coordinating person, and is then seated - by the same coordinator. - Once seated, the player may make moves on the table he or she is seated - by, this corresponds clearly to how the GGS is structured, as can be seen - in the following sections. -\end_layout - -\begin_layout Subsection -The protocol parser module -\begin_inset CommandInset label -LatexCommand label -name "sub:The-protocol-parser" - -\end_inset - - -\end_layout - -\begin_layout Standard -The protocol parser is an easily interchangeable module in the GGS, handling - the client-to-server, and server-to-client protocol parsing. - In the GGS prototype, there is only one protocol supported, namely the - -\emph on -GGS Protocol -\emph default -. - The role of the protocol parser is to translate the meaning of packets - sent using the protocol in use to internal messages of the GGS system. - The GGS protocol, discussed below is used as a sample protocol in order - to explain how protocol parsers can be built for the GGS. -\end_layout - -\begin_layout Subsubsection -The structure of the GGS Protocol -\begin_inset CommandInset label -LatexCommand label -name "sub:The-structure-of" - -\end_inset - - -\end_layout - -\begin_layout Standard -The GGS protocol is modeled after the HTTP protocol. - The main reason for this is the familiarity many developers already have - with HTTP due to its presence in internet software. - Each GGS protocol packet contains a headers section. - The headers section is followed by a data section. - In the headers section, parameters concerning the packet is placed. - In the data section, the actual data payload of the packet is placed. -\end_layout - -\begin_layout Standard -There is no requirement of any specific order of the parameters in the headers - section, however the data section must always follow directly after the - headers section. -\end_layout - -\begin_layout Standard -In the example below, line 1 contains a Game-Command parameter. - This parameter is used to determine which game-specific command the client - is trying to perform. - The handling of this parameter is specific to each game, and can be anything. -\end_layout - -\begin_layout Standard -Line 2 specifies a game token. - This is a UUID which is generated for each client upon authentication with - the GGS. - The GGS uses this token in case a client is disconnected and the new connection - created when the client reconnects must be re-paired with the player object - inside the GGS. - The UUID is also used as a unique ID within GDL VMs. -\end_layout - -\begin_layout Standard -Line 3 specifies the content type of the payload of this particular packet. - This parameter allows the GGS to invoke special parsers, should the data - be encoded or encrypted. - When encryption is employed, only the payload is encrypted, not the header - section. - This is a scheme which does not allow for strong encryption, but is deemed - feasible for gaming purposes. -\end_layout - -\begin_layout Standard -Line 4 specifies the content length of the payload following immediately - after the headers section. -\end_layout - -\begin_layout Standard -The parser of the GGS protocol implemented in the GGS prototype is designed - as a finite state machine using the gen_fsm behavior. - When a full message has been parsed by the parser, the message is converted - into the internal structure of the GGS messages, and sent in to the system - from the protocol parser using message passing. -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Packet below is not an algorithm, but I don't know how to change that label.. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -lstset{ -\end_layout - -\begin_layout Plain Layout - -backgroundcolor= -\backslash -color{white}, -\end_layout - -\begin_layout Plain Layout - -extendedchars=true, -\end_layout - -\begin_layout Plain Layout - -basicstyle= -\backslash -footnotesize -\backslash -ttfamily, -\end_layout - -\begin_layout Plain Layout - -showstringspaces=false, -\end_layout - -\begin_layout Plain Layout - -showspaces=false, -\end_layout - -\begin_layout Plain Layout - -numbers=left, -\end_layout - -\begin_layout Plain Layout - -numberstyle= -\backslash -footnotesize, -\end_layout - -\begin_layout Plain Layout - -numbersep=9pt, -\end_layout - -\begin_layout Plain Layout - -tabsize=2, -\end_layout - -\begin_layout Plain Layout - -breaklines=true, -\end_layout - -\begin_layout Plain Layout - -showtabs=false, -\end_layout - -\begin_layout Plain Layout - -captionpos=b -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - - -\backslash -begin{lstlisting} -\end_layout - -\begin_layout Plain Layout - -Game-Command: chat -\end_layout - -\begin_layout Plain Layout - -Token: e30174d4-185e-493b-a21a-832e2d9d7a1a -\end_layout - -\begin_layout Plain Layout - -Content-Type: text -\end_layout - -\begin_layout Plain Layout - -Content-Length: 18 -\end_layout - -\begin_layout Plain Layout - -\end_layout - -\begin_layout Plain Layout - -Hello world, guys! -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{lstlisting} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:A-sample-packet" - -\end_inset - -A sample packet sent from a client to the GGS during a chat session -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Mention that the protocol is heavily influenced bye HTTP, is parsed using - a FSM, perhaps give a sample packet. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -The coordinator module -\begin_inset CommandInset label -LatexCommand label -name "sub:The-coordinator-module" - -\end_inset - - -\end_layout - -\begin_layout Standard -The coordinator module is responsible for keeping track of all players, - their seats and tables. - Players register with the coordinator process when first connecting to - the server, and the coordinator places each player by their respective - table. -\end_layout - -\begin_layout Standard -The coordinator keeps mappings between each player and table, therefore - it is used to perform lookups on tables and players to find out which are - connected. - The connectivity of players and tables is important when sending messages - to all participants in a game. - A lookup in the coordinator process is performed prior to notifying all - players in a game to ensure the message reaches all players. - The lookup can be performed either using internal identification codes - or using the UUID associated with each client and table. -\end_layout - -\begin_layout Standard -The coordinator process contains important state, therefore a backup process - is kept at allt times. - All good data processed by the coordinator is stored for safekeeping in - the backup process as well. - Data which is potentisally harmful is not stored in the backup process. -\end_layout - -\begin_layout Standard -Upon a crash, the coordinator process recovers the prior good state from - the backup process and continues where it left off. - A supervisor process monitors the coordinator process and restarts the - process when it malfunctions. - There is a window of time between the crash of the coordinator and the - restarting of the coordinator, during this time, players can not be seated - by new tables, and can not disconnect from the server. - This window of time is very small, and the unavailability of the coordinator - process should not be noticed by more than a short time lag for the clients. -\end_layout - -\begin_layout Standard -Moving back to the example of the chess club, the coordinator process can - be seen as a judge, monitoring all moves of the players. - At the same time as acting as a judge, the coordinator process is also - a host in the chess club, seating players by their tables and offering - services to the players. -\end_layout - -\begin_layout Subsection -The table module -\end_layout - -\begin_layout Standard -The table module is mostly a hub used for communication. - New table processes are created by the coordinator on demand. - The table module does not contain any business logic, however each process - contains information concerning which players are seated by that particular - table. -\end_layout - -\begin_layout Standard -The information about which players are seated by each table is used when - notifying all players by a table of an action. - Consider a game of chess, each player notifies the table of its actions, - the table then notifies the rest of the participants of these actions after - having had the ac tions processed by the game VM, where an action could - be moving a playing piece. -\end_layout - -\begin_layout Standard -Each table is associated with a game VM. - The actions sent to a table are processed by the game VM, this is where - the game logic is implemented. -\end_layout - -\begin_layout Standard -After a crash in a table process, the entire table must be rebuilt and the - players must be re-associated with the table. - Data concerning players is kept in the coordinator process, and is restored - from there. - Data kept in the actual game is not automatically corrupted by the crash - in a table, however the table must be re-associated with the game VM is - was associated with prior to the crash of the table. - The table process maps well into the setting of the real-world chess club - scenario previously discussed. - A table works in the same way in a real world setting as in the GGS setting. -\end_layout - -\begin_layout Subsection -The game virtual machine module -\end_layout - -\begin_layout Standard -This module holds the game logic of a game and is responsible for the VM - associated with each game. - -\end_layout - -\begin_layout Standard -The game VM contains the state of the VM and a table token associated with - a running game. - GameVM is started by the table module. - The table module hands over a token to the game VM during initialization. - During initialization a new VM instance and various objects associated - to the VM instance will be created. - Callbacks to Erlang are registered into the VM and then the source code - of a game is loaded into the VM and the game is ready for startup. - The only means for a game to communicate with the VM is through usage of - a provided interface. - -\end_layout - -\begin_layout Standard -The VM itself makes it possible for the game developer to program in the - programming language covered by the VM. - In future releases, more game VM:s will be added to support more programming - languages. - Because the game VM keeps track of the correct table, the game developer - does not need to take this into consideration when programming a game. - If a method within the game sends data to a player, it will be delivered - to the player in the correct running game. - The same game token is used to store the game state in the database. - Therefore, no game states will be mixed up either. -\end_layout - -\begin_layout Standard -This module does not affect game runtime but evaluates a new game state - and handles communication between the game and the players. - A closer look at the structure of this model is given in -\begin_inset CommandInset ref -LatexCommand vref -reference "sec:Communication-with-the-GDL-VM" - -\end_inset - -. -\end_layout - -\begin_layout Subsection -The database module -\begin_inset CommandInset label -LatexCommand label -name "sub:The-database-module" - -\end_inset - - -\end_layout - -\begin_layout Standard -Game data from all games on the GGS are stored in the database backend of - the database module. -\end_layout - -\begin_layout Standard -In the GGS prototype the database module is using a database management - system called Mnesia. - Mnesia ships with the standard Erlang distribution and is a key-value store - type database. - Mnesia is designed to handle the stress of telecoms systems, and has some - features specifically tailored for telecoms which are not commonly found - in other databases. - Key features of the Mnesia database are: -\end_layout - -\begin_layout Itemize -Fast key/value lookups -\end_layout - -\begin_layout Itemize -Distribution of the database system -\end_layout - -\begin_layout Itemize -Fault tolerance -\end_layout - -\begin_layout Standard -\begin_inset CommandInset citation -LatexCommand citet -key "667766" - -\end_inset - - -\end_layout - -\begin_layout Standard -The features of Mnesia originally intended for telecoms prove very useful - for the purposes of the GGS as well. - The fault tolerance and speed of Mnesia are very valuable tools, the fast - key/value lookups permit many lookups per second to the database. -\end_layout - -\begin_layout Standard -Game data will not be lost when a game is stopped or has gone down for unknown - reasons. - This makes it possible to continue a game just before the failure without - having to start the game from the beginning. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Mnesia}}{Database server used in the GGS} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The GGS stores the game state in the distributed Mnesia database, from which - the state can be restored in the event of a crash. -\end_layout - -\begin_layout Standard -Each game is uniquely identified by a table token and the data of each game - is stored within two different namespaces. - The namespaces are named World and Localstorage. - The World is used contain all game data related to the game state. - This sort of game data may change during the runtime of the game. - The Localstorage should contain data independent of the game state. - Game resources, constants and global variables are all examples of data - that could reside within the Localstorage. - To store a value within the database, not only is the table token and the - name of the namespace required, but a unique key so that the value can - be successfully retrieved or modified later. - The key is fully decidable by the game developer. - -\end_layout - -\begin_layout Standard -The interface of the database module is an implementation of the upcoming - W3C Web Storage specification. - Web Storage is intended for use in web browsers, providing a persistent - storage on the local machine for web applications. - The storage can be used to communicate in between browser windows (which - is difficult when using cookies), and to store larger chunks of data -\begin_inset CommandInset citation -LatexCommand citet -key "webstorage:website" - -\end_inset - -. - Usage of the web storage standard in the GGS provides a well documented - interface to the database backend. -\end_layout - -\begin_layout Section -Techniques for ensuring reliability -\end_layout - -\begin_layout Standard -One of the main goals of the project is to achieve high reliability. - The term -\begin_inset Quotes eld -\end_inset - -reliable system -\begin_inset Quotes erd -\end_inset - - is defined by the IEEE as a system with -\begin_inset Quotes eld -\end_inset - -the ability of a system or component to perform its required functions under - stated conditions for a specified period of time -\begin_inset Quotes erd -\end_inset - - -\begin_inset CommandInset citation -LatexCommand citet -key "ieee_90" - -\end_inset - -. - There are some tools for creating reliable applications built in to Erlang. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Reliability}}{The ability of a system or component to perform its - required functions under stated conditions for a specified period of time} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{IEEE}}{Institute of Electrical and Electronics Engineers, read "I-triple- -E"} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Itemize -Links between processes. - When a process spawns a new child process, and the child process later - exits, the parent process is notified of the exit. - -\end_layout - -\begin_layout Itemize -Transparent distribution over a network of processors. - When several nodes participate in a network, it does not matter on which - of these machines a process is run. - Communication between processes does not depend on the node in which each - process is run. - -\end_layout - -\begin_layout Itemize -Hot code replacements. - Two versions of the same module can reside in the memory of Erlang at any - time. - This means that a simple swap between these versions can take place very - quickly, and without stopping the machine. -\end_layout - -\begin_layout Standard -These three features are some of the basic building blocks for more sophisticate -d reliability systems in Erlang. - Many times it is not necessary to use these features directly, but rather - through the design patterns described below. -\end_layout - -\begin_layout Subsection -Supervisor structure -\begin_inset CommandInset label -LatexCommand label -name "sub:Supervisor-structure" - -\end_inset - - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -This entire section is bad. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -By linking processes together and notifying parents when children exit, - supervisors are created. - A supervisor is a common approach in ensuring that an application functions - in the way it was intended -\begin_inset CommandInset citation -LatexCommand citet -key "Savor:1997:HSA:851010.856089" - -\end_inset - -. - When a process misbehaves, the supervisor takes some action to restore - the process to a functional state. - -\end_layout - -\begin_layout Standard -There are several approaches to supervisor design in general (when not just - considering how they work in Erlang). - One common approach is to have the supervisor look in to the state of the - process(es) it supervises, and let the supervisor make decisions based - on this state. - The supervisor has a specification of how the process it supervises should - function, and this is how it makes decisions. - -\end_layout - -\begin_layout Standard -In Erlang, we have a simple version of supervisors. - We do not inspect the state of the processes being supervised. - We do have a specification of how the supervised processes should behave, - but on a higher level. - The specification describes things such as how many times in a given time - interval a child process may crash, which processes need restarting when - crashes occur, and so forth. - -\end_layout - -\begin_layout Standard -When the linking of processes in order to monitor exit behavior is coupled - with the transparent distribution of Erlang, a very powerful supervision - system is created. - For instance, we can restart a failing process on a different, new node, - with minimal impact on the system as a whole. - -\end_layout - -\begin_layout Standard -In the GGS, we have separated the system in to two large supervised parts. - We try to restart a crashing child separately, if this fails too many -\begin_inset Foot -status collapsed - -\begin_layout Plain Layout -Exactly how many -\begin_inset Quotes eld -\end_inset - -too many -\begin_inset Quotes erd -\end_inset - - is depends on a setting in the supervisor, ten crashes per second is a - reasonable upper limit. -\end_layout - -\end_inset - - times, we restart the nearest supervisor of this child. - This ensures separation of the subsystems so that a crash is as isolated - as possible. -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset Note Note -status open - -\begin_layout Plain Layout -We should really do this graphic in EPS instead of PNG -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/Supervisor_tree_GGS.eps - scale 40 - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -The supervisor structure of GGS -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The graphic above shows our two subsystems, the coordinator subsystem and - the dispatcher subsystem. - Since these two systems perform very different tasks they have been separated. - Each subsystem has one worker process, the coordinator or the dispatcher. - The worker process keeps a state which should not be lost upon a crash. -\end_layout - -\begin_layout Standard -We have chosen to let faulty processes crash very easily when they receive - bad data, or something unexpected happens. - The alternative to crashing would have been to try and fix this faulty - data, or to foresee the unexpected events. - We chose not to do this because it is so simple to monitor and restart - processes, and so difficult to try and mend broken states. - This approach is something widely deployed in the Erlang world, and developers - are often encouraged to “Let it crash”. -\end_layout - -\begin_layout Standard -To prevent any data loss, the good state of the worker processes is stored - in their respective backup processes. - When a worker process (re)starts, it asks the backup process for any previous - state, if there is any that state is loaded in to the worker and it proceeds - where it left off. - If on the other hand no state is available, a special message is delivered - instead, making the worker create a new state, this is what happens when - the workers are first created. -\end_layout - -\begin_layout Subsection -Redundancy -\end_layout - -\begin_layout Standard -The modules in the GGS are built to be capable of redundant operation. - By adding a backup process to sensitive processes, the state can be kept - in the event of a crash. - The coordinator of the GGS prototype has this backup feature built in. - The coordinator passes state along to the backup process which keeps the - data safe. - In the event of a crash, the coordinator recovers the state from the backup - process. - Figure -\begin_inset CommandInset ref -LatexCommand ref -reference "fig:redundancy" - -\end_inset - - depicts the redundancy built in to the coordinator process. -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/redundancy.eps - scale 40 - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "fig:redundancy" - -\end_inset - -To the left normal execution is pictured; the server state is backed up. - To the right; the exceptional execution, where the state is retrieved from - the backup to repopulate the server. -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Hot code replacement -\end_layout - -\begin_layout Standard -Hot code replacement is a technique used to update systems while they are - running. - The main use of hot code replacement are in critical systems that require - low downtime, such as telecom systems. - By using hot code replacement system can be able to achieve as high uptime - as possible and thus improving the reliability of the system. - Code replacement is a feature that exist in Erlang which means that with - some work it could be implemented into the GGS. -\end_layout - -\begin_layout Section -Example of a GGS server application in Javascript -\end_layout - -\begin_layout Standard -Below is a concrete example of a simple chat server application written - using the GGS. - The language chosen for this chat server is JavaScript. - The GGS processes all incoming data through a protocol parser, which interprets - the data and parses it into an internal format for the GGS. -\end_layout - -\begin_layout Standard -When the GGS receives a -\emph on -Game-Command -\emph default - from a client, it is passed along to the game VM through a function called - -\emph on -playerCommand -\emph default - which is the entry point for each game and has to be implemented by the - developer; one can think of it like the -\emph on -main() -\emph default - function of a C or Java program -\emph on -. - -\emph default - Typically the -\emph on -playerCommand -\emph default - function contains conditional constructs which decide the next action to - take. - In -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-concrete-example" - -\end_inset - - an example of the -\emph on -playerCommand -\emph default - function can be seen. -\end_layout - -\begin_layout Standard -In -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-concrete-example" - -\end_inset - - the -\emph on -playerCommand -\emph default - function accepts two different commands. - The first command is a command which allows chat clients connected to the - chat server to change nicknames, which are used when chatting. - In order to change the nickname, a client must send a Game-Command -\begin_inset Quotes eld -\end_inset - -nick -\begin_inset Quotes erd -\end_inset - - with the actual new nickname as a argument. - When a message arrives to the GGS which has the form corresponding to the - nickname change, the -\emph on -playerCommand -\emph default - function is called with the parameters -\emph on -player_id, command, -\emph default -and -\emph on -args -\emph default - filled in appropriately. -\end_layout - -\begin_layout Standard -The -\emph on -playerCommand -\emph default - function is responsible for calling the helper functions responsibly for - carrying out the actions of each message received. - -\emph on -changeNick -\emph default - is a function which is called when the -\begin_inset Quotes eld -\end_inset - -nick -\begin_inset Quotes erd -\end_inset - - message is received. - The -\emph on -changeNick -\emph default -function uses a feature of the GGS called localstorage (see section -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Communication-with-the-GDL-VM" - -\end_inset - -), which is an interface to the database backend contained in the database - module (see -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:The-database-module" - -\end_inset - -). - The database can be used as any key-value store, however the syntax for - insertions and fetch operations is tighty integrated in the GDL of the - GGS. -\end_layout - -\begin_layout Standard -Access to the localStorage is provided through the -\emph on -GGS object -\emph default -, which also can be used to communicate with the rest of the system from - the GDL. - Implementation specifics of the GGS object are provided in -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Communication-with-the-GDL-VM" - -\end_inset - -. -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -lstset{ -\end_layout - -\begin_layout Plain Layout - -language=JavaScript, -\end_layout - -\begin_layout Plain Layout - -backgroundcolor= -\backslash -color{white}, -\end_layout - -\begin_layout Plain Layout - -extendedchars=true, -\end_layout - -\begin_layout Plain Layout - -basicstyle= -\backslash -footnotesize -\backslash -ttfamily, -\end_layout - -\begin_layout Plain Layout - -showstringspaces=false, -\end_layout - -\begin_layout Plain Layout - -showspaces=false, -\end_layout - -\begin_layout Plain Layout - -numbers=left, -\end_layout - -\begin_layout Plain Layout - -numberstyle= -\backslash -footnotesize, -\end_layout - -\begin_layout Plain Layout - -numbersep=9pt, -\end_layout - -\begin_layout Plain Layout - -tabsize=2, -\end_layout - -\begin_layout Plain Layout - -breaklines=true, -\end_layout - -\begin_layout Plain Layout - -showtabs=false, -\end_layout - -\begin_layout Plain Layout - -captionpos=b -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - - -\backslash -begin{lstlisting}[language=JavaScript] -\end_layout - -\begin_layout Plain Layout - -function playerCommand(player_id, command, args) { -\end_layout - -\begin_layout Plain Layout - - if(command == "nick") { -\end_layout - -\begin_layout Plain Layout - - changeNick(player_id, args); -\end_layout - -\begin_layout Plain Layout - - } else if(command == "message") { -\end_layout - -\begin_layout Plain Layout - - message(player_id, args); -\end_layout - -\begin_layout Plain Layout - - } -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - -function changeNick(player_id, nick) { -\end_layout - -\begin_layout Plain Layout - - var old_nick = GGS.localStorage.getItem("nick_" + player_id); -\end_layout - -\begin_layout Plain Layout - - GGS.localStorage.setItem("nick_" + player_id, nick); -\end_layout - -\begin_layout Plain Layout - - if (!old_nick) { -\end_layout - -\begin_layout Plain Layout - - GGS.sendCommandToAll("notice", nick + " joined"); -\end_layout - -\begin_layout Plain Layout - - } else { -\end_layout - -\begin_layout Plain Layout - - GGS.sendCommandToAll("notice", old_nick + " is now called " + nick); -\end_layout - -\begin_layout Plain Layout - - } -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - -function message(player_id, message) { -\end_layout - -\begin_layout Plain Layout - - var nick = GGS.localStorage.getItem("nick_" + player_id); -\end_layout - -\begin_layout Plain Layout - - GGS.sendCommandToAll('message', nick + "> " + message); -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{lstlisting} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:A-concrete-example" - -\end_inset - -A concrete example of a simple chat server written in JavaScript, running - on the GGS -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Chapter -Problems of implementation -\begin_inset CommandInset label -LatexCommand label -name "cha:Problems-of-implementation" - -\end_inset - - -\end_layout - -\begin_layout Standard -This chapter contains specific problems encountered when implementing the - GGS prototype. - Some of the problems described have solutions attached, however some problems - were not solved, therefore only ideas for slutions have been attached. -\end_layout - -\begin_layout Standard -The integration of JavaScript as a GDL in the GGS prototype was particularily - difficult, and is handled in this section. - Unique identification is also handled, as is the design of the GGS protocol. -\end_layout - -\begin_layout Section -JavaScript engine -\end_layout - -\begin_layout Standard -The GGS prototype uses a vistual machine to sandbox each game. - JavaScript was chosen for the prototype due to its commonality in web applicati -ons and the flexibility of the language. - Any language with the proper bindings to Erlang could have been used in - theory. -\end_layout - -\begin_layout Standard -There are two main JavaScript virtual machines, or -\emph on -engines -\emph default - available at the time of the writing of this thesis. - There is a group of machines developed by Mozilla called -\emph on -TraceMonkey, JaegerMonkey, SpiderMonkey -\emph default -and -\emph on -IonMonkey -\emph default -, and also there is Google V8. - The group of Mozilla machines are largely the same, and are referred to - as the same machine for simplicity. -\end_layout - -\begin_layout Standard -For the Mozilla machines, there exists an Erlang binding called erlang_js, - and for the V8 machine a binding called erlv8 exists. -\end_layout - -\begin_layout Subsection -erlang_js -\end_layout - -\begin_layout Standard -Erlang_js provides direct communication with the JavaScript VM. - Which is exactly what is desired, however also required is thee possibility - to communicate from erlang_js to Erlang. - The ability to communicate from JavaScript to Erlang functionality is not - yet implemented in erlang_js, due to lack of time on the behalf of the - erlang_js developers. -\end_layout - -\begin_layout Standard -There were two possible solutions to the problem of the JavaScript to Erlang - communication path missing, the path could be implemented by the GGS project, - or a switch from erlang_js for some other JavaScript engine could be made. - -\end_layout - -\begin_layout Standard -Attempts at creating the communication path from JavaScript to Erlang were - initially made, however the communication path never became stable enough - for usage in the GGS and the erlang_js software was abandoned. -\end_layout - -\begin_layout Subsection -erlv8 -\end_layout - -\begin_layout Standard -erlv8 is powered by the V8 engine developed by Google rather than the engines - developed by Mozilla. - The ability to communicate with Erlang from JavaScript using callbacks - is available in the erlv8 bindings, therefore this feature does not have - to be added to the bindings in order to be used in the GGS. -\end_layout - -\begin_layout Standard -Initial releases of the erlv8 bindings had stability issues, these were - however solved by the erlv8 developers during the usage of erlv8 in the - GGS. - erlv8 is the JavaScript engine powering JavaScript as a GDL in the GGS. -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{V8}}{JavaScript engine developed by Google} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{SpiderMonkey}}{JavaScript engine developed by Mozilla} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -UUID -\end_layout - -\begin_layout Standard -Erlang identifies processes uniquely throughout the entire Erlang network - using process IDs (PID). - When we wish to refer to erlang processes from outside our erlang system, - for example in a virtual machine for a different language, possibly on - a different machine, these PID:s are no longer useful. - -\end_layout - -\begin_layout Standard -This problem is not new, and a common solution is to use a Universally Unique - Identifier, a UUID. - These identifiers are generated both using randomization and using time. - A reasonably large number of UUID:s can be generated before a collision - should occur. - There are standard tools in many UNIX systems to generate UUID:s, we chose - to use the uuidgen command, which employs an equidistributed combined Tausworth -e generator. -\end_layout - -\begin_layout Section -Protocol design -\end_layout - -\begin_layout Standard -Initially the GGS protocol was designed to use the UDP protocol for transport. - Due to the lack of error checking in the UDP protocol, the UDP protocol - is faster than the TCP protocol, this was a main reason to use UDP. - The GGS does however need error checking to be as reliable as possible, - therefore an error checking layer would have to be placed on top of UDP. -\end_layout - -\begin_layout Standard -The development of an error checking layer was weighed against the implementatio -n of TCP instead of UDP, thus losing some speed. - Even though speed was lost, TCP was chosen due to the relative ease of - implementation compared to UDP. - Due to the modularity of the GGS, a UDP extension is possible by replacing - the network parts of the GGS. -\end_layout - -\begin_layout Standard -Furthermore, in a move to increase the speed of the GGS protocol the binary - BSON protocol -\begin_inset CommandInset citation -LatexCommand citet -key "bson:website" - -\end_inset - - was initially considered. - BSON is a protocol which can be used for very fast traversal of data. - The BSON protocol is however rather difficult to read in its plain format, - and no implementation has been bade for the GGS. -\end_layout - -\begin_layout Standard -The Apache Thrift -\begin_inset CommandInset citation -LatexCommand citep -key "Slee2007" - -\end_inset - - was also an alternative. - Using Thrift would mean the GGS would feature a standard protocol for network - communication. - Before finding out about Thrift, an implementation of the GGS protocol - had already been made, moving to Thrift would mean too much work. -\end_layout - -\begin_layout Standard -The use of Thrift, BSON, or other protocols can be supported quite easily - by developing protocol modules for each protocol. - No protocol modules for these protocols have however been developed during - the writing of this thesis -\end_layout - -\begin_layout Section -Design choices -\begin_inset Note Note -status open - -\begin_layout Plain Layout -This section is wrongly placed -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -When designing concurrent applications, it is useful to picture them as - real world scenarios, and to model each actor as a real world process. - A real world process is a process which performs some action in the real - world, such as a mailbox receiving a letter, a door being opened, a person - translating a text, a soccer player kicking the ball, just to name a few - examples. - Since we focus on games in this project, it is suitable to model our system - as a place where games take place. - We imagined a chess club. - -\end_layout - -\begin_layout Standard -The clients pictured as green circles can be thought of as the physical - chess players. -\end_layout - -\begin_layout Standard -When a player wants to enter the our particular chess club, he must first - be let in by the doorman, called the -\emph on -Dispatcher -\emph default - in the GGS. -\end_layout - -\begin_layout Standard -He then gets a name badge, and thus becomes a -\emph on -Player -\emph default - process in the system. - He is also guided in to the lobby by the -\emph on -Coordinator -\emph default -, which has the role of the host of the chess club. -\end_layout - -\begin_layout Standard -When players wish to play against each other, they talk to the -\emph on -Coordinator -\emph default - who pairs them up, and places them at a table. - Once they have sat down at the table, they no longer need the assistance - of the -\emph on -Coordinator -\emph default -, all further communication takes place via the table. - This can be thought of as the actual chess game commencing. - -\end_layout - -\begin_layout Standard -All the moves made in the game are recorded by the table, such that the - table can restore the game in case something would happen, such as the - table tipping over, which would represent the table process crashing. -\end_layout - -\begin_layout Standard -Once a player wishes to leave a game, or the entire facility, he should - contact the -\emph on -Coordinator -\emph default -, who revokes his name badge and the -\emph on -Dispatcher -\emph default - will let the player out. -\end_layout - -\begin_layout Standard -With the information kept in the tables and the -\emph on -Coordinator -\emph default - combined, we can rebuild the entire state of the server at a different - location. - This can be thought of the chess club catching fire, and the -\emph on -Coordinator -\emph default - rounding up all the tables, running to a new location and building the - club up in the exact state it was prior to the fire. -\end_layout - -\begin_layout Chapter -Results and discussion -\begin_inset CommandInset label -LatexCommand label -name "chap:Results-and-discussion" - -\end_inset - - -\end_layout - -\begin_layout Section -Statistics -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Mention the hardware which the GGS was run on; A Thinkpad T410 wityh a core - i5 and 4GB of ram. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Important things to note are that the number of clients is not a good way - of measuring the performance of the server because the server is possible - to have a large number of clients on the server but it can not handle all - the information. - Instead the performance of the server should be measured in the number - of messages it can handle per second. -\end_layout - -\begin_layout Standard -We were able to reach 6000 messages per second on the server, which corresponds - to around 350 clients. - However soon after this mnesia printed some warnings and the clients started - to lag. - With this in mind one thing to investigate is if mnesia is the bottleneck - in the system. - Current game servers do not use databases to save their state and maybe - we can see the reason here. - Other possible bottlenecks may be the protocol, but this seems less likely - than mnesia. - -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/msg_per_sec.eps - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout - -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/ping.eps - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout - -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/msg_per_secoutput.eps - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout - -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Future improvements -\end_layout - -\begin_layout Standard -The specification of the GGS prototype is huge and like many other software - projects relying on outside technologies, in time it would require a lot - of maintenance. - Therefore there are a lot of areas in which the GGS could be improved such - as performance, compatibility, ease of setup and usage. -\end_layout - -\begin_layout Subsection -Performance -\end_layout - -\begin_layout Subsubsection -Protocols -\end_layout - -\begin_layout Standard -Because of TCP being a connection oriented protocol, it is not suited for - all types of game data transfers. - Each transmission will consume more network bandwidth than connectionless - protocols like UDP and cause unnecessary load on the processor. - Therefore support for UDP would mean that more games could be run simultaneousl -y on the GGS. - Another advantage of UDP is latency being reduced. - Without having to setup a connection for each group packets of data being - sent, they will be sent instantly and therefore arrive earlier. - Latency is of highest importance in real-time games as it improves realism - and fairness in gameplay and many game developers requires the freedom - to take care of safety issues as packet losses themselves. - This concludes that UDP would be a benefit for the GGS, game developers - and players alike. -\end_layout - -\begin_layout Subsubsection -Database -\end_layout - -\begin_layout Standard -Currently Mnesia is used for game data storage. - During stress tests, Mnesia has turned out to be the bottleneck due to - data losses when too many games are played on the GGS simultaneously. - This could be prevented by replacing Mnesia with another database management - system or use Mnesia in combination with the ETS module of erlang. - ETS provides fast access to the RAM and thus Mnesia could be used less - frequently. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{ETS}}{Erlang Term Storage} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Compatibility -\end_layout - -\begin_layout Standard -GGS relies on modern technologies. - This includes the virtual machines(VM) that the GGS uses for communication - between Erlang and the GDL:s. - These specific VM:s are crucial for game developers to be able to write - games in other languages than Erlang. - Therefore it would be best for the GGS to have as many of these VM:s implemente -d as possible. - The VM:s taken into consideration so far have been unstable or incomplete - and it is possible to search for more VM:s, testing them and integrate - them into the GGS prototype. -\end_layout - -\begin_layout Subsection -Setup -\end_layout - -\begin_layout Standard -The GGS prototype installation procedure requires different configuration - and building steps and thus it is not in an acceptable release state. - An executable installation file for each supported platform would be optimal. -\end_layout - -\begin_layout Subsection* -5.3.4 Usage -\end_layout - -\begin_layout Subsubsection -Programming languages -\end_layout - -\begin_layout Standard -The GGS does not support many programming languages. - For a programming language to be compatible with the GGS, not only does - it require a VM for that specific language, but the VM must have the ability - to communicate to Erlang. - More research is needed to find VM:s with this built in functionality. - -\end_layout - -\begin_layout Subsubsection -Documentation -\end_layout - -\begin_layout Standard -To start the GGS is not self explanatory. - This together with overall usage of GGS should be documented. - The interface for usage of game developers is also in need of documentation. - Features and requirements with respect to the GGS would assist users to - know what they need in order to use the GGS and how they would benefit - of it. - The GGS does not support many programming languages nor does it have a - complete documentation. - This needs to be taken care of in future versions. -\end_layout - -\begin_layout Chapter -Conclusion -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -addcontentsline{toc}{section}{Glossary} -\end_layout - -\begin_layout Plain Layout - - -\backslash -printnomenclature -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard - -\end_layout - -\begin_layout Standard -\begin_inset CommandInset bibtex -LatexCommand bibtex -bibfiles "bibliography" -options "plainnat" - -\end_inset - - -\end_layout - -\end_body -\end_document diff --git a/not-working.lyx b/not-working.lyx deleted file mode 100644 index 579d6b8..0000000 --- a/not-working.lyx +++ /dev/null @@ -1,7817 +0,0 @@ -#LyX 2.0 created this file. For more info see http://www.lyx.org/ -\lyxformat 413 -\begin_document -\begin_header -\textclass report -\begin_preamble -\usepackage{indentfirst} -\usepackage{tocloft} -\usepackage{calc} -\date{} -\usepackage[section] {placeins} -\def\myClearpage{% - \ifvmode - \ifnum \@dbltopnum =\m@ne - \ifdim \pagetotal <\topskip - \hbox{}% - \fi - \fi - \fi -% \newpage - \write\m@ne{}% - \vbox{}% - \penalty -\@Mi -} -\def\myCleardoublepage{\myClearpage\if@twoside \ifodd\c@page\else - \hbox{}\if@twocolumn\hbox{}\fi\fi\fi} -\usepackage{morefloats} -\usepackage{graphicx} -\usepackage{subfig} -\usepackage{tocloft} -\renewcommand{\cftchapfont}{\bfseries} -\renewcommand{\cftchappagefont}{\bfseries} -\renewcommand{\cftchappresnum}{Chapter } -\renewcommand{\cftchapnumwidth}{6em} - -\oddsidemargin 0.5in -\textwidth 6in -\topmargin 0.0in -\textheight 8.0in -\setlength\topskip{24pt} -\footskip 0.75in - -\usepackage[compact]{titlesec} - - -\titleformat{\chapter}[display] -{\vskip-8em\normalfont\bfseries} -{\LARGE\raggedright\thechapter} -{14ex} -{\vspace{-20ex}% -\LARGE\raggedleft} -[\vspace{1ex}% -{\titlerule[1pt]}] - -\usepackage[absolute]{textpos} - -\usepackage{fancyheadings} -\pagestyle{fancy} -\lhead{\thechapter} - -\usepackage[hmargin=3cm,vmargin=3.5cm]{geometry} -\usepackage{algorithmic} -\usepackage{listings} - -\usepackage{color} -\definecolor{lightgray}{rgb}{.9,.9,.9} -\definecolor{darkgray}{rgb}{.4,.4,.4} -\definecolor{purple}{rgb}{0.65, 0.12, 0.82} - -\lstdefinelanguage{JavaScript}{ - keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break}, - keywordstyle=\color{blue}\bfseries, - ndkeywords={class, export, boolean, throw, implements, import, this}, - ndkeywordstyle=\color{darkgray}\bfseries, - identifierstyle=\color{black}, - sensitive=false, - comment=[l]{//}, - morecomment=[s]{/*}{*/}, - commentstyle=\color{purple}\ttfamily, - stringstyle=\color{red}\ttfamily, - morestring=[b]', - morestring=[b]" -} - -\lstdefinelanguage{Erlang}{ - keywords={typeof, true, false, catch, return, null, catch, switch, var, if, in, while, do, else, case, break, expose}, - keywordstyle=\color{blue}\bfseries, - ndkeywords={class, export, boolean, throw, implements, import, this,erlv8_vm, erlv8_fun_invocation -,erlv8_object}, - ndkeywordstyle=\color{darkgray}\bfseries, - identifierstyle=\color{black}, - sensitive=false, - comment=[l]{\%}, - morecomment=[s]{/*}{*/}, - commentstyle=\color{purple}\ttfamily, - stringstyle=\color{red}\ttfamily, - morestring=[b]', - morestring=[b]" -} - -\usepackage{float} - -\floatstyle{ruled} -\newfloat{code}{thp}{lop} -\floatname{code}{Code} - -\usepackage{nomencl} -\makenomenclature -\renewcommand{\nomname}{Glossary} -\end_preamble -\use_default_options true -\maintain_unincluded_children false -\language english -\language_package default -\inputencoding auto -\fontencoding global -\font_roman lmodern -\font_sans default -\font_typewriter default -\font_default_family rmdefault -\use_non_tex_fonts false -\font_sc false -\font_osf false -\font_sf_scale 100 -\font_tt_scale 100 - -\graphics default -\default_output_format default -\output_sync 0 -\bibtex_command default -\index_command default -\paperfontsize default -\spacing onehalf -\use_hyperref false -\papersize a4paper -\use_geometry false -\use_amsmath 1 -\use_esint 1 -\use_mhchem 1 -\use_mathdots 1 -\cite_engine natbib_authoryear -\use_bibtopic false -\use_indices false -\paperorientation portrait -\suppress_date false -\use_refstyle 0 -\index Index -\shortcut idx -\color #008000 -\end_index -\paperwidth 11in -\paperheight 8.5in -\leftmargin 1.25in -\topmargin 0in -\rightmargin 1in -\bottommargin 1.7in -\secnumdepth 2 -\tocdepth 2 -\paragraph_separation indent -\paragraph_indentation default -\quotes_language english -\papercolumns 1 -\papersides 1 -\paperpagestyle empty -\tracking_changes false -\output_changes false -\html_math_output 0 -\html_css_as_file 0 -\html_be_strict false -\end_header - -\begin_body - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{textblock*}{ -\backslash -paperwidth}(0mm,40mm) -\end_layout - -\begin_layout Plain Layout - - -\backslash -begin{center} -\end_layout - -\begin_layout Plain Layout - - -\backslash -includegraphics[width= -\backslash -paperwidth/2]{graphics/logo} -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{center} -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{textblock*} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Title -A Reliable Generic Game Server -\end_layout - -\begin_layout Author -Niklas Landin -\begin_inset Newline newline -\end_inset - -Richard Pannek -\begin_inset Newline newline -\end_inset - -Mattias Pettersson -\begin_inset Newline newline -\end_inset - -Jonatan Pålsson -\end_layout - -\begin_layout Abstract -This is the abstract! -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -pagenumbering{roman} -\end_layout - -\begin_layout Plain Layout - - -\backslash -setcounter{page}{3} -\end_layout - -\begin_layout Plain Layout - - -\backslash -renewcommand -\backslash -contentsname{Table of Contents} -\end_layout - -\begin_layout Plain Layout - - -\backslash -renewcommand{ -\backslash -cfttoctitlefont}{ -\backslash -hfill -\backslash -Large} -\backslash -renewcommand{ -\backslash -cftaftertoctitle}{ -\backslash -hfill} -\end_layout - -\begin_layout Plain Layout - - -\backslash -renewcommand -\backslash -cftpartdotsep{6.6} -\end_layout - -\begin_layout Plain Layout - - -\backslash -renewcommand -\backslash -cftchapdotsep{6.6} -\end_layout - -\end_inset - - -\begin_inset CommandInset toc -LatexCommand tableofcontents - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Newpage newpage -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -pagenumbering{arabic} -\end_layout - -\begin_layout Plain Layout - - -\backslash -setcounter{page}{1} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Chapter -Introduction -\end_layout - -\begin_layout Standard -Online gaming, and computer gaming in general has become an important part - in many peoples day-to day lives. - A few years ago, computer games were not at all as popular as they are - today. - With the advances in computer graphics and computer hardware today's games - are much more sophisticated then they were in the days of -\emph on -NetHack -\emph default -, -\emph on -Zork, -\emph default -or -\emph on -Pacman. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Zork}}{A textual computer game developed by students at MIT} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Pacman}}{An early graphical computer game developed by Namco} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{NetHack}}{An early computer game developed by the NetHack team, arguably - the oldest computer game still in development} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The early computer games featured simple, or no graphics at all -\begin_inset CommandInset citation -LatexCommand citet -key "nethack:website" - -\end_inset - -. - The games often took place in a textual world, leaving the task of picturing - the world up to the player. - Multi-player games were not as common as they are today, whereas most games - today are expected to have a multi-player mode, most early games did not. -\end_layout - -\begin_layout Standard -Since these early games, the gaming industry have become much more influential - in many ways. - Many advanced in computer hardware are thought to come from pressure from - the computer game industry. - More powerful games require more powerful, and more easily available hardware -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Drop a reference to the gaming industry pressuring more advanced hardware -\end_layout - -\end_inset - -. - Due to the high entertainment value of modern computer games, gaming has - become a huge industry, where large amounts of money are invested. - The gaming industry is today, in some places even larger than the motion - picture industry. - -\begin_inset CommandInset citation -LatexCommand citet -key "esa:website,thenumbers:website" - -\end_inset - - -\end_layout - -\begin_layout Standard -Due to the increasing importance of computer gaming, more focus should be - spent on improving the quality of the gaming service. - As more and more computer games are gaining multi-player capabilities, - the demands for multiplayer networking software rises. - This thesis is about techniques for improving the quality of this networking - software. -\end_layout - -\begin_layout Standard -The reliable generic game server, hereafter known as GGS -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{GGS}}{Generic Game Server, a software for reliably hosting network - games. - The subject of this thesis.} -\end_layout - -\end_inset - -, is a computer program designed to -\emph on -host -\emph default - network games on one or more server computers. - Hosting, in a network software setting, means allowing client software - connect to the server software, for the purpose of utilizing services provided - by the server. - The GGS software provides games as a service, and the clients connecting - to the GGS can play these games on the GGS. -\end_layout - -\begin_layout Standard -The idea of game servers is not new, network games have been played for - decades. - Early, popular examples of network games include the -\emph on -Quake -\emph default - series, or the -\emph on -Doom -\begin_inset Note Note -status collapsed - -\begin_layout Plain Layout - -\emph on -Come up w/ better game -\end_layout - -\end_inset - - -\emph default - games. - Newer examples of network games include -\emph on -World of Warcraft -\emph default -, and -\emph on -Counter-Strike -\emph default -. - The difference between the GGS and the servers for these games is that - the servers for Doom, Quake, and the others listed, were designed with - these specific games in mind. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Quake}}{A first person shooter series developed by ID software. - The series consists of four games.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Doom}}{A first person shooter series developed by ID software. - The series consists of three games.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{World of Warcraft}}{A MMORPG game developed by Blizzard. - The world's most popular MMORPG by subscriber count.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Counter-Strike}}{A multiplayer first person shooter game, popular - in E-Sports.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Framework}}{A supporting structure, the GGS is a framework for developing - network games} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{First-person shooter}}{A game in which centers around gun combat - from the first person perspective.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{MMORPG}}{Massively multiplayer online role playing game. - An online game with several thousand participants.} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -What GGS does is to provide a -\emph on -generic -\emph default - framework for developing network games. - The framework is generic in the sense that it is not bound to a specific - game. - There are many different types of games, some are inherently more time - sensitive than others, strategy games are examples of games which are not - very sensitive to time delays, first-person shooters however, can be very - sensitive. -\end_layout - -\begin_layout Standard -The generic nature of the GGS allows the creation of many different types - of games, the motivation behind this is to remove the necessity of writing - new game servers when developing new games. -\end_layout - -\begin_layout Standard -The GGS is in addition to being generic, also -\emph on -reliable -\emph default - in the sense that the gaming service provided is consistent and available. - A consistent and available server is a server that handles hardware failures - and software failures gracefully. - In the event of a component breaking within the GGS, the error is handled - by fault recovery processes, thereby creating a more reliable system. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Hardware failiure}}{A failiure in hardware (hard drive, memory, processor -, etc) which causes a system to stop functioning} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Software failiure}}{A failiure in software (the GGS, the operating - system, etc) which causes a system to stop functioning} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Background -\end_layout - -\begin_layout Standard -The game industry is a quickly growing industry where the need for new technique -s are large. - One specific section where the development has stalled is the game server - section. -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Citation needed -\end_layout - -\end_inset - - The existing game servers are functional but they lack good fault tolerance - and the ability to scale well -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Citation needed -\end_layout - -\end_inset - -. - Users will notice this in low uptime and many crashes. - This is a problem that has existed and been resolved in other industries. - In the telecom industry solutions to similar problems have been found. -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{The nine nines}}{A common goal for availability in the telecom business. - A system with nine nines of availability is available 99.999999999% of the - time} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Downtime}}{The amount of time a system is unavailable and does not - function} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Uptime}}{The amount of time a system is available and functions} -\end_layout - -\end_inset - -A common figure often used in telecoms is that of -\emph on -the nine nines -\emph default -, referring to -\begin_inset Formula $99.999999999\%$ -\end_inset - - of availability, or rougly -\begin_inset Formula $15ms$ -\end_inset - - downtime in a year -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Citation needed -\end_layout - -\end_inset - -. - The level of instability and bad fault tolerance seen in the game server - industry would not have been accepted in the telecoms industry. - This level of instability should not be accepted in the game server industry - either. - An unavailabvle phone system could potentially have life threatening consequenc -es, leaving the public unable to contant emergency services. - The same can not be said about an unavailable game server. - The statement that game servers are less important than phone systems is - not a reason not to draw wisdom from what the telecoms have already learnt. -\end_layout - -\begin_layout Standard -Moving back to the gaming industry. - The main reason to develop reliable servers are monetary, it is important - for game companies to expand its customer base. - Reliable game servers are one improvement that will create a good image - of a company. - In general the downtime of game servers is much higher than the downtime - of telecom system -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Citation needed... -\end_layout - -\end_inset - -. - The structure of the system is similar in many ways and it should be possible - to reuse solutions from the telecom system to improve game servers. - -\end_layout - -\begin_layout Standard -In the current state game servers are developed on a per-game basis, in - many cases this seems like a bad solution. - Developers of network game need to understand network programming. - A way to change this is a generic game server which give the game developers - a server which they implement their game towards. - This approach would not only make it easier to develop network games, it - would also allow games in different programming languages to be implemented - using the same server. -\end_layout - -\begin_layout Standard -Some factors key to the development of GGS have been isolated. - Many of these come from the telecom sector. - The factors are -\emph on -scalability, fault tolerance -\emph default -and being -\emph on -generic -\emph default -. - These terms are defined below. -\end_layout - -\begin_layout Standard -Scalability (see -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Scalability" - -\end_inset - -) in computer science is a large topic and is commonly divided into sub-fields, - two of which are -\emph on -structural scalability -\emph default - and -\emph on -load scalability -\emph default - -\begin_inset CommandInset citation -LatexCommand citet -key "Bondi:2000:CSI:350391.350432" - -\end_inset - -. - These two issues are addressed in this thesis. - Structural scalability means expanding an architecture, e.g. - adding nodes to a system without requiring modification of the system. - Load scalability means using the available resources in a way which allows - handling increasing load, e.g more users, gracefully. -\end_layout - -\begin_layout Standard -Fault tolerance (see -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Fault-Tolerance" - -\end_inset - -) is used to raise the level of -\emph on -dependability -\emph default - in a system, so that the dependability is high even in presence of errors. - Dependability is defined as the statistical probability of the system functioni -ng as intended at a given point in time. - Fault tolerance is defined as the property of a system to always follow - a specification, even in the presence of errors. - The specification could take the form of error handling procedures which - activate when an error occurs. - This means that a fault tolerant, dependable system, will have a very high - probability of functioning at a given point in time, and is exactly what - is desired. - -\begin_inset CommandInset citation -LatexCommand citet -key "Gartner:1999:FFD:311531.311532" - -\end_inset - - -\end_layout - -\begin_layout Standard -A generic (see -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Generic" - -\end_inset - -) game server has to be able to run different client-server network games - regardless of the platform the clients are running on. - It runs network games of different type. - A very rough separation of games is real time games and turn based games. -\end_layout - -\begin_layout Standard -The server behaves in a way similar to an application server, but is designed - to help running games. - An application server provides processing ability and time, therefore it - is different from a file- or print-server, which only serves resources - to the clients. -\end_layout - -\begin_layout Standard -The most common type of application servers are web servers, where you run - a web application within the server. - The application server provides an environment and interfaces to the outer - world, in which applications run. - Hooks and helpers are provided to use the resources of the server. - Some examples for web application servers are the -\emph on -Glassfish -\emph default - server which allows running applications written in Java or the -\emph on -Google App Engine -\emph default - where you can run applications written in Python or some language which - runs in the -\emph on -Java Virtual Machine -\emph default -. - An example of an application server not powering web applications, but - instead regular business logic, is Oracle’s -\emph on -TUXEDO -\emph default - application server, which can be used to run applications written in COBOL, - C++ and other languages. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{SQL}}{Structured Query Language, a computer language common in querying - certain databases} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{JavaScript}}{A programming language originally developed by Netscape, - common in web programming} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{COBOL}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{C++}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Java}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{AXD301}}{Telephone switch developed by Ericsson} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Erlang}}{A concurrent programming language, often used for telecom - applications. - The main language of the GGS} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -A database server can also be seen as an application server. - Scripts, for example SQL queries or JavaScript, are sent to the server, - which runs them and returns the evaluated data to the clients. - -\end_layout - -\begin_layout Standard -One purpose of this thesis is to investigate how we can make a game server - as generic as possible. - Some important helpers are discussed, such as abstraction of the network - layer, data store and game specific features. - -\end_layout - -\begin_layout Standard -As an aid in discussing the theoretical parts of the GGS a prototype has - been developed. - The prototype does not feature all of the characteristics described in - this thesis. - A selection has been made among the features, and the most important ones - have been implemented either full or in part in the prototype. -\end_layout - -\begin_layout Standard -The choice of implementation language for the prototype of the GGS was made - with inspiration from the telecom industry. - The Erlang language was developed by the telecom company Ericsson to develop - highly available and dependable telecom switches. - One of the most reliable systems ever developed by Ericsson, the AXD301 - was developed using Erlang. - The AXD301 is also possibly has the largest code base even written in a - functional language -\begin_inset CommandInset citation -LatexCommand citep -key "Armstrong03" - -\end_inset - -. - The same language is used to develop the prototype of the GGS. - Usage of Erlang in the GGS is discussed in further detail in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:The-usage-of-erlang" - -\end_inset - -. - Chapter -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Implementation-of-a" - -\end_inset - - provides a description of the prototype developed for this thesis. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -We could go on and on about erlang.. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Purpose -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status collapsed - -\begin_layout Plain Layout -The purpose of the GGS project. - What is the purpose of creating a fault tolerant server, why is it generic, - and what good does it do to have a scalable system? In the background, - we should give the motivations behind creating this software, but here - we should outline why the software is needed. - This section should be shortened, and the bulk of the text should be moved - to theory or background. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The purpose of creating a generic and fault tolerant game server is to provide - a good framework for the development of many different types of games. - Allowing the system to scale up and down is a powerful way to maximize - the usage of physical resources. - By scaling up to new machines when load increases, and scaling down from - machines when load decreases costs and energy consumption can be optimized. -\end_layout - -\begin_layout Standard -Fault tolerance is important for the GGS to create a reliable service. - The purpose of a reliable game server is to provide a consistent service - to people using the server. - Going back to the telecom example, the purpose of creating a reliable telecom - system is to allow calls, possibly emergency calls, at any time. - Should the telecom network be unavailable at any time, emergency services - may become unavailable, furthermore the consumer image of the telecom system - degrades. -\end_layout - -\begin_layout Standard -Returning to the game industry, emergency services will not be contacted - using a game server, however an unavailable server will degrade the consumer - image of the system. - Consider an online casino company. - The online casino company's servers must be available at all times to allow - customers to play. - If the servers are unavailable, customers can not play, and the company - loses money. - In this scenario, an unavailable server can be compared to a closed real-world - casino. -\end_layout - -\begin_layout Section -Challenges in developing the prototype -\end_layout - -\begin_layout Standard -The word -\emph on -generic -\emph default - in the name of the GGS implies that the system is able to run a very broad - range of different code, for instance code wrote in different programming - languages, besides a broad range of different game types. - To support this, a virtual machine (VM) for each -\emph on -game development language -\emph default - (hereafter GDL for brevity) is used. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{GDL}}{Game Development Language, the language used to program games - in the GGS} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{VM}}{Virtual Machine} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -No hard limit has been set on which languages can be used for game development - on the GGS, but there are several factors which decide the feasibility - of a language: -\end_layout - -\begin_layout Itemize -How well it integrates with Erlang, which is used in the core the GGS system - -\end_layout - -\begin_layout Itemize -How easy it is to send messages to the virtual machine of the GDL from the - GGS -\end_layout - -\begin_layout Itemize -How easy it is to send messages from the GDL VM to the GGS -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Add more like threads, events, etc. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Internally, the GDL VM needs to interface with the GGS to make use of the - helpers and tools that the GGS provides. - Thus an internal API has to be designed for use in interacting with the - GGS. - This API is ideally completely independent of the GDL, and reusable for - any GDL. -\end_layout - -\begin_layout Standard -The communication with gaming clients has to take place over a protocol. - Ideally a standard protocol should be used, in order to shorten the learning - curve for developers, and also make the system as a whole less obscure. - A large challenge during this project is to decide whether an existing - protocol can be used, and if not, how a new protocol can be designed which - performs technically as desired, while still being familiar enough to existing - developers. -\end_layout - -\begin_layout Standard -A great deal of work is devoted to make the GGS -\emph on -reliable -\emph default -. - This includes ensuring that the system scales well, and to make sure it - is fault tolerant. - In order to facilitate scalability, we need a storage platform which is - accessible and consistent among all of the GGS, this is also investigated. -\end_layout - -\begin_layout Section -Limitations of the prototype -\end_layout - -\begin_layout Standard -The implementation of the GGS protocol, together with storage possibilities, - server capacity, and game language support imposes some limitations on - the project. - To get a functional prototype some limits must be set on the types games - that can be played on the prototype. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{UDP}}{User Datagram Protocol, a connectionless networking protocol} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{TCP}}{Transmission Control Protocol, a streaming network protocol} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The UDP protocol is not supported for communication between client and server. - The TCP protocol was chosen in favour of UDP, due to the fact that the - implementation process using TCP was faster than if UDP would have been - used. - UDP is generally considered to be faster than TCP for the transfer of game - (and other) related data, this is discussed in more depth in -\begin_inset CommandInset ref -LatexCommand vref -reference "sec:Choice-of-network" - -\end_inset - -. - In short, the decision of using TCP means that games that requires a high - speed protocol will not be supported by the GGS prototype. - Another limitation necessary to set on the system is the possibility to - have huge game worlds due to the implementation of the scaling mechanism - in the prototype. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Latency}}{A measure of delay, often measured in milliseconds} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -In real time games all players are playing together at the same time. - Latency is a huge problem in real time games, a typical round trip time - for such games are one of -\begin_inset Formula $50$ -\end_inset - - to -\begin_inset Formula $150ms$ -\end_inset - - and everything above -\begin_inset Formula $200ms$ -\end_inset - - is reported to be intolerable -\begin_inset CommandInset citation -LatexCommand citet -key "Farber:2002:NGT:566500.566508" - -\end_inset - -. - Latency sensitive games include most of the first person shooters with - multiplayer ability, for example -\emph on -Counter Strike -\emph default - or massively multiplayer online role playing games (MMORPG:s), for example - -\emph on -World of Warcraft -\emph default -. -\end_layout - -\begin_layout Standard -In turn based games each player has to wait for their turn. - Latency is not a problem since the gameplay does not require fast interactions - among the players, long round trip times will not be noticed. - Examples of turn based games include board and card games, as well as multiplay -er games like -\emph on -Jeopardy -\emph default -. - Both game types have varying difficulties and needs when it comes to implementi -ng them, a Generic Game Server should address all of them and help the developer - to accomplish his goal. -\end_layout - -\begin_layout Standard -Due to the limited capability of threading in many GDL VM:s, the GGS prototype - will not support MMORPG:s. -\end_layout - -\begin_layout Standard -The implementation of the GGS described in this thesis is only a small prototype - and tests will be performed on simple games like pong or chess, thus there - are no need to implement more advanced features in the system. - Note that these limitations only apply for the prototype of the project, - and that further developments to the GGS could be to implement these features. -\end_layout - -\begin_layout Section -Method -\end_layout - -\begin_layout Standard -A prototype was developed early on in the project to carry out experiments. - Using this prototype, the system was divided into modules. - A demand specification was created, using this specification, the modules - were easily identifiable. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Module}}{A part of a larger system} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The first prototype of the GGS consisted of simple modules, however, due - to the separation of concerns among the modules, they were easily independently - modified and improved. -\end_layout - -\begin_layout Standard -Once the basic structure of the GGS had been established, the first prototype - was removed, remaining was the structure of the modules and the internal - flow of the application. - This could be seen as an interative workflow, with the first prototype - being the first iteration. - The second iteration later became the final result of the GGS. -\end_layout - -\begin_layout Standard -The layout of the GGS is both layered and modular. - The first layer handles the most primitive data and produces a higher level - representation of the data, passing it along to different modules of the - GGS. - The modular structure of the GGS plays an important role in making the - system fault tolerant. - The approach to fault tolerance is by replication, and restarting the faulting - modules with the last known good data. -\end_layout - -\begin_layout Standard -An informal specification and list of requirements of the system was outlined - early on in the project. - Usaility goals for developers were set. - During the project several demo applications were constructed, by constructing - these applications, the usability goals were enforced. -\end_layout - -\begin_layout Chapter -Theory behind the GGS -\begin_inset CommandInset label -LatexCommand label -name "cha:Theory" - -\end_inset - - -\end_layout - -\begin_layout Standard -In this chapter, the theory behind the techniques used in the GGS are discussed. - Performance issues and the measuring of performance is discussed. - Benchmarking techniques are discussed. - The options when choosing network protocols are given, along with a discussion - of each alternative. - Finally, an overview of scalability, fault tolerance and availability are - presented. -\end_layout - -\begin_layout Section -Design of the GGS system -\begin_inset CommandInset label -LatexCommand label -name "sec:Design-of-the" - -\end_inset - - -\end_layout - -\begin_layout Standard -The GGS is modeled after a real world system performing much of the same - duties as GGS. - This is common practice -\begin_inset CommandInset citation -LatexCommand citep -key "armstrong2011" - -\end_inset - - in the computer software world, to understand complex problems more easily. - While there may not always be a real world example of a system performing - the exact duties of the system being modeled in the computer, it is often - easier to create and analyze requirements for real world systems and processes - than systems existing solely in a computer. - The requirements and limitations imposed on the real-world system can, - using the proper tools, be transferred in to the software. -\end_layout - -\begin_layout Standard -The real world system chosen for the GGS is a -\begin_inset Quotes eld -\end_inset - -Chess club -\begin_inset Quotes erd -\end_inset - - - a building where chess players can meet and play chess. - Since a real-world scenario is readily available, and to such a large extent - resembles the computer software required for the GGS, the next step in - developing the GGS system is to duplicate this real world scenario in a - software setting. -\end_layout - -\begin_layout Standard -Some requirements, limitations and additions were made to the chess club - system, so that the system would more easily and efficiently be replicated - in a software setting. -\end_layout - -\begin_layout Standard -In the text below, two examples will be presented. - On example is that of a real-world chess club, in which players meet to - play chess against each other, the other example is the GGS, and how it - corresponds to this chess club. - -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/theory_layout.eps - scale 40 - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "fig:theory-layout" - -\end_inset - -The layout of a physical -\begin_inset Quotes eld -\end_inset - -Chess club -\begin_inset Quotes erd -\end_inset - - with two players (P) sitting by each chess table (Table), a coordinator - keeps track of all moves and players in the building. - A player has to pass by the entrance to enter or exit the building. - The building is represented by the outermost box. -\end_layout - -\end_inset - - -\end_layout - -\end_inset - -In figure -\begin_inset CommandInset ref -LatexCommand vref -reference "fig:theory-layout" - -\end_inset - - a graphical representation for the chess club is presented. - The club is seen from above. - The outermost box represents the building. - In the GGS setting, the building would represent one instance of GGS. - Several buildings linked together would represent a cluster of GGS instances. - In order for a player (the P symbol in the graphic) to enter the theoretical - chess club, the player must pass by the entrance. - By having each player pass by the entrance, a tally -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Does this mean what I think it does? -\begin_inset Quotes eld -\end_inset - -Räkning -\begin_inset Quotes erd -\end_inset - - ? -\end_layout - -\end_inset - - can be kept, ensuring that there are not too many players within the building. - In the GGS setting, too many players entering would mean too many connections - have been accepted by the GGS system, and that the structure of the system - thus must be modified, adding additional servers. -\end_layout - -\begin_layout Standard -Once a player has been allowed in to the chess club the player is greeted - by the host of the chess club, in the GGS setting represented by the -\emph on -Coordinator -\emph default -, and is seated by a table. - The coordinator keeps track of all the players in the building, and all - moved made by the players. - The information available to the coordinator means that cheating can be - monitored and book keeping can be performed by this entity. -\end_layout - -\begin_layout Standard -Moves by players are made using the tables present in the chess club. - Every game is isolated to a table, just as expected. - This means that communication during a game only has to pass by the players - of that particular game, and the coordinator, making sure that no cheating - takes place. -\end_layout - -\begin_layout Standard -This isolation of the games play an important part in many properties of - the GGS, the isolation means that games can for example be transferred - among different chess clubs, furthermore, if cheating takes place, corruption - can only occur in the particular table where it was found, and can not - spread. -\end_layout - -\begin_layout Standard -Moving chess players from one location to another is one alteration made - to the real world chess club system to make the system more appropriate - for a software setting. - Allowing games to be transferred is not a property usually desired in a - real world chess club, where transferring players would mean moving the - players from one building to another. - In the software setting, moving players means moving the game processes - from one system to another, perhaps to balance the system load. - This transfer of players can occur transparently, without notifying the - players. -\end_layout - -\begin_layout Standard -The simplified life cycle of a game in GGS can be viewed using algorithm - -\begin_inset CommandInset ref -LatexCommand vref -reference "alg:game-lifecycle" - -\end_inset - -. - To make this life cycle as efficient and useful as possible, the scalability, - fault tolerant and generic traits are added to the GGS. - These are not shown in the algorithm, as these traits are tools in making - the algorithm behaves as efficient as possible, and are not the main focus - when studying the life cycle of a game. -\end_layout - -\begin_layout Standard -The limits imposed in -\begin_inset CommandInset ref -LatexCommand vref -reference "alg:game-lifecycle" - -\end_inset - - are arbitrary for this example, there are no limits in the GGS on the number - of players connecting, for example. -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{algorithmic}[1] -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -newcommand{ -\backslash -INDSTATE}[1][1]{ -\backslash -STATE -\backslash -hspace{#1 -\backslash -algorithmicindent}} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -while -\series default - -\begin_inset Formula $players<2$ -\end_inset - -: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - -\series bold -if -\series default - a player connects, call -\emph on -connected -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -while -\series default -the game commences: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -call the function -\emph on -game -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -when -\series default - the game has stopped -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -call the function -\emph on -endGame -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -function -\series default -connected: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -assign the new player an id -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -alert the coordinator of the new player -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - -\series bold -if -\series default - a free table does not exist: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE[2] -\end_layout - -\end_inset - -the coordinator creates a new table -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -the coordinator places the player by the table, and begins watching the - player -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -function -\series default - game -\series bold -: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - perform game-specific functions. - In chess, the rules of chess are placed here -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -function -\series default -endGame: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -alert the coordinator, de-registering the players -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -disconnect the players from the system, freeing system resources -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{algorithmic} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:game-lifecycle" - -\end_inset - -A very simple example of the flow through the GGS system when a game played. -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Performance -\end_layout - -\begin_layout Standard -There are many ways in which performance could be measured. - For the clients, time and response times are useful measurements in time - critical settings. - In non-time critical settings, the reliability of message delivery may - be an even more important factor than speed. -\end_layout - -\begin_layout Standard -In a first person shooter game, the speed of delivery of messages is essential. - Failure to deliver messages in time results in choppy gameplay for the - players. - In strategy games, the reliability of delivery may be more important than - the speed, since the game is not perceieved as choppy even if the messages - are delayed. -\end_layout - -\begin_layout Standard -For someone operating a GGS, it is perhaps more interesting to measure the - system load, memory consumption, energy consumption and network saturation. - These topics are discussed in theory in this section. - The practical results for the prototype is discussed in chapter -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Implementation-of-a" - -\end_inset - -. -\end_layout - -\begin_layout Subsection -Performance measurements -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Tue apr 26, 9:15. - Continue from here on. - Discuss which results we may expect in a fully fledged GGS system. - What impedes the speeds, what raises the CPU load (and therefore the temperetur -es & power consumption). - What factors are there in the network saturation problem? -\end_layout - -\begin_layout Plain Layout -Which games are affected by what, and what does this mean for the number - of players a GGS can handle? -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -How many players can we have on a server? Performance differences between - games? e.g can one game have thousands players on a server and another only - have hundreds? Questions -\end_layout - -\begin_layout Standard -In the current state game servers is coded for each game that needs it, - in many cases this seems like a bad solution. - Developers that want to make a network game need to understand network - programming. - A way to change this is a generic game server which give the game developers - a server which they implement their game towards. - This approach would not only make it easier to develop network games, it - would also allow games in different programming languages to be implemented - using the same server. - to be discussed here. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Create a game with several thousand players, see how our server scales, - how can we improve the performance? Sharding isn’t very nice.. - alternatives? Improve the speed of sharding? -\end_layout - -\begin_layout Itemize -See how the server scales -\end_layout - -\begin_deeper -\begin_layout Itemize -When adding many clients -\end_layout - -\begin_deeper -\begin_layout Itemize -Measure in -\begin_inset Formula $ms$ -\end_inset - - (ping to clients) -\end_layout - -\begin_layout Itemize -measure in system load -\end_layout - -\begin_layout Itemize -Measure in loss of messages -\end_layout - -\begin_layout Itemize -Measure in # of timeouts? (if any??) -\end_layout - -\begin_layout Itemize -Measure in time-to-crash -\end_layout - -\end_deeper -\begin_layout Itemize -When adding new machines to the pool -\end_layout - -\begin_deeper -\begin_layout Itemize -% increase of performance per machine -\end_layout - -\end_deeper -\begin_layout Itemize -Single-core CPU vs multi-core CPU -\end_layout - -\begin_deeper -\begin_layout Itemize -It's very important to scale well on multi-core systems, since this is where - the industry is going. - Multicore is the future. -\end_layout - -\end_deeper -\end_deeper -\begin_layout Plain Layout -Find reference on how to benchmark distributed, multiprocess systems -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Choice of network protocol -\begin_inset CommandInset label -LatexCommand label -name "sec:Choice-of-network" - -\end_inset - - -\end_layout - -\begin_layout Standard -There are two main ways in which computer communication over the Internet - usually takes place; TCP, UDP are known network layer protocols and HTTP - is the most prominent application layer protocol. - The transport layer protocols, are commonly used to transport application - layer protocols, such as HTTP. - TCP and UDP can not be used on their own, without an application layer - protocol on top. - Application layer protocols such as HTTP on the other hand needs a transport - layer protocol in order to work. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{HTTP}}{Hyper Text Transport Protocol, a network protocol commonly - used to deliver web pages} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -HTTP -\end_layout - -\begin_layout Standard -Since HTTP is so widely used on the Internet today in web servers, it is - available on most Internet connected devices. - This means that if HTTP is used in the GGS, firewalls will not pose problems, - which is a great benefit. - However, due to the intended usage of HTTP in web servers, the protocol - was designed to be stateless and client-initiated. - In order to maintain a state during a game session using HTTP, some sort - of token would have to be passed between client and server at all times, - much like how a web server works. - These facts combined makes HTTP unsuitable for our purposes, since the - GGS requires a state to be maintained throughout a session, and also needs - to push data from the server to clients without the clients requesting - data. - It should also be mentioned that HTTP uses the TCP protocol for transport, - and what is said about TCP also applies to HTTP. - -\end_layout - -\begin_layout Subsection -UDP -\end_layout - -\begin_layout Standard -Many online games use UDP as the carrier for their application layer protocol. - UDP moves data across a network very quickly, however it does not ensure - that the data transferred arrives in consistent manner. - Data sent via UDP may be repeated, lost or out of order. - To ensure the data transferred is in good shape, some sort of error checking - mechanisms must be implemented. - UDP is a good choice for applications where it is more important that data - arrives in a timely manner than that all data arrives undamaged, it is - thus very suitable for media streaming, for example. - In the GGS reliability of transfer was chosen before the speed of the transfer, - ruling out UDP as the transport later protocol. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Perhaps we should only say that we chose TCP just for our GGS prototype - and why. - If we leave it like that it seems that we think it is not suitable. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -TCP -\end_layout - -\begin_layout Standard -For reliable transfers, TCP is often used on the Internet. - Built in to the protocol are the error checking and correction mechanisms - missing in UDP. - This ensures the consistency of data, but also makes the transfer slower - than if UDP had been used. - In the GGS, data consistency is more important than transfer speeds, and - thus TCP is a better alternative than UDP. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Same here it is simply not true for a generic server to chose one or the - other. - We should rephrase it so it is clear that we only state it about the GGS - prototype. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Generic -\begin_inset CommandInset label -LatexCommand label -name "sec:Generic" - -\end_inset - - -\end_layout - -\begin_layout Standard -The GGS is a game server. - It was made with a desire to be suitable for any kind of game. - Any game with a client-server behaviour should be perfectly suited for - GGS. - A game should not only be able to vary in terms of genre, graphics, gameplay - etc, but also in the way the game is implemented. - Such as different programming languages. - The GGS should be OS independent and run on Windows, OSX and Linux. - The GGS can be run as a listen server on the players computer and host - games locally. - It could also be a dedicated server running on independent hardware. - It is meant to run any game in any environment in any way desired, therefor - being as generic as possible. -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Bad name of the chapter, but here we should give the theory of how the server - is generic -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Fault Tolerance -\begin_inset CommandInset label -LatexCommand label -name "sec:Fault-Tolerance" - -\end_inset - - -\end_layout - -\begin_layout Standard -Fault tolerance is an important factor in all servers, a server that is - fault tolerant should be able to follow a given specification when parts - of the system failures. - This means that fault tolerance is different in each system depending on - what specification they have. - A system could be fault tolerant in different aspects, one is where the - system is guaranteed to be available but not safe and it could also be - reversed, that the system is safe but not guaranteed to be available. - Depending on the system one property may be more important(some example - here). - A system could also have non existent fault tolerance or it could be both - safe and guaranteed to be available. - It should be noted that it is not possible to achieve complete fault tolerance, - a system will always have a certain risk of failure. - With this in mind the goal is to make the GGS prototype as fault tolerant - as possible. -\end_layout - -\begin_layout Standard -In order to make the GGS prototype fault tolerant the programming language - Erlang has been used. - Erlang will not guarantee a fault tolerant system but it has features that - support and encourage the development of fault tolerant systems. - In the GGS it is important that the system overall is fault tolerant. - Crashes of the whole system should be avoided as this would make the system - unusable for a time. - By using supervisor structures it is possible to crash and restart small - parts of the system, this is convenient as fault can be handled within - small modules thus never forcing a crash of the system. -\end_layout - -\begin_layout Standard -The need for fault tolerance in game servers is not as obvious as it may - be for other typ of servers. - In general all servers strive to be fault tolerant as fault tolerance means - more uptime and a safer system. - This applies to game servers as well, in brief good fault tolerance is - a way of satisfying customers. - In general, game servers differ from many other fault tolerant systems - in that high-availability is more important than the safety of the system. - For example a simple calculation error will not be critical for a game - server but it may be in a life-critical system and then it is better that - the system crashes than works with the faulty data. - There are cases where safety may be critical in game servers, one example - is in games where in-game money exist. -\end_layout - -\begin_layout Subsubsection -Performance penalties -\end_layout - -\begin_layout Section -Availability -\begin_inset CommandInset label -LatexCommand label -name "sec:Availability" - -\end_inset - - -\end_layout - -\begin_layout Standard -One important factor of any server is the availability. - A server to which you are unable to connect to is an useless server. - Other then within telecommunication, their uptime is of about 99,9999999%, - the game developer community has not approached this problem very genuinely - yet so there is much room for improvement. -\end_layout - -\begin_layout Standard -There are several good papers on how to migrate whole virtual machines among - nodes to replicate them -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Add more information about that -\end_layout - -\end_inset - - but for the GGS a different approach has been chosen. - Instead of just duplicating a virtual machine, the programming language - Erlang has been used which offers several features to increase the availability. - Some of them are -\emph on -hot code replacement -\emph default -, where code can be updated while the application is running and without - the need to restart it, the -\emph on -supervisor structure -\emph default - provided by -\emph on -OTP -\emph default - and the inter node and process communication via -\emph on -messages -\emph default - instead of shared memory. - We will discuss each of them later on. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Supervisor}}{A process monitoring and hadning crashes in other processes} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Scalability -\begin_inset CommandInset label -LatexCommand label -name "sec:Scalability" - -\end_inset - - -\end_layout - -\begin_layout Standard -Each instance of the GGS contains several tables. - Each table is an isolated instance of a game, for example a chess game - or a poker game. - The way that the GGS scales is to distribute these tables on different - servers. - In many games it is not necessary for a player to move among tables during - games. - This is for example not a common occurrence in chess, where it would be - represented as a player standing up from her current table and sitting - down at a new table, all within the same game session. - Therefore, the main focus of the GGS is not to move players among tables, - but to keep a player in a table, and to start new tables instead. - When a server has reached a certain number of players the performance will - start to decrease. - To avoid this the GGS will start new tables on another server, using this - technique the players will be close to evenly distributed among the servers. - It is important to investigate and find out how many players that are optimal - for each server. - This approach makes it possible to use all resources with moderate load, - instead of having some resources with heavy load and some with almost no - load. -\end_layout - -\begin_layout Standard -As mentioned in the purpose section there are two different types of scalability -, structural scalability and load scalability. - To make the GGS scalable both types of scalability are needed. - Structural scalability means in our case that it should be possible to - add more servers to an existing cluster of servers. - By adding more servers the limits of how many users a system can have is - increased. - Load scalability in contrast to structural scalability is not about how - to increase the actual limits of the system. - Instead it means how good the system handles increased load. - The GGS should be able to scale well in both categories. -\end_layout - -\begin_layout Subsection -Load balancing -\end_layout - -\begin_layout Standard -The need for load balancing varies among different kind of systems. - Small systems that only use one or a couple of servers can cope with a - simple implementation of it, while in large systems it is critical to have - extensive and well working load balancing. - The need also depends on what kind of server structure that the system - works on. - A static structure where the number of servers are predefined or a dynamic - structure where the number varies. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Amazon EC2}}{A cloud computation service} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Load balancing and scaling is difficult in different scenarios. - When running in a separate server park, there are a set number of servers - available, this means that an even distribution on all servers is preferable. - When running the GGS in a cloud, such as Amazon EC2, it is possible to - add an almost infinite number of servers as execution goes on. - In this cloud setting, it may be more important to evenly distribute load - on newly added servers. -\end_layout - -\begin_layout Standard -Two methods of balancing load (increasing structure): -\end_layout - -\begin_layout Itemize -Fill up the capacity of one server completely, and then move over to the - next server -\end_layout - -\begin_layout Itemize -Evenly distribute all clients to all servers from the beginning, when load - becomes too high on all of them, then comes a new problem: -\end_layout - -\begin_deeper -\begin_layout Itemize -How do we distribute load on these new servers? -\end_layout - -\end_deeper -\begin_layout Standard -Load balancing is a key component to achieve scalability in network systems. - The GGS is a good example of a system that needs to be scalable, to attain - this load balancing is necessary. - Optimization of the load balancing for a system is an important task to - provide a stable and fast load balancer. - There are certain persistence problems that can occur with load balancing, - if a player moves from a server to another data loss may occur. - This is an important aspect to consider when the load balancer is designed - and implemented. -\end_layout - -\begin_layout Standard -Load balancing can often be implemented using dedicated software, this means - that in many applications load balancing may not be implemented because - it already exist functional solutions. - This depends on what specific needs the system have and a minor goal of - the project is to analyze whether the GGS project can use existing load - balancing tools or if it is necessary to implement load balancing in the - project. -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Because P2P game architectures are a constant goal for cheaters and because - “Cheating is a major concern in network games as it degrades the experience - of the majority of players who are honest” and preventing cheating in P2P - game architectures is very difficult game developers try to use Client - - Server architectures which have a natural problem to scale. - In this paper we want to show some strategies to achieve scalability. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -UUID -\begin_inset CommandInset label -LatexCommand label -name "sub:UUID" - -\end_inset - - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{UUID}}{Universally Unique Identifier} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{algorithmic}[1] -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -newcommand{ -\backslash -INDSTATE}[1][1]{ -\backslash -STATE -\backslash -hspace{#1 -\backslash -algorithmicindent}} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - -global variable -\begin_inset Formula $state:=0$ -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -function -\series default -unique -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - -\begin_inset Formula $state:=state+1$ -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - -\series bold -return -\begin_inset Formula $state$ -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{algorithmic} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:A-simple-generator" - -\end_inset - -A simple (insufficient) generator for identifiers -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Inside the GGS, everything has a unique identifier. - There are identifiers for players, tables and other resources. - When players communicate amongst each other, or communicate with tables, - they need to be able to uniquely identify all of these resources. - Within one machine, this is mostly not a problem. - A simple system with a counter can be imagined, where each request for - a new ID increments the previous identifier and returns the new identifier - based off the old one, see algorithm -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-simple-generator" - -\end_inset - -. - This solution poses problems when dealing with concurrent and distributed - systems. - In concurrent systems, the simple solution in algorithm -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-simple-generator" - -\end_inset - - may yield non-unique identifiers due to the lack of mutual exclusion. -\end_layout - -\begin_layout Standard -The obvious solution to this problem is to ensure mutual exclusion by using - some sort of lock, which may work well in many concurrent systems. - In a distributed system, this lock, along with the state, would have to - be distributed. - If the lock is not distributed, no guarantee can be made that two nodes - in the distributed system do not generate the same number. - A different approach is to give each node the ability to generate Universally - Unique Identifiers (UUID), where the state of one machine does not interfere - with the state of another. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{MAC Address}}{Media Access Control address, used to identify network - cards} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{SHA-1}}{Cryptigraphic hash function, designed by the National Security - Agency (NSA)} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -According to -\begin_inset CommandInset citation -LatexCommand citet -key "Leach98uuidsand" - -\end_inset - -, -\begin_inset Quotes eld -\end_inset - -A UUID is 128 bits long, and if generated according to the one of the mechanisms - in this document, is either guaranteed to be different from all other UUIDs/GUI -Ds generated until 3400 A.D. - or extremely likely to be different -\begin_inset Quotes erd -\end_inset - -. - This is accomplished by gathering several different sources of information, - such as: time, MAC addresses of network cards, and operating system data, - such as percentage of memory in use, mouse cursor position and process - ID:s. - The gathered data is then -\emph on -hashed -\emph default - -\begin_inset space ~ -\end_inset - -using an algorithm such as SHA-1. -\end_layout - -\begin_layout Standard -When using system wide unique identifiers, such as the ones generated by - algorithm -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-simple-generator" - -\end_inset - - with mutual exclusion, it is not possible to have identifier collisions - when recovering from network splits between the GGS clusters. - Consider figure -\begin_inset CommandInset ref -LatexCommand ref -reference "fig:network-split" - -\end_inset - -, where -\emph on -Site A -\emph default - is separated from -\emph on -Site B -\emph default - by a faulty network (illustrated by the cloud and lightening bolt). - When -\emph on - -\emph default -the decoupled node -\emph on - -\emph default -and -\emph on - -\emph default -the rest of the network later re-establish communication, they may have - generated the same ID:s if using algorithm -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-simple-generator" - -\end_inset - -, even when mutual system-wide exclusion is implemented. - This is exactly the problem UUID:s solve. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Network split}}{Separation of two networks, occurs when two networks - can not communicate, commonly because of a hardware or software failiure} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/netsplit2.eps - scale 40 - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Add clients on each side, and replace the cloud with phole-landlines being - cut by a pair of scissors -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "fig:network-split" - -\end_inset - -An example of a network split -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Security -\end_layout - -\begin_layout Standard -We only support languages running in a sandboxed environment. - Each game session is started in its own sandbox. - The sandboxing isolates the games in such a way that they can not interfere - with each other. - If sandboxing was not in place, one game could potentially modify the contents - of a different game. - A similar approach is taken with the persistent storage we provide. - In the storage each game has its own namespace, much like a table in a - relational database. - A game is not allowed to venture outside this namespace, and can because - this not modify the persistent data of other games. - of this not modify the persistent data of other games. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Sandbox}}{A protected environment in which computer software can - be run safely} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Encryption -\end_layout - -\begin_layout Section -Game Development Language in a Virtual Machine -\begin_inset CommandInset label -LatexCommand label -name "sec:Game-Development-Language" - -\end_inset - - -\end_layout - -\begin_layout Standard -There is only a very limited number of game developers who would like to - write their games in Erlang, therefore we had to come up with something - to resolve this problem. - The main idea was to offer a replacable module which would introduce a - interface to different virtual machines which would run the game code. - This way a game developer can write the game in his favourite language - while the server part still is written in Erlang and can benefit from all - of its advantages. -\end_layout - -\begin_layout Subsection -JavaScript -\end_layout - -\begin_layout Standard -JavaScript has gained a lot of popularity lately, it is used in large projects - such as -\emph on -Riak -\emph default - -\begin_inset Foot -status open - -\begin_layout Plain Layout -\begin_inset Flex URL -status collapsed - -\begin_layout Plain Layout - -http://wiki.basho.com/An-Introduction-to-Riak.html -\end_layout - -\end_inset - - -\end_layout - -\end_inset - -, -\emph on -CouchDB -\emph default - -\begin_inset Foot -status open - -\begin_layout Plain Layout -\begin_inset Flex URL -status collapsed - -\begin_layout Plain Layout - -http://couchdb.apache.org -\end_layout - -\end_inset - - -\end_layout - -\end_inset - -. - On the popular social coding site -\emph on -GitHub.com -\emph default -, 18% -\begin_inset Foot -status open - -\begin_layout Plain Layout -during the writing of the thesis the percentage went up to 19% -\begin_inset Flex URL -status collapsed - -\begin_layout Plain Layout - -https://github.com/languages/ -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - of all code is written in JavaScript. - The popularity of JavaScript in the programming community, in combination - with the availability of several different JavaScript virtual machines - was an important influence in choosing JavaScript as the main control language - for our GGS prototype. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{CouchDB}}{Database server} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Riak}}{Database server} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{GitHub.com}}{Social coding website} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{ActionScript}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Lua}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{.NET}}{Software platform} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Other languages -\end_layout - -\begin_layout Standard -Other languages like -\emph on -lua -\emph default -, -\emph on -ActionScript -\emph default - are suitable as well because there is a virtual machine for each of them - which can be -\begin_inset Quotes eld -\end_inset - -plugged in -\begin_inset Quotes erd -\end_inset - - into our GDL VM interface. - With help of the -\emph on -Java Virtual Machine -\emph default - or the -\emph on -.NET -\emph default -environment it is even possible to run nearly every available programming - language in a sandbox as a GDL. -\end_layout - -\begin_layout Standard -Due lack of time we have decided to use just the Erlang <-> JavaScript bridge - with our interface. -\end_layout - -\begin_layout Section -Testing -\end_layout - -\begin_layout Standard -There are several ways in which the GGS can be tested. - The most important aspect has been deemed to be the experience players - have when using the GGS. - In order to test the user experience of the GGS, a realistic usage scenario - has to be set up. -\end_layout - -\begin_layout Standard -The GGS is intended to be used for powering games which have many concurrent - players. - The players need not participate in the same instance of the game, games - such as chess are prime candidates for the GGS. -\end_layout - -\begin_layout Standard -When developing the GGS, two main categories of games exhibiting different - performance demands were identified; real-time games and turn-based games. - The real-time games were deemed more demanding than the turn based games. - Tests were carried out using a real time game, since this is the more demanding - type of games. -\end_layout - -\begin_layout Standard -The real time game chosen for testing the GGS is -\emph on -Pong -\emph default -, a game in which two players play a game involving a all and two paddles. - The goal for each player is to shoot eside the othre player's paddle while - not allowing the ball to pass by her own paddle. - The game requires real time updates and is quite demanding when played - in several instances concurrently. -\end_layout - -\begin_layout Standard -There has been some work on the area of testing game servers, see -\begin_inset CommandInset citation -LatexCommand citet -key "Lidholt02designand" - -\end_inset - -, who describes a test bench using -\emph on -bots -\emph default - for testing his generic hazard-gaming server. - Lidholt describes how his server, capable of running several different - casino games is tested using artificial players, so called bots. - Performance is measured in -\begin_inset Quotes eld -\end_inset - -number of clients -\begin_inset Quotes erd -\end_inset - - able to connect to the server, and the system load. -\end_layout - -\begin_layout Standard -Similar tests were performed on the GGS, and the results of these tests - are visible in chapter -\begin_inset CommandInset ref -LatexCommand ref -reference "chap:Results-and-discussion" - -\end_inset - -. - The tests were initially performed by starting an operating system process - for each player. - Due to lack of hardware, not enough player processes could be started in - this way. - The bots were re-written in Erlang, and due to Erlang's light weigh threads, - enough processes could be created to successfully test the server. -\end_layout - -\begin_layout Chapter -Implementation of a prototype -\begin_inset CommandInset label -LatexCommand label -name "cha:Implementation-of-a" - -\end_inset - - -\end_layout - -\begin_layout Standard -This chapter contains the realization of much of the principles and techniques - described in chapter -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Theory" - -\end_inset - -. - Here the problems and their solutions are discussed in greater detail, - and at times the text becomes more specific to GGS. -\end_layout - -\begin_layout Standard -Much of what is discussed in this chapter has been implemented in the Erlang - GGS prototype. - Specific solutions such as -\emph on -supervisor structures -\emph default -and distribution of erlang nodes on physical nodes. - The different means of communications within the GGS and outside the GGS - with third parties are also discussed here. -\end_layout - -\begin_layout Section -Overview of the prototype -\end_layout - -\begin_layout Standard -The prototype of the GGS was developed using the Erlang language. - The functional and concurrent style of Erlang facilitates devlopment of - software based on a real-world model -\begin_inset CommandInset citation -LatexCommand citep -key "armstrong2011" - -\end_inset - -. - In Erlang, most things are processes. - The software running the Erlang code is known as the Erlang machine, or - an Erlang node. - Each Erlang node is capable of running several -\emph on -threads -\emph default -(also known as -\emph on -Light Weight Processes; LWP -\emph default -) -\emph on -, -\emph default -much like the threads in an operating system. - Threads in a Linux system, for example, are treated much like operating - system processes in different systems. - Due to the size of datastructures related to each process, swapping one - process for another (known as -\emph on -context switching -\emph default -) is an expensive task in many systems -\begin_inset CommandInset citation -LatexCommand citep -after "pg 80" -key "McKusick:2004:DIF:1014910" - -\end_inset - -. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{LWP}}{Light Weight Process} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Context switch}}{The act of switching from one context, commonly - a process, to another. - Used by operating systems to achieve multi tasking} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The cost of swapping operating system processes becomes a problem when many - processes are involved. - If the GGS system had been developed using regular operating system processes, - it would have had to be designed in a way to minimize the number of processes. - Using Erlang, which is capable of running very many processes, several - times more than an operating system can, the mapping between the real world - system (described in -\begin_inset CommandInset ref -LatexCommand vref -reference "sec:Design-of-the" - -\end_inset - -) becomes clearer. -\end_layout - -\begin_layout Standard -Erlang allows the GGS to create several process for each player connecting, - these processes can handle a multitude of different tasks, parsing data - for example. - Since each task is handled by a different process, the tasks are clearly - separated and the failiure of one is easily recovered without affecting - the others. -\end_layout - -\begin_layout Standard -In addition to creating (or -\emph on -spawning -\emph default -) processes specifically to handle new players connecting, the GGS has more - permanent processes running at all times. - The constantly running processes in the GGS system are called -\emph on -modules -\emph default -. - An example of a module in the GGS is the -\emph on -dispatcher module -\emph default -, which handles the initial connection made by a client, passing the connection - along further in to the system. -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/Chess_no_text.eps - width 100text% - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "fig:The-layout-of" - -\end_inset - -The layout of the GGS. - The circles marked with 'C' topmost in the picture represent clients. - The cloud marked 'network' pictured directly below the clients can be any - network, for example the Internet. - The barell figure marked 'backup' is a process being fed backup data from - the coordinator. - The barell marked 'State' contains the state of a table, and this is fed - into the box marked 'Mnesia' which is database. - Finally the figure shaped as a shield marked 'GameVM' contains the actual - game process. -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -In figure -\begin_inset CommandInset ref -LatexCommand vref -reference "fig:The-layout-of" - -\end_inset - - the entire GGS system is represented graphically. - The circles marked with 'C' topmost in the picture represent game clients. - These circles represent processes running on gamers' computers, and not - on the GGS machine. - If a game of chess is to be played on the server, the clients on the gamers' - machines will be chess game clients. - Clients connect through a network, pictured as a cloud, to the dispatcher - process in the GGS. - The dispatcher process and all other modules are discussed in -\begin_inset CommandInset ref -LatexCommand vref -reference "sec:The-modular-structure" - -\end_inset - -. - For each connection, a new player process is spawned, which immediately - after spawning is integrated in to the GGS by the coordinator process. -\end_layout - -\begin_layout Section -The usage of Erlang in the GGS -\begin_inset CommandInset label -LatexCommand label -name "sec:The-usage-of-erlang" - -\end_inset - - -\end_layout - -\begin_layout Standard -Erlang was designed by Ericsson, beginning in 1986, for the purpose of creating - concurrent applications and improving telecom software. - Features essential for the telecom instustry to achieve high availability - in telecom switches were added to the language. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Mutex}}{A construct for achieving mutial exclusion, used to avoid - simultaneous access to shared resources in computer systems} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Erlang uses message passing in favour of shared memory, mutextes and locks, - something which at the time was controversial among fellow developers -\begin_inset CommandInset citation -LatexCommand citet -key "Armstrong:2010:ERL:1810891.1810910" - -\end_inset - -. - The reason for using message passing, according to Armstrong, was that - applications should operate correctly before optimizations are done, where - efficient internal communication within the Erlang machine was considered - a later optimization. -\end_layout - -\begin_layout Standard -In using message passing in favour of the methods commonly used at the time, - the issues commonly associated with shared memory and locking were avoided. - In Erlang, everything is a process, and everything operates in its own - memory space. - Memory can not be shared among processes, which prohibits a process from - corrupting the memory of a different process. -\end_layout - -\begin_layout Standard -Messages are sent between the processes in an asynchronous manner, and each - process has a mailbox in which these messages can be retrieved. -\end_layout - -\begin_layout Standard -Processes in Erlang are also called -\emph on -Light Weight Processes. - -\emph default -The Erlang processes are very cheaply created. - Processes exist within an Erlang machine, or Erlang node. - The Erlang machine has its own scheduler and does not rely on the operating - system's scheduler, this is a main reason of Erlang's capability of running - many concurrent processes -\begin_inset CommandInset citation -LatexCommand citet -key "Armstrong03" - -\end_inset - -. -\end_layout - -\begin_layout Standard -The strong isolation of Erlang processes make them ideal for multicore and - distributed systems. - Distribution of software is included as a fundamental part in the Erlang - language. - The 'physical' location of a process, e.g. - which computer the process runs on, is not important when communicating - with the process. - Processes can communicate regardless of whether they run on the same system - of not, transparently. -\end_layout - -\begin_layout Standard -The distributed nature of Erlang is something the GGS makes use of when - scaling across several computers in order to achieve higher performance. - The distribution is also important in creating redundancy. - Erlang promotes a non-defensive programming style in which processes are - allowed to crash and be restarted in favour of having the processes recover - from errors. - The distributed nature of Erlang means supervisor processes (discussed - in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:Supervisor-structure" - -\end_inset - -) can reside on remote systems, thereby increasing the reliability of the - system as a whole. -\end_layout - -\begin_layout Standard -A very important feature of Erlang, used in the GGS, is the ability to interface - with external hardware and software. - Erlang allows communication with external resources through -\emph on -ports -\emph default - and -\emph on -NIF -\emph default -:s (Native implemented functions) -\emph on -. - -\emph default - Through ports communication can take place much in the same way communication - is performed over sockets. - NIF:s are called like any other functions without any difference to the - caller but are implemented in C. -\end_layout - -\begin_layout Standard -The GGS uses Erlang ports for generating UUID:s -\begin_inset Foot -status collapsed - -\begin_layout Plain Layout -UUID:s are discussed in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:UUID" - -\end_inset - - -\end_layout - -\end_inset - - and NIF:s for interfacing with the virtual machines of games -\begin_inset Foot -status collapsed - -\begin_layout Plain Layout -Virtual machines of games are discussed in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Game-Development-Language" - -\end_inset - - -\end_layout - -\end_inset - -. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{OTP}}{Open Telecom Platform, a software suite for Erlang} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Behaviour}}{A design pattern in OTP} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Development of the GGS would have been hard if not impossible had it not - been for the -\emph on -OTP -\emph default - supplied with the standard Erlang distribution. - The OTP (Open Telecom Platform) is a set of standard libraries and design - patterns, called -\emph on -behaviours -\emph default -, which are used when developing Erlang systems. -\end_layout - -\begin_layout Standard -The GGS makes heavy use of the behaviours supplied in the OTP. - The behaviours impose a programming style suitable for distributed and - concurrent applications, perfectly suitable for the GGS. - In particular, the GGS uses the following behaviours: -\end_layout - -\begin_layout Itemize -The -\emph on -supervisor -\emph default - behaviour, which is used when creating a supervisor. - Supervisors are used when monitoring processes in the Erlang system. - When a process exits wrongfully, the supervisor monitoring the process - in question decides which action to take. - In the GGS, the most common action is simply to restart the faulting process. - A more thorough discussion on supervisors can be found in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:Supervisor-structure" - -\end_inset - -. -\end_layout - -\begin_layout Itemize -The -\emph on -gen_tcp -\emph default -behaviour, which is used to work with TCP sockets for network communication. - Using the gen_tcp behaviour, network messages are converted to internal - Erlang messages and passed to a protocol parser, where the messages are - processed further. -\end_layout - -\begin_layout Itemize -The -\emph on -gen_server -\emph default - behaviour, which is used when constructing OTP servers in Erlang. - Using this behaviour, a state can easily be kept in a server process, greatly - increasing the usefulness of the server process. - There are many gen_servers in the GGS, it is the most widely used behaviour - in the project. - In addition to intruducing a state to the server, the gen_server behaviour - also imposes patterns for synchronous and asynchronous communication between - other gen_servers and other OTP behaviours. -\end_layout - -\begin_layout Itemize -The -\emph on -gen_fsm -\emph default - behaviour is used in the protocol parser module in the GGS. - Using the gen_fsm behaviour, finite state machines are easily developed. - Protocol parsers are an ideal example of where to use finite state machines, - which are widely used for parsing strings of text. -\end_layout - -\begin_layout Standard -In addition to supplying behaviours, the OTP also has a style for packaging - and running Erlang applications. - By packaging the GGS as an -\emph on -application -\emph default -the GGS can be started in a way uniform to most erlang software, providing - familiarity for other Erlang users, and eases the incorporation of the - GGS in other applications. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Application}}{A way of packaging Erlang software in a uniform way} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Short introduction to the Erlang syntax -\end_layout - -\begin_layout Standard -In order to understand examples in this thesis, a small subset of Erlang - must be understood. - In this section, the very syntactic basics of Erlang are given. -\end_layout - -\begin_layout Itemize - -\series bold -Variables -\series default - start with an uppercase letter, examples include -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt X, Var}, and { -\backslash -tt Global} -\end_layout - -\end_inset - -. - A variable can only be assigned once. -\end_layout - -\begin_layout Itemize - -\series bold -Atoms -\emph on - -\series default -\emph default -start with lower case letters, for example: -\begin_inset ERT -status open - -\begin_layout Plain Layout - - { -\backslash -tt atom, a} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Itemize - -\series bold -Functions -\series default - are defined starting with an atom for the name, parenthesis containing - parameters, an arrow, a function body and finally a dot marking the end - of a function. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt square(X) -> X*X.} -\end_layout - -\end_inset - - is an example of a function producing the square of X. -\end_layout - -\begin_layout Itemize -Functions are -\series bold -called -\series default - by suffixing an atom with the function name with parenthesis, for example - -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt square(10)} -\end_layout - -\end_inset - -. - Qualified names can be specified using ':', for example: -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt math:square(10)} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Itemize - -\series bold -Tuples -\series default - are containers of fixed type for Erlang data types. - They are constructed using curly brackets, for example: -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt -\backslash -{atom1, atom2, atom3 -\backslash -}}. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Itemize - -\series bold -Lists -\series default - are constructed using [ and ], for example: -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt [1,2,3]} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Itemize - -\series bold -Strings -\series default - doubly qouted lists of characters, for example -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt "Hello world"} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Itemize - -\series bold -Records -\series default - are erlang tuples coupled with a tag for each tuple element. - This allows refering to elements by name instead of by position. - An example of a record looks like this: -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt -\backslash -#myRecord{}} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Section -Communication with external systems and applications -\begin_inset CommandInset label -LatexCommand label -name "sec:Communication-with-external" - -\end_inset - - -\end_layout - -\begin_layout Standard -A game launched on the GGS is run within a virtual machine. - For each programming language supported, there is a virtual machine that - interprets the game. - Furthermore an interface for communication between the GGS, the game and - the players playing the game must be present. -\end_layout - -\begin_layout Standard -The reason for the GGS requiring a communication channel between the game - VM and Erlang is in part because the GGS makes heavy use of callbacks. - Callbacks written in Erlang are registered to the VM for the interface - to work. - It is only with the help of the interface that the game developer can access - the game state and send messages between players. - The interface provides access to three objects called -\emph on -world -\emph default -, -\emph on -player -\emph default - and -\emph on -localstorage -\emph default -. - The game state is safely stored in a database and retrieved for manipulation - by a call for the world object. - Interaction with the players is done the same way using the player object - instead. - The localstorage is a convenient way to store globals and other data seperated - from the game state. - In section -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:Exposing-Erlang-functionality" - -\end_inset - - a concrete example of the implementation of the localStorage and world - objects is given. -\begin_inset Note Note -status open - -\begin_layout Plain Layout - Unique id:s called gametokens are generated for hosted games so that they - are not mixed up. - -- good text, integrate more. -\end_layout - -\end_inset - - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{WebStorage}}{A new standard for letting websites store data on visitors' - computers} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Exposing Erlang functionality to the GDL VM -\begin_inset CommandInset label -LatexCommand label -name "sub:Exposing-Erlang-functionality" - -\end_inset - - -\end_layout - -\begin_layout Standard -This section contains a concrete example of how the localStorage and world - objects are exposed to a GDL VM. - The example comes from the GGS prototype, which uses JavaScript powered - by Google V8 as its GDL VM. -\end_layout - -\begin_layout Standard -The code given in -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:exposing-erlang" - -\end_inset - - is specific to V8 and JavaScript, however implementations for different - GDL:s, or different JavaScript VM:s should be similar. -\end_layout - -\begin_layout Standard -In JavaScript is is common to use a top level object, called a global object, - to establish a global scope. - This allows declaration of global variables and functions. - To gain access to the global object in the GGS, the -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt erlv8 -\backslash -_vm:global(..)} -\end_layout - -\end_inset - - function on line 2 of the example is used. - Using the global object, declarations of the world and GGS object can be - placed in the global scope. -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt Global:set -\backslash -_value(..)} -\end_layout - -\end_inset - - is a call to the global object, declaring new objects in the global scope. - On line 4 the GGS object is declared. - By accessing -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt GGS.localStorage } -\end_layout - -\end_inset - - from within the GDL, access to the localstorage is provided, thus the localstor -age must be connected to the GGS object, this can be seen in line 5. -\end_layout - -\begin_layout Standard -Both the GGS and localStorage objects are dummy objects, which provide no - functionality, these two objects are simply placed in the GDL for the purpose - clearing up the code. - In order to perform an action using the GGS and localStorage objects, the - -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt getItem} and { -\backslash -tt setItem} -\end_layout - -\end_inset - - functions must be used. - These items are directly connected to the database module of the GGS, which - is discussed in more detail in -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:The-database-module" - -\end_inset - -. -\end_layout - -\begin_layout Standard -Similarly the functions -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt sendCommand, sendCommandToAll} and { -\backslash -tt setTimeout} -\end_layout - -\end_inset - - are directly connected to a piece of code in the GGS which performs the - desired action. - The -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt sendCommand} -\end_layout - -\end_inset - - functions are used to send commands or text to participants of the table. - The -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt setTimeout} -\end_layout - -\end_inset - - function introduces timeouts to the V8 engine, which are not available - per default. -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -lstset{ -\end_layout - -\begin_layout Plain Layout - -language=Erlang, -\end_layout - -\begin_layout Plain Layout - -backgroundcolor= -\backslash -color{white}, -\end_layout - -\begin_layout Plain Layout - -extendedchars=true, -\end_layout - -\begin_layout Plain Layout - -basicstyle= -\backslash -footnotesize -\backslash -ttfamily, -\end_layout - -\begin_layout Plain Layout - -showstringspaces=false, -\end_layout - -\begin_layout Plain Layout - -showspaces=false, -\end_layout - -\begin_layout Plain Layout - -numbers=left, -\end_layout - -\begin_layout Plain Layout - -numberstyle= -\backslash -footnotesize, -\end_layout - -\begin_layout Plain Layout - -numbersep=9pt, -\end_layout - -\begin_layout Plain Layout - -tabsize=2, -\end_layout - -\begin_layout Plain Layout - -breaklines=true, -\end_layout - -\begin_layout Plain Layout - -showtabs=false, -\end_layout - -\begin_layout Plain Layout - -captionpos=b -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - - -\backslash -begin{lstlisting}[language=Erlang] -\end_layout - -\begin_layout Plain Layout - -% @doc Exposes some GGS functions to JavaScript -\end_layout - -\begin_layout Plain Layout - -expose(GameVM, Table) -> -\end_layout - -\begin_layout Plain Layout - - Global = erlv8_vm:global(GameVM), -\end_layout - -\begin_layout Plain Layout - - Global:set_value("GGS", erlv8_object:new([ -\end_layout - -\begin_layout Plain Layout - - {"localStorage", erlv8_object:new([ -\end_layout - -\begin_layout Plain Layout - - {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:setItem(Table, local_storage, Key, Val) -\end_layout - -\begin_layout Plain Layout - - end}, -\end_layout - -\begin_layout Plain Layout - - {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:getItem(Table, local_storage, Key) -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - % more functions ... -\end_layout - -\begin_layout Plain Layout - - ])}, -\end_layout - -\begin_layout Plain Layout - - {"world", erlv8_object:new([ -\end_layout - -\begin_layout Plain Layout - - {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:setItem(Table, world, Key, Val), -\end_layout - -\begin_layout Plain Layout - - ggs_table:send_command_to_all( -\end_layout - -\begin_layout Plain Layout - - Table, {"world_set", Key ++ "=" ++ Val} -\end_layout - -\begin_layout Plain Layout - - ) -\end_layout - -\begin_layout Plain Layout - - end}, -\end_layout - -\begin_layout Plain Layout - - {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:getItem(Table, world, Key), -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - % more functions ... -\end_layout - -\begin_layout Plain Layout - - ])}, -\end_layout - -\begin_layout Plain Layout - - {"sendCommand", fun(#erlv8_fun_invocation{}, [Player, Command, Args])-> -\end_layout - -\begin_layout Plain Layout - - ggs_table:send_command(Table, Player, {Command, Args}) -\end_layout - -\begin_layout Plain Layout - - end}, -\end_layout - -\begin_layout Plain Layout - - {"sendCommandToAll", fun(#erlv8_fun_invocation{}, [Command, Args])-> -\end_layout - -\begin_layout Plain Layout - - ggs_table:send_command_to_all(Table, {Command, Args}) -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - {"setTimeout", fund(#erlv8_fun_invocation{}, [Time, Function])-> -\end_layout - -\begin_layout Plain Layout - - timer:apply_after(Time, ?MODULE, call_js, [GameVM, Function]) -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - % more functions ... -\end_layout - -\begin_layout Plain Layout - - ])). -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{lstlisting} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:exposing-erlang" - -\end_inset - -An example of how Erlang functionality is exposed to a Javascript GDL -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -TODO: Go in to more detail about how the world, player and localstorage - objects are implemented. - Also discuss localstorage and how it derives from the webstorage standard - in detail. - This is a great point on how we try to follow standards. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -My idea here is that we describe the erlang-js (which failed, but nontheless), - v8, UUID and other external communication. - We shouldn't describe sockets here though.. - or.. - maybe? -\end_layout - -\begin_layout Plain Layout -Also discuss how we allow GDLs to communicate with Erlang, this is -\begin_inset Quotes eld -\end_inset - -external -\begin_inset Quotes erd -\end_inset - - to thre GDL. - Discuss the GGS world object (there is a reference to this secxtion for - that purpose) -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -The modular structure of the GGS prototype -\begin_inset CommandInset label -LatexCommand label -name "sec:The-modular-structure" - -\end_inset - - -\end_layout - -\begin_layout Standard -The separation of concerns, and principle of single responsibility -\begin_inset Foot -status open - -\begin_layout Plain Layout -More information on the SRP is available at: -\begin_inset CommandInset href -LatexCommand href -target "http://www.objectmentor.com/resources/articles/srp.pdf" - -\end_inset - - -\end_layout - -\end_inset - - are widely respected as good practices in the world of software engineering - and development. - By dividing the GGS up into modules each part of the GGS can be modified - without damaging the rest of the system. -\end_layout - -\begin_layout Standard -The responsibility and concern of each module comes from the responsibility - and concern of the real-world entity the model represents. - The modelling of the GGS after a real world system was discussed in chapter - -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Theory" - -\end_inset - -. -\end_layout - -\begin_layout Standard -In the text below the word module refers to the actual code of the discussed - feature, while the word process is used when referring to a running instance - of the code. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{SRP}}{Single Responsibility Principle} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Object Oriented Programming}}{A programming paradigm focusing on - objects} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -The dispatcher module -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -The discussion of the modules is divided into the following parts: -\end_layout - -\begin_layout Itemize -What does the module do? -\end_layout - -\begin_layout Itemize -What happens when the module fails? -\end_layout - -\begin_layout Itemize -How does the module correspond to the real-world scenario of the chess club? -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The dispatcher module is the first module to have contact with a player. - When a player connects to the GGS, it is first greeted by the dispatcher - module, which sets up an accepting socket for each player. - -\begin_inset Note Note -status collapsed - -\begin_layout Plain Layout -Is this the proper way to day the dispatcher greets connecting players? -\end_layout - -\end_inset - - The dispatcher is the module which handles the interfacing to the operating - system when working with sockets. - Operating system limits concering the number of open files, or number of - open sockets are handled here. - The operating system limits can impose problems on the GGS, this is discussed - more in detail in chapter -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Problems-of-implementation" - -\end_inset - -. -\end_layout - -\begin_layout Standard -Should the dispatcher module fail to function, no new connections to the - GGS can be made. - In the event of a crash in the dispatcher module, a supervisor process - immediately restarts the dispatcher. - There exists a window of time between the crashing of the dispatcher and - the restarting of the dispatcher, this window is very short, and only during - this window is the GGS unable to process new connection requests. - Due to the modular structure of the GGS, the rest of the system is not - harmed by the dispatcher process not functioning. - The process does not contain a state, therefore a simple restart of the - process is sufficient in restoring the GGS to a pristine state after a - dispatcher crash -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Well.. - In theory.. -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Standard -Returning to scenario of the chess club, the dispatcher module is the doorman - of the club. - When a player enters the chess club, the player is greeted by the doorman, - letting the player in to the club. - The actual letting in to the club is in the GGS represented by the creation - of a player process discussed in -\begin_inset CommandInset ref -LatexCommand vref -reference "sub:The-player-module" - -\end_inset - -. - The newly created player process is handed, and granted rights to, the - socket of the newly connected player. -\end_layout - -\begin_layout Subsection -The player module -\begin_inset CommandInset label -LatexCommand label -name "sub:The-player-module" - -\end_inset - - -\end_layout - -\begin_layout Standard -The player module is responsible for representing a player in the system. - Each connected player has its own player process. - The player process has access to the connection of the player it represents, - and can communicate with this player. - In order to communicate with a player, the data to and from the player - object must pass through a protocol parser module, discussed in -\begin_inset CommandInset ref -LatexCommand vref -reference "sub:The-protocol-parser" - -\end_inset - -. - Raw communication, witout passing the data through a protocol parser is - in theory possible, but is not useful. -\end_layout - -\begin_layout Standard -In the creation of a player process, the coordinator process, discussed - in -\begin_inset CommandInset ref -LatexCommand vref -reference "sub:The-coordinator-module" - -\end_inset - -, is notified by the newly connected process. -\end_layout - -\begin_layout Standard -In the event of a crash in a player process, several things happen. - -\end_layout - -\begin_layout Enumerate -The player process, which is the only process with a reference to the socket - leading to the remote client software, passes this reference of the socket - to the coordinator process temporarily. -\end_layout - -\begin_layout Enumerate -The player process exits. -\end_layout - -\begin_layout Enumerate -The coordinator spawns a new player process, with the same socket reference - as the old player process had. -\end_layout - -\begin_layout Enumerate -The player process resumes operation, immediately starting a new protocol - parser process, and begind receiving and sending network messaged again. -\end_layout - -\begin_layout Standard -The window of time between the crash of the player process and the starting - of a new player process is, as with the dispatcher, very short. - Since the connection changes owners for a short period of time, but is - never dropped, the implications of a crash are only noticed, at worst, - as choppy gameplay for the client. - Note however that this crash recovery scheme is not implemented in the - GGS prototype. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Can we do this..? Seems a bit sneaky. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Moving back to the real world example, the player process represent an actual - person in the chess club. - When a person sits down at a table in the chess club, the person does so - by requesting a seat from some coordinating person, and is then seated - by the same coordinator. - Once seated, the player may make moves on the table he or she is seated - by, this corresponds clearly to how the GGS is structured, as can be seen - in the following sections. -\end_layout - -\begin_layout Subsection -The protocol parser module -\begin_inset CommandInset label -LatexCommand label -name "sub:The-protocol-parser" - -\end_inset - - -\end_layout - -\begin_layout Standard -The protocol parser is an easily interchangable module in the GGS, handling - the client-to-server, and server-to-client protocol parsing. - In the GGS prototype, there is only one protocol supported, namely the - -\emph on -GGS Protocol -\emph default -. - The role of the protocol parser is to translate the meaning of packets - sent using the prototocol in use to internal messages of the GGS system. - The GGS protocol, discussed below is used as a sample protocol in order - to explain how protocol parsers can be built for the GGS. -\end_layout - -\begin_layout Subsubsection -The structure of the GGS Protocol -\begin_inset CommandInset label -LatexCommand label -name "sub:The-structure-of" - -\end_inset - - -\end_layout - -\begin_layout Standard -The GGS protocol is modelled after the HTTP protocol. - The main reason for this is the familiarity many developers already have - with HTTP due to its presence in internet software. - Each GGS protocol packet contains a headers section. - The headers section is followed by a data section. - In the headers section, parameters concerning the packet is placed. - In the data section, the actual data payload of the packet is placed. -\end_layout - -\begin_layout Standard -There is no requirement of any specific order of the parameters in the headers - section, however the data section must always follow directly after the - headers section. -\end_layout - -\begin_layout Standard -In the example below, line 1 contains a Game-Command parameter. - This parameter is used to determine which game-specific command the client - is trying to perform. - The handling of this parameter is specific to each game, and can be anything. -\end_layout - -\begin_layout Standard -Line 2 specifies a game token. - This is a UUID which is generated for each client upon authentication with - the GGS. - The GGS uses this token in case a client is disconnected and the new connection - created when the client reconnects must be re-paired with the player object - inside the GGS. - The UUID is also used as a unique ID within GDL VMs. -\end_layout - -\begin_layout Standard -Line 3 specifies the content type of the payload of this particular packet. - This parameter allows the GGS to invoke special parsers, should the data - be encoded or encrypted. - When encryption is employed, only the payload is encrypted, not the header - section. - This is a scheme which does not allow for strong encryption, but is deemed - feasible for gaming purposes. -\end_layout - -\begin_layout Standard -Line 4 specifies the content length of the payload following immediately - after the headers section. -\end_layout - -\begin_layout Standard -The parser of the GGS protocol implemented in the GGS prototype is designed - as a finite state machine using the gen_fsm behaviour. - When a full message has been parsed by the parser, the message is converted - into the internal structure of the GGS messages, and sent in to the system - from the protocol paser using message passing. -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Packet below is not an algorithm, but I don't know how to change that label.. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -lstset{ -\end_layout - -\begin_layout Plain Layout - -backgroundcolor= -\backslash -color{white}, -\end_layout - -\begin_layout Plain Layout - -extendedchars=true, -\end_layout - -\begin_layout Plain Layout - -basicstyle= -\backslash -footnotesize -\backslash -ttfamily, -\end_layout - -\begin_layout Plain Layout - -showstringspaces=false, -\end_layout - -\begin_layout Plain Layout - -showspaces=false, -\end_layout - -\begin_layout Plain Layout - -numbers=left, -\end_layout - -\begin_layout Plain Layout - -numberstyle= -\backslash -footnotesize, -\end_layout - -\begin_layout Plain Layout - -numbersep=9pt, -\end_layout - -\begin_layout Plain Layout - -tabsize=2, -\end_layout - -\begin_layout Plain Layout - -breaklines=true, -\end_layout - -\begin_layout Plain Layout - -showtabs=false, -\end_layout - -\begin_layout Plain Layout - -captionpos=b -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - - -\backslash -begin{lstlisting} -\end_layout - -\begin_layout Plain Layout - -Game-Command: chat -\end_layout - -\begin_layout Plain Layout - -Token: e30174d4-185e-493b-a21a-832e2d9d7a1a -\end_layout - -\begin_layout Plain Layout - -Content-Type: text -\end_layout - -\begin_layout Plain Layout - -Content-Length: 18 -\end_layout - -\begin_layout Plain Layout - -\end_layout - -\begin_layout Plain Layout - -Hello world, guys! -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{lstlisting} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:A-sample-packet" - -\end_inset - -A sample packet sent from a client to the GGS during a chat session -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Mention that the protocol is heavily influenced bye HTTP, is parsed using - a FSM, perhaps give a sample packet. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -The coordinator module -\begin_inset CommandInset label -LatexCommand label -name "sub:The-coordinator-module" - -\end_inset - - -\end_layout - -\begin_layout Standard -The coordinator module is responsible for keeping track of all players, - their seats and tables. - Players register with the coordinator process when first connecting to - the server, and the coordinator places each player by their respective - table. -\end_layout - -\begin_layout Standard -The coordinator keeps mappings between each player and table, therefore - it is used to perform lookups on tables and players to find out which are - connected. - The connectivity of players and tables is important when sending messages - to all participants in a game. - A lookup in the coordinator process is performed prior to notifying all - players in a game to ensure the message reaches all players. - The lookup can be performed either using internal identification codes - or using the UUID associated with each client and table. -\end_layout - -\begin_layout Standard -The coordinator process contains important state, therefore a backup process - is kept at allt times. - All good data processed by the coordinator is stored for safekeeping in - the backup process as well. - Data which is potentisally harmful is not stored in the backup process. -\end_layout - -\begin_layout Standard -Upon a crash, the coordinator process recovers the prior good state from - the backup process and continues where it left off. - A supervisor process monitors the coordinator process and restarts the - process when it malfunctions. - There is a window of time between the crash of the coordinator and the - restarting of the coordinator, during this time, players can not be seated - by new tables, and can not disconnect from the server. - This window of time is very small, and the unavailability of the coordinator - process should not be noticed by more than a short time lag for the clients. -\end_layout - -\begin_layout Standard -Moving back to the example of the chess club, the coordinator process can - be seen as a judge, monitoring all moves of the players. - At the same time as acting as a judge, the coordinator process is also - a host in the chess club, seating players by their tables and offering - services to the players. -\end_layout - -\begin_layout Subsection -The table module -\end_layout - -\begin_layout Standard -The table module is mostly a hub used for communication. - New table processes are created by the coordinator on demand. - The table module does not contain any business logic, however each process - contains information concerning which players are seated by that particular - table. -\end_layout - -\begin_layout Standard -The information about which players are seated by each table is used when - notifying all players by a table of an action. - Consider a game of chess, each player notifies the table of its actions, - the table then notifies the rest of the participants of these actions after - having had the ac tions processed by the game VM, where an action could - be moving a playing piece. -\end_layout - -\begin_layout Standard -Each table is associated with a game VM. - The actions sent to a table are processed by the game VM, this is where - the game logic is implemented. -\end_layout - -\begin_layout Standard -After a crash in a table process, the entire table must be rebuilt and the - players must be re-associated with the table. - Data concerning players is kept in the coordinator process, and is restored - from there. - Data kept in the actual game is not automatically corrupted by the crash - in a table, however the table must be re-associated with the game VM is - was associated with prior to the crash of the table. - The table process maps well into the setting of the real-world chess club - scenario previously discussed. - A table works in the same way in a real world setting as in the GGS setting. -\end_layout - -\begin_layout Subsection -The game virtual machine module -\end_layout - -\begin_layout Standard -This module holds the game logic of a game and is responsible for the VM - associated with each game. - -\end_layout - -\begin_layout Standard -The game VM contains the state of the VM and a table token associated with - a running game. - GameVM is started by the table module. - The table module hands over a token to the game VM during initialization. - During initialization a new VM instance and various objects associated - to the VM instance will be created. - Callbacks to Erlang are registered into the VM and then the source code - of a game is loaded into the VM and the game is ready for startup. - The only means for a game to communicate with the VM is through usage of - a provided interface. - -\end_layout - -\begin_layout Standard -The VM itself makes it possible for the game developer to program in the - prograimming language covered by the VM. - In future releases, more game VM:s will be added to support more programming - languages. - Because the game VM keeps track of the correct table, the game developer - doesn't need to take this into consideration when programming a game. - If a method within the game sends data to a player, it will be delivered - to the player in the correct running game. - The same game token is used to store the game state in the database. - Therefore, no game states will be mixed up either. -\end_layout - -\begin_layout Standard -This module does not affect game runtime but evaluates a new game state - and handles communication between the game and the players. - A closer look at the structure of this model is given in -\begin_inset CommandInset ref -LatexCommand vref -reference "sec:Communication-with-the-GDL-VM" - -\end_inset - -. -\end_layout - -\begin_layout Subsection -The database module -\begin_inset CommandInset label -LatexCommand label -name "sub:The-database-module" - -\end_inset - - -\end_layout - -\begin_layout Standard -Game data from all games on the GGS are stored in the database backend of - the database module. -\end_layout - -\begin_layout Standard -In the GGS prototype the database module is using a database management - system called Mnesia. - Mnesia ships with the standard Erlang distribution and is a key-value store - type database. - Mnesia is designed to handle the stress of telecoms systems, and has some - features specifically tailored for telecoms which are not commonly found - in other databases. - Key features of the Mnesia database are: -\end_layout - -\begin_layout Itemize -Fast key/value lookups -\end_layout - -\begin_layout Itemize -Distribution of the database system -\end_layout - -\begin_layout Itemize -Fault tolerance -\end_layout - -\begin_layout Standard -\begin_inset CommandInset citation -LatexCommand citet -key "667766" - -\end_inset - - -\end_layout - -\begin_layout Standard -The features of Mnesia originally intended for telecoms prove very useful - for the purposes of the GGS as well. - The fault tolerance and speed of Mnesia are very valueable tools, the fast - key/value lookups permit many lookups per second to the database. -\end_layout - -\begin_layout Standard -Game data will not be lost when a game is stopped or has gone down for unknown - reasons. - This makes it possible to continue a game just before the failure without - having to start the game from the beginning. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Mnesia}}{Database server used in the GGS} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The GGS stores the game state in the distributed Mnesia database, from which - the state can be restored in the event of a crash. -\end_layout - -\begin_layout Standard -Each game is uniquely identified by a table token and the data of each game - is stored within two different namespaces. - The namespaces are named World and Localstorage. - The World is used contain all game data related to the game state. - This sort of game data may change during the runtime of the game. - The Localstorage should contain data independent of the game state. - Game resources, constants and globals are all examples of data that could - reside within the Localstorage. - To store a value within the database, not only is the table token and the - name of the namespace required, but a unique key so that the value can - be successfully retrieved or modified later. - The key is fully decidable by the game developer. - -\end_layout - -\begin_layout Standard -The interface of the database module is an implementation of the upcoming - W3C Web Storage specification. - Web Storage is intended for use in web browsers, providing a persistant - storage on the local machine for web applications. - The storage can be used to communicate in between browser windows (which - is difficult when using cookies), and to store larger chunks of data -\begin_inset CommandInset citation -LatexCommand citet -key "webstorage:website" - -\end_inset - -. - Usage of the web storage standard in the GGS provides a well documented - interface to the database backend. -\end_layout - -\begin_layout Subsection -A case study -\end_layout - -\begin_layout Standard -So what happens when a client sends a typical game command? Let us look - at one particular example of a chat client sending the message to change - the nick of a user (we will discuss a example implementation in JavaScript - in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Example-of-a-GGS-server-application-in-JavaScript" - -\end_inset - -). - Every communication between modules happens asynchronously, nothing is - blocking, which is very important in concurrent systems. - It is probably much easier to follow the steps by following them on -\begin_inset CommandInset ref -LatexCommand vref -reference "fig:The-layout-of" - -\end_inset - -. -\end_layout - -\begin_layout Enumerate -Client packages a Game-Command into a package which conforms to the protocol - structure the GGS is using and sends it over the network -\end_layout - -\begin_layout Enumerate -The player module, which is coupled to the TCP-module to react on incoming - messages accepts the message and forwards the raw data to the protocol - parser module -\end_layout - -\begin_layout Enumerate -The protocol parser parses the message and brings it into the format of - the internal GGS presentation of such a message, which is just a specialized - Erlang touple -\end_layout - -\begin_layout Enumerate -The protocol parser sends this Erlang touple back to the player module -\end_layout - -\begin_layout Enumerate -The player module checks if it is a Server-Command or a Game-Commane. - In our example it is a Game-Command and it sends the message to the table - module -\end_layout - -\begin_layout Enumerate -The table module sends it to its own Game VM -\end_layout - -\begin_layout Enumerate -The Game VM module calls the function -\emph on -playerCommand( -\begin_inset Quotes eld -\end_inset - -278d5002-77d6-11e0-b772-af884def5349 -\begin_inset Quotes erd -\end_inset - -, -\begin_inset Quotes eld -\end_inset - -nick -\begin_inset Quotes erd -\end_inset - -, -\begin_inset Quotes eld -\end_inset - -Peter -\begin_inset Quotes erd -\end_inset - -) -\emph default - within the JavaScript VM -\end_layout - -\begin_layout Enumerate -The JavaScript VM (JSVM) - at this stage Googles V8 JavaScript Engine - - evaluates the function within the sandboxed game context which has been - established earlier during the setup of the game. -\end_layout - -\begin_layout Enumerate -In the example ( -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Example-of-a-GGS-server-application-in-JavaScript" - -\end_inset - -) we see that the GGS-functios -\emph on -GGS.localStorage.setItem(key, value) -\emph default - and -\emph on -GGS.localStorage(key) -\emph default - are used. - Both are callbacks coupled to the database module functions. -\end_layout - -\begin_layout Enumerate -Data is being read from and written to the database and handed over to the - JSVM via the database module -\end_layout - -\begin_layout Enumerate -In the example the -\emph on -GGS.sendCommandToAll() -\emph default - is beeing called then which is a callback to a function of the table module - which iterates thrugh its player list and sends the command to every player -\end_layout - -\begin_layout Enumerate -The table module sends every player instance the message to send the message - with the change of a nickname of a particular user to its own client. -\end_layout - -\begin_layout Enumerate -The player module asks the protocol module to create a message conforming - to the protocol which is being used -\end_layout - -\begin_layout Enumerate -The protocol module creates a string according to the protocol and returns - it to the player module -\end_layout - -\begin_layout Enumerate -The player module sends the message with help of the gen_tcp module to the - client -\end_layout - -\begin_layout Section -Communication with the GDL VM -\begin_inset CommandInset label -LatexCommand label -name "sec:Communication-with-the-GDL-VM" - -\end_inset - - -\end_layout - -\begin_layout Standard -A game launched on the GGS is run within a virtual machine. - For each programming language supported, there is a virtual machine that - interprets the game. - Furthermore an interface for communication between the GGS, the game and - the players playing the game is present. -\end_layout - -\begin_layout Standard -Callbacks written in Erlang are registered to the VM for the interface to - work. - It is only with the help of the interface that the game developer can access - the game state and send messages to the clients. - The interface provides access to three objects called -\emph on -world, players -\emph default - and -\emph on -localStorage -\emph default -. - The game state is safely stored in a database and retrieved for manipulation - by a call for the world object. - Interaction with the players is done by using the -\emph on -GGS.sendCommand(player_id, command, args) -\emph default - and -\emph on -GGS. -\emph default -sendCommandToAll(command, args). - The localStorage is a convenient way to store globals and other variables - seperated from the game state. - Unique id:s called gametokens are generated for hosted games so that they - are not mixed up. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{WebStorage}}{A new standard for letting websites store data on visitors' - computers} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Exposing Erlang functionality to the GDL VM -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Prior to this section, the Erlang syntax has to be briefly explained. - I think the 'usage of erlang' section is a good place to do this in. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -lstset{ -\end_layout - -\begin_layout Plain Layout - -language=Erlang, -\end_layout - -\begin_layout Plain Layout - -backgroundcolor= -\backslash -color{white}, -\end_layout - -\begin_layout Plain Layout - -extendedchars=true, -\end_layout - -\begin_layout Plain Layout - -basicstyle= -\backslash -footnotesize -\backslash -ttfamily, -\end_layout - -\begin_layout Plain Layout - -showstringspaces=false, -\end_layout - -\begin_layout Plain Layout - -showspaces=false, -\end_layout - -\begin_layout Plain Layout - -numbers=left, -\end_layout - -\begin_layout Plain Layout - -numberstyle= -\backslash -footnotesize, -\end_layout - -\begin_layout Plain Layout - -numbersep=9pt, -\end_layout - -\begin_layout Plain Layout - -tabsize=2, -\end_layout - -\begin_layout Plain Layout - -breaklines=true, -\end_layout - -\begin_layout Plain Layout - -showtabs=false, -\end_layout - -\begin_layout Plain Layout - -captionpos=b -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - - -\backslash -begin{lstlisting}[language=Erlang] -\end_layout - -\begin_layout Plain Layout - -% @doc Exposes some GGS functions to JavaScript -\end_layout - -\begin_layout Plain Layout - -expose(GameVM, Table) -> -\end_layout - -\begin_layout Plain Layout - - Global = erlv8_vm:global(GameVM), -\end_layout - -\begin_layout Plain Layout - - Global:set_value("GGS", erlv8_object:new([ -\end_layout - -\begin_layout Plain Layout - - {"localStorage", erlv8_object:new([ -\end_layout - -\begin_layout Plain Layout - - {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:setItem(Table, local_storage, Key, Val) -\end_layout - -\begin_layout Plain Layout - - end}, -\end_layout - -\begin_layout Plain Layout - - {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:getItem(Table, local_storage, Key) -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - % more functions ... -\end_layout - -\begin_layout Plain Layout - - ])}, -\end_layout - -\begin_layout Plain Layout - - {"world", erlv8_object:new([ -\end_layout - -\begin_layout Plain Layout - - {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:setItem(Table, world, Key, Val), -\end_layout - -\begin_layout Plain Layout - - ggs_table:send_command_to_all( -\end_layout - -\begin_layout Plain Layout - - Table, {"world_set", Key ++ "=" ++ Val} -\end_layout - -\begin_layout Plain Layout - - ) -\end_layout - -\begin_layout Plain Layout - - end}, -\end_layout - -\begin_layout Plain Layout - - {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:getItem(Table, world, Key), -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - % more functions ... -\end_layout - -\begin_layout Plain Layout - - ])}, -\end_layout - -\begin_layout Plain Layout - - {"sendCommand", fun(#erlv8_fun_invocation{}, [Player, Command, Args])-> -\end_layout - -\begin_layout Plain Layout - - ggs_table:send_command(Table, Player, {Command, Args}) -\end_layout - -\begin_layout Plain Layout - - end}, -\end_layout - -\begin_layout Plain Layout - - {"sendCommandToAll", fun(#erlv8_fun_invocation{}, [Command, Args])-> -\end_layout - -\begin_layout Plain Layout - - ggs_table:send_command_to_all(Table, {Command, Args}) -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - {"setTimeout", fun(#erlv8_fun_invocation{}, [Time, Function])-> -\end_layout - -\begin_layout Plain Layout - - timer:apply_after(Time, ?MODULE, call_js, [GameVM, Function]) -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - % more functions ... -\end_layout - -\begin_layout Plain Layout - - ])). -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{lstlisting} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:exposing-erlang" - -\end_inset - -An example of how Erlang functionality is exposed to a JavaScript GDL -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -TODO: Go in to more detail about how the world, player and localstorage - objects are implemented. - Also discuss localstorage and how it derives from the webstorage standard - in detail. - This is a great point on how we try to follow standards. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -My idea here is that we describe the erlang-js (which failed, but nontheless), - v8, UUID and other external communication. - We shouldn't describe sockets here though.. - or.. - maybe? -\end_layout - -\begin_layout Plain Layout -Also discuss how we allow GDLs to communicate with Erlang, this is -\begin_inset Quotes eld -\end_inset - -external -\begin_inset Quotes erd -\end_inset - - to thre GDL. - Discuss the GGS world object (there is a reference to this secxtion for - that purpose) -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Techniques for ensuring reliability -\end_layout - -\begin_layout Standard -One of the main goals of the project is to achieve high reliability. - The term -\begin_inset Quotes eld -\end_inset - -reliable system -\begin_inset Quotes erd -\end_inset - - is defined by the IEEE as a system with -\begin_inset Quotes eld -\end_inset - -the ability of a system or component to perform its required functions under - stated conditions for a specified period of time -\begin_inset Quotes erd -\end_inset - - -\begin_inset CommandInset citation -LatexCommand citet -key "ieee_90" - -\end_inset - -. - There are some tools for creating reliable applications built in to Erlang. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Reliability}}{The ability of a system or component to perform its - required functions under stated conditions for a specified period of time} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{IEEE}}{Institute of Electrical and Electronics Engineers, read "I-triple- -E"} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Itemize -Links between processes. - When a process spawns a new child process, and the child process later - exits, the parent process is notified of the exit. - -\end_layout - -\begin_layout Itemize -Transparent distribution over a network of processors. - When several nodes participate in a network, it does not matter on which - of these machines a process is run. - Communication between processes does not depend on the node in which each - process is run. - -\end_layout - -\begin_layout Itemize -Hot code replacements. - Two versions of the same module can reside in the memory of Erlang at any - time. - This means that a simple swap between these versions can take place very - quickly, and without stopping the machine. -\end_layout - -\begin_layout Standard -These three features are some of the basic building blocks for more sophisticate -d reliability systems in Erlang. - Many times it is not necessary to use these features directly, but rather - through the design patterns described below. -\end_layout - -\begin_layout Subsection -Supervisor structure -\begin_inset CommandInset label -LatexCommand label -name "sub:Supervisor-structure" - -\end_inset - - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -This entire section is bad. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -By linking processes together and notifying parents when children exit, - supervisors are created. - A supervisor is a common approach in ensuring that an application functions - in the way it was intended -\begin_inset CommandInset citation -LatexCommand citet -key "Savor:1997:HSA:851010.856089" - -\end_inset - -. - When a process misbehaves, the supervisor takes some action to restore - the process to a functional state. - -\end_layout - -\begin_layout Standard -There are several approaches to supervisor design in general (when not just - considering how they work in Erlang). - One common approach is to have the supervisor look in to the state of the - process(es) it supervises, and let the supervisor make decisions based - on this state. - The supervisor has a specification of how the process it supervises should - function, and this is how it makes decisions. - -\end_layout - -\begin_layout Standard -In Erlang, we have a simple version of supervisors. - We do not inspect the state of the processes being supervised. - We do have a specification of how the supervised processes should behave, - but on a higher level. - The specification describes things such as how many times in a given time - interval a child process may crash, which processes need restarting when - crashes occur, and so forth. - -\end_layout - -\begin_layout Standard -When the linking of processes in order to monitor exit behaviour is coupled - with the transparent distribution of Erlang, a very powerful supervision - system is created. - For instance, we can restart a failing process on a different, new node, - with minimal impact on the system as a whole. - -\end_layout - -\begin_layout Standard -In the GGS, we have separated the system in to two large supervised parts. - We try to restart a crashing child separately, if this fails too many -\begin_inset Foot -status collapsed - -\begin_layout Plain Layout -Exactly how many -\begin_inset Quotes eld -\end_inset - -too many -\begin_inset Quotes erd -\end_inset - - is depends on a setting in the supervisor, ten crashes per second is a - reasonable upper limit. -\end_layout - -\end_inset - - times, we restart the nearest supervisor of this child. - This ensures separation of the subsystems so that a crash is as isolated - as possible. -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset Note Note -status open - -\begin_layout Plain Layout -We should really do this graphic in EPS instead of PNG -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/Supervisor_tree_GGS.eps - scale 40 - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -The supervisor structure of GGS -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The graphic above shows our two subsystems, the coordinator subsystem and - the dispatcher subsystem. - Since these two systems perform very different tasks they have been separated. - Each subsystem has one worker process, the coordinator or the dispatcher. - The worker process keeps a state which should not be lost upon a crash. -\end_layout - -\begin_layout Standard -We have chosen to let faulty processes crash very easily when they receive - bad data, or something unexpected happens. - The alternative to crashing would have been to try and fix this faulty - data, or to foresee the unexpected events. - We chose not to do this because it is so simple to monitor and restart - processes, and so difficult to try and mend broken states. - This approach is something widely deployed in the Erlang world, and developers - are often encouraged to “Let it crash”. -\end_layout - -\begin_layout Standard -To prevent any data loss, the good state of the worker processes is stored - in their respective backup processes. - When a worker process (re)starts, it asks the backup process for any previous - state, if there is any that state is loaded in to the worker and it proceeds - where it left off. - If on the other hand no state is available, a special message is delivered - instead, making the worker create a new state, this is what happens when - the workers are first created. -\end_layout - -\begin_layout Subsection -Reduncancy -\end_layout - -\begin_layout Standard -The modules in the GGS are built to be capable of redundant operation. - By adding a backup process to sensitive processes, the state can be kept - in the event of a crash. - The coordinator of the GGS prototype has this backup feature built in. - The coordinator passes state along to the backup process which keeps the - data safe. - In the event of a crash, the coordinator recovers the state from the backup - process. - Figure -\begin_inset CommandInset ref -LatexCommand ref -reference "fig:redundancy" - -\end_inset - - depicts the redundancy built in to the coordinator process. -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/redundancy.eps - scale 40 - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "fig:redundancy" - -\end_inset - -To the left normal execution is pictured; the server state is backed up. - To the left; the exceptional excution, where the state is retrieved from - the backup to repopulate the server. -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Hot code replacement -\end_layout - -\begin_layout Standard -Hot code replacement is a technique used to update systems while they are - running. - The main use of hot code replacement are in critical systems that require - low downtime, such as telecom systems. - By using hot code replacement system can be able to achieve as high uptime - as possible and thus improving the reliability of the system. - Code replacement is a feature that exist in Erlang which means that with - some work it could be implemented into the GGS. -\end_layout - -\begin_layout Section -Example of a GGS server application in Javascript -\end_layout - -\begin_layout Standard -Below is a concrete example of a simple chat server application written - using the GGS. - The language chosen for this chat server is JavaScript. - The GGS processes all incoming data through a protocol parser, which interprets - the data and parses it into an internal format for the GGS. -\end_layout - -\begin_layout Standard -When the GGS receives a -\emph on -Game-Command -\emph default - from a client, it is passed along to the game VM through a function called - -\emph on -playerCommand -\emph default - which is the entry point for each game and has to be implemented by the - developer; one can think of it like the -\emph on -main() -\emph default - function of a C or Java programm -\emph on -. - -\emph default - Typically the -\emph on -playerCommand -\emph default - function contains conditional constructs which decide the next action to - take. - In -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-concrete-example" - -\end_inset - - an example of the -\emph on -playerCommand -\emph default - function can be seen. -\end_layout - -\begin_layout Standard -In -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-concrete-example" - -\end_inset - - the -\emph on -playerCommand -\emph default - function accepts two different commands. - The first command is a command which allows chat clients connected to the - chat server to change nicknames, which are used when chatting. - In order to change the nickname, a client must send a Game-Command -\begin_inset Quotes eld -\end_inset - -nick -\begin_inset Quotes erd -\end_inset - - with the actuall new nickname as a argument. - When a message arrives to the GGS which has the form corresponding to the - nickname change, the -\emph on -playerCommand -\emph default - function is called with the parameters -\emph on -player_id, command, -\emph default -and -\emph on -args -\emph default - filled in appropriately. -\end_layout - -\begin_layout Standard -The -\emph on -playerCommand -\emph default - function is responsible for calling the helper functions responsibly for - carrying out the actions of each message received. - -\emph on -changeNick -\emph default - is a function which is called when the -\begin_inset Quotes eld -\end_inset - -nick -\begin_inset Quotes erd -\end_inset - - message is received. - The -\emph on -changeNick -\emph default -function uses a feature of the GGS called localStorage (see section -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Communication-with-the-GDL-VM" - -\end_inset - -), which is an interface to the database backend contained in the database - module (see -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:The-database-module" - -\end_inset - -). - The database can be used as any key-value store, however the syntax for - insertions and fetch operations is tighty integrated in the GDL of the - GGS. -\end_layout - -\begin_layout Standard -Access to the localStorage is provided through the -\emph on -GGS object -\emph default -, which also can be used to communicate with the rest of the system from - the GDL. - Implementation specifics of the GGS object are provided in -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Communication-with-the-GDL-VM" - -\end_inset - -. -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -lstset{ -\end_layout - -\begin_layout Plain Layout - -language=JavaScript, -\end_layout - -\begin_layout Plain Layout - -backgroundcolor= -\backslash -color{white}, -\end_layout - -\begin_layout Plain Layout - -extendedchars=true, -\end_layout - -\begin_layout Plain Layout - -basicstyle= -\backslash -footnotesize -\backslash -ttfamily, -\end_layout - -\begin_layout Plain Layout - -showstringspaces=false, -\end_layout - -\begin_layout Plain Layout - -showspaces=false, -\end_layout - -\begin_layout Plain Layout - -numbers=left, -\end_layout - -\begin_layout Plain Layout - -numberstyle= -\backslash -footnotesize, -\end_layout - -\begin_layout Plain Layout - -numbersep=9pt, -\end_layout - -\begin_layout Plain Layout - -tabsize=2, -\end_layout - -\begin_layout Plain Layout - -breaklines=true, -\end_layout - -\begin_layout Plain Layout - -showtabs=false, -\end_layout - -\begin_layout Plain Layout - -captionpos=b -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - - -\backslash -begin{lstlisting}[language=JavaScript] -\end_layout - -\begin_layout Plain Layout - -function playerCommand(player_id, command, args) { -\end_layout - -\begin_layout Plain Layout - - if(command == "nick") { -\end_layout - -\begin_layout Plain Layout - - changeNick(player_id, args); -\end_layout - -\begin_layout Plain Layout - - } else if(command == "message") { -\end_layout - -\begin_layout Plain Layout - - message(player_id, args); -\end_layout - -\begin_layout Plain Layout - - } -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - -function changeNick(player_id, nick) { -\end_layout - -\begin_layout Plain Layout - - var old_nick = GGS.localStorage.getItem("nick_" + player_id); -\end_layout - -\begin_layout Plain Layout - - GGS.localStorage.setItem("nick_" + player_id, nick); -\end_layout - -\begin_layout Plain Layout - - if (!old_nick) { -\end_layout - -\begin_layout Plain Layout - - GGS.sendCommandToAll("notice", nick + " joined"); -\end_layout - -\begin_layout Plain Layout - - } else { -\end_layout - -\begin_layout Plain Layout - - GGS.sendCommandToAll("notice", old_nick + " is now called " + nick); -\end_layout - -\begin_layout Plain Layout - - } -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - -function message(player_id, message) { -\end_layout - -\begin_layout Plain Layout - - var nick = GGS.localStorage.getItem("nick_" + player_id); -\end_layout - -\begin_layout Plain Layout - - GGS.sendCommandToAll('message', nick + "> " + message); -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{lstlisting} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:A-concrete-example" - -\end_inset - -A concrete example of a simple chat server written in JavaScript, running - on the GGS -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Chapter -Problems of implementation -\begin_inset CommandInset label -LatexCommand label -name "cha:Problems-of-implementation" - -\end_inset - - -\end_layout - -\begin_layout Standard -This chapter contains specific problems encountered when implementing the - GGS prototype. - Some of the problems described have solutions attached, however some problems - were not solved, therefore only ideas for slutions have been attached. -\end_layout - -\begin_layout Standard -The integration of JavaScript as a GDL in the GGS prototype was particularily - difficult, and is handled in this section. - Unique identification is also handled, as is the design of the GGS protocol. -\end_layout - -\begin_layout Section -JavaScript engine -\end_layout - -\begin_layout Standard -The GGS prototype uses a vistual machine to sandbox each game. - JavaScript was chosen for the prototype due to its commonality in web applicati -ons and the flexibility of the language. - Any language with the proper bindings to Erlang could have been used in - theory. -\end_layout - -\begin_layout Standard -There are two main JavaScript virtual machines, or -\emph on -engines -\emph default - available at the time of the writing of this thesis. - There is a group of machines developed by Mozilla called -\emph on -TraceMonkey, JaegerMonkey, SpiderMonkey -\emph default -and -\emph on -IonMonkey -\emph default -, and also there is Google V8. - The group of Mozilla machines are largely the same, and are referred to - as the same machine for simplicity. -\end_layout - -\begin_layout Standard -For the Mozilla machines, there exists an Erlang binding called erlang_js, - and for the V8 machine a binding called erlv8 exists. -\end_layout - -\begin_layout Subsection -erlang_js -\end_layout - -\begin_layout Standard -Erlang_js provides direct communication with the JavaScript VM. - Which is exactly what is desired, however also required is thee possibility - to communicate from erlang_js to Erlang. - The ability to communicate from JavaScript to Erlang functionality is not - yet implemented in erlang_js, due to lack of time on the behalf of the - erlang_js developers. -\end_layout - -\begin_layout Standard -There were two possible solutions to the problem of the JavaScript to Erlang - communication path missing, the path could be implemented by the GGS project, - or a switch from erlang_js for some other JavaScript engine could be made. - -\end_layout - -\begin_layout Standard -Attempts at creating the communication path from JavaScript to Erlang were - initially made, however the communiucation path never became stable enough - for usage in the GGS and the erlang_js software was abandoned. -\end_layout - -\begin_layout Subsection -erlv8 -\end_layout - -\begin_layout Standard -erlv8 is powered by the V8 engine developed by Google rather than the engines - developed by Mozilla. - The ability to communicate with Erlang from JavaScript using callbacks - is available in the erlv8 bindings, therefore this feature does not have - to be added to the bindings in order to be used in the GGS. -\end_layout - -\begin_layout Standard -Initial releases of the erlv8 bindings had stability issues, these were - however solved by the erlv8 developers during the usage of erlv8 in the - GGS. - erlv8 is the JavaScript engine powering JavaScript as a GDL in the GGS. -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{V8}}{JavaScript engine developed by Google} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{SpiderMonkey}}{JavaScript engine developed by Mozilla} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -UUID -\end_layout - -\begin_layout Standard -Erlang identifies processes uniquely throughout the entire Erlang network - using process IDs (PID). - When we wish to refer to erlang processes from outside our erlang system, - for example in a virtual machine for a different language, possibly on - a different machine, these PID:s are no longer useful. - -\end_layout - -\begin_layout Standard -This problem is not new, and a common solution is to use a Universally Unique - Identifier, a UUID. - These identifiers are generated both using randomization and using time. - A reasonably large number of UUID:s can be generated before a collision - should occur. - There are standard tools in many UNIX systems to generate UUID:s, we chose - to use the uuidgen command, which employs an equidistributed combined Tausworth -e generator. -\end_layout - -\begin_layout Subsection -Protocol design -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Discuss how the early GGS protocol were going to use both UDP and binary - plists to be as fast as possible. - Then discuss how complex these solutions were going to be to implement - in the prototype. - Mention that the modular structure of the GGS allows these features to - be implemented later on, but are not currently implemented. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Design choices -\begin_inset Note Note -status open - -\begin_layout Plain Layout -This section is wrongly placed -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -When designing concurrent applications, it is useful to picture them as - real world scenarios, and to model each actor as a real world process. - A real world process is a process which performs some action in the real - world, such as a mailbox receiving a letter, a door being opened, a person - translating a text, a soccer player kicking the ball, just to name a few - examples. - Since we focus on games in this project, it is suitable to model our system - as a place where games take place. - We imagined a chess club. - -\end_layout - -\begin_layout Standard -The clients pictured as green circles can be thought of as the physical - chess players. -\end_layout - -\begin_layout Standard -When a player wants to enter the our particular chess club, he must first - be let in by the doorman, called the -\emph on -Dispatcher -\emph default - in the GGS. -\end_layout - -\begin_layout Standard -He then gets a name badge, and thus becomes a -\emph on -Player -\emph default - process in the system. - He is also guided in to the lobby by the -\emph on -Coordinator -\emph default -, which has the role of the host of the chess club. -\end_layout - -\begin_layout Standard -When players wish to play against each other, they talk to the -\emph on -Coordinator -\emph default - who pairs them up, and places them at a table. - Once they have sat down at the table, they no longer need the assistance - of the -\emph on -Coordinator -\emph default -, all further communication takes place via the table. - This can be thought of as the actual chess game commencing. - -\end_layout - -\begin_layout Standard -All the moves made in the game are recorded by the table, such that the - table can restore the game in case something would happen, such as the - table tipping over, which would represent the table process crashing. -\end_layout - -\begin_layout Standard -Once a player wishes to leave a game, or the entire facility, he should - contact the -\emph on -Coordinator -\emph default -, who revokes his name badge and the -\emph on -Dispatcher -\emph default - will let the player out. -\end_layout - -\begin_layout Standard -With the information kept in the tables and the -\emph on -Coordinator -\emph default - combined, we can rebuild the entire state of the server at a different - location. - This can be thought of the chess club catching fire, and the -\emph on -Coordinator -\emph default - rounding up all the tables, running to a new location and building the - club up in the exact state it was prior to the fire. -\end_layout - -\begin_layout Section -Usability -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Discuss how the GGS can be difficult to use for people not versed with Erlang -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Chapter -Results and discussion -\begin_inset CommandInset label -LatexCommand label -name "chap:Results-and-discussion" - -\end_inset - - -\end_layout - -\begin_layout Section -Software development methodology -\end_layout - -\begin_layout Standard -The project has not followed any specific software development methodology. - All work has been based on a predefined schedule and the specifications - are made by team members rather than an outside customer or stakeholder. - The process can be described as a plan-driven development method going - from brainstorming to design, then implementation and finally testing. - Yet there has been cycles in the process in form of redesign and code refactori -ng. -\end_layout - -\begin_layout Section -Statistics -\end_layout - -\begin_layout Standard -Important things to note are that the number of clients is not a good way - of measuring the performance of the server because the server is possible - to have a large number of clients on the server but it can not handle all - the information. - Instead the performance of the server should be measured in the number - of messages it can handle per second. -\end_layout - -\begin_layout Standard -We were able to reach 6000 messages per second on the server, which corresponds - to around 350 clients. - However soon after this mnesia printed some warnings and the clients started - to lag. - With this in mind one thing to investigate is if mnesia is the bottleneck - in the system. - Current game servers do not use databases to save their state and maybe - we can see the reason here. - Other possible bottlenecks may be the protocol, but this seems less likely - than mnesia. - -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/msg_per_sec.eps - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout - -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/ping.eps - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout - -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/msg_per_secoutput.eps - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout - -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Future improvements -\end_layout - -\begin_layout Standard -The specification of the GGS prototype is huge and like many other software - projects relying on outside technologies, in time it would require a lot - of maintanance. - Therefore there are a lot of areas in which the GGS could be improved such - as performance, compatibility, ease of setup and usage. -\end_layout - -\begin_layout Subsection -Performance -\end_layout - -\begin_layout Subsubsection -Protocols -\end_layout - -\begin_layout Standard -Because of TCP being a connection oriented protocol, it is not suited for - all types of game data transfers. - Each transmission will consume more network bandwith than connectionless - protocols like UDP and cause uneccessary load on the processor. - Therefore support for UDP would mean that more games could be run simultaneousl -y on the GGS. - Another advantage of UDP is latency being reduced. - Without having to setup a connection for each group packets of data being - sent, they will be sent instantly and therefore arrive earlier. - Latency is of highest importance in realtime games as it improves realism - and fairness in gameplay and many game developers requires the freedom - to take care of safety issues as packet losses themselves. - This concludes that UDP would be a benefit for the GGS, game developers - and players alike. -\end_layout - -\begin_layout Subsubsection -Database -\end_layout - -\begin_layout Standard -Currently Mnesia is used for game data storage. - During stress tests, Mnesia has turned out to be the bottleneck due to - data losses when too many games are played on the GGS simultaneously. - This could be prevented by replacing Mnesia with another database management - system or use Mnesia in combination with the ETS module of erlang. - ETS provides fast access to the RAM and thus Mnesia could be used less - frequently. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{ETS}}{Erlang Term Storage} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Compatibility -\end_layout - -\begin_layout Standard -GGS relies on modern technologies. - This includes the virtual machines(VM) that the GGS uses for communication - between Erlang and the GDL:s. - These specific VM:s are crucial for game developers to be able to write - games in other languages than Erlang. - Therefore it would be best for the GGS to have as many of these VM:s implemente -d as possible. - The VM:s taken into consideration so far have been unstable or incomplete - and it is possible to search for more VM:s, testing them and intergrate - them into the GGS prototype. -\end_layout - -\begin_layout Subsection -Setup -\end_layout - -\begin_layout Standard -The GGS prototype installation procedure requires different configuring - and building steps and thus it isn't in an acceptable release state. - An executable installation file for each supported platform would be optimal. -\end_layout - -\begin_layout Subsection* -5.3.4 Usage -\end_layout - -\begin_layout Subsubsection -Programming languages -\end_layout - -\begin_layout Standard -The GGS does not support many programming languages. - For a programming language to be compatible with the GGS, not only does - it require a VM for that specific language, but the VM must have the ability - to communicate to Erlang. - More research is needed to find VM:s with this built in functionality. - -\end_layout - -\begin_layout Subsubsection -Documentation -\end_layout - -\begin_layout Standard -To start the GGS is not self explanatory. - This together with overall usage of GGS should be documented. - The interface for usage of game developers is also in need of documentation. - Features and requirements with respect to the GGS would assist users to - know what they need in order to use the GGS and how they would benefit - of it. - The GGS does not support many programming languages nor does it have a - complete documentation. - This needs to be taken care of in future versions. -\end_layout - -\begin_layout Chapter -Conclusion -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -addcontentsline{toc}{section}{Glossary} -\end_layout - -\begin_layout Plain Layout - - -\backslash -printnomenclature -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard - -\end_layout - -\begin_layout Standard -\begin_inset CommandInset bibtex -LatexCommand bibtex -bibfiles "bibliography" -options "plainnat" - -\end_inset - - -\end_layout - -\end_body -\end_document diff --git a/working.lyx b/working.lyx deleted file mode 100644 index bdc12ed..0000000 --- a/working.lyx +++ /dev/null @@ -1,7223 +0,0 @@ -#LyX 2.0 created this file. For more info see http://www.lyx.org/ -\lyxformat 413 -\begin_document -\begin_header -\textclass report -\begin_preamble -\usepackage{indentfirst} -\usepackage{tocloft} -\usepackage{calc} -\date{} -\usepackage[section] {placeins} -\def\myClearpage{% - \ifvmode - \ifnum \@dbltopnum =\m@ne - \ifdim \pagetotal <\topskip - \hbox{}% - \fi - \fi - \fi -% \newpage - \write\m@ne{}% - \vbox{}% - \penalty -\@Mi -} -\def\myCleardoublepage{\myClearpage\if@twoside \ifodd\c@page\else - \hbox{}\if@twocolumn\hbox{}\fi\fi\fi} -\usepackage{morefloats} -\usepackage{graphicx} -\usepackage{subfig} -\usepackage{tocloft} -\renewcommand{\cftchapfont}{\bfseries} -\renewcommand{\cftchappagefont}{\bfseries} -\renewcommand{\cftchappresnum}{Chapter } -\renewcommand{\cftchapnumwidth}{6em} - -\oddsidemargin 0.5in -\textwidth 6in -\topmargin 0.0in -\textheight 8.0in -\setlength\topskip{24pt} -\footskip 0.75in - -\usepackage[compact]{titlesec} - - -\titleformat{\chapter}[display] -{\vskip-8em\normalfont\bfseries} -{\LARGE\raggedright\thechapter} -{14ex} -{\vspace{-20ex}% -\LARGE\raggedleft} -[\vspace{1ex}% -{\titlerule[1pt]}] - -\usepackage[absolute]{textpos} - -\usepackage{fancyheadings} -\pagestyle{fancy} -\lhead{\thechapter} - -\usepackage[hmargin=3cm,vmargin=3.5cm]{geometry} -\usepackage{algorithmic} -\usepackage{listings} - -\usepackage{color} -\definecolor{lightgray}{rgb}{.9,.9,.9} -\definecolor{darkgray}{rgb}{.4,.4,.4} -\definecolor{purple}{rgb}{0.65, 0.12, 0.82} - -\lstdefinelanguage{JavaScript}{ - keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break}, - keywordstyle=\color{blue}\bfseries, - ndkeywords={class, export, boolean, throw, implements, import, this}, - ndkeywordstyle=\color{darkgray}\bfseries, - identifierstyle=\color{black}, - sensitive=false, - comment=[l]{//}, - morecomment=[s]{/*}{*/}, - commentstyle=\color{purple}\ttfamily, - stringstyle=\color{red}\ttfamily, - morestring=[b]', - morestring=[b]" -} - -\lstdefinelanguage{Erlang}{ - keywords={typeof, true, false, catch, return, null, catch, switch, var, if, in, while, do, else, case, break, expose}, - keywordstyle=\color{blue}\bfseries, - ndkeywords={class, export, boolean, throw, implements, import, this,erlv8_vm, erlv8_fun_invocation -,erlv8_object}, - ndkeywordstyle=\color{darkgray}\bfseries, - identifierstyle=\color{black}, - sensitive=false, - comment=[l]{\%}, - morecomment=[s]{/*}{*/}, - commentstyle=\color{purple}\ttfamily, - stringstyle=\color{red}\ttfamily, - morestring=[b]', - morestring=[b]" -} - -\usepackage{float} - -\floatstyle{ruled} -\newfloat{code}{thp}{lop} -\floatname{code}{Code} - -\usepackage{nomencl} -\makenomenclature -\renewcommand{\nomname}{Glossary} -\end_preamble -\use_default_options true -\maintain_unincluded_children false -\language english -\language_package default -\inputencoding auto -\fontencoding global -\font_roman lmodern -\font_sans default -\font_typewriter default -\font_default_family rmdefault -\use_non_tex_fonts false -\font_sc false -\font_osf false -\font_sf_scale 100 -\font_tt_scale 100 - -\graphics default -\default_output_format default -\output_sync 0 -\bibtex_command default -\index_command default -\paperfontsize default -\spacing onehalf -\use_hyperref false -\papersize a4paper -\use_geometry false -\use_amsmath 1 -\use_esint 1 -\use_mhchem 1 -\use_mathdots 1 -\cite_engine natbib_authoryear -\use_bibtopic false -\use_indices false -\paperorientation portrait -\suppress_date false -\use_refstyle 0 -\index Index -\shortcut idx -\color #008000 -\end_index -\paperwidth 11in -\paperheight 8.5in -\leftmargin 1.25in -\topmargin 0in -\rightmargin 1in -\bottommargin 1.7in -\secnumdepth 2 -\tocdepth 2 -\paragraph_separation indent -\paragraph_indentation default -\quotes_language english -\papercolumns 1 -\papersides 1 -\paperpagestyle empty -\tracking_changes false -\output_changes false -\html_math_output 0 -\html_css_as_file 0 -\html_be_strict false -\end_header - -\begin_body - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{textblock*}{ -\backslash -paperwidth}(0mm,40mm) -\end_layout - -\begin_layout Plain Layout - - -\backslash -begin{center} -\end_layout - -\begin_layout Plain Layout - - -\backslash -includegraphics[width= -\backslash -paperwidth/2]{graphics/logo} -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{center} -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{textblock*} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Title -A Reliable Generic Game Server -\end_layout - -\begin_layout Author -Niklas Landin -\begin_inset Newline newline -\end_inset - -Richard Pannek -\begin_inset Newline newline -\end_inset - -Mattias Pettersson -\begin_inset Newline newline -\end_inset - -Jonatan Pålsson -\end_layout - -\begin_layout Abstract -This is the abstract! -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -pagenumbering{roman} -\end_layout - -\begin_layout Plain Layout - - -\backslash -setcounter{page}{3} -\end_layout - -\begin_layout Plain Layout - - -\backslash -renewcommand -\backslash -contentsname{Table of Contents} -\end_layout - -\begin_layout Plain Layout - - -\backslash -renewcommand{ -\backslash -cfttoctitlefont}{ -\backslash -hfill -\backslash -Large} -\backslash -renewcommand{ -\backslash -cftaftertoctitle}{ -\backslash -hfill} -\end_layout - -\begin_layout Plain Layout - - -\backslash -renewcommand -\backslash -cftpartdotsep{6.6} -\end_layout - -\begin_layout Plain Layout - - -\backslash -renewcommand -\backslash -cftchapdotsep{6.6} -\end_layout - -\end_inset - - -\begin_inset CommandInset toc -LatexCommand tableofcontents - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Newpage newpage -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -pagenumbering{arabic} -\end_layout - -\begin_layout Plain Layout - - -\backslash -setcounter{page}{1} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Chapter -Introduction -\end_layout - -\begin_layout Standard -Online gaming, and computer gaming in general has become an important part - in many peoples day-to day lives. - A few years ago, computer games were not at all as popular as they are - today. - With the advances in computer graphics and computer hardware today's games - are much more sophisticated then they were in the days of -\emph on -NetHack -\emph default -, -\emph on -Zork, -\emph default -or -\emph on -Pacman. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Zork}}{A textual computer game developed by students at MIT} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Pacman}}{An early graphical computer game developed by Namco} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{NetHack}}{An early computer game developed by the NetHack team, arguably - the oldest computer game still in development} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The early computer games featured simple, or no graphics at all -\begin_inset CommandInset citation -LatexCommand citet -key "nethack:website" - -\end_inset - -. - The games often took place in a textual world, leaving the task of picturing - the world up to the player. - Multi-player games were not as common as they are today, whereas most games - today are expected to have a multi-player mode, most early games did not. -\end_layout - -\begin_layout Standard -Since these early games, the gaming industry have become much more influential - in many ways. - Many advanced in computer hardware are thought to come from pressure from - the computer game industry. - More powerful games require more powerful, and more easily available hardware -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Drop a reference to the gaming industry pressuring more advanced hardware -\end_layout - -\end_inset - -. - Due to the high entertainment value of modern computer games, gaming has - become a huge industry, where large amounts of money are invested. - The gaming industry is today, in some places even larger than the motion - picture industry. - -\begin_inset CommandInset citation -LatexCommand citet -key "esa:website,thenumbers:website" - -\end_inset - - -\end_layout - -\begin_layout Standard -Due to the increasing importance of computer gaming, more focus should be - spent on improving the quality of the gaming service. - As more and more computer games are gaining multi-player capabilities, - the demands for multiplayer networking software rises. - This thesis is about techniques for improving the quality of this networking - software. -\end_layout - -\begin_layout Standard -The reliable generic game server, hereafter known as GGS -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{GGS}}{Generic Game Server, a software for reliably hosting network - games. - The subject of this thesis.} -\end_layout - -\end_inset - -, is a computer program designed to -\emph on -host -\emph default - network games on one or more server computers. - Hosting, in a network software setting, means allowing client software - connect to the server software, for the purpose of utilizing services provided - by the server. - The GGS software provides games as a service, and the clients connecting - to the GGS can play these games on the GGS. -\end_layout - -\begin_layout Standard -The idea of game servers is not new, network games have been played for - decades. - Early, popular examples of network games include the -\emph on -Quake -\emph default - series, or the -\emph on -Doom -\begin_inset Note Note -status collapsed - -\begin_layout Plain Layout - -\emph on -Come up w/ better game -\end_layout - -\end_inset - - -\emph default - games. - Newer examples of network games include -\emph on -World of Warcraft -\emph default -, and -\emph on -Counter-Strike -\emph default -. - The difference between the GGS and the servers for these games is that - the servers for Doom, Quake, and the others listed, were designed with - these specific games in mind. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Quake}}{A first person shooter series developed by ID software. - The series consists of four games.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Doom}}{A first person shooter series developed by ID software. - The series consists of three games.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{World of Warcraft}}{A MMORPG game developed by Blizzard. - The world's most popular MMORPG by subscriber count.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Counter-Strike}}{A multiplayer first person shooter game, popular - in E-Sports.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Framework}}{A supporting structure, the GGS is a framework for developing - network games} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{First-person shooter}}{A game in which centers around gun combat - from the first person perspective.} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{MMORPG}}{Massively multiplayer online role playing game. - An online game with several thousand participants.} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -What GGS does is to provide a -\emph on -generic -\emph default - framework for developing network games. - The framework is generic in the sense that it is not bound to a specific - game. - There are many different types of games, some are inherently more time - sensitive than others, strategy games are examples of games which are not - very sensitive to time delays, first-person shooters however, can be very - sensitive. -\end_layout - -\begin_layout Standard -The generic nature of the GGS allows the creation of many different types - of games, the motivation behind this is to remove the necessity of writing - new game servers when developing new games. -\end_layout - -\begin_layout Standard -The GGS is in addition to being generic, also -\emph on -reliable -\emph default - in the sense that the gaming service provided is consistent and available. - A consistent and available server is a server that handles hardware failures - and software failures gracefully. - In the event of a component breaking within the GGS, the error is handled - by fault recovery processes, thereby creating a more reliable system. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Hardware failiure}}{A failiure in hardware (hard drive, memory, processor -, etc) which causes a system to stop functioning} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Software failiure}}{A failiure in software (the GGS, the operating - system, etc) which causes a system to stop functioning} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Background -\end_layout - -\begin_layout Standard -The game industry is a quickly growing industry where the need for new technique -s are large. - One specific section where the development has stalled is the game server - section. -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Citation needed -\end_layout - -\end_inset - - The existing game servers are functional but they lack good fault tolerance - and the ability to scale well -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Citation needed -\end_layout - -\end_inset - -. - Users will notice this in low uptime and many crashes. - This is a problem that has existed and been resolved in other industries. - In the telecom industry solutions to similar problems have been found. -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{The nine nines}}{A common goal for availability in the telecom business. - A system with nine nines of availability is available 99.999999999% of the - time} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Downtime}}{The amount of time a system is unavailable and does not - function} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Uptime}}{The amount of time a system is available and functions} -\end_layout - -\end_inset - -A common figure often used in telecoms is that of -\emph on -the nine nines -\emph default -, referring to -\begin_inset Formula $99.999999999\%$ -\end_inset - - of availability, or rougly -\begin_inset Formula $15ms$ -\end_inset - - downtime in a year -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Citation needed -\end_layout - -\end_inset - -. - The level of instability and bad fault tolerance seen in the game server - industry would not have been accepted in the telecoms industry. - This level of instability should not be accepted in the game server industry - either. - An unavailabvle phone system could potentially have life threatening consequenc -es, leaving the public unable to contant emergency services. - The same can not be said about an unavailable game server. - The statement that game servers are less important than phone systems is - not a reason not to draw wisdom from what the telecoms have already learnt. -\end_layout - -\begin_layout Standard -Moving back to the gaming industry. - The main reason to develop reliable servers are monetary, it is important - for game companies to expand its customer base. - Reliable game servers are one improvement that will create a good image - of a company. - In general the downtime of game servers is much higher than the downtime - of telecom system -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Citation needed... -\end_layout - -\end_inset - -. - The structure of the system is similar in many ways and it should be possible - to reuse solutions from the telecom system to improve game servers. - -\end_layout - -\begin_layout Standard -In the current state game servers are developed on a per-game basis, in - many cases this seems like a bad solution. - Developers of network game need to understand network programming. - A way to change this is a generic game server which give the game developers - a server which they implement their game towards. - This approach would not only make it easier to develop network games, it - would also allow games in different programming languages to be implemented - using the same server. -\end_layout - -\begin_layout Standard -Some factors key to the development of GGS have been isolated. - Many of these come from the telecom sector. - The factors are -\emph on -scalability, fault tolerance -\emph default -and being -\emph on -generic -\emph default -. - These terms are defined below. -\end_layout - -\begin_layout Standard -Scalability (see -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Scalability" - -\end_inset - -) in computer science is a large topic and is commonly divided into sub-fields, - two of which are -\emph on -structural scalability -\emph default - and -\emph on -load scalability -\emph default - -\begin_inset CommandInset citation -LatexCommand citet -key "Bondi:2000:CSI:350391.350432" - -\end_inset - -. - These two issues are addressed in this thesis. - Structural scalability means expanding an architecture, e.g. - adding nodes to a system without requiring modification of the system. - Load scalability means using the available resources in a way which allows - handling increasing load, e.g more users, gracefully. -\end_layout - -\begin_layout Standard -Fault tolerance (see -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Fault-Tolerance" - -\end_inset - -) is used to raise the level of -\emph on -dependability -\emph default - in a system, so that the dependability is high even in presence of errors. - Dependability is defined as the statistical probability of the system functioni -ng as intended at a given point in time. - Fault tolerance is defined as the property of a system to always follow - a specification, even in the presence of errors. - The specification could take the form of error handling procedures which - activate when an error occurs. - This means that a fault tolerant, dependable system, will have a very high - probability of functioning at a given point in time, and is exactly what - is desired. - -\begin_inset CommandInset citation -LatexCommand citet -key "Gartner:1999:FFD:311531.311532" - -\end_inset - - -\end_layout - -\begin_layout Standard -A generic (see -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Generic" - -\end_inset - -) game server has to be able to run different client-server network games - regardless of the platform the clients are running on. - It runs network games of different type. - A very rough separation of games is real time games and turn based games. -\end_layout - -\begin_layout Standard -The server behaves in a way similar to an application server, but is designed - to help running games. - An application server provides processing ability and time, therefore it - is different from a file- or print-server, which only serves resources - to the clients. -\end_layout - -\begin_layout Standard -The most common type of application servers are web servers, where you run - a web application within the server. - The application server provides an environment and interfaces to the outer - world, in which applications run. - Hooks and helpers are provided to use the resources of the server. - Some examples for web application servers are the -\emph on -Glassfish -\emph default - server which allows running applications written in Java or the -\emph on -Google App Engine -\emph default - where you can run applications written in Python or some language which - runs in the -\emph on -Java Virtual Machine -\emph default -. - An example of an application server not powering web applications, but - instead regular business logic, is Oracle’s -\emph on -TUXEDO -\emph default - application server, which can be used to run applications written in COBOL, - C++ and other languages. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{SQL}}{Structured Query Language, a computer language common in querying - certain databases} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{JavaScript}}{A programming language originally developed by Netscape, - common in web programming} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{COBOL}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{C++}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Java}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{AXD301}}{Telephone switch developed by Ericsson} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Erlang}}{A concurrent programming language, often used for telecom - applications. - The main language of the GGS} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -A database server can also be seen as an application server. - Scripts, for example SQL queries or JavaScript, are sent to the server, - which runs them and returns the evaluated data to the clients. - -\end_layout - -\begin_layout Standard -One purpose of this thesis is to investigate how we can make a game server - as generic as possible. - Some important helpers are discussed, such as abstraction of the network - layer, data store and game specific features. - -\end_layout - -\begin_layout Standard -As an aid in discussing the theoretical parts of the GGS a prototype has - been developed. - The prototype does not feature all of the characteristics described in - this thesis. - A selection has been made among the features, and the most important ones - have been implemented either full or in part in the prototype. -\end_layout - -\begin_layout Standard -The choice of implementation language for the prototype of the GGS was made - with inspiration from the telecom industry. - The Erlang language was developed by the telecom company Ericsson to develop - highly available and dependable telecom switches. - One of the most reliable systems ever developed by Ericsson, the AXD301 - was developed using Erlang. - The AXD301 is also possibly has the largest code base even written in a - functional language -\begin_inset CommandInset citation -LatexCommand citep -key "Armstrong03" - -\end_inset - -. - The same language is used to develop the prototype of the GGS. - Usage of Erlang in the GGS is discussed in further detail in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:The-usage-of-erlang" - -\end_inset - -. - Chapter -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Implementation-of-a" - -\end_inset - - provides a description of the prototype developed for this thesis. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -We could go on and on about erlang.. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Purpose -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status collapsed - -\begin_layout Plain Layout -The purpose of the GGS project. - What is the purpose of creating a fault tolerant server, why is it generic, - and what good does it do to have a scalable system? In the background, - we should give the motivations behind creating this software, but here - we should outline why the software is needed. - This section should be shortened, and the bulk of the text should be moved - to theory or background. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The purpose of creating a generic and fault tolerant game server is to provide - a good framework for the development of many different types of games. - Allowing the system to scale up and down is a powerful way to maximize - the usage of physical resources. - By scaling up to new machines when load increases, and scaling down from - machines when load decreases costs and energy consumption can be optimized. -\end_layout - -\begin_layout Standard -Fault tolerance is important for the GGS to create a reliable service. - The purpose of a reliable game server is to provide a consistent service - to people using the server. - Going back to the telecom example, the purpose of creating a reliable telecom - system is to allow calls, possibly emergency calls, at any time. - Should the telecom network be unavailable at any time, emergency services - may become unavailable, furthermore the consumer image of the telecom system - degrades. -\end_layout - -\begin_layout Standard -Returning to the game industry, emergency services will not be contacted - using a game server, however an unavailable server will degrade the consumer - image of the system. - Consider an online casino company. - The online casino company's servers must be available at all times to allow - customers to play. - If the servers are unavailable, customers can not play, and the company - loses money. - In this scenario, an unavailable server can be compared to a closed real-world - casino. -\end_layout - -\begin_layout Section -Challenges in developing the prototype -\end_layout - -\begin_layout Standard -The word -\emph on -generic -\emph default - in the name of the GGS implies that the system is able to run a very broad - range of different code, for instance code wrote in different programming - languages, besides a broad range of different game types. - To support this, a virtual machine (VM) for each -\emph on -game development language -\emph default - (hereafter GDL for brevity) is used. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{GDL}}{Game Development Language, the language used to program games - in the GGS} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{VM}}{Virtual Machine} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -No hard limit has been set on which languages can be used for game development - on the GGS, but there are several factors which decide the feasibility - of a language: -\end_layout - -\begin_layout Itemize -How well it integrates with Erlang, which is used in the core the GGS system - -\end_layout - -\begin_layout Itemize -How easy it is to send messages to the virtual machine of the GDL from the - GGS -\end_layout - -\begin_layout Itemize -How easy it is to send messages from the GDL VM to the GGS -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Add more like threads, events, etc. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Internally, the GDL VM needs to interface with the GGS to make use of the - helpers and tools that the GGS provides. - Thus an internal API has to be designed for use in interacting with the - GGS. - This API is ideally completely independent of the GDL, and reusable for - any GDL. -\end_layout - -\begin_layout Standard -The communication with gaming clients has to take place over a protocol. - Ideally a standard protocol should be used, in order to shorten the learning - curve for developers, and also make the system as a whole less obscure. - A large challenge during this project is to decide whether an existing - protocol can be used, and if not, how a new protocol can be designed which - performs technically as desired, while still being familiar enough to existing - developers. -\end_layout - -\begin_layout Standard -A great deal of work is devoted to make the GGS -\emph on -reliable -\emph default -. - This includes ensuring that the system scales well, and to make sure it - is fault tolerant. - In order to facilitate scalability, we need a storage platform which is - accessible and consistent among all of the GGS, this is also investigated. -\end_layout - -\begin_layout Section -Limitations of the prototype -\end_layout - -\begin_layout Standard -The implementation of the GGS protocol, together with storage possibilities, - server capacity, and game language support imposes some limitations on - the project. - To get a functional prototype some limits must be set on the types games - that can be played on the prototype. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{UDP}}{User Datagram Protocol, a connectionless networking protocol} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{TCP}}{Transmission Control Protocol, a streaming network protocol} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The UDP protocol is not supported for communication between client and server. - The TCP protocol was chosen in favour of UDP, due to the fact that the - implementation process using TCP was faster than if UDP would have been - used. - UDP is generally considered to be faster than TCP for the transfer of game - (and other) related data, this is discussed in more depth in -\begin_inset CommandInset ref -LatexCommand vref -reference "sec:Choice-of-network" - -\end_inset - -. - In short, the decision of using TCP means that games that requires a high - speed protocol will not be supported by the GGS prototype. - Another limitation necessary to set on the system is the possibility to - have huge game worlds due to the implementation of the scaling mechanism - in the prototype. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Latency}}{A measure of delay, often measured in milliseconds} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -In real time games all players are playing together at the same time. - Latency is a huge problem in real time games, a typical round trip time - for such games are one of -\begin_inset Formula $50$ -\end_inset - - to -\begin_inset Formula $150ms$ -\end_inset - - and everything above -\begin_inset Formula $200ms$ -\end_inset - - is reported to be intolerable -\begin_inset CommandInset citation -LatexCommand citet -key "Farber:2002:NGT:566500.566508" - -\end_inset - -. - Latency sensitive games include most of the first person shooters with - multiplayer ability, for example -\emph on -Counter Strike -\emph default - or massively multiplayer online role playing games (MMORPG:s), for example - -\emph on -World of Warcraft -\emph default -. -\end_layout - -\begin_layout Standard -In turn based games each player has to wait for their turn. - Latency is not a problem since the gameplay does not require fast interactions - among the players, long round trip times will not be noticed. - Examples of turn based games include board and card games, as well as multiplay -er games like -\emph on -Jeopardy -\emph default -. - Both game types have varying difficulties and needs when it comes to implementi -ng them, a Generic Game Server should address all of them and help the developer - to accomplish his goal. -\end_layout - -\begin_layout Standard -Due to the limited capability of threading in many GDL VM:s, the GGS prototype - will not support MMORPG:s. -\end_layout - -\begin_layout Standard -The implementation of the GGS described in this thesis is only a small prototype - and tests will be performed on simple games like pong or chess, thus there - are no need to implement more advanced features in the system. - Note that these limitations only apply for the prototype of the project, - and that further developments to the GGS could be to implement these features. -\end_layout - -\begin_layout Section -Method -\end_layout - -\begin_layout Standard -A prototype was developed early on in the project to carry out experiments. - Using this prototype, the system was divided into modules. - A demand specification was created, using this specification, the modules - were easily identifiable. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Module}}{A part of a larger system} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The first prototype of the GGS consisted of simple modules, however, due - to the separation of concerns among the modules, they were easily independently - modified and improved. -\end_layout - -\begin_layout Standard -Once the basic structure of the GGS had been established, the first prototype - was removed, remaining was the structure of the modules and the internal - flow of the application. -\end_layout - -\begin_layout Standard -Design This could be seen as an interative workflow, with the first prototype - being the first iteration. - The second iteration later became the final result of the GGS. -\end_layout - -\begin_layout Standard -The layout of the GGS is both layered and modular. - The first layer handles the most primitive data and produces a higher level - representation of the data, passing it along to different modules of the - GGS. - The modular structure of the GGS plays an important role in making the - system fault tolerant. - The approach to fault tolerance is by replication, and restarting the faulting - modules with the last known good data. -\end_layout - -\begin_layout Standard -An informal specification and list of requirements of the system was outlined - early on in the project. - Usaility goals for developers were set. - During the project several demo applications were constructed, by constructing - these applications, the usability goals were enforced. -\end_layout - -\begin_layout Chapter -Theory behind the GGS -\begin_inset CommandInset label -LatexCommand label -name "cha:Theory" - -\end_inset - - -\end_layout - -\begin_layout Standard -In this chapter, the theory behind the techniques used in the GGS are discussed. - Performance issues and the measuring of performance is discussed. - Benchmarking techniques are discussed. - The options when choosing network protocols are given, along with a discussion - of each alternative. - Finally, an overview of scalability, fault tolerance and availability are - presented. -\end_layout - -\begin_layout Section -Design of the GGS system -\begin_inset CommandInset label -LatexCommand label -name "sec:Design-of-the" - -\end_inset - - -\end_layout - -\begin_layout Standard -The GGS is modeled after a real world system performing much of the same - duties as GGS. - This is common practice -\begin_inset CommandInset citation -LatexCommand citep -key "armstrong2011" - -\end_inset - - in the computer software world, to understand complex problems more easily. - While there may not always be a real world example of a system performing - the exact duties of the system being modeled in the computer, it is often - easier to create and analyze requirements for real world systems and processes - than systems existing solely in a computer. - The requirements and limitations imposed on the real-world system can, - using the proper tools, be transferred in to the software. -\end_layout - -\begin_layout Standard -The real world system chosen for the GGS is a -\begin_inset Quotes eld -\end_inset - -Chess club -\begin_inset Quotes erd -\end_inset - - - a building where chess players can meet and play chess. - Since a real-world scenario is readily available, and to such a large extent - resembles the computer software required for the GGS, the next step in - developing the GGS system is to duplicate this real world scenario in a - software setting. -\end_layout - -\begin_layout Standard -Some requirements, limitations and additions were made to the chess club - system, so that the system would more easily and efficiently be replicated - in a software setting. -\end_layout - -\begin_layout Standard -In the text below, two examples will be presented. - On example is that of a real-world chess club, in which players meet to - play chess against each other, the other example is the GGS, and how it - corresponds to this chess club. - -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/theory_layout.eps - scale 40 - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "fig:theory-layout" - -\end_inset - -The layout of a physical -\begin_inset Quotes eld -\end_inset - -Chess club -\begin_inset Quotes erd -\end_inset - - with two players (P) sitting by each chess table (Table), a coordinator - keeps track of all moves and players in the building. - A player has to pass by the entrance to enter or exit the building. - The building is represented by the outermost box. -\end_layout - -\end_inset - - -\end_layout - -\end_inset - -In figure -\begin_inset CommandInset ref -LatexCommand vref -reference "fig:theory-layout" - -\end_inset - - a graphical representation for the chess club is presented. - The club is seen from above. - The outermost box represents the building. - In the GGS setting, the building would represent one instance of GGS. - Several buildings linked together would represent a cluster of GGS instances. - In order for a player (the P symbol in the graphic) to enter the theoretical - chess club, the player must pass by the entrance. - By having each player pass by the entrance, a tally -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Does this mean what I think it does? -\begin_inset Quotes eld -\end_inset - -Räkning -\begin_inset Quotes erd -\end_inset - - ? -\end_layout - -\end_inset - - can be kept, ensuring that there are not too many players within the building. - In the GGS setting, too many players entering would mean too many connections - have been accepted by the GGS system, and that the structure of the system - thus must be modified, adding additional servers. -\end_layout - -\begin_layout Standard -Once a player has been allowed in to the chess club the player is greeted - by the host of the chess club, in the GGS setting represented by the -\emph on -Coordinator -\emph default -, and is seated by a table. - The coordinator keeps track of all the players in the building, and all - moved made by the players. - The information available to the coordinator means that cheating can be - monitored and book keeping can be performed by this entity. -\end_layout - -\begin_layout Standard -Moves by players are made using the tables present in the chess club. - Every game is isolated to a table, just as expected. - This means that communication during a game only has to pass by the players - of that particular game, and the coordinator, making sure that no cheating - takes place. -\end_layout - -\begin_layout Standard -This isolation of the games play an important part in many properties of - the GGS, the isolation means that games can for example be transferred - among different chess clubs, furthermore, if cheating takes place, corruption - can only occur in the particular table where it was found, and can not - spread. -\end_layout - -\begin_layout Standard -Moving chess players from one location to another is one alteration made - to the real world chess club system to make the system more appropriate - for a software setting. - Allowing games to be transferred is not a property usually desired in a - real world chess club, where transferring players would mean moving the - players from one building to another. - In the software setting, moving players means moving the game processes - from one system to another, perhaps to balance the system load. - This transfer of players can occur transparently, without notifying the - players. -\end_layout - -\begin_layout Standard -The simplified life cycle of a game in GGS can be viewed using algorithm - -\begin_inset CommandInset ref -LatexCommand vref -reference "alg:game-lifecycle" - -\end_inset - -. - To make this life cycle as efficient and useful as possible, the scalability, - fault tolerant and generic traits are added to the GGS. - These are not shown in the algorithm, as these traits are tools in making - the algorithm behaves as efficient as possible, and are not the main focus - when studying the life cycle of a game. -\end_layout - -\begin_layout Standard -The limits imposed in -\begin_inset CommandInset ref -LatexCommand vref -reference "alg:game-lifecycle" - -\end_inset - - are arbitrary for this example, there are no limits in the GGS on the number - of players connecting, for example. -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{algorithmic}[1] -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -newcommand{ -\backslash -INDSTATE}[1][1]{ -\backslash -STATE -\backslash -hspace{#1 -\backslash -algorithmicindent}} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -while -\series default - -\begin_inset Formula $players<2$ -\end_inset - -: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - -\series bold -if -\series default - a player connects, call -\emph on -connected -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -while -\series default -the game commences: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -call the function -\emph on -game -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -when -\series default - the game has stopped -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -call the function -\emph on -endGame -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -function -\series default -connected: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -assign the new player an id -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -alert the coordinator of the new player -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - -\series bold -if -\series default - a free table does not exist: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE[2] -\end_layout - -\end_inset - -the coordinator creates a new table -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -the coordinator places the player by the table, and begins watching the - player -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -function -\series default - game -\series bold -: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - perform game-specific functions. - In chess, the rules of chess are placed here -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -function -\series default -endGame: -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -alert the coordinator, de-registering the players -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - -disconnect the players from the system, freeing system resources -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{algorithmic} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:game-lifecycle" - -\end_inset - -A very simple example of the flow through the GGS system when a game played. -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Performance -\end_layout - -\begin_layout Standard -There are many ways in which performance could be measured. - For the clients, time and response times are useful measurements in time - critical settings. - In non-time critical settings, the reliability of message delivery may - be an even more important factor than speed. -\end_layout - -\begin_layout Standard -In a first person shooter game, the speed of delivery of messages is essential. - Failure to deliver messages in time results in choppy gameplay for the - players. - In strategy games, the reliability of delivery may be more important than - the speed, since the game is not perceieved as choppy even if the messages - are delayed. -\end_layout - -\begin_layout Standard -For someone operating a GGS, it is perhaps more interesting to measure the - system load, memory consumption, energy consumption and network saturation. - These topics are discussed in theory in this section. - The practical results for the prototype is discussed in chapter -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Implementation-of-a" - -\end_inset - -. -\end_layout - -\begin_layout Subsection -Performance measurements -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Tue apr 26, 9:15. - Continue from here on. - Discuss which results we may expect in a fully fledged GGS system. - What impedes the speeds, what raises the CPU load (and therefore the temperetur -es & power consumption). - What factors are there in the network saturation problem? -\end_layout - -\begin_layout Plain Layout -Which games are affected by what, and what does this mean for the number - of players a GGS can handle? -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -How many players can we have on a server? Performance differences between - games? e.g can one game have thousands players on a server and another only - have hundreds? Questions -\end_layout - -\begin_layout Standard -In the current state game servers is coded for each game that needs it, - in many cases this seems like a bad solution. - Developers that want to make a network game need to understand network - programming. - A way to change this is a generic game server which give the game developers - a server which they implement their game towards. - This approach would not only make it easier to develop network games, it - would also allow games in different programming languages to be implemented - using the same server. - to be discussed here. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Create a game with several thousand players, see how our server scales, - how can we improve the performance? Sharding isn’t very nice.. - alternatives? Improve the speed of sharding? -\end_layout - -\begin_layout Itemize -See how the server scales -\end_layout - -\begin_deeper -\begin_layout Itemize -When adding many clients -\end_layout - -\begin_deeper -\begin_layout Itemize -Measure in -\begin_inset Formula $ms$ -\end_inset - - (ping to clients) -\end_layout - -\begin_layout Itemize -measure in system load -\end_layout - -\begin_layout Itemize -Measure in loss of messages -\end_layout - -\begin_layout Itemize -Measure in # of timeouts? (if any??) -\end_layout - -\begin_layout Itemize -Measure in time-to-crash -\end_layout - -\end_deeper -\begin_layout Itemize -When adding new machines to the pool -\end_layout - -\begin_deeper -\begin_layout Itemize -% increase of performance per machine -\end_layout - -\end_deeper -\begin_layout Itemize -Single-core CPU vs multi-core CPU -\end_layout - -\begin_deeper -\begin_layout Itemize -It's very important to scale well on multi-core systems, since this is where - the industry is going. - Multicore is the future. -\end_layout - -\end_deeper -\end_deeper -\begin_layout Plain Layout -Find reference on how to benchmark distributed, multiprocess systems -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Choice of network protocol -\begin_inset CommandInset label -LatexCommand label -name "sec:Choice-of-network" - -\end_inset - - -\end_layout - -\begin_layout Standard -There are three main ways in which computer communication over the Internet - usually takes place; TCP, UDP and HTTP. - The first two is transport layer protocols, which are commonly used to - transport application layer protocols, such as HTTP. - TCP and UDP can not be used on their own, without an application layer - protocol on top. - Application layer protocols such as HTTP on the other hand needs a transport - layer protocol to work. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{HTTP}}{Hyper Text Transport Protocol, a network protocol commonly - used to deliver web pages} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -HTTP -\end_layout - -\begin_layout Standard -Since HTTP is so widely used on the Internet today in web servers, it is - available on most Internet connected devices. - This means that if HTTP is used in the GGS, firewalls will not pose problems, - which is a great benefit. - However, due to the intended usage of HTTP in web servers, the protocol - was designed to be stateless and client-initiated. - In order to maintain a state during a game session using HTTP, some sort - of token would have to be passed between client and server at all times, - much like how a web server works. - These facts combined makes HTTP unsuitable for our purposes, since the - GGS requires a state to be maintained throughout a session, and also needs - to push data from the server to clients without the clients requesting - data. - It should also be mentioned that HTTP uses the TCP protocol for transport, - and what is said about TCP also applies to HTTP. - -\end_layout - -\begin_layout Subsection -UDP -\end_layout - -\begin_layout Standard -Many online games use UDP as the carrier for their application layer protocol. - UDP moves data across a network very quickly, however it does not ensure - that the data transferred arrives in consistent manner. - Data sent via UDP may be repeated, lost or out of order. - To ensure the data transferred is in good shape, some sort of error checking - mechanisms must be implemented. - UDP is a good choice for applications where it is more important that data - arrives in a timely manner than that all data arrives undamaged, it is - thus very suitable for media streaming, for example. - In the GGS reliability of transfer was chosen before the speed of the transfer, - ruling out UDP as the transport later protocol. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Perhaps we should only say that we chose TCP just for our GGS prototype - and why. - If we leave it like that it seems that we think it is not suitable. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -TCP -\end_layout - -\begin_layout Standard -For reliable transfers, TCP is often used on the Internet. - Built in to the protocol is the error checking and correction mechanisms - missing in UDP. - This ensures the consistency of data, but also makes the transfer slower - than if UDP had been used. - In the GGS, data consistency is more important than transfer speeds, and - thus TCP is a better alternative than UDP. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Same here it is simply not true for a generic server to chose one or the - other. - We should rephrase it so it is clear that we only state it about the GGS - prototype. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Generic -\begin_inset CommandInset label -LatexCommand label -name "sec:Generic" - -\end_inset - - -\end_layout - -\begin_layout Standard -The GGS is a game server. - It was made with a desire to be suitable for any kind of game. - Any game with a client-server behaviour should be perfectly suited for - GGS. - A game should not only be able to vary in terms of genre, graphics, gameplay - etc, but also in the way the game is implemented. - Such as different programming languages. - The GGS should be OS independent and run on Windows, OSX and Linux. - The GGS can be run as a listen server on the players computer and host - games locally. - It could also be a dedicated server running on independent hardware. - It is meant to run any game in any environment in any way desired, therefor - being as generic as possible. -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Bad name of the chapter, but here we should give the theory of how the server - is generic -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Fault Tolerance -\begin_inset CommandInset label -LatexCommand label -name "sec:Fault-Tolerance" - -\end_inset - - -\end_layout - -\begin_layout Standard -Fault tolerance is an important factor in all servers, a server that is - fault tolerant should be able to follow a given specification when parts - of the system failures. - This means that fault tolerance is different in each system depending on - what specification they have. - A system could be fault tolerant in different aspects, one is where the - system is guaranteed to be available but not safe and it could also be - reversed, that the system is safe but not guaranteed to be available. - Depending on the system one property may be more important(some example - here). - A system could also have non existent fault tolerance or it could be both - safe and guaranteed to be available. - It should be noted that it is not possible to achieve complete fault tolerance, - a system will always have a certain risk of failure. - Therefore the goal is to make the GGS prototype as fault tolerant as possible. -\end_layout - -\begin_layout Standard -To make the GGS prototype fault tolerant the programming language Erlang - has been used. - Erlang will not guarantee a fault tolerant system but it has features that - support and encourage the development of fault tolerant systems. - In the GGS it is important that the system overall is fault tolerant. - Crashes of the whole system should be avoided as this would make the system - unusable for a time. - By using supervisor structures it is possible to crash and restart small - parts of the system, this is convenient as fault can be handled within - small modules thus never forcing a crash of the system. -\end_layout - -\begin_layout Standard -The need for fault tolerance in game servers are not as obvious as it may - be for other type of servers. - In general all servers strive to be fault tolerant as fault tolerance means - more uptime and a safer system. - This applies to game servers as well, in brief good fault tolerance is - a way of satisfying customers. - In general, game servers differ from many other fault tolerant systems - in that high-availability is more important than the safety of the system. - For example a simple calculation error will not be critical for a game - server but it may be in a life-critical system and then it is better that - the system crashes than works with the faulty data. - There are cases where safety may be critical in game servers, one example - is in games where in-game money exist. -\end_layout - -\begin_layout Subsubsection -Performance penalties -\end_layout - -\begin_layout Section -Availability -\begin_inset CommandInset label -LatexCommand label -name "sec:Availability" - -\end_inset - - -\end_layout - -\begin_layout Standard -One important factor of any server is the availability. - A server to which you are unable to connect to is an useless server. - Other then within telecommunication, their uptime is of about 99,9999999%, - the game developer community has not approached this problem very genuinely - yet so there is much room for improvement. -\end_layout - -\begin_layout Standard -There are several good papers on how to migrate whole virtual machines among - nodes to replicate them -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Add more information about that -\end_layout - -\end_inset - - but for the GGS a different approach has been chosen. - Instead of just duplicating a virtual machine, the programming language - Erlang has been used which offers several features to increase the availability. - Some of them are -\emph on -hot code replacement -\emph default -, where code can be updated while the application is running and without - the need to restart it, the -\emph on -supervisor structure -\emph default - provided by -\emph on -OTP -\emph default - and the inter node and process communication via -\emph on -messages -\emph default - instead of shared memory. - We will discuss each of them later on. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Supervisor}}{A process monitoring and hadning crashes in other processes} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Scalability -\begin_inset CommandInset label -LatexCommand label -name "sec:Scalability" - -\end_inset - - -\end_layout - -\begin_layout Standard -Each instance of the GGS contains several tables. - Each table is an isolated instance of a game, for example a chess game - or a poker game. - The way that the GGS scales is to distribute these tables on different - servers. - In many games it is not necessary for a player to move among tables during - games. - This is for example not a common occurrence in chess, where it would be - represented as a player standing up from her current table and sitting - down at a new table, all within the same game session. - Therefore, the main focus of the GGS is not to move players among tables, - but to keep a player in a table, and to start new tables instead. - When a server has reached a certain number of players the performance will - start to decrease. - To avoid this the GGS will start new tables on another server, using this - technique the players will be close to evenly distributed among the servers. - It is important to investigate and find out how many players that are optimal - for each server. - This approach makes it possible to use all resources with moderate load, - instead of having some resources with heavy load and some with almost no - load. -\end_layout - -\begin_layout Standard -As mentioned in the purpose section there are two different types of scalability -, structural scalability and load scalability. - To make the GGS scalable both types of scalability are needed. - Structural scalability means in our case that it should be possible to - add more servers to an existing cluster of servers. - By adding more servers the limits of how many users a system can have is - increased. - Load scalability in contrast to structural scalability is not about how - to increase the actual limits of the system. - Instead it means how good the system handles increased load. - The GGS should be able to scale well in both categories. -\end_layout - -\begin_layout Subsection -Load balancing -\end_layout - -\begin_layout Standard -The need for load balancing varies among different kind of systems. - Small systems that only use one or a couple of servers can cope with a - simple implementation of it, while in large systems it is critical to have - extensive and well working load balancing. - The need also depends on what kind of server structure that the system - works on. - A static structure where the number of servers are predefined or a dynamic - structure where the number varies. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Amazon EC2}}{A cloud computation service} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Load balancing and scaling is difficult in different scenarios. - When running in a separate server park, there are a set number of servers - available, this means that an even distribution on all servers are preferable. - When running the GGS in a cloud, such as Amazon EC2, it is possible to - add an almost infinite number of servers as execution goes on. - In this cloud setting, it may be more important to distribute evenly load - on newly added servers. -\end_layout - -\begin_layout Standard -Two methods of balancing load (increasing structure): -\end_layout - -\begin_layout Itemize -Fill up the capacity for one server completely, and then move over to the - next server -\end_layout - -\begin_layout Itemize -Evenly distribute all clients to all servers from the beginning, when load - becomes too high on all of them, then comes a new problem: -\end_layout - -\begin_deeper -\begin_layout Itemize -How do we distribute load on these new servers? -\end_layout - -\end_deeper -\begin_layout Standard -Load balancing is a key component to achieve scalability in network systems. - The GGS is a good example of a system that needs to be scalable, to attain - this load balancing is necessary. - Optimization of the load balancing for a system is an important task to - provide a stable and fast load balancer. - There are certain persistence problems that can occur with load balancing, - if a player moves from a server to another data loss may occur. - This is an important aspect to consider when the load balancer is designed - and implemented. -\end_layout - -\begin_layout Standard -Load balancing can often be implemented using dedicated software, this means - that in many applications load balancing may not be implemented because - it already exist functional solutions. - This depends on what specific needs the system has and a minor goal of - the project is to analyze whether the GGS project can use existing load - balancing tools or if it is necessary to implement load balancing in the - project. -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Because P2P game architectures are a constant goal for cheaters and because - “Cheating is a major concern in network games as it degrades the experience - of the majority of players who are honest” and preventing cheating in P2P - game architectures is very difficult game developers try to use Client - - Server architectures which have a natural problem to scale. - In this paper we want to show some strategies to achieve scalability. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -UUID -\begin_inset CommandInset label -LatexCommand label -name "sub:UUID" - -\end_inset - - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{UUID}}{Universally Unique Identifier} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{algorithmic}[1] -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -newcommand{ -\backslash -INDSTATE}[1][1]{ -\backslash -STATE -\backslash -hspace{#1 -\backslash -algorithmicindent}} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - -global variable -\begin_inset Formula $state:=0$ -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -STATE -\end_layout - -\end_inset - - -\series bold -function -\series default -unique -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - -\begin_inset Formula $state:=state+1$ -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -INDSTATE -\end_layout - -\end_inset - - -\series bold -return -\begin_inset Formula $state$ -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{algorithmic} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:A-simple-generator" - -\end_inset - -A simple (insufficient) generator for identifiers -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Inside the GGS, everything has an unique identifier. - There are identifiers for players, tables and other resources. - When players communicate amongst one another, or communicate with tables, - they need to be able to uniquely identify all these resources. - Within one machine, this is mostly not a problem. - A simple system with a counter can be imagined, where each request for - a new ID increments the previous identifier and returns the new identifier - based off the old one, see algorithm -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-simple-generator" - -\end_inset - -. - This solution poses problems when dealing with concurrent and distributed - systems. - In concurrent systems, the simple solution in algorithm -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-simple-generator" - -\end_inset - - may yield non-unique identifiers due to the lack of mutual exclusion. -\end_layout - -\begin_layout Standard -The obvious solution to this problem is to ensure mutual exclusion by using - some sort of lock, which may work well in many concurrent systems. - In a distributed system, this lock, along with the state, would have to - be distributed. - If the lock is not distributed, no guarantee can be made that two nodes - in the distributed system do not generate the same number. - A different approach is to give each node the ability to generate Universally - Unique Identifiers (UUID), where the state of one machine does not interfere - with the state of another. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{MAC Address}}{Media Access Control address, used to identify network - cards} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{SHA-1}}{Cryptigraphic hash function, designed by the National Security - Agency (NSA)} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -According to -\begin_inset CommandInset citation -LatexCommand citet -key "Leach98uuidsand" - -\end_inset - -, -\begin_inset Quotes eld -\end_inset - -A UUID is 128 bits long, and if generated according to the one of the mechanisms - in this document, is either guaranteed to be different from all other UUIDs/GUI -Ds generated until 3400 A.D. - or extremely likely to be different -\begin_inset Quotes erd -\end_inset - -. - This is accomplished by gathering several different sources of information, - such as: time, MAC addresses of network cards, and operating system data, - such as percentage of memory in use, mouse cursor position and process - ID:s. - The gathered data is then -\emph on -hashed -\emph default - -\begin_inset space ~ -\end_inset - -using an algorithm such as SHA-1. -\end_layout - -\begin_layout Standard -When using system wide unique identifiers, such as the ones generated by - algorithm -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-simple-generator" - -\end_inset - - with mutual exclusion, it is not possible to have identifier collisions - when recovering from network splits between the GGS clusters. - Consider figure -\begin_inset CommandInset ref -LatexCommand ref -reference "fig:network-split" - -\end_inset - -, where -\emph on -Site A -\emph default - is separated from -\emph on -Site B -\emph default - by a faulty network (illustrated by the cloud and lightening bolt). - When -\emph on - -\emph default -the decoupled node -\emph on - -\emph default -and -\emph on - -\emph default -the rest of the network later re-establish communication, they may have - generated the same ID:s if using algorithm -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-simple-generator" - -\end_inset - -, even when mutual system-wide exclusion is implemented. - This is exactly the problem UUID:s solve. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Network split}}{Separation of two networks, occurs when two networks - can not communicate, commonly because of a hardware or software failiure} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/netsplit2.eps - scale 40 - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Add clients on each side, and replace the cloud with phole-landlines being - cut by a pair of scissors -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "fig:network-split" - -\end_inset - -An example of a network split -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Security -\end_layout - -\begin_layout Standard -We only support languages running in a sandboxed environment. - Each game session is started in its own sandbox. - The sandboxing isolates the games in such a way that they can not interfere - with each other. - If sandboxing was not in place, one game could potentially modify the contents - of a different game. - A similar approach is taken with the persistent storage we provide. - In the storage each game has its own namespace, much like a table in a - relational database. - A game is not allowed to venture outside this namespace, and can because - this not modify the persistent data of other games. - of this not modify the persistent data of other games. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Sandbox}}{A protected environment in which computer software can - be run safely} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Encryption -\end_layout - -\begin_layout Section -Game Development Language in a Virtual Machine -\begin_inset CommandInset label -LatexCommand label -name "sec:Game-Development-Language" - -\end_inset - - -\end_layout - -\begin_layout Standard -There is only a very limited number of game developers who would like to - write their games in Erlang, therefore we had to come up with something - to resolve this problem. - The main idea was to offer a replacable module which would introduce a - interface to different virtual machines which would run the game code. - This way a game developer can write the game in his favourite language - while the server part still is written in Erlang and can benefit from all - of its advantages. -\end_layout - -\begin_layout Subsection -JavaScript -\end_layout - -\begin_layout Standard -JavaScript has gained a lot of popularity lately, it is used in large projects - such as -\emph on -Riak -\emph default - -\begin_inset Foot -status open - -\begin_layout Plain Layout -\begin_inset Flex URL -status collapsed - -\begin_layout Plain Layout - -http://wiki.basho.com/An-Introduction-to-Riak.html -\end_layout - -\end_inset - - -\end_layout - -\end_inset - -, -\emph on -CouchDB -\emph default - -\begin_inset Foot -status open - -\begin_layout Plain Layout -\begin_inset Flex URL -status collapsed - -\begin_layout Plain Layout - -http://couchdb.apache.org -\end_layout - -\end_inset - - -\end_layout - -\end_inset - -. - On the popular social coding site -\emph on -GitHub.com -\emph default -, 18% -\begin_inset Foot -status open - -\begin_layout Plain Layout -during the writing of the thesis the percentage went up to 19% -\begin_inset Flex URL -status collapsed - -\begin_layout Plain Layout - -https://github.com/languages/ -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - of all code is written in JavaScript. - The popularity of JavaScript in the programming community, in combination - with the availability of several different JavaScript virtual machines - was an important influence in choosing JavaScript as the main control language - for our GGS prototype. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{CouchDB}}{Database server} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Riak}}{Database server} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{GitHub.com}}{Social coding website} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{ActionScript}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Lua}}{Programming language} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{.NET}}{Software platform} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Other languages -\end_layout - -\begin_layout Standard -Other languages like -\emph on -lua -\emph default -, -\emph on -ActionScript -\emph default - are suitable as well because there is a virtual machine for each of them - which can be -\begin_inset Quotes eld -\end_inset - -plugged in -\begin_inset Quotes erd -\end_inset - - into our GDL VM interface. - With help of the -\emph on -Java Virtual Machine -\emph default - or the -\emph on -.NET -\emph default -environment it is even possible to run nearly every available programming - language in a sandbox as a GDL. -\end_layout - -\begin_layout Standard -Due lack of time we have decided to use just the Erlang <-> JavaScript bridge - with our interface. -\end_layout - -\begin_layout Section -Testing -\end_layout - -\begin_layout Standard -There are several ways in which the GGS can be tested. - The most important aspect has been deemed to be the experience players - have when using the GGS. - In order to test the user experience of the GGS, a realistic usage scenario - has to be set up. -\end_layout - -\begin_layout Standard -The GGS is intended to be used for powering games which have many concurrent - players. - The players need not participate in the same instance of the game, games - such as chess are prime candidates for the GGS. -\end_layout - -\begin_layout Standard -When developing the GGS, two main categories of games exhibiting different - performance demands were identified; real-time games and turn-based games. - The real-time games were deemed more demanding than the turn based games. - Tests were carried out using a real time game, since this is the more demanding - type of games. -\end_layout - -\begin_layout Standard -The real time game chosen for testing the GGS is -\emph on -Pong -\emph default -, a game in which two players play a game involving a all and two paddles. - The goal for each player is to shoot eside the othre player's paddle while - not allowing the ball to pass by her own paddle. - The game requires real time updates and is quite demanding when played - in several instances concurrently. -\end_layout - -\begin_layout Standard -There has been some work on the area of testing game servers, see -\begin_inset CommandInset citation -LatexCommand citet -key "Lidholt02designand" - -\end_inset - -, who describes a test bench using -\emph on -bots -\emph default - for testing his generic hazard-gaming server. - Lidholt describes how his server, capable of running several different - casino games is tested using artificial players, so called bots. - Performance is measured in -\begin_inset Quotes eld -\end_inset - -number of clients -\begin_inset Quotes erd -\end_inset - - able to connect to the server, and the system load. -\end_layout - -\begin_layout Standard -Similar tests were performed on the GGS, and the results of these tests - are visible in chapter -\begin_inset CommandInset ref -LatexCommand ref -reference "chap:Results-and-discussion" - -\end_inset - -. - The tests were initially performed by starting an operating system process - for each player. - Due to lack of hardware, not enough player processes could be started in - this way. - The bots were re-written in Erlang, and due to Erlang's light weigh threads, - enough processes could be created to successfully test the server. -\end_layout - -\begin_layout Chapter -Implementation of a prototype -\begin_inset CommandInset label -LatexCommand label -name "cha:Implementation-of-a" - -\end_inset - - -\end_layout - -\begin_layout Standard -This chapter contains the realization of much of the principles and techniques - described in chapter -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Theory" - -\end_inset - -. - Here the problems and solutions are discussed in greater detail, and at - times the text becomes more specific to the GGS. -\end_layout - -\begin_layout Standard -Much of what is discussed in this chapter has been implemented in the Erlang - GGS prototype. - Specific solutions such as -\emph on -supervisor structures -\emph default -and distribution of erlang nodes on physical nodes. - The different means of communications within the GGS and outside the GGS - with third parties are also discussed here. -\end_layout - -\begin_layout Section -Overview of the prototype -\end_layout - -\begin_layout Standard -The prototype of the GGS was developed using the Erlang language. - The functional and concurrent style of Erlang facilitates devlopment of - software based on a real-world model -\begin_inset CommandInset citation -LatexCommand citep -key "armstrong2011" - -\end_inset - -. - In Erlang, most things are processes. - The software running the Erlang code is known as the Erlang machine, or - an Erlang node. - Each Erlang node is capable of running several -\emph on -threads -\emph default -(also known as -\emph on -Light Weight Processes; LWP -\emph default -) -\emph on -, -\emph default -much like the threads in an operating system. - Threads in a Linux system, for example, are treated much like operating - system processes in different systems. - Due to the size of datastructures related to each process, swapping one - process for another (known as -\emph on -context switching -\emph default -) is an expensive task in many systems -\begin_inset CommandInset citation -LatexCommand citep -after "pg 80" -key "McKusick:2004:DIF:1014910" - -\end_inset - -. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{LWP}}{Light Weight Process} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Context switch}}{The act of switching from one context, commonly - a process, to another. - Used by operating systems to achieve multi tasking} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The cost of swapping operating system processes becomes a problem when many - processes are involved. - If the GGS system had been developed using regular operating system processes, - it would have had to be designed in a way to minimize the number of processes. - Using Erlang, which is capable of running very many processes, several - times more than an operating system can, the mapping between the real world - system (described in -\begin_inset CommandInset ref -LatexCommand vref -reference "sec:Design-of-the" - -\end_inset - -) becomes clearer. -\end_layout - -\begin_layout Standard -Erlang allows the GGS to create several process for each player connecting, - these processes can handle a multitude of different tasks, parsing data - for example. - Since each task is handled by a different process, the tasks are clearly - separated and the failiure of one is easily recovered without affecting - the others. -\end_layout - -\begin_layout Standard -In addition to creating (or -\emph on -spawning -\emph default -) processes specifically to handle new players connecting, the GGS has more - permanent processes running at all times. - The constantly running processes in the GGS system are called -\emph on -modules -\emph default -. - An example of a module in the GGS is the -\emph on -dispatcher module -\emph default -, which handles the initial connection made by a client, passing the connection - along further in to the system. -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/Chess_no_text.eps - width 100text% - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "fig:The-layout-of" - -\end_inset - -The layout of the GGS. - The circles marked with 'C' topmost in the picture represent clients. - The cloud marked 'network' pictured directly below the clients can be any - network, for example the Internet. - The barell figure marked 'backup' is a process being fed backup data from - the coordinator. - The barell marked 'State' contains the state of a table, and this is fed - into the box marked 'Mnesia' which is database. - Finally the figure shaped as a shield marked 'GameVM' contains the actual - game process. -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -In figure -\begin_inset CommandInset ref -LatexCommand vref -reference "fig:The-layout-of" - -\end_inset - - the entire GGS system is represented graphically. - The circles marked with 'C' topmost in the picture represent game clients. - These circles represent processes running on gamers' computers, and not - on the GGS machine. - If a game of chess is to be played on the server, the clients on the gamers' - machines will be chess game clients. - Clients connect through a network, pictured as a cloud, to the dispatcher - process in the GGS. - The dispatcher process and all other modules are discussed in -\begin_inset CommandInset ref -LatexCommand vref -reference "sec:The-modular-structure" - -\end_inset - -. - For each connection, a new player process is spawned, which immediately - after spawning is integrated in to the GGS by the coordinator process. -\end_layout - -\begin_layout Section -The usage of Erlang in the GGS -\begin_inset CommandInset label -LatexCommand label -name "sec:The-usage-of-erlang" - -\end_inset - - -\end_layout - -\begin_layout Standard -Erlang was designed by Ericsson, beginning in 1986, for the purpose of creating - concurrent applications and improving telecom software. - Features essential for the telecom instustry to achieve high availability - in telecom switches were added to the language. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Mutex}}{A construct for achieving mutial exclusion, used to avoid - simultaneous access to shared resources in computer systems} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Erlang uses message passing in favour of shared memory, mutextes and locks, - something which at the time was controversial among fellow developers -\begin_inset CommandInset citation -LatexCommand citet -key "Armstrong:2010:ERL:1810891.1810910" - -\end_inset - -. - The reason for using message passing, according to Armstrong, was that - applications should operate correctly before optimizations are done, where - efficient internal communication within the Erlang machine was considered - a later optimization. -\end_layout - -\begin_layout Standard -In using message passing in favour of the methods commonly used at the time, - the issues commonly associated with shared memory and locking were avoided. - In Erlang, everything is a process, and everything operates in its own - memory space. - Memory can not be shared among processes, which prohibits a process from - corrupting the memory of a different process. -\end_layout - -\begin_layout Standard -Messages are sent between the processes in an asynchronous manner, and each - process has a mailbox in which these messages can be retrieved. -\end_layout - -\begin_layout Standard -Processes in Erlang are also called -\emph on -Light Weight Processes. - -\emph default -The Erlang processes are very cheaply created. - Processes exist within an Erlang machine, or Erlang node. - The Erlang machine has its own scheduler and does not rely on the operating - system's scheduler, this is a main reason of Erlang's capability of running - many concurrent processes -\begin_inset CommandInset citation -LatexCommand citet -key "Armstrong03" - -\end_inset - -. -\end_layout - -\begin_layout Standard -The strong isolation of Erlang processes make them ideal for multicore and - distributed systems. - Distribution of software is included as a fundamental part in the Erlang - language. - The 'physical' location of a process, e.g. - which computer the process runs on, is not important when communicating - with the process. - Processes can communicate regardless of whether they run on the same system - of not, transparently. -\end_layout - -\begin_layout Standard -The distributed nature of Erlang is something the GGS makes use of when - scaling across several computers in order to achieve higher performance. - The distribution is also important in creating redundancy. - Erlang promotes a non-defensive programming style in which processes are - allowed to crash and be restarted in favour of having the processes recover - from errors. - The distributed nature of Erlang means supervisor processes (discussed - in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:Supervisor-structure" - -\end_inset - -) can reside on remote systems, thereby increasing the reliability of the - system as a whole. -\end_layout - -\begin_layout Standard -A very important feature of Erlang, used in the GGS, is the ability to interface - with external hardware and software. - Erlang allows communication with external resources through -\emph on -ports. - -\emph default - Through ports communication can take place much in the same way communication - is performed over sockets. -\end_layout - -\begin_layout Standard -The GGS uses Erlang ports for generating UUID:s -\begin_inset Foot -status collapsed - -\begin_layout Plain Layout -UUID:s are discussed in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:UUID" - -\end_inset - - -\end_layout - -\end_inset - - and for interfacing with the virtual machines of games -\begin_inset Foot -status collapsed - -\begin_layout Plain Layout -Virtual machines of games are discussed in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Game-Development-Language" - -\end_inset - - -\end_layout - -\end_inset - -. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{OTP}}{Open Telecom Platform, a software suite for Erlang} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Behaviour}}{A design pattern in OTP} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Development of the GGS would have been hard if not impossible had it not - been for the -\emph on -OTP -\emph default - supplied with the standard Erlang distribution. - The OTP (Open Telecom Platform) is a set of standard libraries and design - patterns, called -\emph on -behaviours -\emph default -, which are used when developing Erlang systems. -\end_layout - -\begin_layout Standard -The GGS makes heavy use of the behaviours supplied in the OTP. - The behaviours impose a programming style suitable for distributed and - concurrent applications, perfectly suitable for the GGS. - In particular, the GGS uses the following behaviours: -\end_layout - -\begin_layout Itemize -The -\emph on -supervisor -\emph default - behaviour, which is used when creating a supervisor. - Supervisors are used when monitoring processes in the Erlang system. - When a process exits wrongfully, the supervisor monitoring the process - in question decides which action to take. - In the GGS, the most common action is simply to restart the faulting process. - A more thorough discussion on supervisors can be found in section -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:Supervisor-structure" - -\end_inset - -. -\end_layout - -\begin_layout Itemize -The -\emph on -gen_tcp -\emph default -behaviour, which is used to work with TCP sockets for network communication. - Using the gen_tcp behaviour, network messages are converted to internal - Erlang messages and passed to a protocol parser, where the messages are - processed further. -\end_layout - -\begin_layout Itemize -The -\emph on -gen_server -\emph default - behaviour, which is used when constructing OTP servers in Erlang. - Using this behaviour, a state can easily be kept in a server process, greatly - increasing the usefulness of the server process. - There are many gen_servers in the GGS, it is the most widely used behaviour - in the project. - In addition to intruducing a state to the server, the gen_server behaviour - also imposes patterns for synchronous and asynchronous communication between - other gen_servers and other OTP behaviours. -\end_layout - -\begin_layout Itemize -The -\emph on -gen_fsm -\emph default - behaviour is used in one module in the GGS, the protocol parser. - Using the gen_fsm behaviour, finite state machines are easily developed. - Protocol parsers are an ideal example of where to use finite state machines, - which are widely used for parsing strings of text. -\end_layout - -\begin_layout Standard -In addition to supplying behaviours, the OTP also has a style for packaging - and running Erlang applications. - By packaging the GGS as an -\emph on -application -\emph default -the GGS can be started in a way uniform to most erlang software, providing - familiarity for other Erlang users, and eases the incorporation of the - GGS in other applications. -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Application}}{A way of packaging Erlang software in a uniform way} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Short introduction to the Erlang syntax -\end_layout - -\begin_layout Standard -In order to understand examples in this thesis, a small subset of Erlang - must be understood. - In this section, the very syntactic basics of Erlang are given. -\end_layout - -\begin_layout Itemize - -\series bold -Variables -\series default - start with an uppercase letter, examples include -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt X, Var}, and { -\backslash -tt Global} -\end_layout - -\end_inset - -. - A variable can only be assigned once. -\end_layout - -\begin_layout Itemize - -\series bold -Atoms -\emph on - -\series default -\emph default -start with lower case letters, for example: -\begin_inset ERT -status open - -\begin_layout Plain Layout - - { -\backslash -tt atom, a} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Itemize - -\series bold -Functions -\series default - are defined starting with an atom for the name, parenthesis containing - parameters, an arrow, a function body and finally a dot marking the end - of a function. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt square(X) -> X*X.} -\end_layout - -\end_inset - - is an example of a function producing the square of X. -\end_layout - -\begin_layout Itemize -Functions are -\series bold -called -\series default - by suffixing an atom with the function name with parenthesis, for example - -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt square(10)} -\end_layout - -\end_inset - -. - Qualified names can be specified using ':', for example: -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt math:square(10)} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Itemize - -\series bold -Tuples -\series default - are containers of fixed type for Erlang data types. - They are constructed using curly brackets, for example: -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt -\backslash -{atom1, atom2, atom3 -\backslash -}}. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Itemize - -\series bold -Lists -\series default - are constructed using [ and ], for example: -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt [1,2,3]} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Itemize - -\series bold -Strings -\series default - doubly qouted lists of characters, for example -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt "Hello world"} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Itemize - -\series bold -Records -\series default - are erlang tuples coupled with a tag for each tuple element. - This allows refering to elements by name instead of by position. - An example of a record looks like this: -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt -\backslash -#myRecord{}} -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Section -Communication with external systems and applications -\begin_inset CommandInset label -LatexCommand label -name "sec:Communication-with-external" - -\end_inset - - -\end_layout - -\begin_layout Standard -A game launched on the GGS is run within a virtual machine. - For each programming language supported, there is a virtual machine that - interprets the game. - Furthermore an interface for communication between the GGS, the game and - the players playing the game must be present. -\end_layout - -\begin_layout Standard -The reason for the GGS requiring a communication channel between the game - VM and Erlang is in part because the GGS makes heavy use of callbacks. - Callbacks written in Erlang are registered to the VM for the interface - to work. - It is only with the help of the interface that the game developer can access - the game state and send messages between players. - The interface provides access to three objects called -\emph on -world -\emph default -, -\emph on -player -\emph default - and -\emph on -localstorage -\emph default -. - The game state is safely stored in a database and retrieved for manipulation - by a call for the world object. - Interaction with the players is done the same way using the player object - instead. - The localstorage is a convenient way to store globals and other data seperated - from the game state. - In section -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:Exposing-Erlang-functionality" - -\end_inset - - a concrete example of the implementation of the localStorage and world - objects is given. -\begin_inset Note Note -status open - -\begin_layout Plain Layout - Unique id:s called gametokens are generated for hosted games so that they - are not mixed up. - -- good text, integrate more. -\end_layout - -\end_inset - - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{WebStorage}}{A new standard for letting websites store data on visitors' - computers} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Exposing Erlang functionality to the GDL VM -\begin_inset CommandInset label -LatexCommand label -name "sub:Exposing-Erlang-functionality" - -\end_inset - - -\end_layout - -\begin_layout Standard -This section contains a concrete example of how the localStorage and world - objects are exposed to a GDL VM. - The example comes from the GGS prototype, which uses JavaScript powered - by Google V8 as its GDL VM. -\end_layout - -\begin_layout Standard -The code given in -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:exposing-erlang" - -\end_inset - - is specific to V8 and JavaScript, however implementations for different - GDL:s, or different JavaScript VM:s should be similar. -\end_layout - -\begin_layout Standard -In JavaScript is is common to use a top level object, called a global object, - to establish a global scope. - This allows declaration of global variables and functions. - To gain access to the global object in the GGS, the -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt erlv8 -\backslash -_vm:global(..)} -\end_layout - -\end_inset - - function on line 2 of the example is used. - Using the global object, declarations of the world and GGS object can be - placed in the global scope. -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt Global:set -\backslash -_value(..)} -\end_layout - -\end_inset - - is a call to the global object, declaring new objects in the global scope. - On line 4 the GGS object is declared. - By accessing -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt GGS.localStorage } -\end_layout - -\end_inset - - from within the GDL, access to the localstorage is provided, thus the localstor -age must be connected to the GGS object, this can be seen in line 5. -\end_layout - -\begin_layout Standard -Both the GGS and localStorage objects are dummy objects, which provide no - functionality, these two objects are simply placed in the GDL for the purpose - clearing up the code. - In order to perform an action using the GGS and localStorage objects, the - -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt getItem} and { -\backslash -tt setItem} -\end_layout - -\end_inset - - functions must be used. - These items are directly connected to the database module of the GGS, which - is discussed in more detail in -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:The-database-module" - -\end_inset - -. -\end_layout - -\begin_layout Standard -Similarly the functions -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt sendCommand, sendCommandToAll} and { -\backslash -tt setTimeout} -\end_layout - -\end_inset - - are directly connected to a piece of code in the GGS which performs the - desired action. - The -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt sendCommand} -\end_layout - -\end_inset - - functions are used to send commands or text to participants of the table. - The -\begin_inset ERT -status open - -\begin_layout Plain Layout - -{ -\backslash -tt setTimeout} -\end_layout - -\end_inset - - function introduces timeouts to the V8 engine, which are not available - per default. -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -lstset{ -\end_layout - -\begin_layout Plain Layout - -language=Erlang, -\end_layout - -\begin_layout Plain Layout - -backgroundcolor= -\backslash -color{white}, -\end_layout - -\begin_layout Plain Layout - -extendedchars=true, -\end_layout - -\begin_layout Plain Layout - -basicstyle= -\backslash -footnotesize -\backslash -ttfamily, -\end_layout - -\begin_layout Plain Layout - -showstringspaces=false, -\end_layout - -\begin_layout Plain Layout - -showspaces=false, -\end_layout - -\begin_layout Plain Layout - -numbers=left, -\end_layout - -\begin_layout Plain Layout - -numberstyle= -\backslash -footnotesize, -\end_layout - -\begin_layout Plain Layout - -numbersep=9pt, -\end_layout - -\begin_layout Plain Layout - -tabsize=2, -\end_layout - -\begin_layout Plain Layout - -breaklines=true, -\end_layout - -\begin_layout Plain Layout - -showtabs=false, -\end_layout - -\begin_layout Plain Layout - -captionpos=b -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - - -\backslash -begin{lstlisting}[language=Erlang] -\end_layout - -\begin_layout Plain Layout - -% @doc Exposes some GGS functions to JavaScript -\end_layout - -\begin_layout Plain Layout - -expose(GameVM, Table) -> -\end_layout - -\begin_layout Plain Layout - - Global = erlv8_vm:global(GameVM), -\end_layout - -\begin_layout Plain Layout - - Global:set_value("GGS", erlv8_object:new([ -\end_layout - -\begin_layout Plain Layout - - {"localStorage", erlv8_object:new([ -\end_layout - -\begin_layout Plain Layout - - {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:setItem(Table, local_storage, Key, Val) -\end_layout - -\begin_layout Plain Layout - - end}, -\end_layout - -\begin_layout Plain Layout - - {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:getItem(Table, local_storage, Key) -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - % more functions ... -\end_layout - -\begin_layout Plain Layout - - ])}, -\end_layout - -\begin_layout Plain Layout - - {"world", erlv8_object:new([ -\end_layout - -\begin_layout Plain Layout - - {"setItem", fun(#erlv8_fun_invocation{}, [Key, Val])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:setItem(Table, world, Key, Val), -\end_layout - -\begin_layout Plain Layout - - ggs_table:send_command_to_all( -\end_layout - -\begin_layout Plain Layout - - Table, {"world_set", Key ++ "=" ++ Val} -\end_layout - -\begin_layout Plain Layout - - ) -\end_layout - -\begin_layout Plain Layout - - end}, -\end_layout - -\begin_layout Plain Layout - - {"getItem", fun(#erlv8_fun_invocation{}, [Key])-> -\end_layout - -\begin_layout Plain Layout - - ggs_db:getItem(Table, world, Key), -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - % more functions ... -\end_layout - -\begin_layout Plain Layout - - ])}, -\end_layout - -\begin_layout Plain Layout - - {"sendCommand", fun(#erlv8_fun_invocation{}, [Player, Command, Args])-> -\end_layout - -\begin_layout Plain Layout - - ggs_table:send_command(Table, Player, {Command, Args}) -\end_layout - -\begin_layout Plain Layout - - end}, -\end_layout - -\begin_layout Plain Layout - - {"sendCommandToAll", fun(#erlv8_fun_invocation{}, [Command, Args])-> -\end_layout - -\begin_layout Plain Layout - - ggs_table:send_command_to_all(Table, {Command, Args}) -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - {"setTimeout", fund(#erlv8_fun_invocation{}, [Time, Function])-> -\end_layout - -\begin_layout Plain Layout - - timer:apply_after(Time, ?MODULE, call_js, [GameVM, Function]) -\end_layout - -\begin_layout Plain Layout - - end} -\end_layout - -\begin_layout Plain Layout - - % more functions ... -\end_layout - -\begin_layout Plain Layout - - ])). -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{lstlisting} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:exposing-erlang" - -\end_inset - -An example of how Erlang functionality is exposed to a Javascript GDL -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -TODO: Go in to more detail about how the world, player and localstorage - objects are implemented. - Also discuss localstorage and how it derives from the webstorage standard - in detail. - This is a great point on how we try to follow standards. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -My idea here is that we describe the erlang-js (which failed, but nontheless), - v8, UUID and other external communication. - We shouldn't describe sockets here though.. - or.. - maybe? -\end_layout - -\begin_layout Plain Layout -Also discuss how we allow GDLs to communicate with Erlang, this is -\begin_inset Quotes eld -\end_inset - -external -\begin_inset Quotes erd -\end_inset - - to thre GDL. - Discuss the GGS world object (there is a reference to this secxtion for - that purpose) -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -The modular structure of the GGS prototype -\begin_inset CommandInset label -LatexCommand label -name "sec:The-modular-structure" - -\end_inset - - -\end_layout - -\begin_layout Standard -The separation of concerns, and principle of single responsibility -\begin_inset Foot -status open - -\begin_layout Plain Layout -More information on the SRP is available at: -\begin_inset CommandInset href -LatexCommand href -target "http://www.objectmentor.com/resources/articles/srp.pdf" - -\end_inset - - -\end_layout - -\end_inset - - are widely respected as good practices in the world of software engineering - and development. - By dividing the GGS up into modules each part of the GGS can be modified - without damaging the rest of the system. -\end_layout - -\begin_layout Standard -The responsibility and concern of each module comes from the responsibility - and concern of the real-world entity the model represents. - The modelling of the GGS after a real world system was discussed in chapter - -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Theory" - -\end_inset - -. -\end_layout - -\begin_layout Standard -In the text below the word module refers to the actual code of the discussed - feature, while the word process is used when referring to a running instance - of the code. - Those familiar to object oriented programming may be helped by thinking - in the lines of classes and objects. -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Am I right here? -\end_layout - -\end_inset - - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{SRP}}{Single Responsibility Principle} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Object Oriented Programming}}{A programming paradigm focusing on - objects} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -The dispatcher module -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -The discussion of the modules is divided into the following parts: -\end_layout - -\begin_layout Itemize -What does the module do? -\end_layout - -\begin_layout Itemize -What happens when the module fails? -\end_layout - -\begin_layout Itemize -How does the module correspond to the real-world scenario of the chess club? -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The dispatcher module is the first module to have contact with a player. - When a player connects to the GGS, it is first greeted by the dispatcher - module, which sets up an accepting socket for each player. - -\begin_inset Note Note -status collapsed - -\begin_layout Plain Layout -Is this the proper way to day the dispatcher greets connecting players? -\end_layout - -\end_inset - - The dispatcher is the module which handles the interfacing to the operating - system when working with sockets. - Operating system limits concering the number of open files, or number of - open sockets are handled here. - The operating system limits can impose problems on the GGS, this is discussed - more in detail in chapter -\begin_inset CommandInset ref -LatexCommand vref -reference "cha:Problems-of-implementation" - -\end_inset - -. -\end_layout - -\begin_layout Standard -Should the dispatcher module fail to function, no new connections to the - GGS can be made. - In the event of a crash in the dispatcher module, a supervisor process - immediately restarts the dispatcher. - There exists a window of time between the crashing of the dispatcher and - the restarting of the dispatcher, this window is very short, and only during - this window is the GGS unable to process new connection requests. - Due to the modular structure of the GGS, the rest of the system is not - harmed by the dispatcher process not functioning. - The process does not contain a state, therefore a simple restart of the - process is sufficient in restoring the GGS to a pristine state after a - dispatcher crash -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Well.. - In theory.. -\end_layout - -\end_inset - -. -\end_layout - -\begin_layout Standard -Returning to scenario of the chess club, the dispatcher module is the doorman - of the club. - When a player enters the chess club, the player is greeted by the doorman, - letting the player in to the club. - The actual letting in to the club is in the GGS represented by the creation - of a player process discussed in -\begin_inset CommandInset ref -LatexCommand vref -reference "sub:The-player-module" - -\end_inset - -. - The newly created player process is handed, and granted rights to, the - socket of the newly connected player. -\end_layout - -\begin_layout Subsection -The player module -\begin_inset CommandInset label -LatexCommand label -name "sub:The-player-module" - -\end_inset - - -\end_layout - -\begin_layout Standard -The player module is responsible for representing a player in the system. - Each connected player has its own player process. - The player process has access to the connection of the player it represents, - and can communicate with this player. - In order to communicate with a player, the data to and from the player - object must pass through a protocol parser module, discussed in -\begin_inset CommandInset ref -LatexCommand vref -reference "sub:The-protocol-parser" - -\end_inset - -. - Raw communication, witout passing the data through a protocol parser is - in theory possible, but is not useful. -\end_layout - -\begin_layout Standard -In the creation of a player process, the coordinator process, discussed - in -\begin_inset CommandInset ref -LatexCommand vref -reference "sub:The-coordinator-module" - -\end_inset - -, is notified by the newly connected process. -\end_layout - -\begin_layout Standard -In the event of a crash in a player process, several things happen. - -\end_layout - -\begin_layout Enumerate -The player process, which is the only process with a reference to the socket - leading to the remote client software, passes this reference of the socket - to the coordinator process temporarily. -\end_layout - -\begin_layout Enumerate -The player process exits. -\end_layout - -\begin_layout Enumerate -The coordinator spawns a new player process, with the same socket reference - as the old player process had. -\end_layout - -\begin_layout Enumerate -The player process resumes operation, immediately starting a new protocol - parser process, and begind receiving and sending network messaged again. -\end_layout - -\begin_layout Standard -The window of time between the crash of the player process and the starting - of a new player process is, as with the dispatcher, very short. - Since the connection changes owners for a short period of time, but is - never dropped, the implications of a crash are only noticed, at worst, - as choppy gameplay for the client. - Note however that this crash recovery scheme is not implemented in the - GGS prototype. - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Can we do this..? Seems a bit sneaky. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -Moving back to the real world example, the player process represent an actual - person in the chess club. - When a person sits down at a table in the chess club, the person does so - by requesting a seat from some coordinating person, and is then seated - by the same coordinator. - Once seated, the player may make moves on the table he or she is seated - by, this corresponds clearly to how the GGS is structured, as can be seen - in the following sections. -\end_layout - -\begin_layout Subsection -The protocol parser module -\begin_inset CommandInset label -LatexCommand label -name "sub:The-protocol-parser" - -\end_inset - - -\end_layout - -\begin_layout Standard -The protocol parser is an easily interchangable module in the GGS, handling - the client-to-server, and server-to-client protocol parsing. - In the GGS prototype, there is only one protocol supported, namely the - -\emph on -GGS Protocol -\emph default -. - The role of the protocol parser is to translate the meaning of packets - sent using the prototocol in use to internal messages of the GGS system. - The GGS protocol, discussed below is used as a sample protocol in order - to explain how protocol parsers can be built for the GGS. -\end_layout - -\begin_layout Subsubsection -The structure of the GGS Protocol -\begin_inset CommandInset label -LatexCommand label -name "sub:The-structure-of" - -\end_inset - - -\end_layout - -\begin_layout Standard -The GGS protocol is modelled after the HTTP protocol. - The main reason for this is the familiarity many developers already have - with HTTP due to its presence in internet software. - Each GGS protocol packet contains a headers section. - The headers section is followed by a data section. - In the headers section, parameters concerning the packet is placed. - In the data section, the actual data payload of the packet is placed. -\end_layout - -\begin_layout Standard -There is no requirement of any specific order of the parameters in the headers - section, however the data section must always follow directly after the - headers section. -\end_layout - -\begin_layout Standard -In the example below, line 1 contains a Game-Command parameter. - This parameter is used to determine which game-specific command the client - is trying to perform. - The handling of this parameter is specific to each game, and can be anything. -\end_layout - -\begin_layout Standard -Line 2 specifies a game token. - This is a UUID which is generated for each client upon authentication with - the GGS. - The GGS uses this token in case a client is disconnected and the new connection - created when the client reconnects must be re-paired with the player object - inside the GGS. - The UUID is also used as a unique ID within GDL VMs. -\end_layout - -\begin_layout Standard -Line 3 specifies the content type of the payload of this particular packet. - This parameter allows the GGS to invoke special parsers, should the data - be encoded or encrypted. - When encryption is employed, only the payload is encrypted, not the header - section. - This is a scheme which does not allow for strong encryption, but is deemed - feasible for gaming purposes. -\end_layout - -\begin_layout Standard -Line 4 specifies the content length of the payload following immediately - after the headers section. -\end_layout - -\begin_layout Standard -The parser of the GGS protocol implemented in the GGS prototype is designed - as a finite state machine using the gen_fsm behaviour. - When a full message has been parsed by the parser, the message is converted - into the internal structure of the GGS messages, and sent in to the system - from the protocol paser using message passing. -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Packet below is not an algorithm, but I don't know how to change that label.. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -lstset{ -\end_layout - -\begin_layout Plain Layout - -backgroundcolor= -\backslash -color{white}, -\end_layout - -\begin_layout Plain Layout - -extendedchars=true, -\end_layout - -\begin_layout Plain Layout - -basicstyle= -\backslash -footnotesize -\backslash -ttfamily, -\end_layout - -\begin_layout Plain Layout - -showstringspaces=false, -\end_layout - -\begin_layout Plain Layout - -showspaces=false, -\end_layout - -\begin_layout Plain Layout - -numbers=left, -\end_layout - -\begin_layout Plain Layout - -numberstyle= -\backslash -footnotesize, -\end_layout - -\begin_layout Plain Layout - -numbersep=9pt, -\end_layout - -\begin_layout Plain Layout - -tabsize=2, -\end_layout - -\begin_layout Plain Layout - -breaklines=true, -\end_layout - -\begin_layout Plain Layout - -showtabs=false, -\end_layout - -\begin_layout Plain Layout - -captionpos=b -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - - -\backslash -begin{lstlisting} -\end_layout - -\begin_layout Plain Layout - -Game-Command: chat -\end_layout - -\begin_layout Plain Layout - -Token: e30174d4-185e-493b-a21a-832e2d9d7a1a -\end_layout - -\begin_layout Plain Layout - -Content-Type: text -\end_layout - -\begin_layout Plain Layout - -Content-Length: 18 -\end_layout - -\begin_layout Plain Layout - -\end_layout - -\begin_layout Plain Layout - -Hello world, guys! -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{lstlisting} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:A-sample-packet" - -\end_inset - -A sample packet sent from a client to the GGS during a chat session -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Mention that the protocol is heavily influenced bye HTTP, is parsed using - a FSM, perhaps give a sample packet. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -The coordinator module -\begin_inset CommandInset label -LatexCommand label -name "sub:The-coordinator-module" - -\end_inset - - -\end_layout - -\begin_layout Standard -The coordinator module is responsible for keeping track of all players, - their seats and tables. - Players register with the coordinator process when first connecting to - the server, and the coordinator places each player by their respective - table. -\end_layout - -\begin_layout Standard -The coordinator keeps mappings between each player and table, therefore - it is used to perform lookups on tables and players to find out which are - connected. - The connectivity of players and tables is important when sending messages - to all participants in a game. - A lookup in the coordinator process is performed prior to notifying all - players in a game to ensure the message reaches all players. - The lookup can be performed either using internal identification codes - or using the UUID associated with each client and table. -\end_layout - -\begin_layout Standard -The coordinator process contains important state, therefore a backup process - is kept at allt times. - All good data processed by the coordinator is stored for safekeeping in - the backup process as well. - Data which is potentisally harmful is not stored in the backup process. -\end_layout - -\begin_layout Standard -Upon a crash, the coordinator process recovers the prior good state from - the backup process and continues where it left off. - A supervisor process monitors the coordinator process and restarts the - process when it malfunctions. - There is a window of time between the crash of the coordinator and the - restarting of the coordinator, during this time, players can not be seated - by new tables, and can not disconnect from the server. - This window of time is very small, and the unavailability of the coordinator - process should not be noticed by more than a short time lag for the clients. -\end_layout - -\begin_layout Standard -Moving back to the example of the chess club, the coordinator process can - be seen as a judge, monitoring all moves of the players. - At the same time as acting as a judge, the coordinator process is also - a host in the chess club, seating players by their tables and offering - services to the players. -\end_layout - -\begin_layout Subsection -The table module -\end_layout - -\begin_layout Standard -The table module is mostly a hub used for communication. - New table processes are created by the coordinator on demand. - The table module does not contain any business logic, however each process - contains information concerning which players are seated by that particular - table. -\end_layout - -\begin_layout Standard -The information about which players are seated by each table is used when - notifying all players by a table of an action. - Consider a game of chess, each player notifies the table of its actions, - the table then notifies the rest of the participants of these actions after - having had the ac tions processed by the game VM, where an action could - be moving a playing piece. -\end_layout - -\begin_layout Standard -Each table is associated with a game VM. - The actions sent to a table are processed by the game VM, this is where - the game logic is implemented. -\end_layout - -\begin_layout Standard -After a crash in a table process, the entire table must be rebuilt and the - players must be re-associated with the table. - Data concerning players is kept in the coordinator process, and is restored - from there. - Data kept in the actual game is not automatically corrupted by the crash - in a table, however the table must be re-associated with the game VM is - was associated with prior to the crash of the table. - The table process maps well into the setting of the real-world chess club - scenario previously discussed. - A table works in the same way in a real world setting as in the GGS setting. -\end_layout - -\begin_layout Subsection -The game virtual machine module -\end_layout - -\begin_layout Standard -This module holds the game logic of a game and is responsible for the VM - associated with each game. - -\end_layout - -\begin_layout Standard -The game VM contains the state of the VM and a table token associated with - a running game. - GameVM is started by the table module. - The table module hands over a token to the game VM during initialization. - During initialization a new VM instance and various objects associated - to the VM instance will be created. - Callbacks to Erlang are registered into the VM and then the source code - of a game is loaded into the VM and the game is ready for startup. - The only means for a game to communicate with the VM is through usage of - a provided interface. - -\end_layout - -\begin_layout Standard -The VM itself makes it possible for the game developer to program in the - prograimming language covered by the VM. - In future releases, more game VM:s will be added to support more programming - languages. - Because the game VM keeps track of the correct table, the game developer - doesn't need to take this into consideration when programming a game. - If a method within the game sends data to a player, it will be delivered - to the player in the correct running game. - The same game token is used to store the game state in the database. - Therefore, no game states will be mixed up either. -\end_layout - -\begin_layout Standard -This module does not affect game runtime but evaluates a new game state - and handles communication between the game and the players. -\end_layout - -\begin_layout Subsection -The database module -\begin_inset CommandInset label -LatexCommand label -name "sub:The-database-module" - -\end_inset - - -\end_layout - -\begin_layout Standard -Game data from all games on the GGS are stored in the database backend of - the database module. -\end_layout - -\begin_layout Standard -In the GGS prototype the database module is using a database management - system called Mnesia. - Mnesia ships with the standard Erlang distribution and is a key-value store - type database. - Mnesia is designed to handle the stress of telecoms systems, and has some - features specifically tailored for telecoms which are not commonly found - in other databases. - Key features of the Mnesia database are: -\end_layout - -\begin_layout Itemize -Fast key/value lookups -\end_layout - -\begin_layout Itemize -Distribution of the database system -\end_layout - -\begin_layout Itemize -Fault tolerance -\end_layout - -\begin_layout Standard -\begin_inset CommandInset citation -LatexCommand citet -key "667766" - -\end_inset - - -\end_layout - -\begin_layout Standard -The features of Mnesia originally intended for telecoms prove very useful - for the purposes of the GGS as well. - The fault tolerance and speed of Mnesia are very valueable tools, the fast - key/value lookups permit many lookups per second to the database. -\end_layout - -\begin_layout Standard -Game data will not be lost when a game is stopped or has gone down for unknown - reasons. - This makes it possible to continue a game just before the failure without - having to start the game from the beginning. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Mnesia}}{Database server used in the GGS} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The GGS stores the game state in the distributed Mnesia database, from which - the state can be restored in the event of a crash. -\end_layout - -\begin_layout Standard -Each game is uniquely identified by a table token and the data of each game - is stored within two different namespaces. - The namespaces are named World and Localstorage. - The World is used contain all game data related to the game state. - This sort of game data may change during the runtime of the game. - The Localstorage should contain data independent of the game state. - Game resources, constants and globals are all examples of data that could - reside within the Localstorage. - To store a value within the database, not only is the table token and the - name of the namespace required, but a unique key so that the value can - be successfully retrieved or modified later. - The key is fully decidable by the game developer. - -\end_layout - -\begin_layout Standard -The interface of the database module is an implementation of the upcoming - W3C Web Storage specification. - Web Storage is intended for use in web browsers, providing a persistant - storage on the local machine for web applications. - The storage can be used to communicate in between browser windows (which - is difficult when using cookies), and to store larger chunks of data -\begin_inset CommandInset citation -LatexCommand citet -key "webstorage:website" - -\end_inset - -. - Usage of the web storage standard in the GGS provides a well documented - interface to the database backend. -\end_layout - -\begin_layout Section -Techniques for ensuring reliability -\end_layout - -\begin_layout Standard -One of the main goals of the project is to achieve high reliability. - The term -\begin_inset Quotes eld -\end_inset - -reliable system -\begin_inset Quotes erd -\end_inset - - is defined by the IEEE as a system with -\begin_inset Quotes eld -\end_inset - -the ability of a system or component to perform its required functions under - stated conditions for a specified period of time -\begin_inset Quotes erd -\end_inset - - -\begin_inset CommandInset citation -LatexCommand citet -key "ieee_90" - -\end_inset - -. - There are some tools for creating reliable applications built in to Erlang. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{Reliability}}{The ability of a system or component to perform its - required functions under stated conditions for a specified period of time} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{IEEE}}{Institute of Electrical and Electronics Engineers, read "I-triple- -E"} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Itemize -Links between processes. - When a process spawns a new child process, and the child process later - exits, the parent process is notified of the exit. - -\end_layout - -\begin_layout Itemize -Transparent distribution over a network of processors. - When several nodes participate in a network, it does not matter on which - of these machines a process is run. - Communication between processes does not depend on the node in which each - process is run. - -\end_layout - -\begin_layout Itemize -Hot code replacements. - Two versions of the same module can reside in the memory of Erlang at any - time. - This means that a simple swap between these versions can take place very - quickly, and without stopping the machine. -\end_layout - -\begin_layout Standard -These three features are some of the basic building blocks for more sophisticate -d reliability systems in Erlang. - Many times it is not necessary to use these features directly, but rather - through the design patterns described below. -\end_layout - -\begin_layout Subsection -Supervisor structure -\begin_inset CommandInset label -LatexCommand label -name "sub:Supervisor-structure" - -\end_inset - - -\begin_inset Note Note -status open - -\begin_layout Plain Layout -This entire section is bad. -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -By linking processes together and notifying parents when children exit, - supervisors are created. - A supervisor is a common approach in ensuring that an application functions - in the way it was intended -\begin_inset CommandInset citation -LatexCommand citet -key "Savor:1997:HSA:851010.856089" - -\end_inset - -. - When a process misbehaves, the supervisor takes some action to restore - the process to a functional state. - -\end_layout - -\begin_layout Standard -There are several approaches to supervisor design in general (when not just - considering how they work in Erlang). - One common approach is to have the supervisor look in to the state of the - process(es) it supervises, and let the supervisor make decisions based - on this state. - The supervisor has a specification of how the process it supervises should - function, and this is how it makes decisions. - -\end_layout - -\begin_layout Standard -In Erlang, we have a simple version of supervisors. - We do not inspect the state of the processes being supervised. - We do have a specification of how the supervised processes should behave, - but on a higher level. - The specification describes things such as how many times in a given time - interval a child process may crash, which processes need restarting when - crashes occur, and so forth. - -\end_layout - -\begin_layout Standard -When the linking of processes in order to monitor exit behaviour is coupled - with the transparent distribution of Erlang, a very powerful supervision - system is created. - For instance, we can restart a failing process on a different, new node, - with minimal impact on the system as a whole. - -\end_layout - -\begin_layout Standard -In the GGS, we have separated the system in to two large supervised parts. - We try to restart a crashing child separately, if this fails too many -\begin_inset Foot -status collapsed - -\begin_layout Plain Layout -Exactly how many -\begin_inset Quotes eld -\end_inset - -too many -\begin_inset Quotes erd -\end_inset - - is depends on a setting in the supervisor, ten crashes per second is a - reasonable upper limit. -\end_layout - -\end_inset - - times, we restart the nearest supervisor of this child. - This ensures separation of the subsystems so that a crash is as isolated - as possible. -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset Note Note -status open - -\begin_layout Plain Layout -We should really do this graphic in EPS instead of PNG -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/Supervisor_tree_GGS.eps - scale 40 - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -The supervisor structure of GGS -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -The graphic above shows our two subsystems, the coordinator subsystem and - the dispatcher subsystem. - Since these two systems perform very different tasks they have been separated. - Each subsystem has one worker process, the coordinator or the dispatcher. - The worker process keeps a state which should not be lost upon a crash. -\end_layout - -\begin_layout Standard -We have chosen to let faulty processes crash very easily when they receive - bad data, or something unexpected happens. - The alternative to crashing would have been to try and fix this faulty - data, or to foresee the unexpected events. - We chose not to do this because it is so simple to monitor and restart - processes, and so difficult to try and mend broken states. - This approach is something widely deployed in the Erlang world, and developers - are often encouraged to “Let it crash”. -\end_layout - -\begin_layout Standard -To prevent any data loss, the good state of the worker processes is stored - in their respective backup processes. - When a worker process (re)starts, it asks the backup process for any previous - state, if there is any that state is loaded in to the worker and it proceeds - where it left off. - If on the other hand no state is available, a special message is delivered - instead, making the worker create a new state, this is what happens when - the workers are first created. -\end_layout - -\begin_layout Subsection -Reduncancy -\end_layout - -\begin_layout Standard -The modules in the GGS are built to be capable of redundant operation. - By adding a backup process to sensitive processes, the state can be kept - in the event of a crash. - The coordinator of the GGS prototype has this backup feature built in. - The coordinator passes state along to the backup process which keeps the - data safe. - In the event of a crash, the coordinator recovers the state from the backup - process. - Figure -\begin_inset CommandInset ref -LatexCommand ref -reference "fig:redundancy" - -\end_inset - - depicts the redundancy built in to the coordinator process. -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/redundancy.eps - scale 40 - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "fig:redundancy" - -\end_inset - -To the left normal execution is pictured; the server state is backed up. - To the right; the exceptional excution, where the state is retrieved from - the backup to repopulate the server. -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Hot code replacement -\end_layout - -\begin_layout Standard -Hot code replacement is a technique used to update systems while they are - running. - The main use of hot code replacement are in critical systems that require - low downtime, such as telecom systems. - By using hot code replacement system can be able to achieve as high uptime - as possible and thus improving the reliability of the system. - Code replacement is a feature that exist in Erlang which means that with - some work it could be implemented into the GGS. -\end_layout - -\begin_layout Section -Example of a GGS server application in Javascript -\end_layout - -\begin_layout Standard -Below is a concrete example of a simple chat server application written - using the GGS. - The language chosen for this chat server is JavaScript. - The GGS processes all incoming data through a protocol parser, which interprets - the data and parses it into an internal format for the GGS. -\end_layout - -\begin_layout Standard -When the GGS receives a command from a client, it is passed along to the - game VM in a function called -\emph on -playerCommand. - -\emph default - The -\emph on -playerCommand -\emph default - function is responsible for accepting the command into the VM. - Typically the -\emph on -playerCommand -\emph default - function contains conditional constructs which decide the next action to - take. - In -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-concrete-example" - -\end_inset - - an example of the -\emph on -playerCommand -\emph default - function can be seen. -\end_layout - -\begin_layout Standard -In -\begin_inset CommandInset ref -LatexCommand ref -reference "alg:A-concrete-example" - -\end_inset - - the -\emph on -playerCommand -\emph default - function accepts two different commands. - The first command is a command which allows chat clients connected to the - chat server to change nicknames, which are used when chatting. - In order to change nickname, a client must send -\begin_inset Quotes eld -\end_inset - -/nick -\begin_inset Quotes erd -\end_inset - - immediately followed by a nickname. - When a message arrives to the GGS which has the form corresponding to the - nickname change, the -\emph on -playerCommand -\emph default - function is called with the parameters -\emph on -player_id, command, -\emph default -and -\emph on -args -\emph default - filled in appropriately. -\end_layout - -\begin_layout Standard -The -\emph on -playerCommand -\emph default - function is responsible for calling the helper functions responsibly for - carrying out the actions of each message received. - -\emph on -changeNick -\emph default - is a function which is called when the -\begin_inset Quotes eld -\end_inset - -/nick -\begin_inset Quotes erd -\end_inset - - message is received. - The -\emph on -changeNick -\emph default -function uses a feature of the GGS called localStorage (see section -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Communication-with-external" - -\end_inset - -), which is an interface to the database backend contained in the database - module (see -\begin_inset CommandInset ref -LatexCommand ref -reference "sub:The-database-module" - -\end_inset - -). - The database can be used as any key-value store, however the syntax for - insertions and fetch operations is tighty integrated in the GDL of the - GGS. -\end_layout - -\begin_layout Standard -Access to the localStorage is provided through the -\emph on -GGS object -\emph default -, which also can be used to communicate with the rest of the system from - the GDL. - Implementation specifics of the GGS object are provided in -\begin_inset CommandInset ref -LatexCommand ref -reference "sec:Communication-with-external" - -\end_inset - -. -\end_layout - -\begin_layout Standard -\begin_inset Float algorithm -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -lstset{ -\end_layout - -\begin_layout Plain Layout - -language=JavaScript, -\end_layout - -\begin_layout Plain Layout - -backgroundcolor= -\backslash -color{white}, -\end_layout - -\begin_layout Plain Layout - -extendedchars=true, -\end_layout - -\begin_layout Plain Layout - -basicstyle= -\backslash -footnotesize -\backslash -ttfamily, -\end_layout - -\begin_layout Plain Layout - -showstringspaces=false, -\end_layout - -\begin_layout Plain Layout - -showspaces=false, -\end_layout - -\begin_layout Plain Layout - -numbers=left, -\end_layout - -\begin_layout Plain Layout - -numberstyle= -\backslash -footnotesize, -\end_layout - -\begin_layout Plain Layout - -numbersep=9pt, -\end_layout - -\begin_layout Plain Layout - -tabsize=2, -\end_layout - -\begin_layout Plain Layout - -breaklines=true, -\end_layout - -\begin_layout Plain Layout - -showtabs=false, -\end_layout - -\begin_layout Plain Layout - -captionpos=b -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - - -\backslash -begin{lstlisting}[language=JavaScript] -\end_layout - -\begin_layout Plain Layout - -function playerCommand(player_id, command, args) { -\end_layout - -\begin_layout Plain Layout - - if(command == "/nick") { -\end_layout - -\begin_layout Plain Layout - - changeNick(player_id, args); -\end_layout - -\begin_layout Plain Layout - - } else if(command == "message") { -\end_layout - -\begin_layout Plain Layout - - message(player_id, args); -\end_layout - -\begin_layout Plain Layout - - } -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - -function changeNick(player_id, nick) { -\end_layout - -\begin_layout Plain Layout - - var old_nick = GGS.localStorage.getItem("nick_" + player_id); -\end_layout - -\begin_layout Plain Layout - - GGS.localStorage.setItem("nick_" + player_id, nick); -\end_layout - -\begin_layout Plain Layout - - if (!old_nick) { -\end_layout - -\begin_layout Plain Layout - - GGS.sendCommandToAll("notice", nick + " joined"); -\end_layout - -\begin_layout Plain Layout - - } else { -\end_layout - -\begin_layout Plain Layout - - GGS.sendCommandToAll("notice", old_nick + " is now called " + nick); -\end_layout - -\begin_layout Plain Layout - - } -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - -function message(player_id, message) { -\end_layout - -\begin_layout Plain Layout - - var nick = GGS.localStorage.getItem("nick_" + player_id); -\end_layout - -\begin_layout Plain Layout - - GGS.sendCommandToAll('message', nick + "> " + message); -\end_layout - -\begin_layout Plain Layout - -} -\end_layout - -\begin_layout Plain Layout - - -\backslash -end{lstlisting} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout -\begin_inset CommandInset label -LatexCommand label -name "alg:A-concrete-example" - -\end_inset - -A concrete example of a simple chat server written in Javascript, running - on the GGS -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Chapter -Problems of implementation -\begin_inset CommandInset label -LatexCommand label -name "cha:Problems-of-implementation" - -\end_inset - - -\end_layout - -\begin_layout Standard -This chapter contains specific problems encountered when implementing the - GGS prototype. - Some of the problems described have solutions attached, however some problems - were not solved, therefore only ideas for slutions have been attached. -\end_layout - -\begin_layout Standard -The integration of JavaScript as a GDL in the GGS prototype was particularily - difficult, and is handled in this section. - Unique identification is also handled, as is the design of the GGS protocol. -\end_layout - -\begin_layout Section -JavaScript engine -\end_layout - -\begin_layout Standard -The GGS prototype uses a vistual machine to sandbox each game. - JavaScript was chosen for the prototype due to its commonality in web applicati -ons and the flexibility of the language. - Any language with the proper bindings to Erlang could have been used in - theory. -\end_layout - -\begin_layout Standard -There are two main JavaScript virtual machines, or -\emph on -engines -\emph default - available at the time of the writing of this thesis. - There is a group of machines developed by Mozilla called -\emph on -TraceMonkey, JaegerMonkey, SpiderMonkey -\emph default -and -\emph on -IonMonkey -\emph default -, and also there is Google V8. - The group of Mozilla machines are largely the same, and are referred to - as the same machine for simplicity. -\end_layout - -\begin_layout Standard -For the Mozilla machines, there exists an Erlang binding called erlang_js, - and for the V8 machine a binding called erlv8 exists. -\end_layout - -\begin_layout Subsection -erlang_js -\end_layout - -\begin_layout Standard -Erlang_js provides direct communication with the JavaScript VM. - Which is exactly what is desired, however also required is thee possibility - to communicate from erlang_js to Erlang. - The ability to communicate from JavaScript to Erlang functionality is not - yet implemented in erlang_js, due to lack of time on the behalf of the - erlang_js developers. -\end_layout - -\begin_layout Standard -There were two possible solutions to the problem of the JavaScript to Erlang - communication path missing, the path could be implemented by the GGS project, - or a switch from erlang_js for some other JavaScript engine could be made. - -\end_layout - -\begin_layout Standard -Attempts at creating the communication path from JavaScript to Erlang were - initially made, however the communiucation path never became stable enough - for usage in the GGS and the erlang_js software was abandoned. -\end_layout - -\begin_layout Subsection -erlv8 -\end_layout - -\begin_layout Standard -erlv8 is powered by the V8 engine developed by Google rather than the engines - developed by Mozilla. - The ability to communicate with Erlang from JavaScript using callbacks - is available in the erlv8 bindings, therefore this feature does not have - to be added to the bindings in order to be used in the GGS. -\end_layout - -\begin_layout Standard -Initial releases of the erlv8 bindings had stability issues, these were - however solved by the erlv8 developers during the usage of erlv8 in the - GGS. - erlv8 is the JavaScript engine powering JavaScript as a GDL in the GGS. -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{V8}}{JavaScript engine developed by Google} -\end_layout - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{SpiderMonkey}}{JavaScript engine developed by Mozilla} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -UUID -\end_layout - -\begin_layout Standard -Erlang identifies processes uniquely throughout the entire Erlang network - using process IDs (PID). - When we wish to refer to erlang processes from outside our erlang system, - for example in a virtual machine for a different language, possibly on - a different machine, these PID:s are no longer useful. - -\end_layout - -\begin_layout Standard -This problem is not new, and a common solution is to use a Universally Unique - Identifier, a UUID. - These identifiers are generated both using randomization and using time. - A reasonably large number of UUID:s can be generated before a collision - should occur. - There are standard tools in many UNIX systems to generate UUID:s, we chose - to use the uuidgen command, which employs an equidistributed combined Tausworth -e generator. -\end_layout - -\begin_layout Section -Protocol design -\end_layout - -\begin_layout Standard -Initially the GGS protocol was designed to use the UDP protocol for transport. - Due to the lack of error checking in the UDP protocol, the UDP protocol - is faster than the TCP protocol, this was a main reason to use UDP. - The GGS does however need error checking to be as reliable as possible, - therefore an error checking layer would have to be placed on top of UDP. -\end_layout - -\begin_layout Standard -The development of an error checking layer was weighed against the implementatio -n of TCP instead of UDP, thus losing some speed. - Even though speed was lost, TCP was chosen due to the relative ease of - implementation compared to UDP. - Due to the modularity of the GGS, a UDP extension is possible by replacing - the network parts of the GGS. -\end_layout - -\begin_layout Standard -Furthermore, in a move to increase the speed of the GGS prototcol the binary - BSON protocol -\begin_inset CommandInset citation -LatexCommand citet -key "bson:website" - -\end_inset - - was initially considered. - BSON is a protocol which can be used for vert fast traversal of data. - The BSON protocol is however rather difficult to read in its plain format, - and no implementation has been bade for the GGS. -\end_layout - -\begin_layout Standard -The Apache Thrift -\begin_inset CommandInset citation -LatexCommand citep -key "Slee2007" - -\end_inset - - was also an alternative. - Using Thrift would mean the GGS would feature a standard protocol for network - communication. - Before finding out about Thrift, an implementation of the GGS protocol - had already been made, moving to Thrift would mean too much work. -\end_layout - -\begin_layout Standard -The use of Thrift, BSON, or other protocols can be supported quite easily - by develpping protocol modules for each protocol. - No protocol modules for these protocols have however been developed during - the writing of this thesis -\end_layout - -\begin_layout Section -Design choices -\begin_inset Note Note -status open - -\begin_layout Plain Layout -This section is wrongly placed -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -When designing concurrent applications, it is useful to picture them as - real world scenarios, and to model each actor as a real world process. - A real world process is a process which performs some action in the real - world, such as a mailbox receiving a letter, a door being opened, a person - translating a text, a soccer player kicking the ball, just to name a few - examples. - Since we focus on games in this project, it is suitable to model our system - as a place where games take place. - We imagined a chess club. - -\end_layout - -\begin_layout Standard -The clients pictured as green circles can be thought of as the physical - chess players. -\end_layout - -\begin_layout Standard -When a player wants to enter the our particular chess club, he must first - be let in by the doorman, called the -\emph on -Dispatcher -\emph default - in the GGS. -\end_layout - -\begin_layout Standard -He then gets a name badge, and thus becomes a -\emph on -Player -\emph default - process in the system. - He is also guided in to the lobby by the -\emph on -Coordinator -\emph default -, which has the role of the host of the chess club. -\end_layout - -\begin_layout Standard -When players wish to play against each other, they talk to the -\emph on -Coordinator -\emph default - who pairs them up, and places them at a table. - Once they have sat down at the table, they no longer need the assistance - of the -\emph on -Coordinator -\emph default -, all further communication takes place via the table. - This can be thought of as the actual chess game commencing. - -\end_layout - -\begin_layout Standard -All the moves made in the game are recorded by the table, such that the - table can restore the game in case something would happen, such as the - table tipping over, which would represent the table process crashing. -\end_layout - -\begin_layout Standard -Once a player wishes to leave a game, or the entire facility, he should - contact the -\emph on -Coordinator -\emph default -, who revokes his name badge and the -\emph on -Dispatcher -\emph default - will let the player out. -\end_layout - -\begin_layout Standard -With the information kept in the tables and the -\emph on -Coordinator -\emph default - combined, we can rebuild the entire state of the server at a different - location. - This can be thought of the chess club catching fire, and the -\emph on -Coordinator -\emph default - rounding up all the tables, running to a new location and building the - club up in the exact state it was prior to the fire. -\end_layout - -\begin_layout Chapter -Results and discussion -\begin_inset CommandInset label -LatexCommand label -name "chap:Results-and-discussion" - -\end_inset - - -\end_layout - -\begin_layout Section -Software development methodology -\end_layout - -\begin_layout Standard -The project has not followed any specific software development methodology. - All work has been based on a predefined schedule and the specifications - are made by team members rather than an outside customer or stakeholder. - The process can be described as a plan-driven development method going - from brainstorming to design, then implementation and finally testing. - Yet there has been cycles in the process in form of redesign and code refactori -ng. -\end_layout - -\begin_layout Section -Statistics -\end_layout - -\begin_layout Standard -Important things to note are that the number of clients is not a good way - of measuring the performance of the server because the server is possible - to have a large number of clients on the server but it can not handle all - the information. - Instead the performance of the server should be measured in the number - of messages it can handle per second. -\end_layout - -\begin_layout Standard -We were able to reach 6000 messages per second on the server, which corresponds - to around 350 clients. - However soon after this mnesia printed some warnings and the clients started - to lag. - With this in mind one thing to investigate is if mnesia is the bottleneck - in the system. - Current game servers do not use databases to save their state and maybe - we can see the reason here. - Other possible bottlenecks may be the protocol, but this seems less likely - than mnesia. - -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status collapsed - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/msg_per_sec.eps - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout - -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/ping.eps - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout - -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard -\begin_inset Float figure -wide false -sideways false -status open - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -begin{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Graphics - filename graphics/msg_per_secoutput.eps - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -end{centering} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Plain Layout -\begin_inset Caption - -\begin_layout Plain Layout - -\end_layout - -\end_inset - - -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Section -Future improvements -\end_layout - -\begin_layout Standard -The specification of the GGS prototype is huge and like many other software - projects relying on outside technologies, in time it would require a lot - of maintanance. - Therefore there are a lot of areas in which the GGS could be improved such - as performance, compatibility, ease of setup and usage. -\end_layout - -\begin_layout Subsection -Performance -\end_layout - -\begin_layout Subsubsection -Protocols -\end_layout - -\begin_layout Standard -Because of TCP being a connection oriented protocol, it is not suited for - all types of game data transfers. - Each transmission will consume more network bandwith than connectionless - protocols like UDP and cause uneccessary load on the processor. - Therefore support for UDP would mean that more games could be run simultaneousl -y on the GGS. - Another advantage of UDP is latency being reduced. - Without having to setup a connection for each group packets of data being - sent, they will be sent instantly and therefore arrive earlier. - Latency is of highest importance in realtime games as it improves realism - and fairness in gameplay and many game developers requires the freedom - to take care of safety issues as packet losses themselves. - This concludes that UDP would be a benefit for the GGS, game developers - and players alike. -\end_layout - -\begin_layout Subsubsection -Database -\end_layout - -\begin_layout Standard -Currently Mnesia is used for game data storage. - During stress tests, Mnesia has turned out to be the bottleneck due to - data losses when too many games are played on the GGS simultaneously. - This could be prevented by replacing Mnesia with another database management - system or use Mnesia in combination with the ETS module of erlang. - ETS provides fast access to the RAM and thus Mnesia could be used less - frequently. - -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -nomenclature{ -\backslash -textbf{ETS}}{Erlang Term Storage} -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Subsection -Compatibility -\end_layout - -\begin_layout Standard -GGS relies on modern technologies. - This includes the virtual machines(VM) that the GGS uses for communication - between Erlang and the GDL:s. - These specific VM:s are crucial for game developers to be able to write - games in other languages than Erlang. - Therefore it would be best for the GGS to have as many of these VM:s implemente -d as possible. - The VM:s taken into consideration so far have been unstable or incomplete - and it is possible to search for more VM:s, testing them and intergrate - them into the GGS prototype. -\end_layout - -\begin_layout Subsection -Setup -\end_layout - -\begin_layout Standard -The GGS prototype installation procedure requires different configuring - and building steps and thus it isn't in an acceptable release state. - An executable installation file for each supported platform would be optimal. -\end_layout - -\begin_layout Subsection* -5.3.4 Usage -\end_layout - -\begin_layout Subsubsection -Programming languages -\end_layout - -\begin_layout Standard -The GGS does not support many programming languages. - For a programming language to be compatible with the GGS, not only does - it require a VM for that specific language, but the VM must have the ability - to communicate to Erlang. - More research is needed to find VM:s with this built in functionality. - -\end_layout - -\begin_layout Subsubsection -Documentation -\end_layout - -\begin_layout Standard -To start the GGS is not self explanatory. - This together with overall usage of GGS should be documented. - The interface for usage of game developers is also in need of documentation. - Features and requirements with respect to the GGS would assist users to - know what they need in order to use the GGS and how they would benefit - of it. - The GGS does not support many programming languages nor does it have a - complete documentation. - This needs to be taken care of in future versions. -\end_layout - -\begin_layout Chapter -Conclusion -\end_layout - -\begin_layout Standard -\begin_inset ERT -status open - -\begin_layout Plain Layout - - -\backslash -addcontentsline{toc}{section}{Glossary} -\end_layout - -\begin_layout Plain Layout - - -\backslash -printnomenclature -\end_layout - -\end_inset - - -\end_layout - -\begin_layout Standard - -\end_layout - -\begin_layout Standard -\begin_inset CommandInset bibtex -LatexCommand bibtex -bibfiles "bibliography" -options "plainnat" - -\end_inset - - -\end_layout - -\end_body -\end_document From a86e0fca3c3b3cfd4f21978f7f46cab05e1c5b1f Mon Sep 17 00:00:00 2001 From: Niklas Landin Date: Mon, 9 May 2011 12:26:55 +0200 Subject: [PATCH 12/16] Changed all VM:s to VMs --- report.lyx | 48 ++++++++++++++++++++++++------------------------ 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/report.lyx b/report.lyx index c99883f..a17f4a3 100644 --- a/report.lyx +++ b/report.lyx @@ -1356,8 +1356,8 @@ ng them, a Generic Game Server should address all of them and help the developer \end_layout \begin_layout Standard -Due to the limited capability of threading in many GDL VM:s, the GGS prototype - will not support MMORPG:s. +Due to the limited capability of threading in many GDL VMs, the GGS prototype + will not support MMORPGs. \end_layout \begin_layout Standard @@ -2976,7 +2976,7 @@ Ds generated until 3400 A.D. This is accomplished by gathering several different sources of information, such as: time, MAC addresses of network cards, and operating system data, such as percentage of memory in use, mouse cursor position and process - ID:s. + IDs. The gathered data is then \emph on hashed @@ -3028,7 +3028,7 @@ and \emph default the rest of the network later re-establish communication, they may have - generated the same ID:s if using algorithm + generated the same IDs if using algorithm \begin_inset CommandInset ref LatexCommand ref reference "alg:A-simple-generator" @@ -3036,7 +3036,7 @@ reference "alg:A-simple-generator" \end_inset , even when mutual system-wide exclusion is implemented. - This is exactly the problem UUID:s solve. + This is exactly the problem UUIDs solve. \begin_inset ERT status open @@ -3863,24 +3863,24 @@ ports \emph on NIF \emph default -:s (Native implemented functions) +s (Native implemented functions) \emph on . \emph default Through ports communication can take place much in the same way communication is performed over sockets. - NIF:s are called like any other functions without any difference to the + NIFs are called like any other functions without any difference to the caller but are implemented in C. \end_layout \begin_layout Standard -The GGS uses Erlang ports for generating UUID:s +The GGS uses Erlang ports for generating UUIDs \begin_inset Foot status collapsed \begin_layout Plain Layout -UUID:s are discussed in section +UUIDs are discussed in section \begin_inset CommandInset ref LatexCommand ref reference "sub:UUID" @@ -3892,7 +3892,7 @@ reference "sub:UUID" \end_inset - and NIF:s for interfacing with the virtual machines of games + and NIFs for interfacing with the virtual machines of games \begin_inset Foot status collapsed @@ -4364,7 +4364,7 @@ reference "alg:exposing-erlang" \end_inset is specific to V8 and JavaScript, however implementations for different - GDL:s, or different JavaScript VM:s should be similar. + GDLs, or different JavaScript VMs should be similar. \end_layout \begin_layout Standard @@ -5558,7 +5558,7 @@ The game VM contains the state of the VM and a table token associated with \begin_layout Standard The VM itself makes it possible for the game developer to program in the programming language covered by the VM. - In future releases, more game VM:s will be added to support more programming + 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. @@ -5896,7 +5896,7 @@ GGS. sendCommandToAll(command, args). The localstorage is a convenient way to store global data and other variables separated from the game state. - Unique id:s called gametokens are generated for hosted games so that they + Unique ids called gametokens are generated for hosted games so that they are not mixed up. \begin_inset ERT status open @@ -7242,7 +7242,7 @@ Erlang identifies processes uniquely throughout the entire Erlang network using process IDs (PID). When we wish to refer to erlang processes from outside our erlang system, for example in a virtual machine for a different language, possibly on - a different machine, these PID:s are no longer useful. + a different machine, these PIDs are no longer useful. \end_layout @@ -7250,9 +7250,9 @@ Erlang identifies processes uniquely throughout the entire Erlang network This problem is not new, and a common solution is to use a Universally Unique Identifier, a UUID. These identifiers are generated both using randomization and using time. - A reasonably large number of UUID:s can be generated before a collision + A reasonably large number of UUIDs can be generated before a collision should occur. - There are standard tools in many UNIX systems to generate UUID:s, we chose + There are standard tools in many UNIX systems to generate UUIDs, we chose to use the uuidgen command, which employs an equidistributed combined Tausworth e generator. \end_layout @@ -7734,14 +7734,14 @@ Compatibility \begin_layout Standard GGS relies on modern technologies. This includes the virtual machines(VM) that the GGS uses for communication - between Erlang and the GDL:s. - These specific VM:s are crucial for game developers to be able to write + between Erlang and the GDLs. + These specific VMs are crucial for game developers to be able to write games in other languages than Erlang. - Therefore it would be best for the GGS to have as many of these VM:s implemente -d as possible. - The VM:s taken into consideration so far have been unstable or incomplete - and it is possible to search for more VM:s, testing them and integrate - them into the GGS prototype. + Therefore it would be best for the GGS to have as many of these VMs implemented + as possible. + The VMs taken into consideration so far have been unstable or incomplete + and it is possible to search for more VMs, testing them and integrate them + into the GGS prototype. \end_layout \begin_layout Subsection @@ -7767,7 +7767,7 @@ The GGS does not support many programming languages. For a programming language to be compatible with the GGS, not only does it require a VM for that specific language, but the VM must have the ability to communicate to Erlang. - More research is needed to find VM:s with this built in functionality. + More research is needed to find VMs with this built in functionality. \end_layout From 83d5af269395297521ab035021ea6301a2a8c052 Mon Sep 17 00:00:00 2001 From: Niklas Landin Date: Mon, 9 May 2011 15:28:51 +0200 Subject: [PATCH 13/16] Added content to the statistics section --- report.lyx | 59 +++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 54 insertions(+), 5 deletions(-) diff --git a/report.lyx b/report.lyx index a17f4a3..89ccc68 100644 --- a/report.lyx +++ b/report.lyx @@ -7446,6 +7446,50 @@ Mention the hardware which the GGS was run on; A Thinkpad T410 wityh a core \end_layout \begin_layout Standard +The testing of the GGS prototype occurred in two sessions, one session where + the system was tested with clients that were using mnesia and one session + with clients that did not use mnesia. + The data that were measured during both test sessions where how many messages + per second the server could handle, during the second test session the + delay between the server and the clients also was measured. + 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. + The hardware that the GGS was running on was a Thinkpad T410, with an 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 crashed. + 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. + Witout 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. + +\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 will do the same, + this is because the server can not 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 can not handle all @@ -7454,7 +7498,7 @@ Important things to note are that the number of clients is not a good way of messages it can handle per second. \end_layout -\begin_layout Standard +\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 @@ -7466,13 +7510,18 @@ We were able to reach 6000 messages per second on the server, which corresponds 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 collapsed +status open \begin_layout Plain Layout \begin_inset ERT @@ -7536,7 +7585,7 @@ end{centering} \begin_inset Float figure wide false sideways false -status open +status collapsed \begin_layout Plain Layout \begin_inset ERT @@ -7600,7 +7649,7 @@ end{centering} \begin_inset Float figure wide false sideways false -status open +status collapsed \begin_layout Plain Layout \begin_inset ERT @@ -7668,7 +7717,7 @@ Future improvements The specification of the GGS prototype is huge and like many other software projects relying on outside technologies, in time it would require a lot of maintenance. - Therefore there are a lot of areas in which the GGS could be improved such + Therefore there is a lot of areas in which the GGS could be improved such as performance, compatibility, ease of setup and usage. \end_layout From a64370c2aa1f1b7e2407401ff128d78a9e2ff600 Mon Sep 17 00:00:00 2001 From: Niklas Landin Date: Mon, 9 May 2011 16:02:47 +0200 Subject: [PATCH 14/16] Added a introduction to chapter 5 + error changes --- report.lyx | 62 ++++++++++++++++++++++++++++++------------------------ 1 file changed, 34 insertions(+), 28 deletions(-) diff --git a/report.lyx b/report.lyx index 89ccc68..e5507c2 100644 --- a/report.lyx +++ b/report.lyx @@ -4862,7 +4862,7 @@ external \end_inset to three GDL. - Discuss the GGS world object (there is a reference to this secxtion for + Discuss the GGS world object (there is a reference to this section for that purpose) \end_layout @@ -5465,10 +5465,10 @@ The coordinator keeps mappings between each player and table, therefore \begin_layout Standard The coordinator process contains important state, therefore a backup process - is kept at allt times. + 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 potentisally harmful is not stored in the backup process. + Data which is potentially harmful is not stored in the backup process. \end_layout \begin_layout Standard @@ -5508,7 +5508,7 @@ The information about which players are seated by each table is used when notifying all players by a table of an action. Consider a game of chess, each player notifies the table of its actions, the table then notifies the rest of the participants of these actions after - having had the ac tions processed by the game VM, where an action could + having had the actions processed by the game VM, where an action could be moving a playing piece. \end_layout @@ -6842,7 +6842,7 @@ reference "sub:The-database-module" ). The database can be used as any key-value store, however the syntax for - insertions and fetch operations is tighty integrated in the GDL of the + insertions and fetch operations is tightly integrated in the GDL of the GGS. \end_layout @@ -7116,11 +7116,11 @@ name "cha:Problems-of-implementation" This chapter contains specific problems encountered when implementing the GGS prototype. Some of the problems described have solutions attached, however some problems - were not solved, therefore only ideas for slutions have been attached. + 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 particularily +The integration of JavaScript as a GDL in the GGS prototype was particularly difficult, and is handled in this section. Unique identification is also handled, as is the design of the GGS protocol. \end_layout @@ -7130,7 +7130,7 @@ JavaScript engine \end_layout \begin_layout Standard -The GGS prototype uses a vistual machine to sandbox each game. +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 @@ -7157,7 +7157,7 @@ IonMonkey \end_layout \begin_layout Standard -For the Mozilla machines, there exists an Erlang binding called erlang_js, +For the Mozilla machines, there exists a Erlang binding called erlang_js, and for the V8 machine a binding called erlv8 exists. \end_layout @@ -7238,8 +7238,8 @@ UUID \end_layout \begin_layout Standard -Erlang identifies processes uniquely throughout the entire Erlang network - using process IDs (PID). +Erlang identifies processes uniquely throughout the Erlang network using + process IDs (PID). When we wish to refer to erlang processes from outside our erlang system, for example in a virtual machine for a different language, possibly on a different machine, these PIDs are no longer useful. @@ -7386,9 +7386,9 @@ Coordinator \end_layout \begin_layout Standard -All the moves made in the game are recorded by the table, such that the - table can restore the game in case something would happen, such as the - table tipping over, which would represent the table process crashing. +All the moves made in the game is recorded by the table, such that the table + can restore the game if something would happen, such as the table tipping + over, which would represent the table process crashing. \end_layout \begin_layout Standard @@ -7416,7 +7416,7 @@ Coordinator Coordinator \emph default rounding up all the tables, running to a new location and building the - club up in the exact state it was prior to the fire. + club up in the exact state it was before the fire. \end_layout \begin_layout Chapter @@ -7430,13 +7430,21 @@ name "chap:Results-and-discussion" \end_layout +\begin_layout Standard +In this chapter the results of the GGS prototype is presented and discussed. + The results of the testing is presented with both graphical and textual + content. + Together with the test data there are thoughts about how future improvements + to the prototype could look like. +\end_layout + \begin_layout Section Statistics \begin_inset Note Note status open \begin_layout Plain Layout -Mention the hardware which the GGS was run on; A Thinkpad T410 wityh a core +Mention the hardware which the GGS was run on; A Thinkpad T410 with a core i5 and 4GB of ram. \end_layout @@ -7455,7 +7463,7 @@ The testing of the GGS prototype occurred in two sessions, one session where 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. - The hardware that the GGS was running on was a Thinkpad T410, with an Intel + The hardware that the GGS was running on was a Thinkpad T410, with a Intel i5 processor and 4GB of RAM. \end_layout @@ -7468,8 +7476,8 @@ In the first test, where mnesia was used, the server had a peak value of load. In the next testing session, the test was conducted with another client that did not use mnesia. - Witout mnesia the server peaked at 60000 messages per second, however this - was only for a very short time. + 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. @@ -7480,7 +7488,7 @@ 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 will do the same, + When the load on the server increases heavily the delay does the same, this is because the server can not process all incoming messages and therefore messages are put in a queue within the system. \end_layout @@ -7740,8 +7748,8 @@ y on the GGS. Without having to setup a connection for each group packets of data being sent, they will be sent instantly and therefore arrive earlier. Latency is of highest importance in real-time games as it improves realism - and fairness in gameplay and many game developers requires the freedom - to take care of safety issues as packet losses themselves. + 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 @@ -7788,9 +7796,8 @@ GGS relies on modern technologies. games in other languages than Erlang. Therefore it would be best for the GGS to have as many of these VMs implemented as possible. - The VMs taken into consideration so far have been unstable or incomplete - and it is possible to search for more VMs, testing them and integrate them - into the GGS prototype. + The VMs considered so far have been unstable or incomplete and it is possible + to search for more VMs, testing them and integrate them into the GGS prototype. \end_layout \begin_layout Subsection @@ -7827,10 +7834,9 @@ Documentation \begin_layout Standard To start the GGS is not self explanatory. This together with overall usage of GGS should be documented. - The interface for usage of game developers is also in need of documentation. + 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 in order to use the GGS and how they would benefit - of it. + 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. From e660defb888d670f3f28ba689ba87043c21dda79 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Tue, 10 May 2011 09:38:25 +0200 Subject: [PATCH 15/16] Added some more text/image text for 5.1 (Stats) --- report.lyx | 135 +++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 115 insertions(+), 20 deletions(-) diff --git a/report.lyx b/report.lyx index e5507c2..169a0d4 100644 --- a/report.lyx +++ b/report.lyx @@ -7431,11 +7431,11 @@ name "chap:Results-and-discussion" \end_layout \begin_layout Standard -In this chapter the results of the GGS prototype is presented and discussed. - The results of the testing is presented with both graphical and textual +In this chapter the results of the GGS prototype are presented and discussed. + The results of the testing are presented with both graphical and textual content. - Together with the test data there are thoughts about how future improvements - to the prototype could look like. + Finally thoughts about how future improvements to the prototype could look + like are given. \end_layout \begin_layout Section @@ -7454,32 +7454,110 @@ Mention the hardware which the GGS was run on; A Thinkpad T410 with a core \end_layout \begin_layout Standard -The testing of the GGS prototype occurred in two sessions, one session where - the system was tested with clients that were using mnesia and one session - with clients that did not use mnesia. - The data that were measured during both test sessions where how many messages - per second the server could handle, during the second test session the - delay between the server and the clients also was measured. - There was also a testing session where the number of clients were measured, +\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 in figure +\begin_inset CommandInset ref +LatexCommand ref +reference "fig:msg-per-sec-MNESIA" + +\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. - The hardware that the GGS was running on was a Thinkpad T410, with a Intel + +\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 +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 crashed. + 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. + 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. + more than what the server was able to process with Mnesia in place. \end_layout @@ -7576,7 +7654,15 @@ end{centering} \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 @@ -7593,7 +7679,7 @@ end{centering} \begin_inset Float figure wide false sideways false -status collapsed +status open \begin_layout Plain Layout \begin_inset ERT @@ -7640,7 +7726,15 @@ end{centering} \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 @@ -7657,7 +7751,7 @@ end{centering} \begin_inset Float figure wide false sideways false -status collapsed +status open \begin_layout Plain Layout \begin_inset ERT @@ -7704,7 +7798,8 @@ end{centering} \begin_inset Caption \begin_layout Plain Layout - +The graph shows messages per second for intervals of clients connected. + No database is connected. \end_layout \end_inset From 517953c329aaeca73219f7a6aca338f928e1c45b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Tue, 10 May 2011 10:37:25 +0200 Subject: [PATCH 16/16] Changed chap 5 --- .report.lyx.swp | Bin 200704 -> 217088 bytes report.lyx | 131 ++++++++++++++++++++++++++++-------------------- 2 files changed, 77 insertions(+), 54 deletions(-) diff --git a/.report.lyx.swp b/.report.lyx.swp index 7146e010dd07066cc90eda4945bd0329dda115cc..1dc3d161b4cf5b654c1aa548107c200b5eb064b2 100644 GIT binary patch delta 48026 zcmagn2Y3|a`^Nj7O(3*{-rLe^LKj4O?;s#eiYc1{X{1o31QbQ-u)qM)qzWp65f)I2 zAXPv_EFdT#qF6x?6%o$&o}IzS|98&Gb$zmv-DI=7^UPbG_nF-(s|!q79a<@>{(!DM zJxwDTx%evNa=rTJ(VkbYEO%84b-6~SBxiW%&##i-+6YffNX{HLe}4I}$=1*HI(XAZ zWu&BTOHT>%T@T8iU-wX@awSjEB2Q%-MU4Vk8L5q2SzPJXEqwU`7cS$G%V7KG8}{YG zM{dvc$o13gJ8__C>K_2`1>Gox-pumQ6dtUqc znfB$OM{dt&Uq8jZ>|;G6p1N}f)@#F!FWSFw+J4H;?FH=X$J&tY zgYyb3uy>ks2j%SBoqe3&-e=D3(1!CsoM1?Y+zD2p-(!cLmU)##7hxJ!Hc z7p`C#UP4Q#ovw_+$c12Br)~cp-{AsI;UHcOAtDyBu@EogB}~TzJc~&5LuYhCJ>5XjAJtGArC{I&z1&rNgQGZ-#ka$F7YpzrUcg8sARfce9j(y{ zjnEJcPz_ZPiUM%q0lV{i96>f-!AqEqiI{+Ak&MtJzC}YZ(BC)zR`qSGOB?3?D@Ly1 zn3U+u>}svPG|U$^xT}~W-ZgTYMHaZ{6&;nFGS)LTJ~G3T5$_%EN%neU%)<-ZwL?59 zv7UsC2=m4Q_n4r_G_M)&bDuPyxn&gd?Y~!Mao(U1^Vm}Nq;?6(`b$qtWJY9EWV+Xr zloFGf=#6lB`g3jDK3zRyQ!*1{Jjp2;)}4DYQasV|k;!r1x}L~%{xl)oY|z+UdYCsY zIWjSEyzBqoQ(I4JN_u)iRHD}to0*ZB=JiCz#3W=Sr0}0ptbg9Qb3aeC^>3oQx{lke zd-g;}M)N2VlFbIWgK7=o`EU=((fZSLPntI|Au=j)d|ll|nm0CuJLVV0@~C3G-Xw2~ zCp|MZHX%B}o6Mi3q*?zdH7zA0C1ZT5^8}+a)6%%z_i^`Ei%sQsoAlAzgiw% zeLK%R+MAy4^7Kwih)b|y!xNd~W#XZ-vr`izqn~0|MFsX>;K2u8(adz+GY`>z zdF(*dKCpKX565Hw*1!KFK`%v&H^w(VzJ|ZfEAC9gT)W&ox}dfDW79Z3Qj&O`%t|ZV zwT*Cp_Z99)!=3Ckx2$ycHDVU8a!)HB8ACJ2@%y#D(H7s}!sRc#+Fj4cDn;8_0Qqr; zX7YP{i2c}yt?=O`Oh*O=q6fO8IU*2_5^&)*P3kRNz=zleHNR`I2Crf2-7hUBQXMl(F>i?0uiW^mo~Z( z8@X_w#{4(j#Ao;vXK@VgL4)uWn2&kLLU*bH@ zW%2DKPGCEhU^Zr9CUpB`#9;usp(`Q~j=HFXe7H}C@ei)xGA`j$?8iIE#%tJ!4OoV( zrF?rHV=xj4=!+0srB_*wh3J9;2*TfV1V7^kT*i5vfO?&M@M8m(VJRkK5+-6aqA>`? zf?X9|dDsZSPXycA6sLBWT!=jkmE48{h;(d$ylI zc@#z=XrvH~uh~zZ;p5!B8F#SZLwEemtMnsYMF!##hd#)I`@H5yuopYA8QNL%FcTT( zwgpDftd?w6M;Vkx7@PsYeRkCyoWMbB!&)qd57RIP8K{e^?6X5qLf|!Q#4OCj3}iw3 zH5JxZa*A)-(@lI+x>xWYeA|67m$`1I+gpk@c09dKbYyB|R6-)1mN(t%9{d${x$gy; zW%szl{ayFC-*p$(XjuP9joxzIqgi;rdtg>Gd#qWW%W^Q_!c79`8a5yW(TGB4bV5fo zM_p8c#-{u64zjTXCKh8RG(Js3ZREmV1l6A!mtJJ!0=~p)9DpBV(GHKH2^5jFP!o#C zvIxevM4=kjvp9?u=m)i%!B7w;BMJlX6k6dnLHAl7+Pn#Dq#zjsQ4IF7fl1#e;v)RMfM#kbbTjk|=?U-$)TQhvfE ze2rt+gKgLfMQ0a0fg6O=HGBkx-T`cciJ6#zEKEiN6v5v_!mp_G3*SD$LHMx)uVXW; zxb(GcSJA)Xfct1Z^Ykfquvzewds0}v+(rH0 zopP5qtd^-O_o9HC!36<#+I^&OFgsrztFzya_&%OrG;18!Bw`ev0ZA0sFcgK_o@tnX z+W3XN_cr2D24M)r9d_0kOveC(;yyd<9jt~X9+NN;nsD?&JG2cU3?E~o2^!%ldu|n0 zU_RzyJQ^Su-e+f}qYdt`12$nkG@+P=Bt*c#ue{jWIY+S@Z(##gVjkuoIj9@)$wnl) zp&7~`FMj4F{0WzF3G*-s85oA%(97Hf`to-@<1QECW~vZ-&i#`4>p6EdBibx}o|(nt z=iTiLuYbaM_gce<_gA>!z7~|FS*x>~rd#*ma{a+%^cudvXUN8COu|HrMkg=V;#*>;0QWTyy$Er>!XXV{}4NG!9-7JhI^aP zaAvos*?s{dP!u-^i#IS1DNrLY5XDgdcL|lBuojCj3uBR>20&d=Mf^&gPI)U+ff|Bd)R`t zn2a>26B>Z0&>vQ;(I^!2_r2oY5}GyCo0J;wNlA8TWX-GO>ccPTn4f6}({BXFclba- z0za1H6)eMCOvM=VMJIGbZPY?dlt)1X;{-vqAN#N_jQzKkjWsawGA5%jsv$S-5>$WT z7yOK$a0y@IC}yG^+;HJGL3axmFdyR(fd>TLKe&k-IEQ&zd=m|v)IEJgRIP;4EA#Oz zB48k!z?y=lP{Z{xFW0+Rf)}9Ca~k3hix_Cse31a#hb@=^HDnqHt1)Y$6v}8QeL_oS z4UEch=?soe5Piq+HZ;;*j~Tu_qpM`qWXpqMD2jW8;I}x7Pp}h9&>b4;Dt9sqZSem# z403VX142xBk)?PNYQ?@IC{{qhp%#lTev@E`|INK5)SUakU3&3;cW{=nmW^~f0W^gR zecfiK-@*kfLU%;qYxeC5^hGeVkDdMdDciHq3N;Z7Kl^YkhM))TvAb^JJ6r>!kF5U; zh+p8!2}r|83`HRvVqeaHre|td8lyT~xX*t58JBShhwuRoLaDXQ&hr}{UA)=|?y3~J({sJ3K;cV` z%P5S%a45A}2Nh8PO0(`JR?-lIGPrGS+sf#EHzBeMTc8eV5xPMk)Do4Uk*){D5rTV! z(c9R7^;m|b(CBv-H1f?rHJl}K=Au0`a8>`MLF?PtrrG}nHr7L_0nPr)LG!AYF$P{} z=C0{fOK9e<@Trf=C<%>!4&xAZV;6Sf4ZMzp=mqs>*NFm6w?4o@WoY-Z@hTQW*;=(R z8YpS9{S-7lDuM^>`7d!EAK?_#%uGWh2B9mSzzrhe7pP%TqjCrb;l~cFLNto@=i6Dr zp4!LwK`Mrz48jnKJA}|djDZqJYNfs+Oqil8 zq_V6mP&^$V;cm@b4W9UpX-$2TT$de2&}!TW`xn>l(CJo-=EalZEk64PnCi zmEAmcuiJMZA-ZzFtK?Xod9v zVel55;mb_6+u;uT_$!>j$56X89cqVuXMdl?8SKQHSc%yM*q3T>M&lXuM?W+}Q)pSJ z4$2@5q0lK+wqbHJCcbGzbNPb!eTX7+Hm?|w#!?3HOZ@>yZ2#!B-@h2=Z?WxlQxf@_fk56%*L zhoRna7c`M`4sFpIH`tkeXjS+m;x{QqYJd~sQhsq)J8?*g>uOEa1)y2{fcj(yz&w3z-Da19L&ZnOhqO}YD6^{ zy`ZpBBiINUd~4vH2g)yN@U1kZCW;EDpK%6?Bt_9XP~>PpZbB2t7cd^-GTGd4l9*F|^%qoG-=#*1B{q=+)7bx;Te5r!cA zMQ~dIuE-wB8qo;yqA8gfuCBhVe~isuwKCH1-B{Ey`;F(W=UY65c}6{cPY0fk2&XdX z0Y`x|*SN&?=QxAIIE2kuirJV2Ckv9ob_|B$N%VmxupQ7IkD&o7K@I1r8s)g`7hvjYDf@%mZLldI2IEJGt z5IVw!x|XeQhPyAb{SuNe6n)SejnN1VQ3K^s7=@4vY6rgO*w>8tODGYn0tL;s)HY0q zRv%u#vq;V2TMVKx2m?_MRZtlr&!6=MW+FPT$G6;h*rN7bIsmc5lnmg{oPN*ML>$x6F;Vi_= zVq2?nnj~Z(22Z0mlv!0GwK7VeIPTKO{e?gAvsy(pqn|@7HX0@#$5J>==xDZ|fjV3b zA9Kz@>+o|WD7~guG%wVW9-&ct7rUXE#T-0`sfdLaG3YgzZ)zS};0dURq#hzr8I_P5 zH)$g@nf(-M8Q0(?s5R6Qp4yOSgXhn0Xq9r9Z7RD%eD%D!vzu=@Y_&MPZp(@X*Y#v3 zXP;cyE3efV6Mn9z?ap{M+xk+1bt5*w$&2M|YLp+Ff-IyX4MU-(#%X5ivaPAc2B^YM zt%Fu{)FKqbpGvmA#*wN?#sK7pj?|nJ*g5>%-ah#D@kpHmsVCb?Z)x?VJhTFnbE0vZ zc>fX~;S~JHnTQ?7&$0QM26}sq=X6l4#-o#3Ez5ic4dJxfYz^Veww2sP+iKpb(U}&G zwN$7@R#2Z))%{nwOO~X*ML1Q#R`5;$o*PrZsW%Pf< zr%={)E8c=Kud@-4p-`Y`s`Bqwc9Ffm80MNeMhV}rJ>{}jubG+4h|I40+7)+p!PiR# zrXf6WS7rSbz1tM~PnCw%6l4d~lWoEZOotbPF$mqz7~c^xA7MM3PH8#Y^N@-9sER5m zg_0E4nk)< zf##?PEm12Ziy&CjkiQ5oO)Inr@DiqDBD8*_bZj!zmiI?*s14WPQ`Hq$2uY=B)iig7 z3nz%V=g-cVJ~$)v_tYszKmOn1~5bU9?&&tp+ZD#%CIWT_>tm z;3-tZDWYTrl*8AW@i>fyB1u^@r8=~3ybC+=Cf{g-LO1`~-smO%0PNaCK1nVo? zed@lE{p{P_L-HgfQ`-~cP4j)QE891FcU9ls-DTTQQ%2!YQc_AX)kvA?UP`v8=28t) zYD!v$Co(lPky0fkPFyP3QL#=^N_qyRQz=Oa$=+mN*6wmfgzwhwN=>;Z)v+a0JC!ju zC2f=^uwreMPerFBrc+iFKh z7y>Oo-6r0SLL;f1b83yATH!G`X@8A^KEY9F5Of$C2r2is7Oz0@8L#&8DK`3}E4rXF zo1880`N@?8@(1fBhl-m6kT7A}3RpWdO<<OJwSJTr z+Kt~CzE^LR^nG!0msw%EJ0yGQS8;}~>VeNH*tKQxl-Wgjy~$SCMYy^;;W_JISzncd zHOwkCjOrEn9jES)dbWWSuMvX;BEd}j#rUQiY?giK;JdkfFCMSvd*iq#m&*GhvQHcj z2?`>>e4n0-uwqLkycKw0YABuBZmm%*f%?{9yhrSeMhmDaLL=xscn=yl&%k6%LL7!b z;ZXwx5r!aWdC7osI4m(y`M`#f#v@P^hl!PCm;=Sn7^u(Hl7rf`pYanuhEgZW6|aNF zr%Rx*X(=d%)P`xP!Kwag#kPi!CE>=w|{lqS}{siD-YTCL}|xQZ{JA>n>#Hr)x0 z@e{G9)XHLLNY@en5POI4ESf^~QkrJYf>I^FvRg002jzm>;W0FUcDYfWC51|6>xM>% z@A`}i*#&;NZDfa?IhNlFjOxV1dArexwHuwc2nG$p+Tc%u;ULB%3F--zxKn4RU`T_q zC4->0LkkEkPz{&a*IFd#2_2ANDct@ITcKT()<&#^hQ`(zyCtcJDbTg?|!S zgZ>a&gWikvSdA%AI1Iy3Jc&N&4fR6}(EtpTT*Xl=%+<*nEd5Pf+`vKju>-1<*o;kB zf#rAsbWE;c=!JG@i|VFvldgyYzYJmDKHNeVR218j$HN2gm zytP(fG#y@tshEOHWFQSSP#)iKOdW!bt!y1%fiK@Hw?fTIK}LOll`!L?;q%|Br(^Zo zTa9yhIV-^9t9bkQ?6tT11}4lL<5oGE4$igqJva+0A9HY?#><$5iO_6D>u;ZOfN8x= zsWTmTYM(b^Fw`E`g$EU(43^VL|3RQ%$5-m47qBq{&N((wY)9f5JcZ6^fnNyRuki^q z06YS9=!dWiJMk)XP-vxY7&Md7LEy}0l%>*)rWlIifC73nL8_TbJ(NTNyI3cLy&`}(L)<2xY&{VcHqp6E9{6k1sW!PMvf@V3>viQ~!O6Dkuqbau2 zVLP#Mn)pyET%ES2Kr68bik~UaDsU5Mu|%~4<)D0x3+f=WLaYv6>nE3?Rbq7*8hB>4 z<(qOdp(p?YE~r{p(@wfQA%j@d?gAB~v?~T1kDGH(R==QlVSGyuQ!~H-~pI>X?20G0K=V zD;i%|E6L^@x8X70avOesT#&IX$X`0dI3MVO2yQD)peR3J-5ni0QS4--HGjW`Z*d&& zzz0SCOK_rp0^7<+t2VD6+CdrUCU91!OR*h_`y3U&Y0iF=jcZUpcNOaAK8MD>>f4rL z2_~TtN}&MqL)F3$IDGEoH)xFf8Q#Z!Xzs6WOG6?ZdKwaG@u&wPP+8gNN^F#X3M+~s z4?>^chRg? zY=)yQREk>&7daR{#%XBi`~eQa4`st%hcaRtu@YKecaoiI-4hTG)go%hts<~$$cMc6 zm4ikt{*@p`H941jj&Y?5V6~+A9#jacRGE&z=a7M9D9OBEN7U8H3sZRC_9U!YwZJYKL^QXC>N_ap>vR_ zw5Tt%+|vopa!)h1n?hqol^tpRxQpXM^T$e1UhGf8TDgcHaT*^f&v1$jjs3PmW4@Q* zB+8Vp9f9HKhmOz$vn-qmrs@@c!%bYn7tk@X1}ec{1g*S`$2cTG^G?+X)GWXOSdNXd zaNz+5jYfL6@GW#e)571JDOlBxlo4zvVxK?|rqs}CJ~8rZ2Opb}IQ@FxeJCb2)_ zEcRl%mVz~-T?=K6P0WC@b{eo%f%-fb9&nJ|#sxS7ws+Xp;A{z=MTcZL$m_lTV9NcfU(??R2QLTn4PW}#uxTxdw-tXpX9Jr;w|6SYwRtY5fP zO=ZA^--#ua_Flk3D7Gf}MyHkXPwi!78NS9*Rm`Y{#>P%u zVb^o~fr8O_TY?V>vVGVKO~BvAHmrvdzFK>43l)WHkn$4RK#L6*uorJ&4rb#yOhq!H z5DAJpS$`+EwqqlPp*ZqD3EaPN6&l0u#dd7O(@?vniKzw^3N#HYK7tZ)ui#~9p`i{m zzf{eV1{&9J0`KE(C3e+bX)^f&GN7|r;?M)mK%+I=O4?LLC6s`3hC&{;HQxV;0Mvq+ z61}ftH5NgYo*IBm$BWRy?-2At&n&*Fooj&lP+M05isrnyPt+>l z@jO%@H4p=!bkrX^q>&*wilHN1c{bcOotmQcT~WXx~GtO_5VMh7*T&DdxPtx#xiJROS5`nX1@ z`0+Y6L-E!bxuFE{U$}xjcn8a|45}R%2Gs|A%D&J-St7bZCFWI81*OzzmV{Q$oHhQN zgvBOku&YFHbA&-7S|t~~&OLnz$PF6U2q zR&6(xHk&3JpP6AP#&71FWTTS5YF}fH5yaA!xvifuC^$SiCCztvWOZ}ZF{7aQR!bw7 znL60WYcBiKUEHj{*Ims&yT9>LkiWzrqoTWXn$CPrk7pqw#*^etN=X}E*ONqAa-6@< z5ZX$!^<8&v|D~smj)4WRiaZ9B2c!6Nib}PLtGD4<44o4(8Q}=QF=A*xRLS=SHbCV> zn#8HdbR;4%0>hyMrB3_&mT*#@QHx(Gpv}y34P>JxG&#!!B}$YWIfmD<4C=I}!5LiU z%qlu@s6@B2h#FV^gDcpAc~Hmx6#B!7N##bK$j^JWC@7tQWL>t)q9DR>ivzDRfn3v*Pu{Z%rLUD`PF3O zX|s8j(b;@1%V=*N&N7;tXQGWF=Ef-FEpuSB(ZoMH+UVdm&v=bZ!D;EuUFM8fqlI}S z)@YtjZ%h$*hYgciSq-yRobjChjX2|(px|CzJEfcXM;U8$aGL*jSd2lcTNo;$SRn4ofs9w2Yt{&^|vc-BYs{OV(p}ClRN_pa1#r-fG#u8RLzO z%uLL1@hHqTXWSKXX~jF;|5c*VHZV`*rL?NbbvS;&w!X9;9fv2Nv9eB2Qj(=8^1%(Q zQSU?wG#C7tBk3|OL2HVWF%+%w7-~UNJe^ssTs^IOmg{LYoJ4&iwi}`Ws-qM_agZZJ z)3qINisUx2y#mYeJT#Q)jb2dN@fQx0b65i9(`P~@*%^q#F!WS+@PCpg952e9e1%V- z@r~A-UdJk|gbxca4++qeY$&vT-4UvFYY3$=Ye0*Xd7?!wHoKZhwuK{TSE{EOaxNC&a1JF1{0N+3V7^6~8q z2k>DW!dqAkA7(+-9u1&_yaF^2EQ~uGyuafXzQ;M7#0e<3z8`z>Jkk&gFSL310CdFTP^GSt^W{(m8Z+gGS`w|IUcv>O z#z#;?qE-F_L5%|~%65KOg_W3(nV1006k4D@>LKuD7S3;Y%*Jz#6XwZ9MjL-by3rx8 znLg3@(Ht?!Xj&*u6(m-T3CF(<-1%P{CG)E>(2SOKd-HU(QOvwD$rxs~nQX)wDdxt> zM&qnBS7Z#YHvdHDv+8KvWdBE{NU!1wRK)wgCKX$`UK0wHz-v;Wf?ieEjfIY6rA(_q z3kf=s|KW(ehr9R{7qj^GF;3$UKEMI&z;>*{O3cU0&`g;e%F}r-QE3s>9EjWcir`NWJG=q#_2&=HSARifqLq)7|0 z?ZzJ*BpdMxtTZW?I@+GYRAeFpPeVnZ8d3hu0dWS(nI47?Cgn_(#qoFG+iGa8-3UJr z@F(#;_G1&2<5U4x96F;DoE^r_jhDmH zy}X-LWQKYv>Z;6bW!xpqM$?V@#jH1VvI?gH2_L<|mw(c9V{I;f#o0y^!=0I84wz%? zTkJ7{v)B`^j{HL%AxG^aS@=XH^iG%tjIhpaAv|)y^D8k^X2QRzaDY^1n6LXsVCZ^4V-zt`mZ1; zi}f8x(KV>wI*y#lQuSe)=a0oGj6`qrLOWWJw8=gZu-#VBsp8{z)g-@|9b<>nZDXQ?rdL$>2Gi_nq%&yeHTuzq#o%6c4G_P!~)ERrg3Q)jRANHT3^ty`8X<|Jn}%j z(cid)ukj)FX)$jv8_r3Ei`Z80qkMx7+C*snr+J@>RNA2}ltXI*q;$dZ8y&@K#ofd1cs8UP3vxk8lvG>{YI91GEs43@t)9`H3*L-7ugY zO6v|AunbEv8Iv#yBQPB8(GEJB`cID2KX5^73133p*di>%c#MNavPx_WL2I;v4)nq( z1RdzN@f~!M;d$)CUMz*Wz**3mdn&@AyqpJGUkFCle@3hvv>LE#=BO?(4n3fOX%Q$< zk_$g@e5%k&YYiXbINpK|b|p=;I5-!|DyO3fYC-D}p(ucJ9GfR|v;R-9u?<_X3L2a) zz*vmIQ&6U*3&K$sITtR}RcgSx0n4xynyF5Lk}c{UH9IW=%}jOt{=uVSJ~-(Y9bz9r zbHxKtdRv1*t*hMUNYLS=G`G%+QvKCYOhY2Hp7IO^LPt?!9deCO73v>PLi51=*p7FQ zjg8m<%>%vA+)wkq!YBmi5DH>jB`oSozs4)bIn~oTx~6mL8r{g!Nb-GX;bl9NYg8Y( z5juQcK`*qxZ$$f1yoYz8}Ei*ZQADCqqPLO>=u%UaJ< zDq3l1MZRjFMnelSivEGT@O+l{utC9L;k<*ia(Rw;ixZv*i;tUSs5H>?orKd3j9iT<; zicm+TPAX?H$@>I;2I3Kip?DfY&C_kV8Y>Y|>hMM6&i7Tfmc2WVF!KjKu6O|CCwOxV%Xa?m5oi)8X?DFzj z)VqaEV6EgoXORqL#?s;6_2*Te@m|H7zA~Eec4C*mGAbH=-fSZzj}dET95-4U$!7L( zqlW+DaY~)6({8yp*L@9+XsE|=p|72UiI)15#(o|{p^)l>-q5;paTJ4Q;i{*|IX_vz z&zgVyMP!`D2T&=6hAZ>&0;VBRa}f_4E>M7Py~mTzR@FqgD_Wujs^J`Au>^gfvIVt+ z%c0zuDihM7(L^k|L*=BUQ3_gCE&wepKOl0n1gH_kQZ4&UW}`8FB5agnR=d^;m7x_l z4f*d89;&NXlco`Xdj2`kiks3_Q;`Xc2DFS)2+B&$fR<7eL21xLISOTPhUl=~ZLk*` z?VypkM&SyZZwQOicn8^d4I8lmYSxzGIcQlW2&V`cg^&i!74c}9wwL`}4*6j1Zfi#m z_4?y~F_su+ku%0A|K&5rRKp*0*66R6XXmFzja=2OH#tu8MthZ|WpTxm&Z*oFPaI0( zEr(U(;}7}L7#mocno4R!SrHXb1nMI15*kX0Dr^p_OkYcHJD~n?1|~!4 zP$&KQ4BJnkE0h9N)1_&p2L+)DVx9J@cj5gO8g(ASHmt`wybL90CSo*Vpn~G=S$tEr zM&|-3Pg)tdahG8G3(h$KDh*XXyBn*Z^3YkB0tIRyn?rNNwoX7&62}>pDs`#^j+#L& z``y5&IE$W#__hl>q2f0!sHnqsI&0OB4u^86t}M>A3CScief8*^)|nc`M*_F3ep4&gPJUC% z7ixN0RbHtE@In^jp z#mkv!fq#gBZBUas6iykWdT6~zt4^iMfOdIx_&T(!;U5#`o?-Z(`px(=*zEO(vC)6$ z4`XYfoLHZ}amVgyQ|*>fJ?(PL!(5Dmdf42!#@;%QbI|l=EV|%tUiDu``Vq1$)Wwc6FnhiCRDtysISOOCoQ_aN7 zn1qRlMsL)EmRkN{@7%*p+`z9;hj|4mMbRu*DX9?{j?P+{eZX$}9_8>G1_n%;`;SIp6&RgU$V&-9_`Ua1zeoK72q=-{_%@!rFSG6I0SzbWKc28RhX^o?D_gOD=pE zgf~%ZFLCs?$y#smuM2jsGJ^Pk1hZpqx8M9Hx4V(QL5Mpn#B3Ahe$1K}bSIYD^MKUj zjY4R^;ia{snOcXOk|)of}v5|7-)u^fW8QVMsezi)gov`R5RX4&^nl3 z7cvSbIZcDA!LQ&lKEtO_CE-yV!B#}09;%=+Gz(U5?L#EW<2-SvJW&s*#^qDuOnIIW zsB0RRsil68Fk6m(sEAJqGmXbaK_}KY-JmL;bV7K2DARfne(b;s%!4wkD)~!9Rh%cn z=3pumd41t5?AfFGSZ2m_b41l-G(#EWfz})}b^Hoi`_~jwD|Q;6Y3V-!T8OKH%1}qM zkDWIbIp1MGJG31m`(D<_-Yj|1sMw#S2Zc=FBST!&sRRaJp2+BEZ>m0yg2g%eN^7Xb z)N*WOT1?=Ew8*i6HHwVDhk)2;dz+UJ8bu$kt1|59c!eIHKf$~01H&VEK6u|E;=7`VHUh-)X3r_zRYOrqekrY!NB^VKDomgGU}5vJo=Ok>rvV# zp1ay7S|1mZ%BN#!80m@hbdF5&hPUTDcl{wBF2Sdh@Btpy&GuuY$bl!8WDQL9?^4su zzF!)3Rp(R2tk&LWpXKSAp$EV-jM68TP{_km^G2p8=)b4%;UtNPe2RLp4t3dq$)$KY!AC_EXc+$sncS-3HAudlx{i3-o z*j=)2;KfV##B+wem(Nj&Odp>d9iNtxoRXQYPgCKOUgGtC6VhF^%=bfi4r(+SbQ~9{ zl8Eq>*zm}3R$Rl`^W158j`RG(6OzNbMUIK=7oC=nnql4yH5z8|h|;~*XPWQ?^bC^| zq5~g1qV?P~PtCDZ+$SU^>dedN%yhlt-oStQw*bQqMDClqX zsQAzree#MYj(D)%_keh4?djpo;CWb$rtk8MY6aTzHv8$?jhQjyeUS+@{ShVHXEk{V zD&>C3pwZQ%(kI=RGfKNV<@Jn-Ow)(hc+JzL-DUj0mv%oL?0>R?yRczRg}c*uZnPWH zd3Hmp4tgXsZE>c*P1(Ld!>CNkH&B}Y1vE!PR7W+0;t~zzS$u+bu@Ez%G-3<}V-QFk zW?8i*8dDWS0cc8m9pB>{e2D$n2Q9;C4zv_Yp!H>C@l&8ozD5E{J9a=bG(|;dilk0I zXSs={MrE}u_YbY@PdI|Zco(~|3`)f$VmJmti_wpx4%A9tp>_TYYOOVvOGAGsThkf! zP!^gy{Y{hoGgKX`CR`PYowO_$0nM{jlBo84HZ-rUgPc>D%e2#rp=#FA(3npt!%*bH zUo_8u;tD>%I?P8r;xH6XV+b_;?uo&V@$D{c_*N`KA5@3h_R?@;XHZ~Js0l;^=xxq) zBAP}KItlG0K7d9P%GM~JHdyU=yO)gOA@(Qum?~om&QEK)bbd6P$EM5o$) z53Q&^BC4oa;i6G0iiX{O)c?8Lz(3LlK=Ga;&L2k8gJf6@y-xgA{}4@`W}vnBPrsCC z^&DwldX?mKtCum`+;->IM?u;5_^`(cd_H!6-M_tA;K9(?I8WQ| zT6kQ6e$9FrtleRK1eacnNUKFnR;y(Fl%qkk8dzQlo&KbER|&k{flpWB)4me*hAjH9 zFDr$T?$PH~jkk9`t!+9zN_60q5$E9)<<6{hOO9P*Kd?Y=oxz7z>DA1jKgo=v`{qB} z`yi1s>vMFz)|0S%Rqi$C|F+&PCh!{4;96b3TI7c>FHJL7N6`msH%F>GuV$c!v123W zb9&zw8hUA(kY$Cr|<_YToRvHKkJ$#i!yD~O`I^&8OBGbVwCpPL`~bTn57iYe5i z2OcFM6ez#2p5ItbC*vcioDh8Yry4)7*Z62Ed)Sd9WJ|T9(|uUasHbL+d(1bN7-b%R zSb#|7qu%>Qq2*L9I<<&;^Ag4fk%{&ZU2~Lod@bv+HtP;?mu|$5b?I&rGrc*Uy@%d6 z-K(8UzoaLsj{V_(Gw1hk2YUZv|EKq-+c)3u;clEi=c~7Olu_1t^|HJ~PZYa6o@eWg zOrtAJ<1^5#15AIA&SCWLp-k-Z#JqZNcJ%0z;sT%Z#^6B15$nOF^Xf&VjN>ltPMDAS z8pkKTS+VE5CyaH-wf}ddKx5;nshwHN6Rtsn^&T)hx;UO}N=jTJ(K?`6j**3@V=^CC z=JkYIfn77lzyHsDJ`z{8%myutYPtG&IRdm<*{qS5BH30gjM702c>a4;sj3Z|Hj8Oe zzkb8;rcGlW3vbZCTR%LiY14+`k+IF1HD-@CY1H^}>u;V&jBy1HAbSW}^WS3C{@PzU z?smd9e?H?cLr|3@5rxOP5wqIZ%**>LIV34hkk^9fEJ3^1H zx>@jok*k^0*xFMM=il@A?Dq!Bu%-(hr+Lsr(Fo`M`o%;^Q5PGqZ1+%^-+NT?P2VPXk7$$iq(#05qWy? zqI5J^vk+@mp$DpI1R0A0tjRqM<=#BA{>>VfuHL6gYhQ=yPt6h8U!AJ&e`6LRagm~&qt-Abvoz} zE(fb>u{|42@fb8hRMD2srMkypP$R`l(4w=l>_?z{(2fD7L; z;Jk`#Y{Ul4gcg4^IQ2p~b*I83XL9l`V@?fLk7FUk ze_dukdI_&W$?=6ya(owy5;mf?b z-WY0zzHSupm)UGw%VnN^;0`mtAK@;g8Y~u)h8H#R`RYC!?o0i<3lnj*|H%v-INEAF z{Deub^^uk}Xv_lR2&=V=OG$}Q)1fg?iYG>`8rLTzN4Wav!#@N4JJ;BMWPPNX(+Dx8 z&WIdGch7NeeajQQ#vcU$w)BzIM_%QW5uV(LD9Fv{ZNTGQgvYyGcbgEdOX zqXC5e*t{^*O~I0LPJ}sqx=|yPj6`O-Gle$KOgB=kOrJg?yS?@cP1GTK=iH_Vx`i*G z#f2T%3>DeTfr@PO7Fo*lsmNv!RAkc-)lm)kkQaw(wsu3Az?IM%f)|6exG;!~mS_RB zZ%*ONw=_>z@j6yvB~&f_98#fKZZx`}GnzmrQq)8!G|@dp6Q*WOr2`wV9%+b$7u^c@ z=FBgX^$Ts5&QiLJ!#D)Ji_06(X%+LJq;_klcDf--q69vng>t5~ud}@wYUSo(E_7Oj zmXNEX477B7pGN2(s1Su*SmUvI-=0gg7TKYvuVOF5nbiz!;1~0)|5!e9jb) z%Fl{H9lXlUlvhP2DkiEx#g@fUOjq6~cE5vC^NXOON~PzELMuax>CMm* zwpOWCCJ~Gv{6LJIh2FRIRXDMl$#w=5ud2%FgWhP2QYe7@$a3-R0Rf;Yo!_A4Y31@4 zU>xco3_lW^Utl{_Ua<)(uh;;s7Bz=b`gKtU#c-4ueHE(E3B!HTI{I{^=b?g}DQ*|{ z%$Gm7hWlO~UwC3ug=VPvb}_ofO-0<(g7_TpvSz+r#>-YyUY+07Cn_mW7wQlBa+-1l zs!Ao|Q69OVW;qpFl<5PN_P0k}Tqb6;WUE$JgU5VOnZ!NfNAJ{g6-pDTu(ypC1GNAX zfub;Qof!BE7jYKvVH>t09=+jI_G%2Ne4$c>Dy3KtXQViq?Po9o9q{NV@f0C)KqWUS zMcjeyP$}YT*a%hfPJmAROh!NS#gpiSCa8s)D35Z`h_N8TaElmIJ;vM6=x`$xiz>%h z2EA3pY~>l#5Q(SIACIFMnxZbsqc93V)xfIDcy#EfQR5*fpl4t*CLs-~%SeT4Goqn2 zsew>~oz#tQU7>|3orii7N@O;~b;9T(EP&&oMnKJ84@5u}1ZwIG z+#v#g$4rEq; zVH%<^2m{dr&M8-|)Q+l5p)v|17t~hjJgo2W9WLM`-p77y$2-vRun`-eV?u8$oQWZ5 zjv8~A-3x%P^2iJ+Pi?{%tFu4$FTO*-9zYVgQ@J)?tBh)~36vPoi(2vOohgRON zLM!hlpfWYpQmnvSXdKWMYD;TFCpUgVcy7XKEQJ>06}FmfjKJ_9S7ocvLaXylQ46Xg z|CoS04h7~1#B^2jSWov%Go-7V&zp2c*(4bM&16~W+4j7Xwv}yC-Z(BTGU<^-QWBGc znmIFcF{DNlQ&PQYPgv_+(UHo9X$r&LkwLLeeAaBn^>2c-m3}6Lp=@pn$pz&V$ik7v zu<~X~KKwf~$$6qPqkR6UvGLe~@H#$?>O8Mwr$91P94!IX*eJlhp zr5i&oQs>>d?7K?z#%8d9+MF~_jyurrvv{cW=$OF&2|R>=`y7NGW>E9bUdp;piE5c^43ye** zko$k`mj&9&of6`BT!att7|jAcuS?g!PU6`SJG@ESsXIoQr`TOuEf4&gz{{X#ZoMjj zm)aGWl%_|bd2L3WKF@>cT7Hy{dVH7J8NZ^k0YU!I7 znZNZtxvYeF?0I)sWh+oM@wRtoEXy@|yw0;@9cpt~cbP0tyYalmo3(Be>HMz!j1&S) zY}5JV^D$bTx1Of`8R+)o(NPt}o6xiKtsGt;5vtj~_52jB%DV^tDR;;3M(g9$Sv%n{ zAOUSb_`nMeH&Weod8XR^^QpD1a*34Tc|8rW4K~ag?$Ka&`ZJFL!3 z69B!XOed&g)14XotZi+O^So@E}fFbUh1S&3p)Z`pz}uZ!v#%xRoJ%*QRo2G@#KOg3o2#( z6L+9VgE}?UT5rc@yn-2c8Cfbd8-^#LnM2ObttLO~9Fsy&2X~uJO>YOFNy90e#M{`0 z)mVh*F&1OsEFiaITWiNnPzI$D3b*ogztiif;_w1a<0EL+q2AKOOw2$Ek}(K9&>i(r z59Lu9h2Wf@@*M%Kne}n(#U8AIW+{5#u;(yU^D66P72jV|%la1HDiWwB8dcknAFn8|jH@f8l@0MrsV zt-yOItg?plwRnA4$$j#Kb)8v^X|mq3lH+C@XhY4G(_7&(Nsa z#7t=Nr`mgG0_aTsyjOqp)I74QDw7UWan~gW+V~tV2V`#Ly@&E3qRI%^7!% z3g%}??r)7W|9i>qHXQBd=-fti^HM)|T_eR`puanh+vw*nKEVA#ZvQJo-75m`!o!1f zm0)Tuw$kT}Pl@#-})oJxGJ5Y2Oh@ zU*bH}!)coK7Pi2Idbx%OWO&(UdZU1W7=YH$BGVS=q{k8HhrZAPQf*X#-iXQ#XCdi# zUP4u=YI?Q_E3h0+Dohpbnyx8b`!vd32_y$6ONaU%BPH3Gs24L>uFmE{RTvCzhjkD>E({AJ1%yQt^_u=&pEld$eG@k3D<2 zX?*%P4nC{fId1JXDcN-WPNQ}l-qIdT8$JA4XY|0R;a{$Z{^Lw}8g)NHO~8~d^bHxt zT$Q0L2B_@gtzZif<5S%CSnvVX_Z+w!WWiZLUf&iV7l&40#X0T)8^DcV9aszcz;wAk z6y3N7Yy!6dEw!tFBDr%wh-_%7Js5=hGw#N0v)}+Q5$pvN!H|P(2*`Q14;Tk_1s`Lj zZ-HmQX7D(;LrF|)_`pJF@8i||P0F~)19=tXG&>nY;6Y4RPOhooPgvcv;4*M7mEq3<_X2P#UFP^Y(Y}B9J-DNwyp;1q;AV^Z83---MUpFvpiZ{X9wyuj-FB z?+~9Dqv)U4qZc-$S_?HZ4M!L=*DfRt)gMXv%R#8CFu)0qTh{a{qq^`eMzc5Ps6M&`wU8G8~DPbro|ReT}I(OBc5`%H`p29rlw5byM0-T&4bA zX_uL97xe2EZi%AZ;@(Lup-|ltR}H#K_M|fqt)9Y43q%(DLsA3M(;}Ip#J)noiL0GN zF*PSk^U+oCz9;>TT?E&rzeD}f`O5RBG*tFGk7OZJ_4dQ)>;T6RcDY47-B(9E1>&b8 zp?h#Rk*0N)q?U>zlgl<7=&VO7b zM29iwjEYMG&2>kI#M7piG!+{MUa#5X6Mcsqr7>Zn=(IYaW$~?VM0*}D+rorUtEb_- zEQ)dvK%_AM$=>KfwK-Q^aFH|W8fwnVP4TTKB=;QMRx0G<_kSI=96z$EiTV9S)sTBH z8F8wD{s!-Z)?|eK)YLD`Xm5z5_ZFfFJ3B{2E}t$sZm@1rG^QNhCr1=r8b~J{RiHbO zn%8f|iNu>tBgF3G`oQW}#OSr|D+EZb5#Y;mC1;Atl*eMUDCB8s$1ThEYj!yF-_!Tztkiv%2|Vy$AuEKVyqEv&(Xjs&_a<`&NwG99-0SuiS*K%N_g zFf!m&&6^AXzw* z&*Q+SZ0b5Ny$AjZB*c0hYy~<*iNh*<`(q#udl8req`MM1I1C&LK45Q`zG@XX0+bc~ zx}Qy6UK#P(_26tEA=G#fIIO%e%B+$XM*Ot`t^=!qgis1I>;Xhm?`MzS2(;hl!6`s_ z!LxyKgOv~bG5hD~y|f@^{7sTjov9Dp$Q#OCA<72bJKdGwi`osdWwN4v{; zEMGUCGhLa|L&3X_I;iW*qSRBV~vEsS%P^{&*X932dP zWzPFpnb3na4T&je4MEtH#UqYnoaJtr<{CS430JKxJGpr4`^gDqW;m0NYg+Z&RcEs4 zKdl1NM+Z@+Q>&X)vg)y?RB4|zX?^LoLLoNKXQtzj$K9V}@zcJJy!(Bb%-3F2^@pI#nyX>tF?kROnr@bUWwNGzd zyr}i0r3+is&od8U-@x_bYM`vHOjem=>Y=(!DSFt%)f2ZZt5#BTdF1zNBeI>5^i5?! zq|(%>KovBq_E-o|iH^7ZoNno2g|F2L-L(Qk?spiuS`T;17PKb25eo@+);uUwCy}Mj z(8oS1P#Z`rMZttG_4A^TB3P@adbYWFUcES+O%|r0SG5x)S^5GH&G6CPn}eo1{M3YXuFIAr};+m-IO><4fh+q9#zWqC`e?F7LBbd zgsrAeI~AHAo?1pUF4NiGz}iMe3Y|s*Bj};KAkvVbHgOhlET&&Er6hr@VlDOAceU@i zA8#`>YM2JEyDVzHy@%7*w4TxJrh!HKTyVvzRTAG%cPAKF>*3I1?f0p#Zj}Ey*zPym2$dBXJ3hB-X?voYv+fuukbQU?X4OIFM70UR?62;-bF3< z<{Urv{b*uCq1~>Pw(FqXuULcP$5wL^zjxDtZaLI@wa!iDW|_$zxnPb4n}};uViDG) zHfT(_Vm(7rs=fCId$3^^w-?pGZVLJ1Q!QH0@+*4bTg#4|Im1#CXfx`+nx7(ChV%vaaFKTU4(gg1A#6oodCPNxzuj5VC9m0Bf zclAoGIDWPAL1sa`y8j^Zo&qGKDhols38 zf6j$swwUXP-{^~`j(5oc7-_E#m+{#CC`IO2e0YC!P}wIAq%-W|kS5){F9NmR6Da9E zM4)twwlr}fP!oY}|4|6+74QV8yN2RRw@`>&tq1dgeBJwkNnkW6KLlaA0i5hf)K&=6 zGeDyD9GC(=hX_g9rVB$?fb+n)U;+37-lL4gO+fOaL&3{%m^;BnumMP^nFm3o*}~^f zpfq>M*(-;}Vz49l3tZ+8U@Le4NcVjj5Wi8>Nq2MVvXtfE81Nn(#n|RJmK>pf6@I7!YI0wub1GSvV2i^KJ6-eA2Ex=a&RFifIMgiW>Y*f9y&X@U)gp`CYEgno^<%dyOjFY z$OYQ3%YLf5EvL3>YbQ-;t+M%Mo32=pPl~VYc*YJa=Y*7}2BTx{xk~!V=MkZEK$Z~T zE9n6ll|c}&X85Yr(dkKhiQw>`e-OQ!tek(tq~TZBMEPXp(N%jXmex@DXUS2-a;-i# zyK#lE>Zb9&WI1-$B|Ev?ak|Bp2v&)~1-Stdo?c zAG>c;W3ex-cerIZveT57RD0R=uNMD$!s}@vzt0ieWyzHwaw>SACOuvuUYW$YeTdhLvA#3}<^4&cA1JT-gOll0j98oA1TE za{BykZxn#RawJ0kXth^2bH78_@cU2>3o@uTka1aW)5o%6RZV8A&hF;nc_mN|#uu-N_Bpv~YmSYn>Or35$6qDU zt(m~P>>OjRR48eBg)?rL5Z4tP+zB`GHl!015A`f*Ny{SVI;ygx`V3L4E#xRK&cRGF zgBr<^sFX6c)2W5*Z)whI zyo|`XwfI!ZYAG*f%dUCmx82q(>x5x`s3|op<#t#JYeb`Yg!X0A>0)CNp?QY?=#Q?V zQ@YH*z}w(0@FsW}D23*n$N1|GumM~HhJf;CvS1nb4p;yh!QtRApzAfqg9s#n?zZ~~ zdg00=I0YO9W&tJaNHU7 z3gzTH1azgSqP~&_v;uj^lp3fgZY!7#q^oTPlN9QI3&!^_C;`R5#P;q3!Mk-8pUa>G zia@MR@}OBjtnLsn4oCz3Gw>52VQnC6SM&K&PzIU{ouK-sveCcGH6EOsJes|sfcqQQ z3=?h8T&`MFna@?1wDRCvCLu|;!F!Ca}Qy2bSmJKaf1bA4JJ@1%% z+H#kO_w$>hGq1aUe3_*sGl-%`rzJK&B!yazc`DkVFta^LW3dUhBsixJn}I}()$j2P zw=spURXuMUe6?)rh9hW*m@?nipzeq|!$T zD?^V@C|9eC=9oQ)F3Prd zJZ!dDmE!{c!6Bqh_B)n;x{XC+S-Z7DZFMcguoT^4FIHd3w7jPU&l%$gKXSJfwL_cq zB$aI&KFVY7BhYEUu7+TsF~M|gRAhd=)YL^K8^_8kp^aD94UG-`9`FC7s3AW8-@IBt zg|nyk734#pHco2mcjF#6pES}mfoEx6F$T~uiD&(UVH7mUI^O1Kn zekCho=hf{~D&kC621Qe>wN!&j-*P8Z8?3}_s-~t5oy1OUiSV^CH?qORu#MgsvD|$J z$EnMs6>SQ0S3PRfsCH(u-u-_LUte?f`WiQH{pl;_^tIm@{Gq-5@!|!^mn!E!J7(mo z-H)scweDLs6SGh{H4dymo!bMc$+?q*U%JB4N#oN4lg1iq4sM!A0rhQEKL<}f<>ARI j3`}>fxSHjRD&*}%xxMJXw$0gNw0UI^m%sSs)=c^zjU8*K delta 35333 zcmb8&2Y6F;`1k*ula^ifk|AO54T8uXvWIMxm9{CZv`J}NmPnAHAjk@EK-r)SkyRil z$VO2%g2@cr>x6eZDHklki>o<7ym_wAp;NZeeL(5Y7j3;D_|bytBpQ zO8Vmr9FIT`zED3fBP{%o{x}oIda`fxh5CGEhejyIq;&qSYp z344%}XQIc2a0JKG9~b7>w~04Pd20HCBAARfd1`uG6ne>Tq(6R{r3kV>o>~Auc8l>!a6KUe_Wd5)9B2vrq7oF zL1U}LucpUkF%B!!AD82JIjZuj>htB1jFah)i9K6IwB=XV=ZT;|6Qg8m&anGgr>%WB z-4PZ+FxX<%7fu$?MP(F54rGTNCJa30XFb9>oXu`)WIMvaVQhwlF&K!R=z(@kFXv07CSa|B2HGedGPQp2Nn9cShO-R3$n%gse@)cahC7i@}*aj~KAO>yG z2CdN$)leE|_+fgIhp-#FuoD}x0rSuS8M1Tkzvd;~gtt)<5%`~Lg+Cb;&Y6L4~d9Gey9`5st^82H+CC0aSms(7ZdO*{-XC< zfsZi_<1rjVQ5HINCvY5J!;R9o%4wa0H&GuIkO@y{0)OK#w7AEcySRke_z07b3@?(< z1KrUE&uABqa1Cd08r!W!$IMdG);9L9O)Z4NrQPlUj^tQZLM4aO@xozC*NdOvE89lA z_*u99ZyEQCU-ROp|NEcYlzH*9|KoqX_@E`yyQjN))0AMzp(G9m-+(IOV2 zCvqSY)DqMJ`k_54W~M1s;Gh^@MiCq(x@V#tOxz=yf5tH!#U^aT2CTp*n2NS&godbz z8mNxaD1``oOXQD4BwC??k2m#E2ZfLW+3`C~;WQ585LRO%hN3IFpcPu81)kDGPU9$c zVFO|jgFa}B26zosQ3VB1@eIvlBHH0^n#CPlPH!Ryc>g_yp`2+;U6VTE{~@^68~*iQ zo%7Gw;w}{FigFT+YF+fzuuJ=nY{eA zZ2WXZrUvxuMBW*k#%?Gwd!ilGvDd<7B2S}?MwSSuuU?0>_!xeCfcK#pOi5fP=;q=* zBqBN+la443TA?Lg$7`sJ64uVCW?5e%K~^k1;Ql7K{=#LP#_jdu`*Jh)AGoXBxS4}aXn^Xdrta@04vr8-V-b)3=!aHNw|0OC z8iPpm$Ln|v8uSaJ5S|f5cX0_9@eTH355B~5%*7{|iYb_k(dz!*;~)l|P!Yx9KtAM! zLNp^X;5H$78i#NY>#+`N@hN8ELrlO(yo(Xg48nu1XoQ9+343GS+$W|_;z#Vq_gIVB z_z08m9^%j!eUKOD2>03k71K)kYI0Nqnpb3oI?q%12?uciQ!ohXEdL?6*T4yNgntsl zno9hL6Zi@+hymz`=4gh-sD+w#Tkc>(D9eMBM3Ext1Aq1P1^kI8^QY!KaX*Xy z;i;ObRd+QqgVDy9*#@LX+YF935MA#f1?tZFAP)`@U7CjmumT^UIm+QY5w#ezFcTwD z7bZ3mP;qz*9nk@Ga5pQ__8AeSIc5%MkW`Go;Do zWt_t??8Dbsfq9sVX;9ZV1!FMUPA+1AWn4B3zfqjWg^(Q)Fk!%khn)Oha1NS`euXty zja68P1sDr2g2Cc{aJgk_fvY#O_@@reo;vSXpR{1&(>6EHSzVWM2LIb4=pezg6I$kN zgaS@Wz0a@&ehfn*v_N_jy`aUBmU+eDKsdsn+20>p1U(=Uui^?$;U}EL_fX`fLMZ@0 zreg?V@Fsd8wA8E5adni1rjCV>1KII65&bKE!9`raUTlb<>srpiGEBlmd60xe$&p+@#sxz;&F(F@y$|uQ=AgvKgO4 z1I%m;*MQ>YAOW4x1nNI(;UyGA0c687`U@>Jf5mlN!%l3(2F!t$pc+8lf#yX0&=+0M z8Vyh%)lm&Md~`GyppNGUY{oKZlKwID`H^@RNf?NJ(7@6Ko$&^m<26)-Ch!H3A6bwY zcj==v03F2xsVhYsPk*0u&5R7W+0W_Ecv&IAp7zv2O|L5uBFEW>A*h~ZF|;$QTn zmA~4Pyy2A`(XPs=>woKz+25#EHh|n!|Y_ z^&3n?DDt(8D1;{j-+kP}63ShGb|`r9joFY{O0BNGpq&B;Hg&5ga05KEWFZ z!yU#s&7^+7R;4<|2r}R{0jL2-xfJD4 zKE@PG#z%M$N=3$@C>{}%t1uWVmO9jDAeUEuhP}Wo2hx+sE*iL{h#ak!~b+vvZLOthMVr~XLf~JEx5CH=XY`nQn z5MIVf{D|#HL>c@-@TI~9P3Qk0PS!&4GAunSSTs;9uhBN6{pJM>lA?r6uc^M3%Zb&4`-f z4}v6=t4`&389u{AG(|mVCZk!*PdJGKP*8o3ZTK3?umC==lJ(hoanKW*!n8wMG=h@b zWf6gcMAtZIW}<}2KLpNkXo=bqb?|_ISc-8NhM{nx4YZO}(3F72{C(JpEg5MBT1BqG zYAnVgs4G-9MUmACl~D=B;XpAc%aR*^6KNXHBTpk;%$c$~cif*6DRbx?Jw`)NNOfBf&Y)Wf{?C z9;;YsqpTG<$Ea+bi7_)<6H6O)BOH8vqQ~ovi;QU(wh>O?22~8c#;D9Dj6B=Ch>c$s!=6SBDe80ZCuxmU3Q+J zx=)3j)(i8{1zB;7IQj;Au^Q1(Z}$iBbP`jb+*(;h*NJZE znw5Px#Yc7I!au}>hR>@wjZ^sVP&$H-y#nof%)=nK5DjH{wWF#D<`L|{ZY;N+=Cl{^ z)#Xt6-Ff&B$}_}6)4_cBoinbf-YM+I*U&U?Ef&Lr81z9$)Iv7=O=R4|U4&+IM-?sD zj4#kToHo*lgN|s9W@rknZEK?#G;@1MSY5z(*oUvN6eMp6%WB;yZhU2@M+z)0VZ^5eL0Mk9{n~9L2%>qXh2uhK zFEArEbHYDEZ{$W+JmZA_gX>UsVgM8b=Q;5!(H~ur73Vm=>M*qL9O^67KUB-gerYKV zN+KKfadJnY7L>-{!3ouH6lcBB*(m8#|DeT#77i=092!vO;uB24WDG$a+~LH|MOWm- zcbqVt(4|-clFb>MI4}}wXp%?#qYh4qgOyF8Gqh^?$CTkULWjx6h9p_C>ii=E1 zb~#*wT?{l!$0-4{DEdQj7R^T&Hz7Ar}I4Te&Q5r`qL6m zIdu=AIrcS#c57F0{5hsV$tUgbYwXafx;RdA8V^DHox89TJFo#7OFjmxWuGmDgGh9S zwtkdPZ-M5hiLxjI#YGlm#y^~T4Lnz&*~=BzvgqF`g z<9lq=lt??V>#+`Nu@sv4Yg=Fl2I6gm769tGv;cSwRZ#^cQ3AOTiu$WW^cDOBO|!N_ zsk#Nw)M^ZTqj~cl21AM1C`6(Mx}zIfLBnYkltp0_!ZVu4T_~@25n51ar*{v&ghtpU z&P5CU&K+RnXpa4drDSoG+sj+Rcj67!HY1Oh?JG&WGt%u!=ni)K9=6-Ig zVs~SV;SQ|sZgkEZINiiJXc%5=MKhy8FilL{+C20DYOP8WD~qRviV85aLe{GIGIn4) zHXs%2pqZaKWxlz4hf(BHyY9EE0cYBYn8h;HbLE@*{%sEUik@c*7uqP4E#lS(Yj!25`THYn=h zRj4skhW2iABeX%GAs`wpp($Y&D1QIJ6DU>{lL|YH?|%{r_i+_Mtp>#|gsFWciej^rsg4Q7iupb&0zQlSg#Z-KNQAmQXGH=S_ zWfVbnsP^Gk+=uomenx18y_e&6(Frx6?DIdw&Qtt~2iS~{Fan8CYy~qn{4VaHWfJE^TDd>+u)g zPqC`Pv8%*qs1!$|%=g$1Wqrz_2vj_z3{R+lC{#Rji+EMNkY<*fuoBw-n2dKZ2#L^& zrfYU~X}fUH3UyEs6;KQ>`;XqwQ(8ME+wgzN@r?BEY+TG&p06s3BFKfD$N@XFuc9sD zBM2pimvh_)S|Ta&QyXauaDGXSwf-&)8*bBHZb6BmHBddn7=&sW25Y&brBY~_)R^PY zQb`#kO^3^%G&D0RhypO6hIkulgg-#Z-YDdUMx+h2kNM~Y4IF>dCe}fD)#j*)vYBXf zWjM$RHJZ#&qtWKvRcL~&%{WbvMl_k3Ti`3DK)Mm(8PH*)SfiI3bm<` z9KVYgHM*iu4pjYbD7$ot*w^HC42EDZ`atuk*U%NdBqaQ zw+9=|t#yNqdJ!o}EU6svPWONm=K$;JVEXm=A;!}TMrku&D|fof4kM`PA~ zBh1GWw&mofs>P_ZGPLFVkQSj-)is3b98}152;X2c0{9ejFdOe;0RCI1SB#J4fkq2W z*E1j-e=0?#T-Gm8K1)qbi@C3%T&i+f^Dzmd;DZ);rH~y@X$?;h+K*8#RmE@{u@Wnw zN#b05f~lB-Sg3`a$kvfzf@YC`-q5DFwklNyq{(0nXhNvHaqXwvA<8e{JoaEWb|HWj zm~Sm=V$V~%JBM0Cwn2TU(Y(0H`7@2-96}@2ZjLuw)pr_YecDOa3@$q~d;1j+a1B4< zAT%Z|!~$qs@?$zQJ}G+}kKWKYrAb^}XtJh#k9^P=6$Z7xySM;tn17Io^Px$Z1};s^ zdO{oHwV@5xf(VBOuk37f|8Z$LI)cH6A76Ccp*l8ummJXq9;e`>+P9 zu>^}T5-HFGClWPrTN9fVMAIZBL!0EW=#GX6Mcz}w<^i)hT=`AHuJwlXPOLs zL)<8<|2DKr&_pcpbi+5E*AizK{-H_;ItpyISJ z9OgXl#x8sgB`!KZg=giE3w9jlJdaZ!`{D#ydr^gv1EHd`jp^rJbrLEN%7MQ*&wt?_ z?&1#iVgv@F9;%}p3PHQ*2CfnhClTtGYp8~P3skSE%&P+C2Vx-=D=`}%A`*&`hNks$ zZhJxht9^@D#by{20xM=1+s!~69cm`)_=iR*E7urfPXX$KqSK1YJj$m!5~(F~C6%@A zj4^i1>STubRR4XN@2Bo|CGUPAuFgY~64eK%Vm;Pk0sNSbAs7tRX1onm1HA!lRh59Y z#zWnzw#MmNgBjQhyq^vAo^93LHsV0}*P5t->L?9$sS(gtl)6mK#4|x_XfM<|DmE)Y zJz)e)7@(jdxTAcL_sYYLL~SUws%~xuKEOMw7aq=mCIzpf0hCH9gVV&?8h8+czEB6I zEhw!v3qkSt7qO;f{RF%VO&(lm3-wji;XpAcE*}ze>Z`6{e>UEzs^>dwvx+aKcuwoU zYH&dF1m$5uY1a%KhePW?CEgC=0M=nG)#+`Nu@p<7GGq(0@F6B337T)T zL0zaK7kp#v665D zq0v4QE)hKzMxz-NRe7L-i8}}l(m!*oQla)}g2t$Tte|TQR;_D4Q}qsCV3oSd&pB9t z`S<|ZtJYm{QOexuImqGH7@m zsP0k;k$zBEYHZC5?HwruW1udv7nO%7DrYD_RpZ*pMM*G3!D zTAR--7Fe{{$Y~g5t#wO`HoW_LiP1lpa;Qvr&E&bLm(;~A8j**i8kB0#o~QOX)vIY^ z=?zqZR$UHg)pde!QfH>Qpw?XTppqMv+uR^}ln4F^C-EJIqpw0Olo-@*lM;Y`5IWa! z4ccj1iAi_|F;LiPL=Gj6|GRR^$mf)rxPr@24p}{-Le2%%P=-Y3F(Bf!~Q|r6O+P0*+xE>f<5ta~>Mik6|kU zSdAr6e9cJP_3Gcup4kfQHg*^(){s3$ZQ^;=9;3O*!~5SDE5cKfy!C8W&Vu$r))(Iz zmH6q9eMWz~Rq=qam`@!%V2n5GdHombmbI=QG=^r-o~^e^ zVEZAXiDBigXcn}l9x%eJqU()ge2aVQjbDR-PuvD;mKFG^9Dhx~yHOwa_~g%+j^-$U ztjK~#1ob^!gZkGaQ1Neb{6-8bBfbe6p)OQ0PSJ007fdnEOw$)E5L-&H_J)@IRiS>f z1Qf(t!Gz;4;_wcXytbfvt`DJ|(~)>F=hlPA%CVJ%>bkOG7cuw+Gz0Aqb*rs2zm^uL zN-|eRacFIF4o9IaGv(A&kF_4lFcTlb=Wj5rfUf~Z8vIpmQV1_08#3T25&1W6;~dsu zA!fjjp%?-s610Hn1NGdU&;rfz--N=;d`y#C_3rG>`GT_nZNX{BrYoAE4qid1n-7J) z3WJsCy@m5o*RO)AkD;O}HHl;lK!0d=E*y6JO5|U|ReTTa#(f(`$FY@zFR%y;F%vT| z9U3l_rO*sn!-X<>YEp%f6HjO|_n`}#u0Xp(7oi#RafD_ZnrW&K9K6W} zrTA2Se-|n)eg4my_KVRl(Brt#GBY7R|D17~cN2a#>f~hDi1VfuD8#uP9=Fw~j+rly zF40I#@+5nrJn@c1XOh>IWc~WHF^K;ab>4{K-S_8>T4qX;HEWmAn}@&dGFtNP)!jxj z-qCUkSpMBc$>+7s8u`?)Ht!XFJZp57>uqp^V~}(6;4bEW!*Z%`pN@)NS=p1(lH- zxu8)wy=5lS(td~CkTQ`Hr8LUvrCx&MG~@eMSyS_x$l=V1;e z<2`7v?8OCY43FPLFR0{43jt03&tL;I8(WTL_zcR}&++j_Q?%Fdgyw$@nuaC73GHXK z#xq)c09pWO_$q)awB1!$f_cye>Lh3@NfUoJV$lzs(HxqAJ)%wifbsB+70Ohjz`=OVWI{ zTzpW&+D2#!w;b~@7oT7XCL;x{py4hb?$DfW;{udbRHj`++);c5585LP!Qf`j5IM}z z(&HHr?{ajntD20sWb49ZW3|yGFy)GI%{01LgRdJC!eWv<309|f%>34r`DV33Bo*D! z4%V!$BuBI}+3E1QsM2s!oDmps!&nj?$a>ePWtg56tI0iMyZ^$9VpfMAj03%#(Tw&q zr!qVPHLX3odqgvMh_ldTub)F{6iwiULE~8hN+G?8*v=ExY8}I&{UV3I^^U^6P$ESo zkV@OBqS}ijXgfa!^>Cjsd@-a|nWj;0I;LST6v|r1D$k-2R+jI7t6KY+C{;F(F!tFj z4kqG5c;H4nR3y?Cp~QGij+GqOi1^|PVf}=#EB*(fJ?cYAxdPBwr=+D7fS7A6;w<-6_YUr+L0Onjel?9O(>a@8UNkb zROP}!>_RF+#l)X*tnp9nNL46J>heYnN~>WFe1Fg;ZsHuyLTzd-v~{%v9oVGt6bk**iop$WLw##R==xDOn< zV&*ffLm!(fEfVWBtoyA@N|=5#JYh7q>3;5I<-1N0!<@vtBjR7^NBOHe|vG&nmwqgrZ{j$Jcw0{9#2acMe3Cf@}3L*l3 z)08xAybBFL$FLo#SPw1NXW;|912w;X=!@29fchv7t*f%Z2G!PF!Q}`pIr@3bildczPj7G?bFxYW} z7N&*R7HIEkHT;;4j%bFaD2p<V)F;>Btjy|l(s3E}J7_iDj` zZl7Sl1~uO+*oYNSQXzC9S{II6;&lX@EAKVJDaEBx?mjK=9?l_Dw-Cy|59VWUBMu$V z9)*;X&5j8CN^5(73(!88D#ui46u>NKD4YN{l%wyDuFxF4+o9UTV5{W4 z8(pBiGbJ#TyeMCXH(KEph8pEA?1VPXK1CFIz-CR$U>35@uQc-q&aE&@X0R46H?sxY zezRSM;GUMg=3e?_PdDdKVn4JC{3FNO1=h&48cOs>p$EF-HPpj>!u$%9ZV1iWzT$W_ zzJOL?(~yi0Z<;Jmezrlp!`KKXzOPZmqF`L2l!Uykb_z zzFb^ftyQ+1O%fcf9Z7KmVv`-J?QUdETWU7;IapX}K@}h8c2Qdqt%%d%4-nnqfCb2N!H5X}3yGY7m^vyU-wbnYQ_2CC4-#hZbgW9LGX?(7mCdu^BWB zKEPF|O`pO~IEnrE9_#Q4rf9)7nS&wd4@x_Nl^u0?|5)t~H*gFpVE+QEFbkTPYEtS# zN2ppu>6gd21-025P@7dTvMM;8cI16wU#NG_w_~|C|#|2pVmm) zvDHq;aA>}#xt`{ES~rD8k+vK+f_6KU-qvQWs*-$o3)w*vu^q$~%)x9Zt33%H;te$o z4FWl!RNrGlU-^jLQ2xP>>G%NeLn*&u7z!r};0m!b3yLAP(tITX7fPBLGg-GPnhmUS zmCUksf;7;vlDW?AUmG0}D3`}{rIkc*qHVd;Lr=GQP^rUU^u+53?YD*2{CW78LP$$_ z&8B8zBs2n4hc-bBgqG@uhzec#wE%uh$2+Kl+7X1G3V_NXCw3DWL(l zxJ5Lm1XcTPNzi79ve7xPm#Fv>o3RMppoFrL#$(YR>Uc9D1MX=a66$TgB_!0_D$zCr z+H)HZ3I&1}LJsGB6!PIOqGc^&p?%+QC<&~+{!o3SI?+B*Lbw95A`6rV{s&L-K%sIU z3Z0M85h`F)`s)eNa1R%89v0do4Bv6qwI{X}3!xgDzG#c8sDhFxf#S%Ayijf0w|Ez= zkW1%27oPvKteWQGfUA}{+6Y{&ZFV;T_3M~r!^=fGl3Y=)xWVcR)sK3)dx(zRF0RE% z8psZa*GrjBbYMb#bBNvQn$Ij{y;s6)6xdmU-Z0qBsRm)Yeiq%_XS~xDVIQC|YC-v> zA~;C=j71VuROvzoWQVF=K1XjT%cGvBE_6ZhLBc~JlmyjL=7pBH$F#gX%E4FAvR1WR z8r3yP-hfyrE2Ayi`cMyZmiW*>z5&{7&_J#&TE)+PLcj-=1vG=QFcpy(nUE282#NX7 z>T{Ydi+P^|EkVa3l!EQgv6iBBQ65E61ggz_ad6&8+|9xu5mcr zNI+-2fsSZ~rgmG6=PTIKd_Yr-OwiOq1!xzb?GxR3X9pCd+qjuT9`1dXEfCY(oE>gG zYi-_O=i_=C^QCbA{iP9stToJ!(&Aco?(4>XQCv^rU1<1LU%CoP3aR9O3PvCi9&|+) zycquld0YUx+$Re{E7~)}{$U(KXhq8~UN3klh&tjAp@JQC#;Vvy zJMQ}*+|T11OS2h@A&AF7XcFEReb5=YeqT*Z`zy^*3Hgv2s+!Q^b_w3aASA+tXhfk0 zx}yPfu|WoC@TW!kf;VB=%Y#sXnbJ|4umC;K5WmqJSK~8$3|%CkeQZs@@6jADV>X6D z`+k~BuYd>Yv9;`Mi+^ZUs*KRIcogcWS%#LAngD!HE773e9-9ANBeIpGi9}v}LqL9o zFR>Usp4tV4g8wF9-9nWg`&U|gGiaZn8ZHI)!ic&U75KGdD+qC_P`c5{{oLs|7)2uB!H zqp$}WhTnp^&<@a$tR%(P&^gq(dkIH)mP&3jAM*wG$&~p!f#cYMPoNru$ru7<0kwy# zyW?p+WXB!Oiza7N5sRWY!8uur0VoMo*r}pw2R0xTbD`D0ddD*vIA4c3FS_(Vldeac zlYJNsT`kZQx-M18=u4cJPZ64Q`8Xbkw$KXvB@{#ivLP#U50Zay9a^TSV|fSaT%u68 zGH;ZC*52we^oB;zr<{@>@GZVU@D#ChFJmtq2t=C4OlwVHdwAfL7;}zcy31O}2AGt0 zTN7fm;QjD}e)-cJ$(?5y~LNv>2LMB`25z(s;V zl>~>NMfXm8hEK5++D(~=Q3$1+HI1u-S5O<8&Xq$hsLfBsSd4+P%?>1J5X<8!3DyP;i=+^|y1T?}Q#L5Zm!U`#u3qPuPhO&@M97|y_)q2_qQsx;heVGSQ{7Rt(k)|t#D)Lgh4m@(XZD~#*> z?~OEb8Co$|_DFMDa1y7x!q($EDk{hD?lFT||*CbRCZmph;g( zD5X;x;RwT@1lJ!>G5-aqM^iDs77#D)ZKP#SiAoJSFP2Z`=kXIFat&0Ktn^NAyo$Q0 zj7q2grF6DoE7a|+!E7j{QyQmaZf=BSAp(2_D7+R+Z(Q0^y=OKWbl5gQPX zE@+9@@fs8tuLeu1bkkVtyV~}=flm9)!xWbUiXAd98iDuLn}25t#!*Y2#~Qv~aip@R zZ;1=l)TjM+>|Pr8J77h;kl< zImij+_8;O`T*oyiPk9PI;cF-mM?m?GK?vnM)HC)(4=7(*5ykK_LRYUC94jZHt5}o+ zIgP{0S*i=waz$OJs!r8~PQ?^x6S^x}p(X0$HPnLwyfR9lI2_P2Cl8(w(CeX%JmoT< z5Syt8U07U!Dj*-UKb8sB)OAK!oOZ(IK|5d?uzw~h7oZ!oeWk&<01W&} zG%9y^6069vM`xz^qo;Ihm~s{7yQRIw-?CLI&||^r+??^Jl6ejq~CA-XjU@)5w%KX=LHT7hSMN5=NLEIsbZ{q@#&(Y5AQ5=C*6mu~RqoF0TDkR=SYpDCKkK%AZ%Vb># zqWxW}nOwmO6}3iI>BKkq3Th?up*~(4yzfC}6q?FLq9tC3l0~6JQ3j6H_v?BrRW)6N zmM!{cou6agvo2pXSO2^9YvruS_EgU6W&vx<9j-WOeBFG@2+X}~+c znN`^ye)E<&G`y-iE^46v;)&9Mzi*k<%@T1539jfk$}hM_MvNyu-ZLaEzwUJC3*F8H zmsP!xS?1sWXMOsMnb-RI7s|J9{-R|1-ecxOYs77{XmMv$lq)e=X({FZbvqcPs%YV! z;0L<5x8~h7%lW$UNn3AMLSig8*@|&;Pg6R$;MEJw(*8@8^v`Q#K-UrFjF0De+Iqyg(l#5o|3`X;OdAc)f3|8*^e|pq3YDl((QRvb9_JV6@xGbE zI^s49TZz$TnDyszb6k06G!2DUT4_CXBf6QrCRo>T2B)zd+x$g474T_F_1~>LP5PBX zD-0W+(Q*6=-C{tM#NR<%d|zM{=HMe}7}b!elz|i7piU?>bSiC70QvDZeaT+&~UjHOQDN`#^VEw!!QhmvIspTL05uUS-*48Ja8wJP4HtnhJY(SZHb6R6k0(;=8Ic@MR{BVkLjdt z;s$izoC8n==tvEtD*udxYP-royXl2t!!vp-^=d!k9Cl$RK7jTmhC{uZcGb0`-U7{` zo=&^!XXvaBLp$lI(B8!=EW`pd8Oxh7(EeZw)Z3|qxhJYalgd(1k&M!kx)?-bxt2zY zvB-L3x>>-d8w03hOdVftsLoTvyyl*d>D+EYo!>dAlW;)AWCbunSsDZNf%u2)9*uev`eqd>~X8qYm^V3<0-nvDHU;YcDqeD5~kK(ui72 zsmnVKEu7S7wxnJ7zqXWBHMhOAwc@c^F>vCsnaMP~fuDaj$7RS6?0!mE7oV7wt!+=t z%z^p;n30B6G>3WF%6Y}S8l0T+_atm3)$7p)^#>$$m68@Sbx{cwp{2DQnw0*A^H_+E zD1&nZ@^S3Lw@|~-JkkrTW7H7JLMfNa_zJ63lfR4uRdi`sejfwyGX5kOf59D`z=!Ap z1+Mn3D?=sB1&|-lh{5ehLMuEarZ!?ev{so0#h}(G8cnBTs&+&|aTU)8isJ-!B*APq7peF%JLTKhv(rdc2KXHF#4E z!8=9qzC`e@!c&h$Sd+u-4zf0@!|bcVQ@o5aR*FEurOjO}fLfv+sz6i4yil6&4`S&jc3H- z5qygsSdWjPn2o`kXonZ8hjjN7U8eN87TB8NO@k8!kR1wS&G1yjPLCDrl(guMLoD7v zX6z&ehr^8oXmcYwZ1|nHyNz=QU^TRXF%!x$YGPL1%^R&@%AhE6!HzA&!deW1Qas8# zDn8l=*EZI)D&!ft0Ba)rmlgyDEmzb#dtXkDxuSD91qMUB#C*EXT+N8-*a9YEh zCd%n`S);1jOO>=WiH{F{D#0_DIZT2xnm-$mHn|CYF&8>n$E(^)`^|b~0$p?4_hzuF zo-zx!jeOy+3os>$XDY{~QSM3(Zj=z9f_G&%Mr-I3+ zWdDWl96n}No*`a66P0JUxIqTboAM0)q(<7a2^PvH4@-0fi#V8nabKpW6tCA2>lvbn z7k_tSX!?Kmdg4>`{k@JMy7%7zPjGJNQ6&d+!sk!L#>K1L+etsg(Vx#zOC00mHiIwT z=grpqg`c8V(B(|x*U`N1dFB59{2}_=3z5_rJGwRR6x=h7jB`7ahN(y;+L~b6i_td} zu(q1^dGsp1?Dht{n`O7(ntne_`CQv>&airb<-F5g(r9RJJ_Y^I4%$0v1kL+$K?}?< z+@uFkdTj{e(I5SwIb9cY#_Ldeq$*0|B@_hv_deS#x(8idqhU;&uE~hS0EFgmZ*r`i z11&h~KcR%N8U zNWvhv5RG2wiS%LimEbt5w6#{78ej8(m1c1BHHP=ykQqk^(mhbH?y}mOMqyvD*^pE5 zB(eO8a#aepN&fCgB!yPV!z$5mXc&}bd0ojViNS`EqSAr1)|}+x{{_1!-qPhboQ`<< z55AlSs_}R0HXu>4!JbNuFPO1bgQhhn(Q`%nxYc4*Y_KdV!O7as>DII0yYuN_?HB!E z{4jL{^gI0VleEj&T~V=aPrPS9oXg8HjgBTRfp3}Y7!tgbW0Gr7iU#@MlhKVt9o|G& zR9sA4RPgVqgi64Ioq;vKqCIm7F7k;@8NmN=(hoxV2;Pu2L4{=)4&YD~; z-^xDFN^EAnZ0%TPT(UmtV9#w;Y-`UNm|V+V%LtsUZNFvc4`~E0*0H;Fls`)sZW=^y z6&K~TE{-!x`P>8e<$AfeD{Altr_b+Z88s{_o}TmHUNeds4L#JE(NpHiRsE3<7PdS| zm9Oy;GGUAnan!MCHG08WpGGtVtaJ&cgSr#hIIk6&|0Tym^c^^B3dUY;f-D=-9QBZi32x=j1Z!NMOw5yK^_Ict%DyUtD=e96vJJLk#M5 z@w!|IHh+^Dd2^@VJ2hBPnZ%XTgGuphGMifcDj215cXM-&I9+MwMfxd<^0L;4mF$j8 ziTtTbm1;I^E_2@m_hImv~*jJxzH4PEL8KXB8!6zc1nDN zvaEkHeyv6VNcgB~>bPhAQrx zLCH_u`$5G;S)dZeOwh7SRSZ|46u~BFnYI#2fNE@;i%&2b$qu$#;oPg+C2|4A_FvTUBGduCO&{gn28y9cOY-H z*QBv%9cG~e+MzKTp(OG_%QGb_AK00jLv=g#pera>KxGlV&=}cZ!!u5+PVEi&tJeOi z6kS%Ff^ndmC>)~gO4{TwmRtlO-I^zf$nig^UBO@ZmBHLz*ZaN5M&nKn$?9Ix}=omTbI zM!qWgF?5@n+iD!8^`<{lm*$_9g3T*<<7+iG{)Ry9n%1QQW*Ps{1$nIu6OFvVS0PjF zDmAOra&+_h*R{;U)HAcM0+X44{|Fe}qTAsb>WWH9TQR8Prz=nE+GDu$R`3^cIeGcK zDT%tsTWz1u^Lr+wkCQw}4++==XFRWmI!(Qf!8$>2vMVvI0y{aDK0=AmIIp{G@HJMq z9Ti39Hn@0EucH|PKRuaYyDKkJa9q{pv6}UBR$h2w!I34JB|_-6_p%&_iD9P#E^9^nCl=bPQPv9Hzy6PnSkME!U%!8@g=eK#*8Ay*EomTGlpi@_m zxkCCtm-Zd?D+f1}s2fjqsm46*%N!bh7%=q%c~U;jIrs{#e7po8<>$fkpLP>!{dzjb z{G2#<+IoiX6&x#{-*r0pt<&d9&u1yT`jHH~>4BH_Yw-hv-o42dyCWRjZrOa;Q6;z@~YbODFTVvoCfs-<~B*p>HeMMSr-qOWivKQYfx5`I!1n4#719? z8ZeO)ucqFjYj9~dm~$0c4-%zJq0*zKbCdSz69WReJ=Yq7=6KFG*xT7g*VX)9iYNN6{%@2GB>mjsbaNo{K07Y3sf_{1KXi2 z)e`6m0}B%{67kT*Ja0iGaceY0HI&xyoSOsPfX;?T49U8*RhJ>0#E(!Ru}VUe-d9TB z52ay;U@(-`e;a+Etd}xgHK6Ri3Y|h3eic03WGKG@?QNdL8C}|N7>5vm(qL0C8M?48 zbW=&Ca(kj3v;kTTRiQnBlE?-do-rr5g3Gvslh}n#*oc(~RadF9%J&Ix#z70`cnpN@ z6`?wSYs?$wLl@Y!f!4I)c*-2%9<*6{8E0__y7$9QXrol?T5Xo9wq+DvT-Rznt4-7V zVYb4-JECdgahHjP3W@I^t(e%~aCFPm!p)y%OfA&zmOX;={`?Q>%<$*y9@>=Ng?0E8OECfC@c~A_ zjRXY$`HO$qJ@uQ;=fdsuY5v7MWAar_+wUd)nV2@=(z-v@(d&ubsO&G&r?OEwwRN8@ zW`t_H=jq$ft)*rIgatzu{6mC1#U)&X^6Vl)9QhTR_F|mr8K&5>DC&ItE?Ua0Gi1z$&PWvJNVu0*c{fC>(Pk zCsg=$8b|RRwm`Xg?GrV@pG2FktBOJoD6!TCHPx%#B;0g^ibO;s3hhu7d65-Q2{Tn# zM5TwEHWF7u8-+@*E7nqw3@>7#>#MYR_zy9506U=iwxw8t#jt$5nE++YYC*xM4&yG= zVO+vRoWOBx!+Ly%Pca#)rl^Li#L^k;!Dc8gKNl*N7zH0x)2-N3N zw|HKK&#@2-pop1krp}2xnZ;khz0#kY@UH*e_~xlc+_j7dEmoWG1q!K&{(Onw`ocN2 zH#sXm;~e&39X`cUXmA{c1nBHK(I0)07b;mChY`@7@$Yh`)B8F`hnv=B;8NeqWHiC= zywEG5t3TeyIJi+2ChptcX4TFstJc2-Yq1OqFbz}iV%dsnVP8dIWP!?5UMy9d#^aGl zL0@!28|XE+I(%rpoZ2TTV@4y{A2V#c;qu=dR+>L~n|F9gW3a!@@TRH5hc7YA_+kE? zfl{f>N9?dG;B2q*e|5gb^X?v*gNrzityqEgF%F?>*C8CYL}u)yvq*uizNmrfP_1Ak3ZH67N*ae-uZs z5gVW@I+U;a7*jA1+U)6zW@rlC{^AvA)2Aq|5=p1<6TZe)Y(c1^(9(uZdp@8LR4HK| z0=pmEu??X9#@GOQ+Qpe%G5Kxw>$f-s%&Z{gV2l7nfEyhzu1BT!RV*PC;2wFDgR!NXP;8S$_}+ zpJN5)VJ>uurf%b18w!+iP(_qhIy;~ufmF;!vbG2{YZ(A-35M4r)iKP diff --git a/report.lyx b/report.lyx index 169a0d4..f490db7 100644 --- a/report.lyx +++ b/report.lyx @@ -7488,13 +7488,21 @@ 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 in figure + 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 @@ -7798,6 +7806,12 @@ end{centering} \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 @@ -7817,11 +7831,32 @@ Future improvements \end_layout \begin_layout Standard -The specification of the GGS prototype is huge and like many other software - projects relying on outside technologies, in time it would require a lot - of maintenance. - Therefore there is a lot of areas in which the GGS could be improved such - as performance, compatibility, ease of setup and usage. +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 @@ -7830,6 +7865,17 @@ Performance \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 @@ -7857,10 +7903,30 @@ Database Currently Mnesia is used for game data storage. During stress tests, Mnesia has turned out to be the bottleneck due to data losses when too many games are played on the GGS simultaneously. - This could be prevented by replacing Mnesia with another database management - system or use Mnesia in combination with the ETS module of erlang. - ETS provides fast access to the RAM and thus Mnesia could be used less - frequently. + +\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 an 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 @@ -7880,49 +7946,6 @@ textbf{ETS}}{Erlang Term Storage} \end_layout \begin_layout Subsection -Compatibility -\end_layout - -\begin_layout Standard -GGS relies on modern technologies. - This includes the virtual machines(VM) that the GGS uses for communication - between Erlang and the GDLs. - These specific VMs are crucial for game developers to be able to write - games in other languages than Erlang. - Therefore it would be best for the GGS to have as many of these VMs implemented - as possible. - The VMs considered so far have been unstable or incomplete and it is possible - to search for more VMs, testing them and integrate them into the GGS prototype. -\end_layout - -\begin_layout Subsection -Setup -\end_layout - -\begin_layout Standard -The GGS prototype installation procedure requires different configuration - and building steps and thus it is not in an acceptable release state. - An executable installation file for each supported platform would be optimal. -\end_layout - -\begin_layout Subsection* -5.3.4 Usage -\end_layout - -\begin_layout Subsubsection -Programming languages -\end_layout - -\begin_layout Standard -The GGS does not support many programming languages. - For a programming language to be compatible with the GGS, not only does - it require a VM for that specific language, but the VM must have the ability - to communicate to Erlang. - More research is needed to find VMs with this built in functionality. - -\end_layout - -\begin_layout Subsubsection Documentation \end_layout @@ -7956,7 +7979,7 @@ addcontentsline{toc}{section}{Glossary} \backslash - +printnomenclature \end_layout \end_inset