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

Conflicts:
	report.lyx

bibliography.bib

@@ -355,3 +355,25 @@ This paper details the motivations and design choices we made in Thrift, as well
  keywords = {agreement problem, asynchronous system, consensus problem, failure correction, failure detection, fault models, fault tolerance, liveness, message passing, possibility detection, predicate detection, redundancy, safety},
 } 
 
+@article{VM:Jin2010,
+ title = "Optimizing the live migration of virtual machine by CPU scheduling",
+ journal = "Journal of Network and Computer Applications",
+ volume = "In Press, Corrected Proof",
+ year = "2010",
+ issn = "1084-8045",
+ doi = "DOI: 10.1016/j.jnca.2010.06.013",
+ url = "http://www.sciencedirect.com/science/article/B6WKB-50GWNDF-1/2/8e238feaccf38844aba14ece109b28a6",
+ author = "Hai Jin and Wei Gao and Song Wu and Xuanhua Shi and Xiaoxin Wu and Fan Zhou",
+ keywords = "Live virtual machine migration",
+ keywords = "Pre-copy algorithm",
+ keywords = "CPU scheduling",
+ keywords = "Dirty rate"
+}
+
+@INPROCEEDINGS{VM:Polze, 
+ author={Polze, Andreas and Troger, Peter and Salfner, Felix}, 
+booktitle={Object/Component/Service-Oriented Real-Time Distributed Computing Workshops (ISORCW), 2011 14th IEEE International Symposium on}, title={Timely  Virtual Machine Migration for Pro-active Fault Tolerance}, 
+ year={2011}, 
+ month={march}, 
+ doi={10.1109/ISORCW.2011.42}, 
+}

report.lyx

@@ -2239,12 +2239,22 @@ There are two main types of protocols with help of which computer communication
  network layer protocols and HTTP which is the most prominent application
  layer protocol.
  The transport layer protocols are commonly used to transport application
- layer protocols such as HTTP.
+ layer protocols such as HTTP, FTP and IRC.
  TCP and UDP cannot be used on their own without an application layer protocol
  on top of them.
  Application layer protocols such as HTTP on the other hand need a transport
  layer protocol in order to work.
- 
+\end_layout
+
+\begin_layout Standard
+In order for the GGS to communicate with clients over a network, both an
+ application layer protocol and a network layer protocol must be chosen.
+ This section outlines some candidates for application and network layer
+ protocols for the GGS, along with a motivation as to why the described
+ protocol was or was not chosen.
+\end_layout
+
+\begin_layout Standard
 \begin_inset ERT
 status open
 
@@ -2258,6 +2268,24 @@ textbf{HTTP}}{Hyper Text Transport Protocol, a network protocol commonly
  used to deliver web pages}
 \end_layout
 
+\begin_layout Plain Layout
+
+
+\backslash
+nomenclature{
+\backslash
+textbf{FTP}}{File Transfer Protocol}
+\end_layout
+
+\begin_layout Plain Layout
+
+
+\backslash
+nomenclature{
+\backslash
+textbf{IRC}}{Internet Relay Chat}
+\end_layout
+
 \end_inset
 
 
@@ -2279,6 +2307,14 @@ Many online games use UDP as the carrier for their application layer protocol.
  thus very suitable for media streaming for example.
 \end_layout
 
+\begin_layout Standard
+The need to implement custom error checking, and possibly correction makes
+ UDP a bad candidate for the GGS.
+ If error checking and correction were to be implemented in the GGS project,
+ UDP would be a good candidate, however the time neccessary to implement
+ these features makes this option unfeasable.
+\end_layout
+
 \begin_layout Subsection
 TCP
 \end_layout
@@ -2289,7 +2325,12 @@ For reliable transfers TCP is often used on the Internet.
  missing in UDP.
  This ensures the consistency of data, but also makes the transfer slower
  than if UDP had been used.
- 
+ TCP was chosen for the GGS as the network layer protocol even though TCP
+ can be considerably slower than UDP.
+ The error checking mechanisms in TCP are reason enough to use TCP instead
+ of UDP in the GGS prototype.
+ The implementation of UDP is still possible, it will however not appear
+ in the prototype.
 \end_layout
 
 \begin_layout Subsection
@@ -2350,9 +2391,7 @@ name "sec:Generic"
 
 \begin_layout Standard
 The GGS is a game server.
- It was made with a desire to be suitable for any kind of game.
- Any game with a client-server behavior should be perfectly suited for the
- GGS.
+ It was made with a desire to be suitable for many kinds of games.
  A game should not only be able to vary in terms of genre, graphics, gameplay
  etc, but also in the way the game is implemented for example in different
  programming languages.
@@ -2365,9 +2404,8 @@ The GGS is a game server.
 \end_layout
 
 \begin_layout Standard
-Another aspect is the desire to let a client upload the source code of the
- game it would like to play on the GGS.
- This way every client could connect to the server and install the game
+Clients upload the source code of the game it would like to play on the
+ GGS, this way any client can connect to the server and install the game
  through a API without the need of installation through the server provider
  or maintainer.
 \end_layout
@@ -2506,8 +2544,16 @@ key "armstrong2011"
 \end_layout
 
 \begin_layout Standard
-There are several good papers on how to migrate whole virtual machines among
- nodes to replicate them but for the GGS a different approach has been chosen.
+There are several good papers (e.g.
+ 
+\begin_inset CommandInset citation
+LatexCommand citet
+key "VM:Jin2010,VM:Polze"
+
+\end_inset
+
+) on how to migrate whole virtual machines among nodes to replicate them
+ but for the GGS a different approach has been chosen.
  Instead of duplicating a virtual machine, an attempt to lift the state
  of the VM to a storage external to the VM is made.
  The state is stored in a fast, fault tolerant data store instead of inside
@@ -2564,8 +2610,8 @@ name "sec:Scalability"
 Each instance of the GGS contains several so called tables.
  Each table is an isolated instance of a game, for instance a chess game
  or a poker game.
- The way that the GGS scales is to distribute these tables on different
- servers.
+ A possible way for the GGS to scale up is to distribute these tables on
+ different servers.
  In many games it is not necessary for a player to move among tables during
  games.
  This is for example not a common occurrence in chess, where it would be
@@ -2636,8 +2682,8 @@ textbf{Amazon EC2}}{A cloud computation service}
 
 \begin_layout Standard
 Load balancing and scaling are difficult in different scenarios.
- When running in a separate server park, there is a set number of servers
- available, this means that an even distribution on all servers is preferable.
+ When running in a server park, there is a set number of servers available,
+ this means that an even distribution on all servers is preferable.
  When running the GGS in a cloud, such as Amazon EC2, it is possible to
  add an almost infinite number of servers as execution goes on and the load
  increases.
@@ -3193,14 +3239,22 @@ Erlang is not a very popular language for game development, therefore the
  The main idea is to offer a replaceable module which would introduce an
  interface to different virtual machines which would run the game code.
  This way a game developer can write the game in his favorite language while
- the server part still is written in Erlang and can benefit from all its
- advantages.
+ the server part still is written in Erlang and can benefit from all the
+ advantages of the Erlang language.
+ In this section, a few potential languages are given.
 \end_layout
 
 \begin_layout Subsection
 JavaScript
 \end_layout
 
+\begin_layout Standard
+JavaScript is a prime GDL candidate for the GGS.
+ The language is very flexible, a general knowledge of the language is present
+ in the computer science community, furthermore there are virtual machines
+ readily available for JavaScript.
+\end_layout
+
 \begin_layout Standard
 JavaScript has gained a lot of popularity lately, it is used in large projects
  such as 
@@ -3278,7 +3332,21 @@ https://github.com/languages/
 \end_inset
 
  of all code is written in JavaScript.
- The popularity of JavaScript in the programming community, in combination
+ 
+\end_layout
+
+\begin_layout Standard
+Since the GGS is intended to be connected to several different GDL VMs the
+ choice for the first language implemented for the GGS prototype seems not
+ only to depend on the technical features of the GDL chosen, in this case
+ JavaScript.
+ A different, albeit still important non technical feature of JavaScript
+ is the familiarity with the language of the members of the GGS development
+ team.
+\end_layout
+
+\begin_layout Standard
+The popularity of JavaScript in the programming community, in combination
  with the availability of several different JavaScript virtual machines
  was an important influence in choosing JavaScript as the main control language
  for our GGS prototype.
@@ -3357,7 +3425,7 @@ Lua
 \emph on
 ActionScript
 \emph default
- are suitable as well because there is a virtual machine for each of them
+ are suitable as well since there is a virtual machine for each of them
  which can be 
 \begin_inset Quotes eld
 \end_inset