From 9a1961e1d9dc89fe98765edecb6f39600cba3abc Mon Sep 17 00:00:00 2001 From: Niklas Landin Date: Thu, 12 May 2011 20:48:22 +0200 Subject: [PATCH 01/11] Revisited 3.3.1, 3.3.2 and 3.3.3 --- report.lyx | 67 +++++++++++++++++++++++++++--------------------------- 1 file changed, 33 insertions(+), 34 deletions(-) diff --git a/report.lyx b/report.lyx index 8238541..44e43a6 100644 --- a/report.lyx +++ b/report.lyx @@ -4115,8 +4115,8 @@ Short introduction to the Erlang syntax \end_layout \begin_layout Standard -In order to understand examples in this thesis, a small subset of Erlang - must be understood. +To understand the examples in this thesis, a small subset of Erlang must + be understood. In this section, the very syntactic basics of Erlang are given. \end_layout @@ -4333,7 +4333,7 @@ name "sec:The-modular-structure" \end_layout \begin_layout Standard -The separation of concerns, and principle of single responsibility +The separation of concerns and principle of single responsibility \begin_inset Foot status open @@ -4352,8 +4352,8 @@ target "http://www.objectmentor.com/resources/articles/srp.pdf" are widely respected as good practices in the world of software engineering and development. - By dividing the GGS up into modules each part of the GGS can be modified - without damaging the rest of the system. + By dividing the GGS into modules each part of the GGS can be modified without + damaging the rest of the system. \end_layout \begin_layout Standard @@ -4407,7 +4407,7 @@ The dispatcher module \begin_layout Standard \begin_inset Note Note -status open +status collapsed \begin_layout Plain Layout The discussion of the modules is divided into the following parts: @@ -4448,7 +4448,7 @@ Is this the proper way to day the dispatcher greets connecting players? system when working with sockets. Operating system limits concerning the number of open files, or number of open sockets are handled here. - The operating system limits can impose problems on the GGS, this is discussed + The operating system limits can impose problems in the GGS, this is discussed more in detail in chapter \begin_inset CommandInset ref LatexCommand vref @@ -4460,7 +4460,7 @@ reference "cha:Problems-of-implementation" \end_layout \begin_layout Standard -Should the dispatcher module fail to function, no new connections to the +Should the dispatcher module fails to function, no new connections to the GGS can be made. In the event of a crash in the dispatcher module, a supervisor process immediately restarts the dispatcher. @@ -4486,8 +4486,8 @@ Well.. \end_layout \begin_layout Standard -Returning to scenario of the chess club, the dispatcher module is the doorman - of the club. +Returning to the scenario of the chess club, the dispatcher module is the + doorman of the club. When a player enters the chess club, the player is greeted by the doorman, letting the player in to the club. The actual letting in to the club is in the GGS represented by the creation @@ -4499,8 +4499,8 @@ reference "sub:The-player-module" \end_inset . - The newly created player process is handed, and granted rights to, the - socket of the newly connected player. + The newly created player process is handed and granted rights to, the socket + of the newly connected player. \end_layout \begin_layout Subsection @@ -4519,8 +4519,8 @@ The player module is responsible for representing a player in the system. Each connected player has its own player process. The player process has access to the connection of the player it represents, and can communicate with this player. - In order to communicate with a player, the data to and from the player - object must pass through a protocol parser module, discussed in + To communicate with a player, the data to and from the player object must + pass through a protocol parser module, discussed in \begin_inset CommandInset ref LatexCommand vref reference "sub:The-protocol-parser" @@ -4529,7 +4529,7 @@ reference "sub:The-protocol-parser" . Raw communication, without passing the data through a protocol parser is - in theory possible, but is not useful. + in theory possible but it is not useful. \end_layout \begin_layout Standard @@ -4572,9 +4572,9 @@ The player process resumes operation, immediately starting a new protocol \begin_layout Standard The window of time between the crash of the player process and the starting of a new player process is, as with the dispatcher, very short. - Since the connection changes owners for a short period of time, but is - never dropped, the implications of a crash are only noticed, at worst, - as choppy gameplay for the client. + Since the connection changes owners for a short period of time but is never + dropped, the implications of a crash is only noticed, at worst, as choppy + gameplay for the client. Note however that this crash recovery scheme is not implemented in the GGS prototype. @@ -4591,8 +4591,8 @@ Can we do this..? Seems a bit sneaky. \end_layout \begin_layout Standard -Moving back to the real world example, the player process represent an actual - person in the chess club. +Moving back to the real world example, the player process represents an + actual person in the chess club. When a person sits down at a table in the chess club, the person does so by requesting a seat from some coordinating person, and is then seated by the same coordinator. @@ -4615,16 +4615,15 @@ name "sub:The-protocol-parser" \begin_layout Standard The protocol parser is an easily interchangeable module in the GGS, handling the client-to-server, and server-to-client protocol parsing. - In the GGS prototype, there is only one protocol supported, namely the - + In the GGS prototype, there is only one protocol supported, the \emph on GGS Protocol \emph default . The role of the protocol parser is to translate the meaning of packets - sent using the protocol in use to internal messages of the GGS system. - The GGS protocol, discussed below is used as a sample protocol in order - to explain how protocol parsers can be built for the GGS. + sent, using the protocol in use, to internal messages of the GGS system. + The GGS protocol, discussed below is used as a sample protocol to explain + how protocol parsers can be built for the GGS. \end_layout \begin_layout Subsubsection @@ -4642,16 +4641,16 @@ name "sub:The-structure-of" The GGS protocol is modeled after the HTTP protocol. The main reason for this is the familiarity many developers already have with HTTP due to its presence in internet software. - Each GGS protocol packet contains a headers section. - The headers section is followed by a data section. - In the headers section, parameters concerning the packet is placed. + Each GGS protocol packet contains a header section. + The header section is followed by a data section. + In the header section, parameters concerning the packet is placed. In the data section, the actual data payload of the packet is placed. \end_layout \begin_layout Standard -There is no requirement of any specific order of the parameters in the headers +There is no requirement of any specific order of the parameters in the header section, however the data section must always follow directly after the - headers section. + header section. \end_layout \begin_layout Standard @@ -4665,10 +4664,10 @@ In the example below, line 1 contains a Game-Command parameter. Line 2 specifies a game token. This is a UUID which is generated for each client upon authentication with the GGS. - The GGS uses this token in case a client is disconnected and the new connection + The GGS uses this token if a client is disconnected and the new connection created when the client reconnects must be re-paired with the player object inside the GGS. - The UUID is also used as a unique ID within GDL VMs. + The UUID is also used as an unique ID within GDL VMs. \end_layout \begin_layout Standard @@ -4683,14 +4682,14 @@ Line 3 specifies the content type of the payload of this particular packet. \begin_layout Standard Line 4 specifies the content length of the payload following immediately - after the headers section. + after the header section. \end_layout \begin_layout Standard The parser of the GGS protocol implemented in the GGS prototype is designed as a finite state machine using the gen_fsm behavior. When a full message has been parsed by the parser, the message is converted - into the internal structure of the GGS messages, and sent in to the system + into the internal structure of the GGS messages and sent in to the system from the protocol parser using message passing. \end_layout From 6b51f285802466f5099fe33e1e154cbb693aef69 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Thu, 12 May 2011 21:09:06 +0200 Subject: [PATCH 02/11] Revised 3.3.2 --- report.lyx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/report.lyx b/report.lyx index 09bc56c..6a28d8b 100644 --- a/report.lyx +++ b/report.lyx @@ -4576,8 +4576,8 @@ The window of time between the crash of the player process and the starting Since the connection changes owners for a short period of time, but is never dropped, the implications of a crash are only noticed, at worst, as choppy gameplay for the client. - Note however that this crash recovery scheme is not implemented in the - GGS prototype. + Note however that this crash recovery scheme is only partly implemented + in the GGS prototype. \begin_inset Note Note status open @@ -4592,8 +4592,8 @@ Can we do this..? Seems a bit sneaky. \end_layout \begin_layout Standard -Moving back to the real world example, the player process represent an actual - person in the chess club. +Moving back to the real world example, the player process represents an + actual person in the chess club. When a person sits down at a table in the chess club, the person does so by requesting a seat from some coordinating person, and is then seated by the same coordinator. From 29036514c14817e1bc69ac16b52d6828157b0008 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Thu, 12 May 2011 21:32:57 +0200 Subject: [PATCH 03/11] Revised 3.3.6 --- report.lyx | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/report.lyx b/report.lyx index 23a0c06..463f994 100644 --- a/report.lyx +++ b/report.lyx @@ -2974,8 +2974,8 @@ reference "alg:A-simple-generator" \begin_layout Standard The obvious solution to this problem is to ensure mutual exclusion by using some sort of a lock, which may work well in many concurrent systems. - In a distributed system such as the GGS however, this lock, along with the - state, would have to be distributed. + In a distributed system such as the GGS however, this lock, along with + the state, would have to be distributed. If the lock is not distributed, no guaranties can be made that two nodes in the distributed system do not generate the same identifier. \end_layout @@ -4353,8 +4353,8 @@ target "http://www.objectmentor.com/resources/articles/srp.pdf" are widely respected as good practices in the world of software engineering and development. - By dividing the GGS into modules each part of the GGS can be modified - without damaging, or requiring changes in the rest of the system. + By dividing the GGS into modules each part of the GGS can be modified without + damaging, or requiring changes in the rest of the system. Due to the hot code updates featured in Erlang, it is theoretically possible to update parts of the GGS while the system is running, this has however not been implemented in the prototype. @@ -4999,12 +4999,13 @@ This module holds the game logic of a game and is responsible for the VM \begin_layout Standard The game VM contains the state of the VM and a table token associated with a running game. - GameVM is started by the table module. - The table module hands over a token to the game VM during initialization. + The game VM is started by the table module. + The table module hands over a token used for identification to the game + VM during initialization. During initialization a new VM instance and various objects associated - to the VM instance will be created. - Callbacks to Erlang are registered into the VM and then the source code - of a game is loaded into the VM and the game is ready for startup. + to the VM instance are created. + Callbacks to Erlang are registered into the VM and the source code of a + game is loaded into the VM, finally the game is ready for startup. The only means for a game to communicate with the VM is through usage of a provided interface. @@ -5015,12 +5016,12 @@ The VM itself makes it possible for the game developer to program in the programming language covered by the VM. In future releases, more game VMs will be added to support more programming languages. - Because the game VM keeps track of the correct table, the game developer + Since the game VM keeps track of the correct table, the game developer does not need to take this into consideration when programming a game. - If a method within the game sends data to a player, it will be delivered + If a method within the game sends data to a player, the data is delivered to the player in the correct running game. The same game token is used to store the game state in the database. - Therefore, no game states will be mixed up either. + Therefore, no game states can be mixed up. \end_layout \begin_layout Standard From 711466ead402c760095bf85f8b62e462969caad8 Mon Sep 17 00:00:00 2001 From: Niklas Landin Date: Thu, 12 May 2011 21:36:29 +0200 Subject: [PATCH 04/11] Small changes in 3.3.4 --- report.lyx | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/report.lyx b/report.lyx index 881c7ed..55b4eae 100644 --- a/report.lyx +++ b/report.lyx @@ -4349,8 +4349,8 @@ target "http://www.objectmentor.com/resources/articles/srp.pdf" are widely respected as good practices in the world of software engineering and development. - By dividing the GGS into modules each part of the GGS can be modified - without damaging, or requiring changes in the rest of the system. + By dividing the GGS into modules each part of the GGS can be modified without + damaging, or requiring changes in the rest of the system. Due to the hot code updates featured in Erlang, it is theoretically possible to update parts of the GGS while the system is running, this has however not been implemented in the prototype. @@ -4897,38 +4897,38 @@ name "sub:The-coordinator-module" The coordinator module is responsible for keeping track of all players, their seats and tables. Players register with the coordinator process when first connecting to - the server, and the coordinator places each player by their respective + the server and, the coordinator places each player by their respective table. \end_layout \begin_layout Standard -The coordinator keeps mappings between each player and table, therefore - it is used to perform lookups on tables and players to find out which are - connected. +The coordinator keeps relations between each player and table, therefore + it is used to perform lookups on tables and players to find out which ones + that are connected. The connectivity of players and tables is important when sending messages to all participants in a game. - A lookup in the coordinator process is performed prior to notifying all - players in a game to ensure the message reaches all players. + A lookup in the coordinator process is performed before notifying all players + in a game to ensure the message reaches all players. The lookup can be performed either using internal identification codes or using the UUID associated with each client and table. \end_layout \begin_layout Standard -The coordinator process contains important state, therefore a backup process - is kept at all times. +The coordinator process contains an important state, therefore a backup + process is kept at all times. All good data processed by the coordinator is stored for safekeeping in the backup process as well. - Data which is potentially harmful is not stored in the backup process. + Data which are potentially harmful is not stored in the backup process. \end_layout \begin_layout Standard -Upon a crash, the coordinator process recovers the prior good state from - the backup process and continues where it left off. +On a crash, the coordinator process recovers the prior good state from the + backup process and continues where it left off. A supervisor process monitors the coordinator process and restarts the process when it malfunctions. There is a window of time between the crash of the coordinator and the restarting of the coordinator, during this time, players cannot be seated - by new tables, and cannot disconnect from the server. + by new tables and cannot disconnect from the server. This window of time is very small, and the unavailability of the coordinator process should not be noticed by more than a short time lag for the clients. \end_layout From b434af48cadb8dfc3e1f1ed3bf3472ecf15110ae Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Thu, 12 May 2011 21:38:34 +0200 Subject: [PATCH 05/11] Revised 3.3.7 --- report.lyx | 42 +++++++++++++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 11 deletions(-) diff --git a/report.lyx b/report.lyx index 463f994..3aa427f 100644 --- a/report.lyx +++ b/report.lyx @@ -5054,7 +5054,7 @@ name "sub:The-database-module" \end_layout \begin_layout Standard -Game data from all games on the GGS are stored in the database backend of +Game data from all games on the GGS is stored in the database backend of the database module. \end_layout @@ -5063,9 +5063,9 @@ In the GGS prototype the database module is using a database management system called Mnesia. Mnesia ships with the standard Erlang distribution and is a key-value store type database. - Mnesia is designed to handle the stress of telecoms systems, and has some - features specifically tailored for telecoms which are not commonly found - in other databases. + Mnesia is designed to handle the stress of telecoms systems, therefore + it has some features specifically tailored for telecoms which are not commonly + found in other databases. Key features of the Mnesia database are: \end_layout @@ -5095,12 +5095,12 @@ key "667766" The features of Mnesia originally intended for telecoms prove very useful for the purposes of the GGS as well. The fault tolerance and speed of Mnesia are very valuable tools, the fast - key/value lookups permit many lookups per second to the database. + key/value lookups permit many lookups per second from the database. \end_layout \begin_layout Standard -Game data will not be lost when a game is stopped or has gone down for unknown - reasons. +Game data will not be lost when a game is stopped or has gone down for any + reason. This makes it possible to continue a game just before the failure without having to start the game from the beginning. @@ -5129,12 +5129,32 @@ The GGS stores the game state in the distributed Mnesia database, from which \begin_layout Standard Each game is uniquely identified by a table token and the data of each game is stored within two different namespaces. - The namespaces are named World and Localstorage. - The World is used contain all game data related to the game state. + The namespaces are named +\noun on +world +\noun default + and +\noun on +Localstorage +\noun default +. + The +\noun on +World +\noun default + is used contain all game data related to the game state. This sort of game data may change during the runtime of the game. - The Localstorage should contain data independent of the game state. + The +\noun on +Localstorage +\noun default + contains data independent of the game state. Game resources, constants and global variables are all examples of data - that could reside within the Localstorage. + that reside within the +\noun on +Localstorage +\noun default +. To store a value within the database, not only is the table token and the name of the namespace required, but a unique key so that the value can be successfully retrieved or modified later. From cb886616d9d4864a7501fdc4ea52894d707b4587 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Thu, 12 May 2011 21:43:01 +0200 Subject: [PATCH 06/11] Revised 3.4 --- report.lyx | 57 +++++++++++++++++++++++++++++------------------------- 1 file changed, 31 insertions(+), 26 deletions(-) diff --git a/report.lyx b/report.lyx index 3aa427f..9cf0a85 100644 --- a/report.lyx +++ b/report.lyx @@ -5193,7 +5193,7 @@ name "sec:Communication-with-the-GDL-VM" \begin_layout Standard A game launched on the GGS is run within a virtual machine. - For each programming language supported, there is a virtual machine that + For each programming language supported, there is a virtual machine which interprets the game. Furthermore an interface for communication between the GGS, the game and the players playing the game is present. @@ -5217,40 +5217,45 @@ localStorage by a call for the world object. Interaction with the players is done by using the \emph on -GGS.sendCommand(player_id, command, args) -\emph default - and -\emph on -GGS. -\emph default -sendCommandToAll(command, args). - The localstorage is a convenient way to store global data and other variables - separated from the game state. - Unique ids called gametokens are generated for hosted games so that they - are not mixed up. -\end_layout -\begin_layout Standard -A game launched on the GGS is run within a virtual machine. - For each programming language supported, there is a virtual machine that - interprets the game. - Furthermore an interface for communication between the GGS, the game and - the players playing the game must be present. -\end_layout - -\begin_layout Standard -\begin_inset Note Note +\begin_inset ERT status open \begin_layout Plain Layout - Unique id:s called gametokens are generated for hosted games so that they - are not mixed up. - -- good text, integrate more. + +{ +\backslash +tt GGS.sendCommand(player_id, command, args) +\emph on +} \end_layout \end_inset +\emph default + and +\emph on + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\backslash +tt GGS.sendCommandToAll(command, args)} +\end_layout + +\end_inset + + +\emph default +. + The localStorage is a convenient way to store global data and other variables + separated from the game state. + Unique ids called game tokens are generated for hosted games so that they + are not mixed up. \begin_inset ERT status open From b4273bb570670fc49af4acd76735dd32743e4705 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Thu, 12 May 2011 21:44:24 +0200 Subject: [PATCH 07/11] Revised 3.4 --- report.lyx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/report.lyx b/report.lyx index c9f6013..a7bfc95 100644 --- a/report.lyx +++ b/report.lyx @@ -5225,9 +5225,9 @@ status open { \backslash -tt GGS.sendCommand(player_id, command, args) -\emph on -} +tt GGS.sendCommand(player +\backslash +_id, command, args)} \end_layout \end_inset From ed0c12aeabb76ff9dec90237ef8ecfbe06a4cdca Mon Sep 17 00:00:00 2001 From: Niklas Landin Date: Thu, 12 May 2011 21:45:05 +0200 Subject: [PATCH 08/11] Language changes to 3.3.5 --- report.lyx | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/report.lyx b/report.lyx index 928adc2..54306f0 100644 --- a/report.lyx +++ b/report.lyx @@ -4964,23 +4964,23 @@ The information about which players are seated by each table is used when Consider a game of chess, each player notifies the table of its actions, the table then notifies the rest of the participants of these actions after having had the actions processed by the game VM, where an action could - be moving a playing piece. + be moving a piece in the game. \end_layout \begin_layout Standard Each table is associated with a game VM. - The actions sent to a table are processed by the game VM, this is where + The actions sent to a table is processed by the game VM, this is where the game logic is implemented. \end_layout \begin_layout Standard After a crash in a table process, the entire table must be rebuilt and the players must be re-associated with the table. - Data concerning players is kept in the coordinator process, and is restored + Data concerning players is kept in the coordinator process and is restored from there. Data kept in the actual game is not automatically corrupted by the crash - in a table, however the table must be re-associated with the game VM is - was associated with prior to the crash of the table. + in a table, however the table must be re-associated with the game VM it + was associated with before the crash of the table. The table process maps well into the setting of the real-world chess club scenario previously discussed. A table works in the same way in a real world setting as in the GGS setting. From 89ec38819f77258b6ecbdecfd0e594e56eb1c48b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Thu, 12 May 2011 21:47:31 +0200 Subject: [PATCH 09/11] Revised 3.4.1 --- report.lyx | 64 ++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 41 insertions(+), 23 deletions(-) diff --git a/report.lyx b/report.lyx index a7bfc95..a882b28 100644 --- a/report.lyx +++ b/report.lyx @@ -5206,12 +5206,20 @@ Callbacks written in Erlang are registered to the VM for the interface to the game state and send messages to the clients. The interface provides access to three objects called \emph on -world, players +\noun on +world +\noun default +, +\noun on +players \emph default +\noun default and \emph on +\noun on localStorage \emph default +\noun default . The game state is safely stored in a database and retrieved for manipulation by a call for the world object. @@ -5286,7 +5294,14 @@ name "sub:Exposing-Erlang-functionality" \end_layout \begin_layout Standard -This section contains a concrete example of how the localstorage and world +This section contains a concrete example of how the +\noun on +localStorage +\noun default + and +\noun on +world +\noun default objects are exposed to a GDL VM. The example comes from the GGS prototype, which uses JavaScript powered by Google V8 as its GDL VM. @@ -5358,16 +5373,33 @@ tt GGS.localStorage } \end_inset - from within the GDL, access to the localstorage is provided, thus the localstor -age must be connected to the GGS object, this can be seen in line 5. + from within the GDL, access to the +\noun on +localStorage +\noun default + is provided, thus the +\noun on +localStorage +\noun default + must be connected to the GGS object, this can be seen in line 5. \end_layout \begin_layout Standard -Both the GGS and localstorage objects are dummy objects, which provide no - functionality, these two objects are simply placed in the GDL for the purpose - clearing up the code. - In order to perform an action using the GGS and localstorage objects, the - +Both the +\noun on +GGS +\noun default + and +\noun on +localStorage +\noun default + objects are dummy objects, which provide no functionality, these two objects + are simply placed in the GDL for the purpose clearing up the code. + In order to perform an action using the GGS and +\noun on +localStorage +\noun default + objects, the \begin_inset ERT status open @@ -5443,20 +5475,6 @@ tt setTimeout} per default. \end_layout -\begin_layout Standard -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Prior to this section, the Erlang syntax has to be briefly explained. - I think the 'usage of erlang' section is a good place to do this in. -\end_layout - -\end_inset - - -\end_layout - \begin_layout Standard \begin_inset Float algorithm wide false From e099c26937f003a355a21c898f4c1852587a1d74 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Thu, 12 May 2011 21:56:38 +0200 Subject: [PATCH 10/11] Revised 3.5 --- report.lyx | 47 +++++++++++++++++++++++++---------------------- 1 file changed, 25 insertions(+), 22 deletions(-) diff --git a/report.lyx b/report.lyx index 725f32b..e3b442c 100644 --- a/report.lyx +++ b/report.lyx @@ -5846,24 +5846,12 @@ Techniques for ensuring reliability \begin_layout Standard One of the main goals of the project is to achieve high reliability. - The term -\begin_inset Quotes eld -\end_inset + The term 'reliable system' is defined by the IEEE as +\end_layout -reliable system -\begin_inset Quotes erd -\end_inset - - is defined by the IEEE as a system with -\begin_inset Quotes eld -\end_inset - -the ability of a system or component to perform its required functions under - stated conditions for a specified period of time -\begin_inset Quotes erd -\end_inset - - +\begin_layout Quotation +A system with the ability of a system or component to perform its required + functions under stated conditions for a specified period of time \begin_inset CommandInset citation LatexCommand citet key "ieee_90" @@ -5871,10 +5859,13 @@ key "ieee_90" \end_inset . - There are some tools for creating reliable applications built in to Erlang. +\end_layout + +\begin_layout Standard +There are some tools for creating reliable applications built in to Erlang: \begin_inset ERT -status open +status collapsed \begin_layout Plain Layout @@ -5902,14 +5893,22 @@ E"} \end_layout \begin_layout Itemize -Links between processes. + +\series bold +Links between processes +\series default +. 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. + +\series bold +Transparent distribution over a network of processors +\series default +. 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 @@ -5918,7 +5917,11 @@ Transparent distribution over a network of processors. \end_layout \begin_layout Itemize -Hot code replacements. + +\series bold +Hot code replacements +\series default +. 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 From fdcc7e2fc5e8e8219b5b00a7f301008347b74b1b Mon Sep 17 00:00:00 2001 From: Niklas Landin Date: Thu, 12 May 2011 22:07:47 +0200 Subject: [PATCH 11/11] Revisited 3.3.6 and 3.3.7 --- report.lyx | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/report.lyx b/report.lyx index f5f90d9..0541e61 100644 --- a/report.lyx +++ b/report.lyx @@ -5019,7 +5019,7 @@ The VM itself makes it possible for the game developer to program in the Since the game VM keeps track of the correct table, the game developer does not need to take this into consideration when programming a game. If a method within the game sends data to a player, the data is delivered - to the player in the correct running game. + to the player in the correct game. The same game token is used to store the game state in the database. Therefore, no game states can be mixed up. \end_layout @@ -5038,7 +5038,7 @@ reference "sec:Communication-with-the-GDL-VM" \end_layout \begin_layout Standard -The code which is run in the VM is uploaded to the GGS prior to each game. +The code which is run in the VM is uploaded to the GGS before each game. Allowing the clients to upload code allows clients to run any game. \end_layout @@ -5062,7 +5062,7 @@ Game data from all games on the GGS is stored in the database backend of In the GGS prototype the database module is using a database management system called Mnesia. Mnesia ships with the standard Erlang distribution and is a key-value store - type database. + type of database. Mnesia is designed to handle the stress of telecoms systems, therefore it has some features specifically tailored for telecoms which are not commonly found in other databases. @@ -5093,9 +5093,9 @@ key "667766" \begin_layout Standard The features of Mnesia originally intended for telecoms prove very useful - for the purposes of the GGS as well. - The fault tolerance and speed of Mnesia are very valuable tools, the fast - key/value lookups permit many lookups per second from the database. + for the GGS as well. + The fault tolerance and speed of Mnesia are valuable tools, the fast key/value + lookups permit many lookups per second from the database. \end_layout \begin_layout Standard @@ -5156,9 +5156,9 @@ Localstorage \noun default . To store a value within the database, not only is the table token and the - name of the namespace required, but a unique key so that the value can + name of the namespace required, but an unique key so that the value can be successfully retrieved or modified later. - The key is fully decidable by the game developer. + The key is decidable by the game developer. \end_layout @@ -5167,8 +5167,8 @@ The interface of the database module is an implementation of the upcoming W3C Web Storage specification. Web Storage is intended for use in web browsers, providing a persistent storage on the local machine for web applications. - The storage can be used to communicate in between browser windows (which - is difficult when using cookies), and to store larger chunks of data + The storage can be used to communicate among browser windows (which is + difficult when using cookies), and to store larger chunks of data \begin_inset CommandInset citation LatexCommand citet key "webstorage:website"