Corrected a lot of errors in chapter 1&2
This commit is contained in:
niklas
parent
a72e14ffdb
commit
79848ce54c
1 changed files with 78 additions and 82 deletions
160
report.lyx
160
report.lyx
|
|
@ -401,7 +401,7 @@ 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.
|
||||
This thesis is about techniques for improving the quality if this networking
|
||||
This thesis is about techniques for improving the quality of this networking
|
||||
software.
|
||||
\end_layout
|
||||
|
||||
|
|
@ -465,14 +465,15 @@ generic
|
|||
framework for developing network games.
|
||||
The framework is generic in the sense that it is not bound to a specific
|
||||
game.
|
||||
There are many different types of games, some are inheritly more time sensitive
|
||||
than others, strategy games are examples of games which are not very sensitive
|
||||
to time delays, first-person shooters however, can be very sensitive.
|
||||
There are many different types of games, some are inherently more time
|
||||
sensitive than others, strategy games are examples of games which are not
|
||||
very sensitive to time delays, first-person shooters however, can be very
|
||||
sensitive.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
The generic nature of the GGS allows the creation of many different types
|
||||
of games, the motivation behind this is to remove the neccessity of writing
|
||||
of games, the motivation behind this is to remove the necessity of writing
|
||||
new game servers when developing new games.
|
||||
\end_layout
|
||||
|
||||
|
|
@ -481,9 +482,9 @@ The GGS is in addition to being generic, also
|
|||
\emph on
|
||||
reliable
|
||||
\emph default
|
||||
in the sense that the gaming service provided is consistant and available.
|
||||
A consistant and available server is a server that handles hardware failiures
|
||||
and software failiures gracefully.
|
||||
in the sense that the gaming service provided is consistent and available.
|
||||
A consistent and available server is a server that handles hardware failures
|
||||
and software failures gracefully.
|
||||
In the event of a component breaking within the GGS, the error is handled
|
||||
by fault recovery processes, thereby creating a more reliable system.
|
||||
\end_layout
|
||||
|
|
@ -494,7 +495,7 @@ Background
|
|||
|
||||
\begin_layout Standard
|
||||
The game industry is a quickly growing industry where the need for new technique
|
||||
s is large.
|
||||
s are large.
|
||||
One specific section where the development has stalled is the game server
|
||||
section.
|
||||
\begin_inset Note Note
|
||||
|
|
@ -520,7 +521,7 @@ Citation needed
|
|||
.
|
||||
Users will notice this in low uptime and many crashes.
|
||||
This is a problem that has existed and been resolved in other industries.
|
||||
In the telecom industry solutins to similar problems have been found.
|
||||
In the telecom industry solutions to similar problems have been found.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
|
|
@ -720,8 +721,8 @@ A database server can also be seen as an application server.
|
|||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
One of the purposes of this thesis is to investigate how we can make a game
|
||||
server as generic as possible.
|
||||
One purpose of this thesis is to investigate how we can make a game server
|
||||
as generic as possible.
|
||||
Some important helpers are discussed, such as abstraction of the network
|
||||
layer, data store and game specific features.
|
||||
|
||||
|
|
@ -815,8 +816,8 @@ The purpose of creating a generic and fault tolerant game server is to provide
|
|||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
Fault tolerance is important for the GGS in order to create a reliable service.
|
||||
The purpose of a reliable game server is to provide a consistant service
|
||||
Fault tolerance is important for the GGS to create a reliable service.
|
||||
The purpose of a reliable game server is to provide a consistent service
|
||||
to people using the server.
|
||||
Going back to the telecom example, the purpose of creating a reliable telecom
|
||||
system is to allow calls, possibly emergency calls, at any time.
|
||||
|
|
@ -848,9 +849,9 @@ The word
|
|||
generic
|
||||
\emph default
|
||||
in the name of the GGS implies that the system is able to run a very broad
|
||||
range of different code, for instance code written in different programming
|
||||
languages, in addition to a broad range of different game types.
|
||||
In order to support this, a virtual machine (VM) for each
|
||||
range of different code, for instance code wrote in different programming
|
||||
languages, besides a broad range of different game types.
|
||||
To support this, a virtual machine (VM) for each
|
||||
\emph on
|
||||
game development language
|
||||
\emph default
|
||||
|
|
@ -933,9 +934,8 @@ The implementation of the GGS protocol, together with storage possibilities,
|
|||
|
||||
\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, because the implementation
|
||||
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
|
||||
|
|
@ -955,7 +955,7 @@ reference "sec:Choice-of-network"
|
|||
\begin_layout Standard
|
||||
In real time games all players are playing together at the same time.
|
||||
Latency is a huge problem in real time games, a typical round trip time
|
||||
for such games is one of
|
||||
for such games are one of
|
||||
\begin_inset Formula $50$
|
||||
\end_inset
|
||||
|
||||
|
|
@ -991,7 +991,7 @@ World of Warcraft
|
|||
\begin_layout Standard
|
||||
In turn based games each player has to wait for their turn.
|
||||
Latency is not a problem since the gameplay does not require fast interactions
|
||||
between the players, long round trip times will not be noticed.
|
||||
among the players, long round trip times will not be noticed.
|
||||
Examples of turn based games include board and card games, as well as multiplay
|
||||
er games like
|
||||
\emph on
|
||||
|
|
@ -1012,9 +1012,8 @@ Due to the limited capability of threading in many GDL VM:s, the GGS prototype
|
|||
The implementation of the GGS described in this thesis is only a small prototype
|
||||
and tests will be performed on simple games like pong or chess, thus there
|
||||
are no need to implement more advanced features in the system.
|
||||
It is important to note that these limitations only apply for the prototype
|
||||
of the project, and that further developments to the GGS could be to implement
|
||||
these features.
|
||||
Note that these limitations only apply for the prototype of the project,
|
||||
and that further developments to the GGS could be to implement these features.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Section
|
||||
|
|
@ -1026,8 +1025,7 @@ Development process
|
|||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
A prototype was developed early on in the project in order to carry out
|
||||
experiments.
|
||||
A prototype was developed early on in the project to carry out experiments.
|
||||
Using this prototype, the system was divided into modules.
|
||||
A demand specification was created, using this specification, the modules
|
||||
were easily identifiable.
|
||||
|
|
@ -1035,17 +1033,17 @@ A prototype was developed early on in the project in order to carry out
|
|||
|
||||
\begin_layout Standard
|
||||
The first prototype of the GGS consisted of simple modules, however, due
|
||||
to the separation of concerns between the modules, they were easily independant
|
||||
ly modified and improved.
|
||||
to the separation of concerns among the modules, they were easily independently
|
||||
modified and improved.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
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.
|
||||
The second iteration later became the final result of the GGS
|
||||
This could be seen as an iterative workflow, with the first prototype being
|
||||
the first iteration.
|
||||
The second iteration later became the result of the GGS
|
||||
\end_layout
|
||||
|
||||
\begin_layout Subsection
|
||||
|
|
@ -1059,7 +1057,7 @@ The layout of the GGS is both layered and modular.
|
|||
GGS.
|
||||
The modular structure of the GGS plays an important role in making the
|
||||
system fault tolerant.
|
||||
The approach to fault tolerance is by replication, and restarting faulting
|
||||
The approach to fault tolerance is by replication, and restarting the faulting
|
||||
modules with the last known good data.
|
||||
\end_layout
|
||||
|
||||
|
|
@ -1101,7 +1099,7 @@ In this chapter, the theory behind the techniques used in the GGS are discussed.
|
|||
Benchmarking techniques are discussed.
|
||||
The options when choosing network protocols are given, along with a discussion
|
||||
of each alternative.
|
||||
Finally, a overview of scalability, fault tolerance and availability is
|
||||
Finally, an overview of scalability, fault tolerance and availability are
|
||||
presented.
|
||||
\end_layout
|
||||
|
||||
|
|
@ -1117,7 +1115,7 @@ name "sec:Design-of-the"
|
|||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
The GGS is modelled after a real world system performing much of the same
|
||||
The GGS is modeled after a real world system performing much of the same
|
||||
duties as GGS.
|
||||
This is common practice
|
||||
\begin_inset CommandInset citation
|
||||
|
|
@ -1126,12 +1124,11 @@ key "armstrong2011"
|
|||
|
||||
\end_inset
|
||||
|
||||
in the computer software world, in order to understand complex problems
|
||||
more easily.
|
||||
in the computer software world, to understand complex problems more easily.
|
||||
While there may not always be a real world example of a system performing
|
||||
th exact duties of the system being modelled in the computer, it is often
|
||||
the exact duties of the system being modeled in the computer, it is often
|
||||
easier to create and analyze requirements for real world systems and processes
|
||||
than systems existing soley in a computer.
|
||||
than systems existing solely in a computer.
|
||||
The requirements and limitations imposed on the real-world system can,
|
||||
using the proper tools, be transferred in to the software.
|
||||
\end_layout
|
||||
|
|
@ -1276,7 +1273,7 @@ Räkning
|
|||
|
||||
can be kept, ensuring that there are not too many players within the building.
|
||||
In the GGS setting, too many players entering would mean too many connections
|
||||
have been accepted to the GGS system, and that the structure of the system
|
||||
have been accepted by the GGS system, and that the structure of the system
|
||||
thus must be modified, adding additional servers.
|
||||
\end_layout
|
||||
|
||||
|
|
@ -1302,16 +1299,16 @@ Moves by players are made using the tables present in the chess club.
|
|||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
This isolation of the games plays an imporant part in many properties of
|
||||
This isolation of the games play an important part in many properties of
|
||||
the GGS, the isolation means that games can for example be transferred
|
||||
between different chess clubs, furthermore, if cheating takes place, corruption
|
||||
among different chess clubs, furthermore, if cheating takes place, corruption
|
||||
can only occur in the particular table where it was found, and can not
|
||||
spread.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
Moving chess players from one location to another is one of the alterations
|
||||
made to the real world chess club system to make the system more appropriate
|
||||
Moving chess players from one location to another is one alteration made
|
||||
to the real world chess club system to make the system more appropriate
|
||||
for a software setting.
|
||||
Allowing games to be transferred is not a property usually desired in a
|
||||
real world chess club, where transferring players would mean moving the
|
||||
|
|
@ -1332,10 +1329,10 @@ reference "alg:game-lifecycle"
|
|||
\end_inset
|
||||
|
||||
.
|
||||
In order to make this life cycle as efficient and useful as possible, the
|
||||
scalability, fault tolerant and generic traits are added to the GGS.
|
||||
To make this life cycle as efficient and useful as possible, the scalability,
|
||||
fault tolerant and generic traits are added to the GGS.
|
||||
These are not shown in the algorithm, as these traits are tools in making
|
||||
the algorithm behave as efficient as possible, and are not the main focus
|
||||
the algorithm behaves as efficient as possible, and are not the main focus
|
||||
when studying the life cycle of a game.
|
||||
\end_layout
|
||||
|
||||
|
|
@ -1768,10 +1765,10 @@ There are many ways in which performance could be measured.
|
|||
|
||||
\begin_layout Standard
|
||||
In a first person shooter game, the speed of delivery of messages is essential.
|
||||
Failiure to deliver messages in time results in choppy gameplay for the
|
||||
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 percieved as choppy even if the messages
|
||||
the speed, since the game is not perceieved as choppy even if the messages
|
||||
are delayed.
|
||||
\end_layout
|
||||
|
||||
|
|
@ -1779,7 +1776,7 @@ In a first person shooter game, the speed of delivery of messages is essential.
|
|||
For someone operating a GGS, it is perhaps more interesting to measure the
|
||||
system load, memory consumption, energy consumption and network saturation.
|
||||
These topics are discussed in theory in this section.
|
||||
The practical results for the prototype are discussed in chapter
|
||||
The practical results for the prototype is discussed in chapter
|
||||
\begin_inset CommandInset ref
|
||||
LatexCommand vref
|
||||
reference "cha:Implementation-of-a"
|
||||
|
|
@ -1924,12 +1921,12 @@ name "sec:Choice-of-network"
|
|||
\begin_layout Standard
|
||||
There are three main ways in which computer communication over the Internet
|
||||
usually takes place; TCP, UDP and HTTP.
|
||||
The first two are transport layer protocols, which are commonly used to
|
||||
The first two is transport layer protocols, which are commonly used to
|
||||
transport application layer protocols, such as HTTP.
|
||||
TCP and UDP can not be used on their own, without an application layer
|
||||
protocol on top.
|
||||
Application layer protocols such as HTTP on the other hand needs a transport
|
||||
layer protocol in order to work.
|
||||
layer protocol to work.
|
||||
|
||||
\end_layout
|
||||
|
||||
|
|
@ -1993,7 +1990,7 @@ TCP
|
|||
|
||||
\begin_layout Standard
|
||||
For reliable transfers, TCP is often used on the Internet.
|
||||
Built in to the protocol are the error checking and correction mechanisms
|
||||
Built in to the protocol is the error checking and correction mechanisms
|
||||
missing in UDP.
|
||||
This ensures the consistency of data, but also makes the transfer slower
|
||||
than if UDP had been used.
|
||||
|
|
@ -2082,13 +2079,12 @@ Fault tolerance is an important factor in all servers, a server that is
|
|||
safe and guaranteed to be available.
|
||||
It should be noted that it is not possible to achieve complete fault tolerance,
|
||||
a system will always have a certain risk of failure.
|
||||
With this in mind the goal is to make the GGS prototype as fault tolerant
|
||||
as possible.
|
||||
Therefore the goal is to make the GGS prototype as fault tolerant as possible.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
In order to make the GGS prototype fault tolerant the programming language
|
||||
Erlang has been used.
|
||||
To make the GGS prototype fault tolerant the programming language Erlang
|
||||
has been used.
|
||||
Erlang will not guarantee a fault tolerant system but it has features that
|
||||
support and encourage the development of fault tolerant systems.
|
||||
In the GGS it is important that the system overall is fault tolerant.
|
||||
|
|
@ -2100,12 +2096,12 @@ In order to make the GGS prototype fault tolerant the programming language
|
|||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
The need for fault tolerance in game servers is not as obvious as it may
|
||||
be for other typ of servers.
|
||||
The need for fault tolerance in game servers are not as obvious as it may
|
||||
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 aswell, in brief good fault tolerance is a
|
||||
way of satisfying customers.
|
||||
This applies to game servers as well, in brief good fault tolerance is
|
||||
a way of satisfying customers.
|
||||
In general, game servers differ from many other fault tolerant systems
|
||||
in that high-availability is more important than the safety of the system.
|
||||
For example a simple calculation error will not be critical for a game
|
||||
|
|
@ -2132,14 +2128,14 @@ name "sec:Availability"
|
|||
|
||||
\begin_layout Standard
|
||||
One important factor of any server is the availability.
|
||||
A server to which you are unable to connect to is a useless server.
|
||||
Other then within telecomunication, their uptime is of about 99,9999999%,
|
||||
the game developer community has not approched this problem very genuinely
|
||||
A server to which you are unable to connect to is an useless server.
|
||||
Other then within telecommunication, their uptime is of about 99,9999999%,
|
||||
the game developer community has not approached this problem very genuinely
|
||||
yet so there is much room for improvement.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
There are several good papers on how to migrate whole virtual machines between
|
||||
There are several good papers on how to migrate whole virtual machines among
|
||||
nodes to replicate them
|
||||
\begin_inset Note Note
|
||||
status open
|
||||
|
|
@ -2191,22 +2187,22 @@ Each instance of the GGS contains several tables.
|
|||
or a poker game.
|
||||
The way that the GGS scales is to distribute these tables on different
|
||||
servers.
|
||||
In many games it is not necessary for a player to move between tables during
|
||||
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
|
||||
represented as a player standing up from her current table and sitting
|
||||
down at a new table, all within the same game session.
|
||||
With this in mind, the main focus of the GGS is not to move players between
|
||||
tables, but to keep a player in a table, and to start new tables instead.
|
||||
When a server has reached a certain amount of players the performance will
|
||||
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.
|
||||
When a server has reached a certain number of players the performance will
|
||||
start to decrease.
|
||||
To avoid this the GGS will start new tables on another server, using this
|
||||
technique the players will be close to evenly distributed between the servers.
|
||||
technique the players will be close to evenly distributed among the servers.
|
||||
It is important to investigate and find out how many players that are optimal
|
||||
for each server.
|
||||
This approach makes it possible to utilize all resources with moderate
|
||||
load, instead of having some resources with heavy load and some with almost
|
||||
no load.
|
||||
This approach makes it possible to use all resources with moderate load,
|
||||
instead of having some resources with heavy load and some with almost no
|
||||
load.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
|
|
@ -2228,7 +2224,7 @@ Load balancing
|
|||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
The need for load balancing varies between different kind of systems.
|
||||
The need for load balancing varies among different kind of systems.
|
||||
Small systems that only use one or a couple of servers can cope with a
|
||||
simple implementation of it, while in large systems it is critical to have
|
||||
extensive and well working load balancing.
|
||||
|
|
@ -2241,10 +2237,10 @@ The need for load balancing varies between different kind of systems.
|
|||
\begin_layout Standard
|
||||
Load balancing and scaling is difficult in different scenarios.
|
||||
When running in a separate server park, there are a set number of servers
|
||||
available, this means that an even distribution on all servers is preferable.
|
||||
available, this means that an even distribution on all servers are 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.
|
||||
In this cloud setting, it may be more important to evenly distribute load
|
||||
In this cloud setting, it may be more important to distribute evenly load
|
||||
on newly added servers.
|
||||
\end_layout
|
||||
|
||||
|
|
@ -2253,7 +2249,7 @@ Two methods of balancing load (increasing structure):
|
|||
\end_layout
|
||||
|
||||
\begin_layout Itemize
|
||||
Fill up the capacity of one server completely, and then move over to the
|
||||
Fill up the capacity for one server completely, and then move over to the
|
||||
next server
|
||||
\end_layout
|
||||
|
||||
|
|
@ -2284,7 +2280,7 @@ Load balancing is a key component to achieve scalability in network systems.
|
|||
Load balancing can often be implemented using dedicated software, this means
|
||||
that in many applications load balancing may not be implemented because
|
||||
it already exist functional solutions.
|
||||
This depends on what specific needs the system have and a minor goal of
|
||||
This depends on what specific needs the system has and a minor goal of
|
||||
the project is to analyze whether the GGS project can use existing load
|
||||
balancing tools or if it is necessary to implement load balancing in the
|
||||
project.
|
||||
|
|
@ -2487,10 +2483,10 @@ A simple (insufficient) generator for identifiers
|
|||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
Inside the GGS, everything has a unique identifier.
|
||||
Inside the GGS, everything has an unique identifier.
|
||||
There are identifiers for players, tables and other resources.
|
||||
When players communicate amongst each other, or communicate with tables,
|
||||
they need to be able to uniquely identify all of these resources.
|
||||
When players communicate amongst one another, or communicate with tables,
|
||||
they need to be able to uniquely identify all 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
|
||||
|
|
@ -2712,7 +2708,7 @@ We only support languages running in a sandboxed environment.
|
|||
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
|
||||
of this not modify the persistent data of other games.
|
||||
this not modify the persistent data of other games.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Subsection
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue