Merge branch 'master' of github.com:jeena/GGS-report

Conflicts:
	report.lyx

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
@@ -2973,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 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
@@ -3028,8 +3029,8 @@ 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
@@ -3043,16 +3044,8 @@ 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
@@ -3147,20 +3140,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
@@ -4374,7 +4353,7 @@ 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
+ 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
@@ -4441,6 +4420,31 @@ textbf{Object Oriented Programming}}{A programming paradigm focusing on
 The dispatcher module
 \end_layout
 
+\begin_layout Standard
+\begin_inset Note Note
+status collapsed
+
+\begin_layout Plain Layout
+The discussion of the modules is divided into the following parts:
+\end_layout
+
+\begin_layout Itemize
+What does the module do?
+\end_layout
+
+\begin_layout Itemize
+What happens when the module fails?
+\end_layout
+
+\begin_layout Itemize
+How does the module correspond to the real-world scenario of the chess club?
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
 \begin_layout Standard
 The dispatcher module is the first module to have contact with a player.
  When a player connects to the GGS, the player is first greeted by the dispatche
@@ -4449,7 +4453,7 @@ r module, which sets up an accepting socket for each player.
  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
@@ -4487,8 +4491,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
@@ -4500,8 +4504,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
@@ -4530,7 +4534,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, however it is not useful.
 \end_layout
 
 \begin_layout Standard