Merge branch 'master' of github.com:jeena/GGS-report
This commit is contained in:
Jonatan Pålsson
commit
ddc7d3f535
1 changed files with 40 additions and 40 deletions
80
report.lyx
80
report.lyx
|
|
@ -197,7 +197,7 @@ begin{center}
|
|||
\backslash
|
||||
includegraphics[width=
|
||||
\backslash
|
||||
paperwidth/2]{graphics/logoBW}
|
||||
paperwidth-200px]{graphics/logoBW}
|
||||
\end_layout
|
||||
|
||||
\begin_layout Plain Layout
|
||||
|
|
@ -224,7 +224,7 @@ end{textblock*}
|
|||
\backslash
|
||||
begin{textblock*}{
|
||||
\backslash
|
||||
paperwidth}(21mm,230mm)
|
||||
paperwidth}(21mm,240mm)
|
||||
\end_layout
|
||||
|
||||
\begin_layout Plain Layout
|
||||
|
|
@ -371,15 +371,15 @@ Contemporary game servers lack good fault tolerance, furthermore the game
|
|||
It is investigated if the techniques and tools used in the telecom industry,
|
||||
specifically Erlang and OTP, can be used to create a highly reliable game
|
||||
server.
|
||||
In order to make the server generic, it is investigated if virtual machines
|
||||
can be used to run the actual games, thereby allowing the games to be developed
|
||||
To make the server generic, it is investigated if virtual machines can
|
||||
be used to run the actual games, thereby allowing the games to be developed
|
||||
in a language different from the actual server software.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Abstract
|
||||
A prototype is developed in Erlang and OTP.
|
||||
A prototype is developed in Erlang using OTP.
|
||||
The prototype features basic fault tolerance and is connected to the Google
|
||||
V8 JavaScript virtual machine in order to run games written in JavaScript.
|
||||
V8 JavaScript virtual machine to run games written in JavaScript.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Abstract
|
||||
|
|
@ -391,9 +391,9 @@ The results from testing the server show that: it is possible to design
|
|||
|
||||
\begin_layout Abstract
|
||||
The conclusion of the thesis is that since simple games could be developed
|
||||
in a fault tolerant and using a generic server, it should be worth while
|
||||
trying to develop more advanced games using the same techniques as those
|
||||
described in this thesis.
|
||||
in a fault tolerant way, while also making use of a generic server, it
|
||||
should be worthwhile trying to develop more advanced games using the same
|
||||
techniques as those described in this thesis.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
|
|
@ -905,7 +905,7 @@ 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 is a higher revenue for game
|
||||
companies, to achive this it is important for game companies to expand
|
||||
companies, to achieve 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
|
||||
|
|
@ -1179,7 +1179,7 @@ A prototype has been developed in order to aid the discussion of the theoretical
|
|||
\begin_layout Standard
|
||||
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
|
||||
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.
|
||||
|
|
@ -1338,7 +1338,7 @@ reliable
|
|||
is fault tolerant.
|
||||
In order to facilitate scalability the GGS needs a storage platform which
|
||||
is accessible and consistent.
|
||||
The sclability aspects of the GGS are discussed from a theoretical point
|
||||
The scalability aspects of the GGS are discussed from a theoretical point
|
||||
of view, however no practical implementation of the scalability aspects
|
||||
are found in the prototype.
|
||||
\end_layout
|
||||
|
|
@ -1463,7 +1463,7 @@ Jeopardy
|
|||
.
|
||||
Both game types have varying difficulties and needs when it comes to implementi
|
||||
ng them, a Generic Game Server should address all of these difficulties
|
||||
in order to provide the tools neccessary for the implementation of both
|
||||
in order to provide the tools necessary for the implementation of both
|
||||
game types.
|
||||
\end_layout
|
||||
|
||||
|
|
@ -1598,7 +1598,7 @@ Chess club
|
|||
\end_inset
|
||||
|
||||
- a building where chess players can meet and play chess.
|
||||
In the following text the choice of using a chess club for modelling the
|
||||
In the following text the choice of using a chess club for modeling the
|
||||
GGS is discussed.
|
||||
The chess club is described in greater detail, furthermore the corresponding
|
||||
parts of the chess club in the GGS are described.
|
||||
|
|
@ -2455,8 +2455,8 @@ Many online games use UDP as the carrier for their application layer protocol.
|
|||
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.
|
||||
UDP would be a good candidate, however the time necessary to implement
|
||||
these features makes this option unfeasible.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Subsection
|
||||
|
|
@ -3188,7 +3188,7 @@ using an algorithm such as SHA-1.
|
|||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
When using system wide unique identifiers it is extremly unlikely to have
|
||||
When using system wide unique identifiers it is extremely unlikely to have
|
||||
identifier collisions when recovering from network splits between GGS clusters.
|
||||
Consider figure
|
||||
\begin_inset CommandInset ref
|
||||
|
|
@ -3460,7 +3460,7 @@ https://github.com/languages/
|
|||
|
||||
\begin_layout Standard
|
||||
Apart from that there are virtual machines with bindings to Erlang readily
|
||||
available for JavaScript which are provided by organisations like Mozilla
|
||||
available for JavaScript which are provided by organizations like Mozilla
|
||||
and companies like Google.
|
||||
In the end this choice was more or less arbitrary since the GGS is intended
|
||||
to be able to run several different GDL VMs, and one had to be the first.
|
||||
|
|
@ -3620,7 +3620,7 @@ bots
|
|||
\emph default
|
||||
for testing his generic hazard-gaming server.
|
||||
Lidholt describes how his server, capable of running several different
|
||||
casino games is tested using artificial players, so called bots.
|
||||
casino games, is tested using artificial players, so called bots.
|
||||
Performance is measured in
|
||||
\begin_inset Quotes eld
|
||||
\end_inset
|
||||
|
|
@ -3931,7 +3931,7 @@ name "sec:The-usage-of-erlang"
|
|||
\begin_layout Standard
|
||||
As mentioned earlier, the GGS prototype is implemented in Erlang.
|
||||
The current section and the subsequent section function as a short introduction
|
||||
to Erlang, focusing on the parts of the language neccessary to understand
|
||||
to Erlang, focusing on the parts of the language necessary to understand
|
||||
the material regarding Erlang presented in this thesis.
|
||||
\end_layout
|
||||
|
||||
|
|
@ -4200,7 +4200,7 @@ gen_server
|
|||
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.
|
||||
This behaviour is the most widely used one in the GGS prototype.
|
||||
This behavior is the most widely used one in the GGS prototype.
|
||||
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 behaviors.
|
||||
|
|
@ -4793,7 +4793,7 @@ Line 4 is a empty line which is, like in the HTTP protocol, the separator
|
|||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
Line 5 is the actuall payload which is transported to the game as a parameter
|
||||
Line 5 is the actual payload which is transported to the game as a parameter
|
||||
of the playerCommand() function call.
|
||||
\end_layout
|
||||
|
||||
|
|
@ -5090,7 +5090,7 @@ This module is responsible for the VM associated with each game.
|
|||
\begin_layout Standard
|
||||
The game VM contains a connection to the GDL VM and a table token associated
|
||||
with a running game.
|
||||
The game VM is started by the table module during its initialisation.
|
||||
The game VM is started by the table module during its initialization.
|
||||
The table module hands over a token used for identification to the game
|
||||
VM during the initialization.
|
||||
During the initialization a new GDL VM instance and various objects associated
|
||||
|
|
@ -6353,9 +6353,9 @@ citation needed
|
|||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
Finally to test the robustness of the prototype virtuall users, so called
|
||||
Finally to test the robustness of the prototype virtual users, so called
|
||||
bots are being used to simulate large amounts of players playing different
|
||||
games simultanously.
|
||||
games simultaneously.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Subsection
|
||||
|
|
@ -6471,8 +6471,8 @@ In order to test the robustness of the GGS several different artificial
|
|||
|
||||
\begin_layout Standard
|
||||
With help of this method large amounts of players can be simulated playing
|
||||
games on the GGS simultanously which is a good stress and concurrency test
|
||||
for the overall system.
|
||||
games on the GGS simultaneously which is a good stress and concurrency
|
||||
test for the overall system.
|
||||
In section
|
||||
\begin_inset CommandInset ref
|
||||
LatexCommand ref
|
||||
|
|
@ -6694,7 +6694,7 @@ Initialization and life cycle of a game
|
|||
|
||||
\begin_layout Standard
|
||||
This case study describes the initialization and definition of a game and
|
||||
in roughly its life cycle untill it is removed from the GGS.
|
||||
in roughly its life cycle until it is removed from the GGS.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Subsubsection
|
||||
|
|
@ -6706,8 +6706,8 @@ A client connects via TCP to the GGS.
|
|||
\end_layout
|
||||
|
||||
\begin_layout Enumerate
|
||||
The dispatcher process reacts on the incomming connecction and creates a
|
||||
new player process.
|
||||
The dispatcher process reacts on the incoming connection and creates a new
|
||||
player process.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Enumerate
|
||||
|
|
@ -6737,7 +6737,7 @@ hello
|
|||
to create a new table process and add this player process to this newly
|
||||
created table.
|
||||
If the client did send a table token then the player process asks the coordinat
|
||||
or to att the player process to this table.
|
||||
or to add the player process to this table.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Enumerate
|
||||
|
|
@ -7520,7 +7520,7 @@ erlv8 is powered by the V8 engine developed by Google.
|
|||
Initial releases of the erlv8 bindings had stability issues, these however
|
||||
were resolved by the erlv8 developers during the development GGS.
|
||||
While still described to be in 'alpha' stage, the erlv8 bindings have proved
|
||||
to be stable nough and at this point erlv8 is the JavaScript engine powering
|
||||
to be stable enough and at this point erlv8 is the JavaScript engine powering
|
||||
JavaScript as a GDL in the GGS.
|
||||
\end_layout
|
||||
|
||||
|
|
@ -7588,7 +7588,7 @@ key "Slee2007"
|
|||
communication.
|
||||
Before finding out about Thrift during a lecture of Joe Armstrong (one
|
||||
of the inventors of Erlang), the GGS protocol had already been implemented,
|
||||
moving to Thrift would have meant too much efford for a prototype during
|
||||
moving to Thrift would have meant too much effort for a prototype during
|
||||
the short amount of time.
|
||||
\end_layout
|
||||
|
||||
|
|
@ -7745,7 +7745,7 @@ reference "fig:msg-per-sec-NOMNESIA"
|
|||
\series bold
|
||||
Latency between server and client
|
||||
\series default
|
||||
is used to measure the round-trip time for a message travelling between
|
||||
is used to measure the round-trip time for a message traveling between
|
||||
the client and server.
|
||||
This measurement is used to determine how many players the server can handle
|
||||
while still providing a playable gaming experience.
|
||||
|
|
@ -7772,7 +7772,7 @@ There was also a testing session where the number of clients were measured,
|
|||
status open
|
||||
|
||||
\begin_layout Plain Layout
|
||||
Since we donät include this..
|
||||
Since we don’t include this..
|
||||
should we mention it?
|
||||
\end_layout
|
||||
|
||||
|
|
@ -8109,7 +8109,7 @@ Performance
|
|||
\begin_layout Standard
|
||||
The GGS prototype was not developed for maximum performance.
|
||||
Performance optimizations were considered, many were however not implemented
|
||||
in the prorotype.
|
||||
in the prototype.
|
||||
There are several performance optimizations which can be included in future
|
||||
versions of the GGS, below are some of the most important performance optimizat
|
||||
ions identified.
|
||||
|
|
@ -8208,14 +8208,14 @@ This thesis describes a method to create a reliable and generic game server
|
|||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
To make the GGS as generic as possible seperation of game and server logic
|
||||
To make the GGS as generic as possible separation of game and server logic
|
||||
is necessary.
|
||||
Designing a good API is vital in order to allow game developers to interact
|
||||
with the server in a easy manner and with minimal overhead.
|
||||
Furthermore every game should be isolated so that games can not interfare
|
||||
Furthermore every game should be isolated so that games can not interfere
|
||||
with each other.
|
||||
Isolation can be achived by introducing a context for each game which leads
|
||||
to the fact that each game runs in its own sandbox.
|
||||
Isolation can be achieved by introducing a context for each game which
|
||||
leads to the fact that each game runs in its own sandbox.
|
||||
To be able to use different game development languages virtual machines
|
||||
should be used.
|
||||
Each virtual machine instance evaluates game source code safely.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue