diff --git a/bibliography.bib b/bibliography.bib index 6b64938..2a05109 100644 --- a/bibliography.bib +++ b/bibliography.bib @@ -335,3 +335,23 @@ This paper details the motivations and design choices we made in Thrift, as well address = {New York, NY, USA}, 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}, +} + diff --git a/report.lyx b/report.lyx index 2bf9cd9..cb43579 100644 --- a/report.lyx +++ b/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. There are cases where safety may be critical in game servers, one example is in games where in-game money exist. +\begin_inset CommandInset citation +LatexCommand citet +key "Gartner:1999:FFD:311531.311532" + +\end_inset + + \end_layout \begin_layout Section @@ -2515,7 +2522,7 @@ name "sec:Scalability" \end_layout \begin_layout Standard -Each instance of the GGS contains several tables. +Each instance of the GGS contains several so called tables. Each table is an isolated instance of a game, for instance a chess game or a poker game. The way that the GGS scales is to distribute these tables on different @@ -2855,9 +2862,9 @@ textbf{UUID}}{Universally Unique Identifier} \end_layout \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. - 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. Within one machine, this is mostly not a problem. 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 . - This is accomplished by gathering several different sources of information, - such as: time, MAC addresses of network cards, and operating system data, - such as percentage of memory in use, mouse cursor position and process - IDs. + The generation of a UUID is accomplished by gathering several different + sources of information, such as: time, MAC addresses of network cards, + and operating system data, such as percentage of memory in use, mouse cursor + position and process IDs. The gathered data is then \emph on hashed @@ -2973,15 +2980,7 @@ reference "fig:network-split" \end_inset -, where -\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). +, where an example of a network split is presented. When \emph on @@ -8103,6 +8102,11 @@ To start the GGS is not self explanatory. Conclusion \end_layout +\begin_layout Standard +This thesis describes a method to create a reliable and generic game server + with help of the techniques used in the telecom industry. +\end_layout + \begin_layout Standard \begin_inset ERT status open