#LyX 1.6.7 created this file. For more info see http://www.lyx.org/ \lyxformat 345 \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} \end_preamble \use_default_options true \language english \inputencoding auto \font_roman lmodern \font_sans default \font_typewriter default \font_default_family rmdefault \font_sc false \font_osf false \font_sf_scale 100 \font_tt_scale 100 \graphics default \paperfontsize default \spacing onehalf \use_hyperref false \papersize a4paper \use_geometry false \use_amsmath 1 \use_esint 1 \cite_engine natbib_authoryear \use_bibtopic false \paperorientation portrait \paperwidth 11in \paperheight 8.5in \leftmargin 1.25in \topmargin 0in \rightmargin 1in \bottommargin 1.7in \secnumdepth 2 \tocdepth 2 \paragraph_separation indent \defskip medskip \quotes_language english \papercolumns 1 \papersides 1 \paperpagestyle empty \tracking_changes false \output_changes false \author "" \author "" \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 Generic Game Server \end_layout \begin_layout Author Niklas Landin \begin_inset Newline newline \end_inset Richard Pannek \begin_inset Newline newline \end_inset Matias Petterson \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 The introduction aims to give the reader a good base to stand on when taking on the rest of this thesis. A background and motivation of why this topic is interesting is given, and some basic terminoligy is defined and explained. To understand many of the core issued in the GGS, some prior knowledge of other topics is needed, the introduction aims to give this prior knowledge. \end_layout \begin_layout Standard We draw some parallels to existing solutions which solve similar problems in different sectors. The main challenges of the project are outlined, with the solutions thereof following later on in the paper. Some boundaries are placed on the project, since it is not possible to cover everything at once. By placing these boundaries, the purpose of the GGS is further refined. \end_layout \begin_layout Standard \begin_inset Note Note status open \begin_layout Plain Layout Also cover the final topics; method (development process, etc). As of this eriting, the contents of method are unknown. \end_layout \end_inset \end_layout \begin_layout Section Background \end_layout \begin_layout Section Purpose \end_layout \begin_layout Standard The purpose of the GGS project is to create a \emph on scalable \emph default and \emph on fault tolerant \emph default server, while still allowing the server to be as \emph on generic \emph default as possible. These three italicised terms need some explanation. \end_layout \begin_layout Standard Scalability 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 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 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 others. \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 of the purposes 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 Section Challenges \end_layout \begin_layout Standard The word \emph on generic \emph default in GGS implies that the system is able to run a very broad range of different code, for instance code written in different programming languages, in addition to a broad range of different game types. In order to support this, a virtual machine (VM) for each \emph on game development language \emph default (hereafter GDL for brevity) is used. \end_layout \begin_layout Standard No hard limit has been set on which languages can be used for game development on 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 GGS system \end_layout \begin_layout Itemize How easy it is to send messages to the virtual machine of the GDL from GGS \end_layout \begin_layout Itemize How easy it is to send messages from the GDL VM to 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 GGS to make use of the helpers and tools that GGS provides. Thus an internal API has to be designed for use in interacting with 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 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 GGS, this is also investigated. \end_layout \begin_layout Section Delimitations \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. \end_layout \begin_layout Standard The UDP protocol will not be implemented, only TCP, the main reason behind this is a strict timetable. This decision 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. \end_layout \begin_layout Standard In real time games all players are playing together at the same time. Latency is a huge problem in real time games, a typical round trip time for such games is one of 50 to 150 ms and everything above 200 ms 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 her turn. Latency is not a problem since the gameplay does not require fast interactions between 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 as it is not possible to implement and test something that complex within the projects timetable. \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. It is important to note that these limitations only apply for the prototype of the project, and that further developments to GGS could be to implement these features. \end_layout \begin_layout Section Method \end_layout \begin_layout Subsection Development process \end_layout \begin_layout Standard May be Extreme Programming(XP), need to check this out further. Maybe adapt so we can say that we use a standardized software development method. \end_layout \begin_layout Subsubsection Demand specification \end_layout \begin_layout Subsection Design \end_layout \begin_layout Subsection Testing and evaluation \end_layout \begin_layout Standard Can we use quickcheck? \end_layout \begin_layout Chapter Theory \end_layout \begin_layout Standard In this chapter, the theory behind the techniques used in the GGS are discussed here. Performance issues and the measuring of performance is discussed. Benchmarking techniques are discusses. The options when choosing network protocols are given, along with pros and cons for each of our alternatives. Finally, a bird's eye-view of scalability, fault tolerance and availability is presented. \end_layout \begin_layout Section Performance \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 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 \end_inset \end_layout \begin_layout Section Choice of network protocol \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 are 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 in order to work. \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 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 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 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 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 Fault Tolerant \end_layout \begin_layout Subsubsection Performance penalties \end_layout \begin_layout Section Availability \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 a useless server. Other then within telecomunication, their uptime is of about 99,99%, the game developer community hasn't approched 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 between nodes to replicate them but for the GGS a different approche 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. \end_layout \begin_layout Section Scalability \end_layout \begin_layout Standard Each instance of 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 GGS scales is to distribute these tables on different servers. In many games it is not necessary for a player to move between tables during games. This is for example not a common occurrence in chess, where it would be represented as a player standing up from her current table and sitting down at a new table, all within the same game session. With this in mind, the main focus of GGS is not to move players between tables, but to keep a player in a table, and to start new tables instead. When a server has reached a certain amount of players the performance will start to decrease. To avoid this GGS will start new tables on another server, using this technique the players will be close to evenly distributed between 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 utilize 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 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. GGS should be able to scale well in both categories. \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 \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 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 exclution. \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. \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 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 Site A \emph default and \emph on Site B \emph default later re-establish communications, 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. \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/NetworkSPlit.eps scale 40 \end_inset \end_layout \begin_layout Plain Layout \begin_inset ERT status open \begin_layout Plain Layout \backslash end{centering} \end_layout \end_inset \end_layout \begin_layout Plain Layout \begin_inset Caption \begin_layout Plain Layout \begin_inset CommandInset label LatexCommand label name "fig:network-split" \end_inset An example of a network split \end_layout \end_inset \end_layout \end_inset \end_layout \begin_layout Section Security \end_layout \begin_layout Standard 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 of this not modify the persistent data of other games. \end_layout \begin_layout Subsection Encryption \end_layout \begin_layout Chapter Practice \begin_inset Note Note status open \begin_layout Plain Layout Perhaps call this \begin_inset Quotes eld \end_inset realization \begin_inset Quotes erd \end_inset or \begin_inset Quotes eld \end_inset implementation \begin_inset Quotes erd \end_inset \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. A highly reliable application is one crashes very, very rarely \begin_inset Note Note status open \begin_layout Plain Layout CITATION NEEDED \end_layout \end_inset . There are some tools for creating reliable applications built in to Erlang. \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 \end_layout \begin_layout Standard By linking processes together and notifying parents when children exit, we can create supervisors. A supervisor is a common approach in ensuring that an application functions in the way it was intended. 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 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 open \begin_layout Plain Layout Exactly how many \begin_inset Quotes eld \end_inset too many \begin_inset Quotes erd \end_inset is depends on a setting in the supervisor, ten crashes per second is a reasonable upper limit. \end_layout \end_inset times, 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 Distribution \end_layout \begin_layout Subsection Hot code replacement \end_layout \begin_layout Section Implementation \end_layout \begin_layout Subsubsection User interface \end_layout \begin_layout Chapter Problems \end_layout \begin_layout Section erlang_js \end_layout \begin_layout Standard To be able to run JavaScript on our server we needed to embed a JavaScript engine within the server. After a thorough investigation erlang_js became our choice. erlang_js provides direct communication with a JavaScript VM (Virtual Machine). This was exactly what we wanted, but we also needed the possibility to communicate from erlang_js to Erlang. This functionality was not yet implemented in erlang_js, due to lack of time. \end_layout \begin_layout Standard There were two possible solutions to the problem. We could rewrite some part of erlang_js, or we could switch erlang_js for some other JavaScript engine. Searching for other engines we found erlv8 and beam.js which provided the functionality that we wanted. As we tested beam.js it occurred random crashes of the whole Erlang environment. These crashes were related to the use of erlv8 in beam.js and we decided that the use of erlv8 was not an alternative due to the stability issues. \end_layout \begin_layout Standard To get the functionality needed we decided to implement this in erlang_js. \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 Section Design choices \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 Dispatcher in GGS. \end_layout \begin_layout Standard He then gets a name badge, and thus becomes a Player process in the system. He is also guided in to the lobby by the Coordinator, 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 Coordinator 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 Coordinator, 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 Coordinator, who revokes his name badge and the Dispatcher will let the player out. \end_layout \begin_layout Standard With the information kept in the tables and the Coordinator 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 Coordinator 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. \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/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 The layout of GGS \end_layout \end_inset \end_layout \end_inset \end_layout \begin_layout Section Understanding OTP \end_layout \begin_layout Section Usability \end_layout \begin_layout Chapter Results and discussion \end_layout \begin_layout Section Software development methodology \end_layout \begin_layout Section Statistics \end_layout \begin_layout Chapter Conclusion \end_layout \begin_layout Standard \begin_inset CommandInset bibtex LatexCommand bibtex bibfiles "bibliography" options "plainnat" \end_inset \end_layout \end_body \end_document