Merge branch 'master' of github.com:jeena/GGS-report
This commit is contained in:
commit
059d97d40e
2 changed files with 38 additions and 18 deletions
|
@ -335,3 +335,23 @@ This paper details the motivations and design choices we made in Thrift, as well
|
||||||
address = {New York, NY, USA},
|
address = {New York, NY, USA},
|
||||||
keywords = {property based testing, test automation},
|
keywords = {property based testing, test automation},
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@article{Gartner:1999:FFD:311531.311532,
|
||||||
|
author = {G\"{a}rtner, Felix C.},
|
||||||
|
title = {Fundamentals of fault-tolerant distributed computing in asynchronous environments},
|
||||||
|
journal = {ACM Comput. Surv.},
|
||||||
|
volume = {31},
|
||||||
|
issue = {1},
|
||||||
|
month = {March},
|
||||||
|
year = {1999},
|
||||||
|
issn = {0360-0300},
|
||||||
|
pages = {1--26},
|
||||||
|
numpages = {26},
|
||||||
|
url = {http://doi.acm.org/10.1145/311531.311532},
|
||||||
|
doi = {http://doi.acm.org/10.1145/311531.311532},
|
||||||
|
acmid = {311532},
|
||||||
|
publisher = {ACM},
|
||||||
|
address = {New York, NY, USA},
|
||||||
|
keywords = {agreement problem, asynchronous system, consensus problem, failure correction, failure detection, fault models, fault tolerance, liveness, message passing, possibility detection, predicate detection, redundancy, safety},
|
||||||
|
}
|
||||||
|
|
||||||
|
|
36
report.lyx
36
report.lyx
|
@ -2427,6 +2427,13 @@ The need for fault tolerance in game servers is not as obvious as it may
|
||||||
the system crashes than works with the faulty data.
|
the system crashes than works with the faulty data.
|
||||||
There are cases where safety may be critical in game servers, one example
|
There are cases where safety may be critical in game servers, one example
|
||||||
is in games where in-game money exist.
|
is in games where in-game money exist.
|
||||||
|
\begin_inset CommandInset citation
|
||||||
|
LatexCommand citet
|
||||||
|
key "Gartner:1999:FFD:311531.311532"
|
||||||
|
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Section
|
\begin_layout Section
|
||||||
|
@ -2855,9 +2862,9 @@ textbf{UUID}}{Universally Unique Identifier}
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
\begin_layout Standard
|
||||||
Inside the GGS, everything has a unique identifier.
|
Inside the GGS everything has a unique identifier.
|
||||||
There are identifiers for players, tables and other resources.
|
There are identifiers for players, tables and other resources.
|
||||||
When players communicate amongst each other, or communicate with tables,
|
When players communicate amongst each other or communicate with tables,
|
||||||
they need to be able to uniquely identify all of these resources.
|
they need to be able to uniquely identify all of these resources.
|
||||||
Within one machine, this is mostly not a problem.
|
Within one machine, this is mostly not a problem.
|
||||||
A simple system with a counter can be imagined, where each request for
|
A simple system with a counter can be imagined, where each request for
|
||||||
|
@ -2940,10 +2947,10 @@ Ds generated until 3400 A.D.
|
||||||
\end_inset
|
\end_inset
|
||||||
|
|
||||||
.
|
.
|
||||||
This is accomplished by gathering several different sources of information,
|
The generation of a UUID is accomplished by gathering several different
|
||||||
such as: time, MAC addresses of network cards, and operating system data,
|
sources of information, such as: time, MAC addresses of network cards,
|
||||||
such as percentage of memory in use, mouse cursor position and process
|
and operating system data, such as percentage of memory in use, mouse cursor
|
||||||
IDs.
|
position and process IDs.
|
||||||
The gathered data is then
|
The gathered data is then
|
||||||
\emph on
|
\emph on
|
||||||
hashed
|
hashed
|
||||||
|
@ -2973,15 +2980,7 @@ reference "fig:network-split"
|
||||||
|
|
||||||
\end_inset
|
\end_inset
|
||||||
|
|
||||||
, where
|
, where an example of a network split is presented.
|
||||||
\emph on
|
|
||||||
Site A
|
|
||||||
\emph default
|
|
||||||
is separated from
|
|
||||||
\emph on
|
|
||||||
Site B
|
|
||||||
\emph default
|
|
||||||
by a faulty network (illustrated by the cloud and lightening bolt).
|
|
||||||
When
|
When
|
||||||
\emph on
|
\emph on
|
||||||
|
|
||||||
|
@ -3112,18 +3111,19 @@ Security
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
\begin_layout Standard
|
||||||
We only support languages running in a sandboxed environment.
|
The GGS only supports languages running in a sandboxed environment.
|
||||||
Each game session is started in its own sandbox.
|
Each game session is started in its own sandbox.
|
||||||
The sandboxing isolates the games in such a way that they cannot interfere
|
The sandboxing isolates the games in such a way that they cannot interfere
|
||||||
with each other.
|
with each other.
|
||||||
If sandboxing was not in place, one game could potentially modify the contents
|
If sandboxing was not in place, one game could potentially modify the contents
|
||||||
of a different game.
|
of a different game.
|
||||||
A similar approach is taken with the persistent storage we provide.
|
A similar approach is taken with the persistent storage provided by the
|
||||||
|
GGS.
|
||||||
In the storage each game has its own namespace, much like a table in a
|
In the storage each game has its own namespace, much like a table in a
|
||||||
relational database.
|
relational database.
|
||||||
A game is not allowed to venture outside this namespace, and can because
|
A game is not allowed to venture outside this namespace, and can because
|
||||||
this not modify the persistent data of other games.
|
this not modify the persistent data of other games.
|
||||||
of this not modify the persistent data of other games.
|
|
||||||
\begin_inset ERT
|
\begin_inset ERT
|
||||||
status open
|
status open
|
||||||
|
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue