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

Conflicts:
	report.lyx

bibliography.bib

@@ -377,3 +377,11 @@ booktitle={Object/Component/Service-Oriented Real-Time Distributed Computing Wor
  month={march}, 
  doi={10.1109/ISORCW.2011.42}, 
 }
+@MISC{NIF:website,
+      AUTHOR = "Ericsson AB",
+      TITLE = "Erlang -- erl\_nif",
+      MONTH = "May",
+      YEAR = {2011},
+      URL = "http://www.erlang.org/doc/man/erl_nif.html"
+}
+

report.lyx

@@ -2617,8 +2617,9 @@ Each instance of the GGS contains several so called tables.
  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.
- Therefore, the main focus of the GGS is not to move players among tables,
+ Therefore the main focus of the GGS is not to move players among tables,
- but to keep a player in a table, and to start new tables 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
@@ -2641,8 +2642,8 @@ reference "sec:Background"
  there are two different types of scalability, structural scalability and
  load scalability.
  To make the GGS scalable both types of scalability have to be considered.
- Structural scalability means in this case that it should be possible to
+ Structural scalability means - in this case - that it should be possible
- add more servers to an existing cluster of servers.
+ to add more servers to an existing cluster of servers.
  By adding more servers the limits of with how many users a system can be
  burdened with is increased.
  Load scalability, in contrast to structural scalability, is not about how
@@ -2661,7 +2662,7 @@ The need for load balancing varies among different kind of systems.
  simple implementation of a load balancer, while in large systems it is
  useful to have extensive and well working load balancing implementations.
  The need also depends on what kind of server structure the system is working
- on, a static structure where the number of servers is predefined or a dynamic
+ on; a static structure where the number of servers is predefined or a dynamic
  structure where this number varies.
 \begin_inset ERT
 status open
@@ -2702,8 +2703,8 @@ Fill up the capacity of one server completely, and then move over to the
 
 \begin_layout Itemize
 Evenly distribute all clients to all servers from the beginning.
- When the load becomes too high on all of them a new problem arises: how
+ When the load becomes too high on all of them a new problem arises: How
- do we distribute load on these new servers?
+ do we distribute the load on these new servers?
 \end_layout
 
 \begin_layout Standard
@@ -2720,11 +2721,11 @@ Load balancing is a key component to achieve scalability in network systems.
 
 \begin_layout Standard
 Load balancing can often be implemented using dedicated software, this means
- that in many applications load balancing may not be implemented because
+ that in many applications load balancing may not be implemented internally
- there already exist functional or even better external solutions.
+ because better external solutions exist already.
  This depends on what specific needs the system has.
  A minor goal of this thesis is to analyze whether the GGS can use existing
- load balancing tools or if it is necessary how to implement load balancing
+ load balancing tools or if it is necessary, how to implement load balancing
  in the project.
 \end_layout
 
@@ -2948,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 simple systems a counter can be imagined, where each request for a new
- a new ID increments the previous identifier and returns the new identifier
+ ID increments the previous identifier and returns the new identifier based
- based on the old one; see algorithm 
+ on the old one; see algorithm 
 \begin_inset CommandInset ref
 LatexCommand ref
 reference "alg:A-simple-generator"
@@ -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,
+ In a distributed system like the GGS however, this lock, along with the
- would have to be distributed.
+ 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,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,
+ sources of information, such as: time, MAC addresses of network cards;
- and operating system data, such as percentage of memory in use, mouse cursor
+ 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.
 \end_layout
 
 \begin_layout Standard
-When using system wide unique identifiers, such as the ones generated by
+When using system wide unique identifiers it is extremly unlikely to have
- algorithm 
+ identifier collisions when recovering from network splits between GGS clusters.
-\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.
  Consider figure 
 \begin_inset CommandInset ref
 LatexCommand ref
@@ -3081,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
@@ -3147,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
@@ -3543,6 +3518,11 @@ name "cha:Implementation-of-a"
 
 \end_layout
 
