diff --git a/report.lyx b/report.lyx
index 46f268c..e3e7d06 100644
--- a/report.lyx
+++ b/report.lyx
@@ -416,8 +416,8 @@ key "nethack:website"
 .
  The games often took place in a textual world, leaving the task of picturing
  the world up to the player.
- Multi-player games were not as common as they are today, whereas most games
- today are expected to have a multi-player mode, most early games did not.
+ Multiplayer games were not as common as they are today, whereas most games
+ today are expected to have a multiplayer mode, most early games did not.
 \end_layout
 
 \begin_layout Standard
@@ -453,8 +453,8 @@ key "esa:website,thenumbers:website"
 \begin_layout Standard
 Due to the increasing importance of computer gaming, more focus should be
  spent on improving the quality of the gaming service.
- As more and more computer games are gaining multi-player capabilities,
- the demands for multiplayer networking software rises.
+ As more and more computer games are gaining multiplayer capabilities, the
+ demands for multiplayer networking software rises.
  This thesis is about techniques for improving the quality of this networking
  software.
 \end_layout
@@ -738,7 +738,7 @@ the nine nines
 \begin_inset Formula $99.999999999\%$
 \end_inset
 
- of availability, or rougly 
+ of availability, or roughly 
 \begin_inset Formula $15ms$
 \end_inset
 
@@ -757,11 +757,11 @@ Citation needed
  industry would not have been accepted in the telecoms industry.
  This level of instability should not be accepted in the game server industry
  either.
- An unavailabvle phone system could potentially have life threatening consequenc
-es, leaving the public unable to contant emergency services.
+ An unavailable phone system could potentially have life threatening consequence
+s, leaving the public unable to contact emergency services.
  The same can not be said about an unavailable game server.
  The statement that game servers are less important than phone systems is
- not a reason not to draw wisdom from what the telecoms have already learnt.
+ not a reason not to draw wisdom from what the telecoms have already learned.
 \end_layout
 
 \begin_layout Standard
@@ -1271,9 +1271,8 @@ textbf{TCP}}{Transmission Control Protocol, a streaming network protocol}
 
 \begin_layout Standard
 The UDP protocol is not supported for communication between client and server.
- The TCP protocol was chosen in favour of UDP, due to the fact that the
- implementation process using TCP was faster than if UDP would have been
- used.
+ The TCP protocol was chosen in favor of UDP, due to the fact that the implement
+ation process using TCP was faster than if UDP would have been used.
  UDP is generally considered to be faster than TCP for the transfer of game
  (and other) related data, this is discussed in more depth in 
 \begin_inset CommandInset ref
@@ -1333,7 +1332,7 @@ key "Farber:2002:NGT:566500.566508"
 \emph on
 Counter Strike
 \emph default
- or massively multiplayer online role playing games (MMORPG:s), for example
+ or massively multiplayer online role playing games (MMORPGs), for example
  
 \emph on
 World of Warcraft
@@ -1402,8 +1401,8 @@ The first prototype of the GGS consisted of simple modules, however, due
  Once the basic structure of the GGS had been established, the first prototype
  was removed, remaining was the structure of the modules and the internal
  flow of the application.
- This could be seen as an interative workflow, with the first prototype
- being the first iteration.
+ This could be seen as an iterative workflow, with the first prototype being
+ the first iteration.
  The second iteration later became the final result of the GGS.
 \end_layout
 
@@ -1421,7 +1420,7 @@ The layout of the GGS is both layered and modular.
 \begin_layout Standard
 An informal specification and list of requirements of the system was outlined
  early on in the project.
- Usaility goals for developers were set.
+ Usability goals for developers were set.
  During the project several demo applications were constructed, by constructing
  these applications, the usability goals were enforced.
 \end_layout
@@ -2037,7 +2036,7 @@ INDSTATE
 
 \end_inset
 
-alert the coordinator, de-registering the players
+alert the coordinator, unregistering the players
 \end_layout
 
 \begin_layout Plain Layout
@@ -2112,7 +2111,7 @@ In a first person shooter game, the speed of delivery of messages is essential.
  Failure to deliver messages in time results in choppy gameplay for the
  players.
  In strategy games, the reliability of delivery may be more important than
- the speed, since the game is not perceieved as choppy even if the messages
+ the speed, since the game is not perceived as choppy even if the messages
  are delayed.
 \end_layout
 
@@ -2142,7 +2141,7 @@ status open
 Tue apr 26, 9:15.
  Continue from here on.
  Discuss which results we may expect in a fully fledged GGS system.
- What impedes the speeds, what raises the CPU load (and therefore the temperetur
+ What impedes the speeds, what raises the CPU load (and therefore the temperatur
 es & power consumption).
  What factors are there in the network saturation problem?
 \end_layout
@@ -2387,8 +2386,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 behaviour should be perfectly suited for
- GGS.
+ Any game with a client-server behavior should be perfectly suited for GGS.
  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.
  Such as different programming languages.
@@ -2459,7 +2457,7 @@ In order to make the GGS prototype fault tolerant the programming language
 
 \begin_layout Standard
 The need for fault tolerance in game servers is not as obvious as it may
- be for other typ of servers.
+ be for other type of servers.
  In general all servers strive to be fault tolerant as fault tolerance means
  more uptime and a safer system.
  This applies to game servers as well, in brief good fault tolerance is
@@ -3110,7 +3108,7 @@ end{centering}
 status open
 
 \begin_layout Plain Layout
-Add clients on each side, and replace the cloud with phole-landlines being
+Add clients on each side, and replace the cloud with pole-landlines being
  cut by a pair of scissors
 \end_layout
 
@@ -3196,11 +3194,11 @@ name "sec:Game-Development-Language"
 There is only a very limited number of game developers who would like to
  write their games in Erlang, therefore we had to come up with something
  to resolve this problem.
- The main idea was to offer a replacable module which would introduce a
+ The main idea was to offer a replaceable module which would introduce a
  interface to different virtual machines which would run the game code.
- This way a game developer can write the game in his favourite language
- while the server part still is written in Erlang and can benefit from all
- of its advantages.
+ 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 of
+ its advantages.
 \end_layout
 
 \begin_layout Subsection
@@ -3423,7 +3421,7 @@ The real time game chosen for testing the GGS is
 Pong
 \emph default
 , a game in which two players play a game involving a all and two paddles.
- The goal for each player is to shoot eside the othre player's paddle while
+ The goal for each player is to shoot beside the other players paddle while
  not allowing the ball to pass by her own paddle.
  The game requires real time updates and is quite demanding when played
  in several instances concurrently.
@@ -3516,7 +3514,7 @@ 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 devlopment of
+ The functional and concurrent style of Erlang facilitates development of
  software based on a real-world model 
 \begin_inset CommandInset citation
 LatexCommand citep
@@ -3543,7 +3541,7 @@ Light Weight Processes; LWP
 much like the threads in an operating system.
  Threads in a Linux system, for example, are treated much like operating
  system processes in different systems.
- Due to the size of datastructures related to each process, swapping one
+ Due to the size of data structures related to each process, swapping one
  process for another (known as 
 \emph on
 context switching
@@ -3607,7 +3605,7 @@ Erlang allows the GGS to create several process for each player connecting,
  these processes can handle a multitude of different tasks, parsing data
  for example.
  Since each task is handled by a different process, the tasks are clearly
- separated and the failiure of one is easily recovered without affecting
+ separated and the failure of one is easily recovered without affecting
  the others.
 \end_layout
 
@@ -3721,9 +3719,9 @@ reference "fig:The-layout-of"
 
  the entire GGS system is represented graphically.
  The circles marked with 'C' topmost in the picture represent game clients.
- These circles represent processes running on gamers' computers, and not
+ 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 gamers
  machines will be chess game clients.
  Clients connect through a network, pictured as a cloud, to the dispatcher
  process in the GGS.
@@ -3753,7 +3751,7 @@ name "sec:The-usage-of-erlang"
 \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 instustry to achieve high availability
+ Features essential for the telecom industry to achieve high availability
  in telecom switches were added to the language.
 \begin_inset ERT
 status open
@@ -3774,7 +3772,7 @@ textbf{Mutex}}{A construct for achieving mutial exclusion, used to avoid
 \end_layout
 
 \begin_layout Standard
-Erlang uses message passing in favour of shared memory, mutextes and locks,
+Erlang uses message passing in favor of shared memory, mutexes and locks,
  something which at the time was controversial among fellow developers 
 \begin_inset CommandInset citation
 LatexCommand citet
@@ -3790,7 +3788,7 @@ key "Armstrong:2010:ERL:1810891.1810910"
 \end_layout
 
 \begin_layout Standard
-In using message passing in favour of the methods commonly used at the time,
+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
  memory space.
@@ -3824,8 +3822,8 @@ key "Armstrong03"
 \end_layout
 
 \begin_layout Standard
-The strong isolation of Erlang processes make them ideal for multicore and
- distributed systems.
+The strong isolation of Erlang processes make them ideal for multi-core
+ and distributed systems.
  Distribution of software is included as a fundamental part in the Erlang
  language.
  The 'physical' location of a process, e.g.
@@ -3840,7 +3838,7 @@ The distributed nature of Erlang is something the GGS makes use of when
  scaling across several computers in order to achieve higher performance.
  The distribution is also important in creating redundancy.
  Erlang promotes a non-defensive programming style in which processes are
- allowed to crash and be restarted in favour of having the processes recover
+ allowed to crash and be restarted in favor of having the processes recover
  from errors.
  The distributed nature of Erlang means supervisor processes (discussed
  in section 
@@ -3948,16 +3946,16 @@ OTP
  The OTP (Open Telecom Platform) is a set of standard libraries and design
  patterns, called 
 \emph on
-behaviours
+behaviors
 \emph default
 , which are used when developing Erlang systems.
 \end_layout
 
 \begin_layout Standard
-The GGS makes heavy use of the behaviours supplied in the OTP.
- The behaviours impose a programming style suitable for distributed and
- concurrent applications, perfectly suitable for the GGS.
- In particular, the GGS uses the following behaviours:
+The GGS makes heavy use of the behaviors supplied in the OTP.
+ The behaviors impose a programming style suitable for distributed and concurren
+t applications, perfectly suitable for the GGS.
+ In particular, the GGS uses the following behaviors:
 \end_layout
 
 \begin_layout Itemize
@@ -3965,7 +3963,7 @@ The
 \emph on
 supervisor
 \emph default
- behaviour, which is used when creating a supervisor.
+ behavior, which is used when creating a supervisor.
  Supervisors are used when monitoring processes in the Erlang system.
  When a process exits wrongfully, the supervisor monitoring the process
  in question decides which action to take.
@@ -3985,8 +3983,8 @@ The
 \emph on
 gen_tcp 
 \emph default
-behaviour, which is used to work with TCP sockets for network communication.
- Using the gen_tcp behaviour, network messages are converted to internal
+behavior, which is used to work with TCP sockets for network communication.
+ Using the gen_tcp behavior, network messages are converted to internal
  Erlang messages and passed to a protocol parser, where the messages are
  processed further.
 \end_layout
@@ -3996,14 +3994,14 @@ The
 \emph on
 gen_server
 \emph default
- behaviour, which is used when constructing OTP servers in Erlang.
- Using this behaviour, a state can easily be kept in a server process, greatly
+ behavior, which is used when constructing OTP servers in Erlang.
+ Using this behavior, a state can easily be kept in a server process, greatly
  increasing the usefulness of the server process.
- There are many gen_servers in the GGS, it is the most widely used behaviour
+ There are many gen_servers in the GGS, it is the most widely used behavior
  in the project.
- In addition to intruducing a state to the server, the gen_server behaviour
+ In addition to introducing a state to the server, the gen_server behavior
  also imposes patterns for synchronous and asynchronous communication between
- other gen_servers and other OTP behaviours.
+ other gen_servers and other OTP behaviors.
 \end_layout
 
 \begin_layout Itemize
@@ -4011,14 +4009,14 @@ The
 \emph on
 gen_fsm
 \emph default
- behaviour is used in the protocol parser module in the GGS.
- Using the gen_fsm behaviour, finite state machines are easily developed.
+ behavior is used in the protocol parser module in the GGS.
+ Using the gen_fsm behavior, finite state machines are easily developed.
  Protocol parsers are an ideal example of where to use finite state machines,
  which are widely used for parsing strings of text.
 \end_layout
 
 \begin_layout Standard
-In addition to supplying behaviours, the OTP also has a style for packaging
+In addition to supplying behaviors, the OTP also has a style for packaging
  and running Erlang applications.
  By packaging the GGS as an 
 \emph on
@@ -4214,7 +4212,7 @@ tt [1,2,3]}
 \series bold
 Strings
 \series default
- doubly qouted lists of characters, for example 
+ doubly quoted lists of characters, for example 
 \begin_inset ERT
 status open
 
@@ -4236,7 +4234,7 @@ tt "Hello world"}
 Records
 \series default
  are erlang tuples coupled with a tag for each tuple element.
- This allows refering to elements by name instead of by position.
+ This allows referring to elements by name instead of by position.
  An example of a record looks like this: 
 \begin_inset ERT
 status open
@@ -4298,8 +4296,8 @@ localstorage
  by a call for the world object.
  Interaction with the players is done the same way using the player object
  instead.
- The localstorage is a convenient way to store globals and other data seperated
- from the game state.
+ The localstorage is a convenient way to store global data and other data
+ separated from the game state.
  In section 
 \begin_inset CommandInset ref
 LatexCommand ref
@@ -4307,7 +4305,7 @@ reference "sub:Exposing-Erlang-functionality"
 
 \end_inset
 
- a concrete example of the implementation of the localStorage and world
+ a concrete example of the implementation of the localstorage and world
  objects is given.
 \begin_inset Note Note
 status open
@@ -4351,7 +4349,7 @@ 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 localstorage and world
  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.
@@ -4428,10 +4426,10 @@ age 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
+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
+ In order to perform an action using the GGS and localstorage objects, the
  
 \begin_inset ERT
 status open
@@ -4847,7 +4845,7 @@ TODO: Go in to more detail about how the world, player and localstorage
 status open
 
 \begin_layout Plain Layout
-My idea here is that we describe the erlang-js (which failed, but nontheless),
+My idea here is that we describe the erlang-js (which failed, but nonetheless),
  v8, UUID and other external communication.
  We shouldn't describe sockets here though..
  or..
@@ -4863,7 +4861,7 @@ external
 \begin_inset Quotes erd
 \end_inset
 
- to thre GDL.
+ to three GDL.
  Discuss the GGS world object (there is a reference to this secxtion for
  that purpose)
 \end_layout
@@ -4911,7 +4909,7 @@ target "http://www.objectmentor.com/resources/articles/srp.pdf"
 \begin_layout Standard
 The responsibility and concern of each module comes from the responsibility
  and concern of the real-world entity the model represents.
- The modelling of the GGS after a real world system was discussed in chapter
+ The modeling of the GGS after a real world system was discussed in chapter
  
 \begin_inset CommandInset ref
 LatexCommand vref
@@ -4998,8 +4996,8 @@ Is this the proper way to day the dispatcher greets connecting players?
 
  The dispatcher is the module which handles the interfacing to the operating
  system when working with sockets.
- Operating system limits concering the number of open files, or number of
- open sockets are handled here.
+ 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
  more in detail in chapter 
 \begin_inset CommandInset ref
@@ -5080,7 +5078,7 @@ reference "sub:The-protocol-parser"
 \end_inset
 
 .
- Raw communication, witout passing the data through a protocol parser is
+ Raw communication, without passing the data through a protocol parser is
  in theory possible, but is not useful.
 \end_layout
 
@@ -5118,7 +5116,7 @@ The coordinator spawns a new player process, with the same socket reference
 
 \begin_layout Enumerate
 The player process resumes operation, immediately starting a new protocol
- parser process, and begind receiving and sending network messaged again.
+ parser process, and begins to receive and send network messages again.
 \end_layout
 
 \begin_layout Standard
@@ -5165,7 +5163,7 @@ name "sub:The-protocol-parser"
 \end_layout
 
 \begin_layout Standard
-The protocol parser is an easily interchangable module in the GGS, handling
+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
  
@@ -5174,7 +5172,7 @@ GGS Protocol
 \emph default
 .
  The role of the protocol parser is to translate the meaning of packets
- sent using the prototocol in use to internal messages of the GGS system.
+ 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.
 \end_layout
@@ -5191,7 +5189,7 @@ name "sub:The-structure-of"
 \end_layout
 
 \begin_layout Standard
-The GGS protocol is modelled after the HTTP protocol.
+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.
@@ -5240,10 +5238,10 @@ Line 4 specifies the content length of the payload following immediately
 
 \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 behaviour.
+ 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
- from the protocol paser using message passing.
+ from the protocol parser using message passing.
 \end_layout
 
 \begin_layout Standard
@@ -5559,11 +5557,11 @@ The game VM contains the state of the VM and a table token associated with
 
 \begin_layout Standard
 The VM itself makes it possible for the game developer to program in the
- prograimming language covered by the VM.
+ programming language covered by the VM.
  In future releases, more game VM:s will be added to support more programming
  languages.
  Because the game VM keeps track of the correct table, the game developer
- doesn't need to take this into consideration when programming a game.
+ 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
  to the player in the correct running game.
  The same game token is used to store the game state in the database.
@@ -5635,7 +5633,7 @@ 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 valueable tools, the fast
+ The fault tolerance and speed of Mnesia are very valuable tools, the fast
  key/value lookups permit many lookups per second to the database.
 \end_layout
 
@@ -5674,8 +5672,8 @@ Each game is uniquely identified by a table token and the data of each game
  The World 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.
- Game resources, constants and globals are all examples of data that could
- reside within the Localstorage.
+ Game resources, constants and global variables are all examples of data
+ that could reside within the Localstorage.
  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.
@@ -5686,7 +5684,7 @@ Each game is uniquely identified by a table token and the data of each game
 \begin_layout Standard
 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 persistant
+ 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 
@@ -5743,7 +5741,7 @@ The player module, which is coupled to the TCP-module to react on incoming
 \begin_layout Enumerate
 The protocol parser parses the message and brings it into the format of
  the internal GGS presentation of such a message, which is just a specialized
- Erlang touple
+ Erlang tuple
 \end_layout
 
 \begin_layout Enumerate
@@ -5751,7 +5749,7 @@ The protocol parser sends this Erlang touple back to the player module
 \end_layout
 
 \begin_layout Enumerate
-The player module checks if it is a Server-Command or a Game-Commane.
+The player module checks if it is a Server-Command or a Game-Command.
  In our example it is a Game-Command and it sends the message to the table
  module
 \end_layout
@@ -5806,7 +5804,7 @@ reference "sec:Example-of-a-GGS-server-application-in-JavaScript"
 
 \end_inset
 
-) we see that the GGS-functios 
+) we see that the GGS-functions 
 \emph on
 GGS.localStorage.setItem(key, value)
 \emph default
