From 0d4d02376e49099c6fd770ee1b92bc148fab72dc Mon Sep 17 00:00:00 2001 From: Jeena Paradies Date: Thu, 12 May 2011 20:43:02 +0200 Subject: [PATCH 1/4] better language on sitting by a table --- report.lyx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/report.lyx b/report.lyx index c59d0d2..e55d3dd 100644 --- a/report.lyx +++ b/report.lyx @@ -2618,7 +2618,8 @@ Each instance of the GGS contains several so called tables. represented as a player standing up from her current table and sitting down at a new table, all within the same game session. Therefore the main focus of the GGS is not to move players among tables, - but to keep a player by one table, and to start new tables if needed instead. + but to keep a player seated by a table and to start new tables if needed + instead. When a server reaches a certain number of players the performance will start to decrease, or worse, the server may even crash. To avoid this the GGS will start new tables on another server, using this From 9a1961e1d9dc89fe98765edecb6f39600cba3abc Mon Sep 17 00:00:00 2001 From: Niklas Landin Date: Thu, 12 May 2011 20:48:22 +0200 Subject: [PATCH 2/4] 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 277677ea4bf9c2c157a7423c769e0a3e95d4d6ac Mon Sep 17 00:00:00 2001 From: Jeena Paradies Date: Thu, 12 May 2011 20:57:34 +0200 Subject: [PATCH 3/4] clearified UUID --- report.lyx | 48 +++++++++++------------------------------------- 1 file changed, 11 insertions(+), 37 deletions(-) diff --git a/report.lyx b/report.lyx index e55d3dd..a9bdb50 100644 --- a/report.lyx +++ b/report.lyx @@ -2949,9 +2949,9 @@ Inside the GGS everything needs a unique identifier. When players communicate amongst each other or 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 on the old one; see algorithm + A simple systems a counter can be imagined, where each request for a new + ID increments the previous identifier and returns the new identifier based + on the old one; see algorithm \begin_inset CommandInset ref LatexCommand ref reference "alg:A-simple-generator" @@ -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, like the GGS, this lock, along with the state, - would have to be distributed. + In a distributed system like 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 @@ -3029,31 +3029,19 @@ Ds generated until 3400 A.D. \begin_layout Standard The generation of a UUID 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 + 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 IDs. The gathered data is then \emph on hashed \emph default - -\begin_inset space ~ -\end_inset - -using an algorithm such as SHA-1. + 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 extremly unlikely to have identifier collisions - when recovering from network splits between the GGS clusters. +When using system wide unique identifiers it is extremly unlikely to have + identifier collisions when recovering from network splits between GGS clusters. Consider figure \begin_inset CommandInset ref LatexCommand ref @@ -3082,7 +3070,7 @@ reference "alg:A-simple-generator" \end_inset -, even when mutual system-wide exclusion is implemented. +, even when mutual system-wide exclusion was implemented. This is exactly the problem UUIDs solve. \begin_inset ERT status open @@ -3148,20 +3136,6 @@ end{centering} \end_inset -\end_layout - -\begin_layout Plain Layout -\begin_inset Note Note -status open - -\begin_layout Plain Layout -Add clients on each side, and replace the cloud with pole-landlines being - cut by a pair of scissors -\end_layout - -\end_inset - - \end_layout \begin_layout Plain Layout From 9a9858e5d2a12d29cc36a7feb4cd5648e0ce4d9f Mon Sep 17 00:00:00 2001 From: Jeena Paradies Date: Thu, 12 May 2011 21:01:08 +0200 Subject: [PATCH 4/4] language in Security --- report.lyx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/report.lyx b/report.lyx index dfcfd76..f7d000e 100644 --- a/report.lyx +++ b/report.lyx @@ -3170,14 +3170,14 @@ The GGS only supports 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 cannot interfere with each other. - If sandboxing was not in place, one game could potentially modify the contents - of a different game. + If sandboxing would not have been in place, one game could potentially + modify the contents of a different game. A similar approach is taken with the persistent storage provided by the GGS. In the storage each game has its own namespace, much like a table in a relational database. - A game is not allowed to venture outside this namespace, and can because - this not modify the persistent data of other games. + A game is not allowed to venture outside this namespace and can, because + of that, not modify the persistent data of other games. \begin_inset ERT status open