diff --git a/#report.lyx# b/#report.lyx# deleted file mode 100644 index c062968..0000000 --- a/#report.lyx# +++ /dev/null @@ -1,1226 +0,0 @@ -#LyX 1.6.9 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} -\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 2in -\topmargin 2in -\rightmargin 2in -\bottommargin 2in -\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}{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 -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 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 Subsection -Generic -\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 should be able to run network games of different type, a very rough - separation would be in -\emph on -real time games -\emph default - and turn based games. -\end_layout - -\begin_layout Subsubsection -Application server targeted on games -\end_layout - -\begin_layout Standard -The server is something like a application server designed to help to run - games. - A application server is different from a file or print server, which only - serves resources to the clients, it serves processing ability and time. -\end_layout - -\begin_layout Standard -The most common type of application servers are webservers where you run - a web-application within the server. - The application-server handles all the network-/inter process-stuff and - offers hooks and helpers for your application to use the resources, some - examples for such web-application-servers are the Glassfish-Server which - allows you to run applications written in Java, or the Google App Engine - where you can run applications written in Python or some language which - runs in the Java Virtual Machine. -\end_layout - -\begin_layout Standard -But you can find specialized application servers within the industry where - one central server serves processing power for different independent robotic-cl -ients. - Or in Academia where one mainframe is used as a cerver for different clients - to run different applications which are doing havy calculations and return - the result to the clients. -\end_layout - -\begin_layout Standard -You could too think of a database server as a application server. - You send it different -\begin_inset Quotes eld -\end_inset - -scripts -\begin_inset Quotes erd -\end_inset - -, e.g. - bis SQL queries or JavaScript, the server runs them and returns the evaluated - data to the clients. - It is perhaps not the best example but just so you see how different applicatio -n servers can be. -\end_layout - -\begin_layout Standard -One of the purposes of this thesis is to investigate how we can make a game - server as generic, that is so that you are not limited to just one game, - as possible. - Some important helpers which are needed in network games and therefore - should be offered by a generic game server are for example the abstraction - of the network layer, a data store, and others, which will be discussed - more in detail later in the thesis. -\end_layout - -\begin_layout Subsubsection -Different types of games -\end_layout - -\begin_layout Standard -In real time games all players are playing at the same time simultanously - together. - Latency is a big problem here, a typical round trip time for such games - is one of 50 to 150 ms and everything above 200 ms is reported to be intolerabl -e -\begin_inset CommandInset citation -LatexCommand citet -key "Farber:2002:NGT:566500.566508" - -\end_inset - -. - Examples for such games are most of the first person shoters with multiplayer - ability like Counter Strike, Call Of Duty and -\emph on -MMORPG's -\emph default -(Massively multiplayer online role-playing game) like World Of Warcraft, - Starcraft, Ultima Online, etc. -\end_layout - -\begin_layout Standard -In turn based games each player has to wait for her turn. - Latency is not a problem because even if a round trip takes a bigger amount - of time, the gameplay does not require fast interactions between the players - and it will not be noticed. - Examples are board and card games like chess, poker or Carcassonne played - online, as well as multiplayer games like -\begin_inset Quotes erd -\end_inset - -Hattrick - The online football manager game -\begin_inset Quotes erd -\end_inset - - or the -\begin_inset Quotes eld -\end_inset - -Wheel of Fortune -\begin_inset Quotes erd -\end_inset - -. -\end_layout - -\begin_layout Standard -Both game types have varying difficulties and needs when it comes to implementin -g them, a Generic Game Server should address all of them and help the developer - to acomplish his goal. -\end_layout - -\begin_layout Section -Challenges -\end_layout - -\begin_layout Standard -The main challenge is to provide a reliable, high-performing and scalable - server without making it too difficult for game developers do write their - game. - It should for example be possible for them to use the language they are - familiar with. - In our GGS prototype we added a module for a virtual machine which is highly - exchangable. - For now we have a JavaScript VM (Spidermonkey) and a ActionScript VM. -\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 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. - -\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. -\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 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 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 Subsubsection -UUID -\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 -Overview -\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 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 open - -\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 -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 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. -\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 diff --git a/bibliography.bib b/bibliography.bib index 939ca8c..a44463c 100644 --- a/bibliography.bib +++ b/bibliography.bib @@ -143,4 +143,12 @@ acmid = {566508}, publisher = {ACM}, address = {New York, NY, USA}, -} +} + +@MISC{tuxedo:website, + AUTHOR = "Oraclee Software", + TITLE = "TUXEDO transaction Processing Products", + MONTH = "March", + YEAR = {2011}, + URL = "http://www.oracle.com/tuxedo" +} diff --git a/report.lyx b/report.lyx index 50d0f22..ed1c020 100644 --- a/report.lyx +++ b/report.lyx @@ -1,4 +1,4 @@ -#LyX 1.6.9 created this file. For more info see http://www.lyx.org/ +#LyX 1.6.7 created this file. For more info see http://www.lyx.org/ \lyxformat 345 \begin_document \begin_header @@ -831,7 +831,33 @@ Encryption \end_layout \begin_layout Chapter -Overview +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