@@ -5828,8 +5826,8 @@ In the example the
 \emph on
 GGS.sendCommandToAll()
 \emph default
- is beeing called then which is a callback to a function of the table module
- which iterates thrugh its player list and sends the command to every player
+ is being called then which is a callback to a function of the table module
+ which iterates through its player list and sends the command to every player
 \end_layout
 
 \begin_layout Enumerate
@@ -5896,8 +5894,8 @@ GGS.sendCommand(player_id, command, args)
 GGS.
 \emph default
 sendCommandToAll(command, args).
- The localStorage is a convenient way to store globals and other variables
- seperated from the game state.
+ The localstorage is a convenient way to store global data and other variables
+ separated from the game state.
  Unique id:s called gametokens are generated for hosted games so that they
  are not mixed up.
 \begin_inset ERT
@@ -6454,7 +6452,7 @@ In Erlang, we have a simple version of supervisors.
 \end_layout
 
 \begin_layout Standard
-When the linking of processes in order to monitor exit behaviour is coupled
+When the linking of processes in order to monitor exit behavior is coupled
  with the transparent distribution of Erlang, a very powerful supervision
  system is created.
  For instance, we can restart a failing process on a different, new node,
@@ -6594,7 +6592,7 @@ To prevent any data loss, the good state of the worker processes is stored
 \end_layout
 
 \begin_layout Subsection
-Reduncancy
+Redundancy
 \end_layout
 
 \begin_layout Standard
@@ -6675,7 +6673,7 @@ name "fig:redundancy"
 \end_inset
 
 To the left normal execution is pictured; the server state is backed up.
- To the right; the exceptional excution, where the state is retrieved from
+ To the right; the exceptional execution, where the state is retrieved from
  the backup to repopulate the server.
 \end_layout
 
@@ -6731,7 +6729,7 @@ playerCommand
 \emph on
 main()
 \emph default
- function of a C or Java programm
+ function of a C or Java program
 \emph on
 .
 
@@ -6779,7 +6777,7 @@ nick
 \begin_inset Quotes erd
 \end_inset
 
- with the actuall new nickname as a argument.
+ with the actual new nickname as a argument.
  When a message arrives to the GGS which has the form corresponding to the
  nickname change, the 
 \emph on
@@ -6820,7 +6818,7 @@ nick
 \emph on
 changeNick 
 \emph default
-function uses a feature of the GGS called localStorage (see section 
+function uses a feature of the GGS called localstorage (see section 
 \begin_inset CommandInset ref
 LatexCommand ref
 reference "sec:Communication-with-the-GDL-VM"
@@ -7178,7 +7176,7 @@ There were two possible solutions to the problem of the JavaScript to Erlang
 
 \begin_layout Standard
 Attempts at creating the communication path from JavaScript to Erlang were
- initially made, however the communiucation path never became stable enough
+ initially made, however the communication path never became stable enough
  for usage in the GGS and the erlang_js software was abandoned.
 \end_layout
 
@@ -7274,7 +7272,7 @@ n of TCP instead of UDP, thus losing some speed.
 \end_layout
 
 \begin_layout Standard
-Furthermore, in a move to increase the speed of the GGS prototcol the binary
+Furthermore, in a move to increase the speed of the GGS protocol the binary
  BSON protocol 
 \begin_inset CommandInset citation
 LatexCommand citet
@@ -7283,7 +7281,7 @@ key "bson:website"
 \end_inset
 
  was initially considered.
- BSON is a protocol which can be used for vert fast traversal of data.
+ BSON is a protocol which can be used for very fast traversal of data.
  The BSON protocol is however rather difficult to read in its plain format,
  and no implementation has been bade for the GGS.
 \end_layout
@@ -7305,7 +7303,7 @@ key "Slee2007"
 
 \begin_layout Standard
 The use of Thrift, BSON, or other protocols can be supported quite easily
- by develpping protocol modules for each protocol.
+ by developing protocol modules for each protocol.
  No protocol modules for these protocols have however been developed during
  the writing of this thesis
 \end_layout
@@ -7662,7 +7660,7 @@ Future improvements
 \begin_layout Standard
 The specification of the GGS prototype is huge and like many other software
  projects relying on outside technologies, in time it would require a lot
- of maintanance.
+ of maintenance.
  Therefore there are a lot of areas in which the GGS could be improved such
  as performance, compatibility, ease of setup and usage.
 \end_layout
@@ -7678,14 +7676,14 @@ Protocols
 \begin_layout Standard
 Because of TCP being a connection oriented protocol, it is not suited for
  all types of game data transfers.
- Each transmission will consume more network bandwith than connectionless
- protocols like UDP and cause uneccessary load on the processor.
+ Each transmission will consume more network bandwidth than connectionless
+ protocols like UDP and cause unnecessary load on the processor.
  Therefore support for UDP would mean that more games could be run simultaneousl
 y on the GGS.
  Another advantage of UDP is latency being reduced.
  Without having to setup a connection for each group packets of data being
  sent, they will be sent instantly and therefore arrive earlier.
- Latency is of highest importance in realtime games as it improves realism
+ Latency is of highest importance in real-time games as it improves realism
  and fairness in gameplay and many game developers requires the freedom
  to take care of safety issues as packet losses themselves.
  This concludes that UDP would be a benefit for the GGS, game developers
@@ -7735,7 +7733,7 @@ GGS relies on modern technologies.
  Therefore it would be best for the GGS to have as many of these VM:s implemente
 d as possible.
  The VM:s taken into consideration so far have been unstable or incomplete
- and it is possible to search for more VM:s, testing them and intergrate
+ and it is possible to search for more VM:s, testing them and integrate
  them into the GGS prototype.
 \end_layout
 
@@ -7744,8 +7742,8 @@ Setup
 \end_layout
 
 \begin_layout Standard
-The GGS prototype installation procedure requires different configuring
- and building steps and thus it isn't in an acceptable release state.
+The GGS prototype installation procedure requires different configuration
+ and building steps and thus it is not in an acceptable release state.
  An executable installation file for each supported platform would be optimal.
 \end_layout
 
@@ -7801,7 +7799,7 @@ addcontentsline{toc}{section}{Glossary}
 
 
 \backslash
-\printnomenclature
+
 \end_layout
 
 \end_inset