#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 \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 double \use_hyperref false \papersize default \use_geometry true \use_amsmath 1 \use_esint 1 \cite_engine natbib_authoryear \use_bibtopic false \paperorientation portrait \paperwidth 11in \paperheight 8.5in \leftmargin 1.25in \topmargin 1in \rightmargin 1in \bottommargin 1.7in \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \papercolumns 1 \papersides 1 \paperpagestyle default \tracking_changes false \output_changes false \author "" \author "" \end_header \begin_body \begin_layout Title Generic Game Server \end_layout \begin_layout Author Jonatan Pålsson \begin_inset Newline newline \end_inset Niklas Landin \begin_inset Newline newline \end_inset Richard Pannek \begin_inset Newline newline \end_inset Matias Petterson \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}{5} \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 addcontentsline{toc}{chapter}{List of Tables} \end_layout \begin_layout Plain Layout \backslash renewcommand{ \backslash cftlottitlefont}{ \backslash hfill \backslash Large} \backslash renewcommand{ \backslash cftafterlottitle}{ \backslash hfill} \backslash renewcommand{ \backslash cfttabpresnum}{Table~} \backslash setlength \backslash cfttabnumwidth{60pt} \end_layout \end_inset \end_layout \begin_layout Standard \begin_inset FloatList table \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 addcontentsline{toc}{chapter}{List of Figures} \end_layout \begin_layout Plain Layout \backslash renewcommand{ \backslash cftloftitlefont}{ \backslash hfill \backslash Large} \backslash renewcommand{ \backslash cftafterloftitle}{ \backslash hfill} \backslash renewcommand{ \backslash cftfigpresnum}{Figure~} \backslash setlength \backslash cftfignumwidth{60pt} \end_layout \end_inset \end_layout \begin_layout Standard \begin_inset FloatList figure \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 Section Background \end_layout \begin_layout Section Purpose \end_layout \begin_layout Section Challenges \end_layout \begin_layout Standard Challenges lies mainly in providing a reliable, high-performing server and at the same time make it easy to use for game developers. \end_layout \begin_layout Subsection Basis \end_layout \begin_layout Section Delimitations \end_layout \begin_layout Subsection Types of games \end_layout \begin_layout Standard In theory no limitations, but in reality it will be limitations. Many factors are involved here. Implementation of protocol, storage possibilities, server capacity, language support. In real time games a low latency is very important not a high bandwidth because the games already send very little data, ~ 80 bytes. Lag of below 250 ms is good, lag up to 500 ms payable and beyond that the lag is noticeable. \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 Subsection 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 Subsection 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 Subsubsection 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 Subsubsection 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. \end_layout \begin_layout Subsubsection 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. \end_layout \begin_layout Subsection Encryption \end_layout \begin_layout Subsubsection Performance penalties \end_layout \begin_layout Subsection Availability \end_layout \begin_layout Standard One important factor of a server is the availability, a server that you can not connect to is a bad server. Erlang has several features to increase the availability, for example hot code replacement. It is also critical to have a good design, we want to separate each part of the server and thus avoiding that the whole server will crash. \end_layout \begin_layout Standard \begin_inset Note Note status open \begin_layout Plain Layout Players are unsatisfied with the service of WoW Telecoms have the same problem of having to migrate users from one node to another, this is called handover \end_layout \end_inset \end_layout \begin_layout Subsection Scalability \end_layout \begin_layout Standard 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 \begin_layout Subsubsection UUID \end_layout \begin_layout Subsection 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 Chapter Overview \end_layout \begin_layout Subsection 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 Subsubsection 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 times, we restart the nearest supervisor of this child. This ensures separation of the subsystems so that a crash is as isolated as possible. \end_layout \begin_layout Standard \begin_inset Graphics filename supervisors.png scale 40 \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 Subsubsection Hot code replacement \end_layout \begin_layout Subsection Implementation \end_layout \begin_layout Subsubsection User interface \end_layout \begin_layout Chapter Problems \end_layout \begin_layout Subsection 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 Subsubsection 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 PIDs 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 UUIDs can be generated before a collision should occur. 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 \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. \end_layout \begin_layout Standard \begin_inset Graphics filename system_structure.png scale 40 \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 Chapter References \end_layout \begin_layout Chapter Appendix \end_layout \begin_layout Standard Text goes here.. \end_layout \begin_layout Bibliography \begin_inset CommandInset bibitem LatexCommand bibitem key "key-1" \end_inset Savor, T.; Seviora, R.E.; , "Hierarchical supervisors for automatic detection of software failures," PROCEEDINGS The Eighth International Symposium On Software Reliability Engineering , vol., no., pp.48-59, 2-5 Nov1997 doi: 10.1109/IS SRE.1997.630847 URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=630847&i snumber=13710 \end_layout \begin_layout Bibliography \begin_inset CommandInset bibitem LatexCommand bibitem key "key-6" \end_inset Vinoski, S.; , "Reliability with Erlang," Internet Computing, IEEE , vol.11, no.6, pp.79-81, Nov.-Dec. 2007 doi: 10.1109/MIC.2007.132 URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&ar number=4376232&isnumber=4376216 \end_layout \begin_layout Bibliography \begin_inset CommandInset bibitem LatexCommand bibitem key "key-5" \end_inset CESARINI, F., & THOMPSON, S. (2009). Erlang programming. Beijing, O'Reilly. pp.139 \end_layout \begin_layout Bibliography \begin_inset CommandInset bibitem LatexCommand bibitem key "key-4" \end_inset "Erlang/OTP Product Information: Technical Description of Erlang." Home of Erlang/OTP. Web. 01 Mar. 2011. . \end_layout \begin_layout Bibliography \begin_inset CommandInset bibitem LatexCommand bibitem key "key-3" \end_inset Joe Armstrong – Armstrong, J. [2011]. If Erlang is the answer, then what is the question?. [1]. IT University. Computer Science and Engineering, 15/2/2011 \end_layout \begin_layout Bibliography \begin_inset CommandInset bibitem LatexCommand bibitem key "key-2" \end_inset Gul Abdulnabi Agha (1985). ACTORS: A MODEL OF CONCURRENT COMPUTATION IN DISTRIBUTED SYSTEMS. Ph.D thesis, Artificial Intelligence Laboratory, MIT. \end_layout \end_body \end_document