jeena/GGS-report
1
0
Fork 0
Code Issues Pull requests Projects Packages Wiki Activity Actions

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

Browse source
This commit is contained in:
niklas 2011-05-11 18:04:17 +02:00
commit 8863f907e2
2 changed files with 8130 additions and 108 deletions
Download patch file Download diff file Expand all files Collapse all files

165
report.lyx
View file

@ -726,7 +726,7 @@ the nine nines
\begin_inset Formula $99.999999999\%$
\end_inset
of availability
of availability
\begin_inset CommandInset citation
LatexCommand citet
key "Armstrong03"
@ -739,7 +739,7 @@ key "Armstrong03"
downtime in a year.
The level of instability and bad fault tolerance seen in the game server
industry would not have been accepted in the telecoms industry.
industry would not have been accepted in the telecom industry.
This level of instability should not be accepted in the game server industry
either.
An unavailable phone system could potentially have life threatening consequence
@ -751,50 +751,43 @@ s, leaving the public unable to contact emergency services.
\begin_layout Standard
Moving back to the gaming industry.
The main reason to develop reliable servers are monetary, it is important
for game companies to expand its customer base.
Reliable game servers are one improvement that will create a good image
of a company.
The main reason to develop reliable servers is a higher revenue, do archive
this it is important for game companies to expand their customer base.
Reliable game servers will create a good image of the company.
In general the downtime of game servers is much higher than the downtime
of telecom system
\begin_inset Note Note
status open
\begin_layout Plain Layout
Citation needed...
\end_layout
\end_inset
.
The structure of the system is similar in many ways and it should be possible
to reuse solutions from the telecom system to improve game servers.
of telecom systems evenso the overall structure of the systems is similar
in many ways.
It should be possible to learn and reuse solutions from the telecom systems
to improve game servers.
\end_layout
\begin_layout Standard
In the current state game servers are developed on a per-game basis, often
this seems like a bad solution.
Developers of network game need to understand network programming.
A way to change this is a generic game server which gives the game developers
a server which they implement their game towards.
Developers of multiplayer games need to understand network programming,
which above all be a problem for small companies and indipendent game developer
s who often lack expertise in that field.
A way to help them in the competition would be to offer a generic game
server which gives them a environment in which they can implement their
game in.
This approach would not only make it easier to develop network games, it
would also allow games in different programming languages to be implemented
using the same server.
\end_layout
\begin_layout Standard
Some factors key to the development of GGS have been isolated.
Many of these come from the telecom sector.
Some key factors to the development of the GGS have been isolated.
Many of these are found in the telecom sector too.
The factors are
\emph on
scalability, fault tolerance
\emph default
and being
and a
\emph on
generic
\emph default
.
nature.
These terms are defined below.
\end_layout
@ -847,8 +840,8 @@ dependability
as intended at a given point in time.
Fault tolerance is the property of a system always to follow a specification,
even in the presence of errors.
The specification could take the form of error handling procedures which
activate when an error occurs.
The specification could define error handling procedures which activate
when an error occurs.
This means that a fault tolerant, dependable system, will have a very high
probability of functioning at a given point in time, and is exactly what
is desired.
@ -994,7 +987,7 @@ A database server can also be seen as an application server.
\end_layout
\begin_layout Standard
One purpose of this thesis is to investigate how we can make a game server
One purpose of this thesis is to investigate how one could 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.
@ -1002,19 +995,19 @@ One purpose of this thesis is to investigate how we can make a game server
\end_layout
\begin_layout Standard
As an aid in discussing the theoretical parts of the GGS a prototype has
been developed.
A prototype has been developed in order to aid the discussion of the theoretical
parts of the GGS.
The prototype does not feature all the characteristics described in this
thesis.
A selection has been made among the features, and the most important ones
A selection has been made among the features and the most important ones
have been implemented either full or in part in the prototype.
\end_layout
\begin_layout Standard
The choice of implementation language for the prototype of the GGS was made
with inspiration from the telecom industry.
The Erlang language was developed by the telecom company Ericsson to develop
highly available and dependable telecom switches.
The choice of the implementation language for the prototype of the GGS was
made with inspiration from the telecom industry.
The Erlang language was developed by the swedish telecom company Ericsson
to develop highly available and dependable telecom switches.
One of the most reliable systems ever developed by Ericsson, the AXD301
was developed using Erlang.
The AXD301 has possibly the largest code base even written in a functional
@ -1027,7 +1020,8 @@ key "Armstrong03"
.
The same language is used to develop the prototype of the GGS.
Usage of Erlang in the GGS is discussed in further detail in section
The usage of Erlang in the GGS is discussed in further detail in section
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:The-usage-of-erlang"
@ -1035,50 +1029,12 @@ reference "sec:The-usage-of-erlang"
\end_inset
.
Chapter
\begin_inset CommandInset ref
LatexCommand vref
reference "cha:Implementation-of-a"
\end_inset
provides a description of the prototype developed for this thesis.
\begin_inset Note Note
status collapsed
\begin_layout Plain Layout
We could go on and on about erlang..
\end_layout
\end_inset
\end_layout
\begin_layout Section
Purpose
\end_layout
\begin_layout Standard
\begin_inset Note Note
status collapsed
\begin_layout Plain Layout
The purpose of the GGS project.
What is the purpose of creating a fault tolerant server, why is it generic,
and what good does it do to have a scalable system? In the background,
we should give the motivations behind creating this software, but here
we should outline why the software is needed.
This section should be shortened, and the bulk of the text should be moved
to theory or background.
\end_layout
\end_inset
\end_layout
\begin_layout Standard
The purpose of creating a generic and fault tolerant game server is to provide
a good framework for the development of many different types of games.
@ -1095,20 +1051,20 @@ Fault tolerance is important for the GGS to create a reliable service.
Going back to the telecom example, the purpose of creating a reliable telecom
system is to allow calls, possibly emergency calls, at any time.
Should the telecom network be unavailable at any time, emergency services
may become unavailable, furthermore the consumer image of the telecom system
degrades.
may become unavailable, furthermore the consumer's image of the telecom
system degrades.
\end_layout
\begin_layout Standard
Returning to the game industry, emergency services will not be contacted
using a game server, however an unavailable server will degrade the consumer
using a game server, however an unavailable server will degrade the consumer's
image of the system.
Consider an online casino company.
The online casino company's servers must be available at all times to allow
customers to play.
If the servers are unavailable, customers cannot play, and the company
loses money.
In this scenario, an unavailable server can be compared to a closed real-world
If the servers are unavailable customers cannot play and the company loses
money.
In this scenario an unavailable server can be compared to a closed real-world
casino.
\end_layout
@ -1122,8 +1078,8 @@ 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 wrote in different programming
languages, besides a broad range of different game types.
range of different code, for instance code written in different programming
languages or code written for a broad range of different game types.
To support this, a virtual machine (VM) for each
\emph on
game development language
@ -1159,48 +1115,41 @@ textbf{VM}}{Virtual Machine}
\begin_layout Standard
No hard limit has been set on which languages can be used for game development
on the GGS, but there are several factors which decide the feasibility
of a language:
on the GGS, but there are several factors which should be taken into considerat
ion when deciding the feasibility of a language:
\end_layout
\begin_layout Itemize
How well it integrates with Erlang, which is used in the core the GGS system
How well it integrates with Erlang, which is used in the core the GGS system?
\end_layout
\begin_layout Itemize
How easy it is to send messages to the virtual machine of the GDL from the
GGS
How easy it is to send messages from the GGS to the GDL VM?
\end_layout
\begin_layout Itemize
How easy it is to send messages from the GDL VM to the GGS
\begin_inset Note Note
status open
\begin_layout Plain Layout
Add more like threads, events, etc.
How easy it is to send messages from the GDL VM to the GGS?
\end_layout
\end_inset
\begin_layout Itemize
Is it possible to sandbox every game with a context or something comperable?
\end_layout
\begin_layout Standard
Internally, the GDL VM needs to interface with the GGS to make use of the
Internally the GDL VM needs to interface with the GGS to make use of the
helpers and tools that the GGS provides.
Thus an internal API has to be designed for use in interacting with the
GGS.
Thus an internal API has to be designed to make the GDL VM to be able to
interacti with the GGS.
This API is ideally completely independent of the GDL, and reusable for
any GDL.
\end_layout
\begin_layout Standard
The communication with gaming clients has to take place over a protocol.
Ideally a standard protocol should be used, in order to shorten the learning
curve for developers, and also make the system as a whole less obscure.
A large challenge during this project is to decide whether an existing
The communication with the gaming clients has to take place with help a
protocol.
Ideally a standard protocol should be used in order to shorten the learning
curve for developers and also make the system as a whole less obscure.
A major challenge during this project is to decide whether an existing
protocol can be used, and if not, how a new protocol can be designed which
performs technically as desired, while still being familiar enough to existing
developers.
@ -1212,10 +1161,10 @@ A great deal of work is devoted to make the GGS
reliable
\emph default
.
This includes ensuring that the system scales well, and to make sure it
This includes ensuring that the system scales well and to make sure it
is fault tolerant.
In order to facilitate scalability, we need a storage platform which is
accessible and consistent among all of the GGS, this is also investigated.
In order to facilitate scalability the GGS needs a storage platform which
is accessible and consistent.
\end_layout
\begin_layout Section