+\begin_layout Standard
+As mentioned earlier in the thesis, a prototype of the GGS has been developed
+ in order to test hypotheses and provide concrete examples.
+\end_layout
+
 \begin_layout Standard
 This chapter contains the realization of much of the principles and techniques
  described in chapter 
@@ -3582,15 +3562,6 @@ Overview of the prototype
 
 \begin_layout Standard
 The prototype of the GGS was developed using the Erlang language.
- The functional and concurrent style of Erlang facilitates development of
- software based on a real-world model 
-\begin_inset CommandInset citation
-LatexCommand citep
-key "armstrong2011"
-
-\end_inset
-
-.
  In Erlang, most things are processes.
  The software running the Erlang code is known as the Erlang machine, or
  a Erlang node.
@@ -3607,6 +3578,8 @@ Light Weight Processes; LWP
 , 
 \emph default
 much like the threads in an operating system.
+ There are however differences between operating system threads and the
+ LWPs of erlang.
  Threads in a Linux system, for example, are treated much like operating
  system processes in different systems.
  Due to the size of data structures related to each process, swapping one
@@ -3652,13 +3625,13 @@ textbf{Context switch}}{The act of switching from one context, commonly
 \end_layout
 
 \begin_layout Standard
-The cost of swapping operating system processes become a problem when many
+The cost of swapping operating system processes becomes a problem when many
  processes are involved.
  If the GGS system had been developed using regular operating system processes,
  it would have had to be designed in a way to minimize the number of processes.
  Using Erlang, which is capable of running very many processes, several
- times more than an operating system can, the relation between the real
+ times more than an operating system, the relation between the real world
- world and the GGS (described in 
+ and the GGS (described in 
 \begin_inset CommandInset ref
 LatexCommand vref
 reference "sec:Design-of-the"
@@ -3678,7 +3651,7 @@ Erlang allows the GGS to create several processes for each player connecting,
 \end_layout
 
 \begin_layout Standard
-Besides creating (or 
+In addition to creating (or 
 \emph on
 spawning
 \emph default
@@ -3761,7 +3734,7 @@ The layout of the GGS.
  network, for example the Internet.
  The barell figure marked 'backup' is a process being fed backup data from
  the coordinator.
- The barell marked 'State' contains the state of a table, and this is fed
+ The barrel marked 'State' contains the state of a table, and this is fed
  into the box marked 'Mnesia' which is database.
  Finally the figure shaped as a shield marked 'GameVM' contains the actual
  game process.
@@ -3789,8 +3762,8 @@ reference "fig:The-layout-of"
  The circles marked with 'C' topmost in the picture represents game clients.
  These circles represent processes running on gamers computers, and not
  on the GGS machine.
- If a game of chess is to be played on the server, the clients on the gamers
+ If a game of chess is to be played on the server, the clients on the machines
- machine will be chess game clients.
+ of the gamers will be chess game clients.
  Clients connect through a network, pictured as a cloud, to the dispatcher
  process in the GGS.
  The dispatcher process and all other modules are discussed in
@@ -3817,8 +3790,15 @@ name "sec:The-usage-of-erlang"
 \end_layout
 
 \begin_layout Standard
-Erlang was designed by Ericsson, beginning in 1986, for creating concurrent
+As mentioned earlier, the GGS prototype is implemented in Erlang.
- applications and improving telecom software.
+ The current section and the subsequent section function as a short introduction
+ to Erlang, focusing on the parts of the language neccessary to understand
+ the material regarding Erlang presented in this thesis.
+\end_layout
+
+\begin_layout Standard
+Erlang was designed by Ericsson, beginning in 1986, for the purpose of creating
+ concurrent applications and improving telecom software.
  Features essential for the telecom industry to achieve high availability
  in telecom switches were added to the language.
 \begin_inset ERT
@@ -3858,8 +3838,11 @@ key "Armstrong:2010:ERL:1810891.1810910"
 \begin_layout Standard
 In using message passing in favor of the methods commonly used at the time,
  the issues commonly associated with shared memory and locking were avoided.
- In Erlang, everything is a process, and everything operates in its own
+\end_layout
- memory space.
+
+\begin_layout Standard
+In Erlang, everything is a process, and everything operates in its own memory
+ space.
  Memory cannot be shared among processes, which prohibits a process from
  corrupting the memory of a different process.
 \end_layout
@@ -3877,9 +3860,9 @@ Light Weight Processes.
 \emph default
 The Erlang processes are inexpensive to create.
  Processes exist within an Erlang machine, or Erlang node.
- The Erlang machine has its own scheduler and does not rely on the operating
+ The Erlang machine has its own scheduler and does not rely on the scheduler
- system's scheduler, this is one main reason of Erlang's capability of running
+ of the operating system, this is a main reason of Erlang's capability of
- many concurrent processes 
+ running many concurrent processes 
 \begin_inset CommandInset citation
 LatexCommand citet
 key "Armstrong03"
@@ -3902,9 +3885,15 @@ The strong isolation of Erlang processes make them ideal for multi-core
 \end_layout
 
 \begin_layout Standard
-The distributed nature of Erlang is something the GGS makes use of, when
+The distributed nature of Erlang is something the GGS can make use of, when
- scaling across several computers to achieve higher performance.
+ scaling across several computers in order to achieve higher performance.
  The distribution is also important in creating redundancy.
+ The GGS prototype does not make use of the distributed nature of Erlang,
+ however the GGS prototype is constructed in such a way that making use
+ of the distributed nature should now pose a big ptoblem.
+\end_layout
+
+\begin_layout Standard
 Erlang promotes a non-defensive programming style in which processes are
  allowed to crash and be restarted in favor of having the processes recover
  from errors.
@@ -3939,7 +3928,15 @@ s (Native implemented functions)
  Through ports communication can take place in a similar way communication
  is performed over sockets.
  NIFs are called like any other functions without any difference to the
- caller but they are implemented in C.
+ caller but are implemented in C, this implementation makes NIFs a very
+ efficient way to interface with the outside world 
+\begin_inset CommandInset citation
+LatexCommand citet
+key "NIF:website"
+
+\end_inset
+
+.
 \end_layout
 
 \begin_layout Standard
@@ -4067,8 +4064,8 @@ gen_server
  increasing the usefulness of the server process.
  There are many gen_servers in the GGS, it is the most widely used behavior
  in the project.
- Besides introducing a state to the server, the gen_server behavior also
+ In addition to introducing a state to the server, the gen_server behavior
- imposes patterns for synchronous and asynchronous communication between
+ also imposes patterns for synchronous and asynchronous communication between
  other gen_servers and other OTP behaviors.
 \end_layout
 
@@ -4084,8 +4081,8 @@ gen_fsm
 \end_layout
 
 \begin_layout Standard
-Besides supplying behaviors, the OTP also has a style for packaging and
+In addition to supplying behaviors, the OTP also has a style for packaging
- running Erlang applications.
+ and running Erlang applications.
  By packaging the GGS as an 
 \emph on
 application 
@@ -4102,7 +4099,7 @@ status open
 \backslash
 nomenclature{
 \backslash
-textbf{Application}}{A way of packaging Erlang software in an uniform way}
+textbf{Application}}{A way of packaging Erlang software in a uniform way}
 \end_layout
 
 \end_inset
@@ -4352,8 +4349,21 @@ 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
+ By dividing the GGS into modules each part of the GGS can be modified
- damaging the rest of the system.
+ 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.
+ The modular composition of the GGS prototype should make a transition to
+ a folly hot code swappable system relatively easy.
+ Hot code replacements are discussed in more detail in section 
+\begin_inset CommandInset ref
+LatexCommand ref
+reference "sub:Hot-code-replacement"
+
+\end_inset
+
+.
 \end_layout
 
 \begin_layout Standard
@@ -4371,7 +4381,8 @@ reference "cha:Theory"
 \end_layout
 
 \begin_layout Standard
-In the text below the word module refers to the actual code of the discussed
+In the text below the different modules of the GGS are presented.
+ In the text the word module refers to the actual code of the discussed
  feature, while the word process is used when referring to a running instance
  of the code.
 \begin_inset ERT
@@ -4432,18 +4443,8 @@ How does the module correspond to the real-world scenario of the chess club?
 
 \begin_layout Standard
 The dispatcher module is the first module to have contact with a player.
- When a player connects to the GGS, it is first greeted by the dispatcher
+ When a player connects to the GGS, the player is first greeted by the dispatche
- module, which sets up an accepting socket for each player.
+r module, which sets up an accepting socket for each player.
- 
-\begin_inset Note Note
-status collapsed
-
-\begin_layout Plain Layout
-Is this the proper way to day the dispatcher greets connecting players?
-\end_layout
-
-\end_inset
-
  The dispatcher is the module which handles the interfacing to the operating
  system when working with sockets.
  Operating system limits concerning the number of open files, or number
@@ -4452,7 +4453,7 @@ Is this the proper way to day the dispatcher greets connecting players?
  more in detail in chapter 
 \begin_inset CommandInset ref
 LatexCommand vref
-reference "cha:Problems-of-implementation"
+reference "sec:Operating-system-limitations"
 
 \end_inset
 
@@ -4469,9 +4470,9 @@ Should the dispatcher module fails to function, no new connections to the
  this window is the GGS unable to process new connection requests.
  Due to the modular structure of the GGS, the rest of the system is not
  harmed by the dispatcher process not functioning.
- The process does not contain a state, therefore a simple restart of the
+ The dispatcher process does not contain a state, therefore a simple restart
- process is sufficient in restoring the GGS to a pristine state after a
+ of the process is sufficient in restoring the GGS to a pristine state after
- dispatcher crash
+ a dispatcher crash
 \begin_inset Note Note
 status open
 
@@ -4491,7 +4492,7 @@ Returning to the scenario of the chess club, the dispatcher module is the
  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
- of a player process discussed in 
+ of a player process discussed in section 
 \begin_inset CommandInset ref
 LatexCommand vref
 reference "sub:The-player-module"
@@ -6173,6 +6174,13 @@ To the left normal execution is pictured; the server state is backed up.
 
 \begin_layout Subsection
 Hot code replacement
+\begin_inset CommandInset label
+LatexCommand label
+name "sub:Hot-code-replacement"
+
+\end_inset
+
+
 \end_layout
 
 \begin_layout Standard
@@ -7259,6 +7267,71 @@ The use of Thrift, Google protocol buffers - which is a different approach
  the writing of this thesis.
 \end_layout
 
+\begin_layout Section
+Operating system limitations
+\begin_inset CommandInset label
+LatexCommand label
+name "sec:Operating-system-limitations"
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+The operating systems on the computers which were used to run the bots when
+ testing the GGS prototype had some limitations.
+ The operating systems used were Linux and Mac OS X, since these systems
+ are quite similar on a lower level they exhibited the same limitations..
+\end_layout
+
+\begin_layout Standard
+The most notable limitation was a limit set on the number of simultaneously
+ open files.
+ Due to the implementation of sockets in UNIX-like systems such as Mac OS
+ X and Linux, a limit on the number of open files is a limit on the number
+ of open sockets.
+ In order to simulate many connections to the GGS, many sockets needed to
+ be opened.
+ Each socket had a bot connected on one end and the GGS on the other end.
+ On each test machine several thousand sockets needed to be open while testing
+ the GGS, therefore the limit on open files had to be removed.
+\end_layout
+
+\begin_layout Standard
+On the Linux machines the limit of open files is configured in 
+\begin_inset ERT
+status open
+
+\begin_layout Plain Layout
+
+{
+\backslash
+tt /etc/security/security.conf}
+\end_layout
+
+\end_inset
+
+.
+\end_layout
+
+\begin_layout Standard
+On the Mac OS X machine the limit of open files is configured in 
+\begin_inset ERT
+status open
+
+\begin_layout Plain Layout
+
+{
+\backslash
+tt /etc/launchd.conf }
+\end_layout
+
+\end_inset
+
+.
+\end_layout
+
 \begin_layout Chapter
 Results and discussion 
 \begin_inset CommandInset label