handwritten notes to Tikz, add list of issues to appendices

4 files changed, 30 insertions, 27 deletions

diff --git a/src/body/background.tex b/src/body/background.tex
index a7d0e3b..88bc72f 100755
--- a/src/body/background.tex
+++ b/src/body/background.tex
@@ -12,9 +12,9 @@ From the poker analogy, we continue to multiple games. In the local bar, several
 To illustrate the more technical interactions between dealers, barkeep and player, we create three roles: {\bf gameserver}, {\bf masterserver} and {\bf client}\footnote{We refer to \emph{gameservers} and \emph{masterservers} instead of \emph{game-} and \emph{master} servers. The latter is correct English, but the former improves readability and avoids confusion about what type of server we explicitly try to describe.} in figure \ref{fig:totaloverview}. When a gameserver is initialised, it repeatedly sends a signal to the masterserver (1). We refer to these signals as \emph{heartbeats}, as the masterserver listens for these signals to determine if the gameserver is still active, similar to how we listen for heartbeats in the human body to determine if somebody is still alive. Game clients make a request to the masterserver to obtain a list of all servers that sent heartbeats and the masterserver provides this list (2). The client then inquires at all of these gameservers for their information (or \emph{status}) so that the user can make a choice which gameserver to join (3).
 
 \begin{figure}[ht]
-  \centering
-  \includegraphics[width=\textwidth]{img/general-overview}
-  \caption{General interactions between gameserver, masterserver and client.}\label{fig:totaloverview}
+\centering
+\input{tikz/overview}
+\caption{General interactions between gameserver, masterserver and client.}\label{fig:totaloverview}
 \end{figure}
 
 All interactions between gameserver, masterserver and client occur over the internet. To avoid a wild growth of different methods to convey the information, GameSpy created a format of communication to handle many games with the same approach. When different gameservers follow the same protocol, the same interaction can be applied for a large variety in games. In other words, one barkeep could keep a room list for poker, monopoly, bridge and other games, instead of having one barkeep for every game: the masterserver can handle different games that use the same form of communication.
diff --git a/src/body/heartbeat.tex b/src/body/heartbeat.tex
index ad365fb..00430e3 100755
--- a/src/body/heartbeat.tex
+++ b/src/body/heartbeat.tex
@@ -4,9 +4,9 @@
 In this chapter, we discuss what information a heartbeat contains and how it is processed by the masterserver.
 
 \begin{figure}[ht]
-  \centering
-  \includegraphics[width=\textwidth]{img/overview-hb}
-  \caption{Focus on interaction between gameserver and masterserver}\label{fig:overviewhb}
+\centering
+\input{tikz/overview-hb}
+\caption{Focus on interaction between gameserver and masterserver}\label{fig:overviewhb}
 \end{figure}
 
 \section{Exchange}
@@ -19,9 +19,10 @@ Heartbeats are sent repeatedly to indicate that a server is still active. The na
 This exchange is visualised in a diagram in figure \ref{fig:heartbeat} where the vertical axis represents passing time and the horizontal interactions correspond to the exchange discussed above.
 
 \begin{figure}[ht]
-  \centering
-  \includegraphics[width=\textwidth]{img/heartbeat-exchange}
-  \caption{Interaction between gameserver and masterserver}\label{fig:heartbeat}
+\centering
+\input{tikz/heartbeat-exchange}
+\caption{UDP interaction between the gameserver (left) and masterserver (right) over time.}
+\label{fig:heartbeat}
 \end{figure}
 
 \section{Secure challenge}
@@ -29,22 +30,22 @@ To authenticate the validity of gameserver, masterserver and client, the GameSpy
 
 Both the secure word and cipher may consist of any uppercase or lowercase character and any number. The validate word is a calculated response and can contain any uppercase or lowercase character and any number, but also certain special characters such as (back)slashes, underscores and dashes. Later versions of the algorithm also allow to specify an encryption type, which results in a different validate word. The algorithm to determine the validate word consists of a series of array operations and is purely mathematical\cite{lam}.
 
-\section{Formatting}
-Many of the games published between 1995 and 2005 follow the GameSpy protocol\cite{gs0} and communicate heartbeats over the user datagram protocol (UDP). Sending data over UDP is fast at the risk of losing packets, corrupted packets or the information arriving out of order. Heartbeats contain only little quantities of information and are sent every few minutes, which minimises the risk and effect of data not arriving properly.
+\section{Formatting of data}
+Many of the games published between 1995 and 2005 follow the GameSpy protocol\cite{gs0} and communicate heartbeats over the user datagram protocol (UDP). Sending data over UDP is fast at the risk of losing packets, corrupted packets or the information arriving out of order. Heartbeats contain only little quantities of information and are sent every few minutes, which minimises the chance and effect that data does not arrive properly.
 
 \lstinputlisting[caption={Example of the GameSpy protocol message formatting.}, stepnumber=1, label={ls:gs0prot}]{lst/gs0protocol.txt}
 
-The GameSpy protocol formats the messages through a backslash. In example \ref{ls:gs0prot}, the first line specifies the general format where there is a keyword, followed by a value, both prefixed by a backslash. A simple heartbeat can be represented by the second line of the example: the {\tt heartbeat} key indicates that the next value is the network port through which the gameserver can be queried and the {\tt gamename} key indicates that the next value is an acronym or shorthand for the game title. An example of how the secure challenge and response would appear is seen at lines 3 and 4.
+The GameSpy protocol formats the messages through backslashes. The general definition and examples of these messages are seen in example \ref{ls:gs0prot}, where the first line specifies the general format. The first word is a keyword, followed by a value, both prefixed by a backslash. Multiple keys and values can be appended to contain multiple game properties in a single message. A simple heartbeat is represented on line 2 in the example: the {\tt heartbeat} key indicates that the next value is the network port through which the gameserver can be queried and the {\tt gamename} key indicates that the following value is an acronym or shorthand for the game title. An example of how the secure challenge and response would appear is seen at lines 3 and 4.
 
 The minimum requirement for a heartbeat is an empty UDP packet. This conveys the IP-address of the gameserver. A masterserver specifically developed to support this single game title can automatically generate the default network port and game title. However, this means that the gameserver can not be serviced on another network port and that the masterserver is limited to serving a client list \emph{only} for this specific game title. 
 
-In order to support different network ports, a heartbeat must contain a network port (as seen in example \ref{ls:gs0prot}, line 0). A masterserver that supports multiple game titles also requires an additional key {\tt gamename}. The gamename is, as mentioned before, a unique identifier for the game title and allows the masterserver to identify which game is being serviced and authenticated\footnote{The game title and \emph{gamename} both refer to the original publications from game developers. As per the protocol, we use the word ``gamename'' to refer to these titles from now on. This term returns in chapter \ref{chap:serverlist} and \ref{chap:status}}.
+In order to support different network ports, a heartbeat must contain a network port (as seen in example \ref{ls:gs0prot}, line 0). A masterserver that supports multiple game titles also requires an additional key {\tt gamename}. The gamename is, as mentioned before, a unique identifier for the game title and allows the masterserver to identify which game is being serviced and authenticated\footnote{The game title and \emph{gamename} both refer to the original publications from game developers. As per the protocol, we use the word ``gamename'' to refer to these titles from now on. This term returns in chapter \ref{chap:serverlist} and \ref{chap:status}.}.
 
 Additional information is often incorporated in the heartbeat as well. Some developers allow the indication of a new session through the {\tt statechanged} keyword, that could be used to indicate to the masterserver that a new session or map has been started. An overview of the protocol is added in appendix \ref{app:protref}.
 
 \section{Practical execution}
-In the past fifteen years, we have seen many different ways of formatting a heartbeat. It is worth noting that many game developers deviate from the specified protocol. Some games like \emph{Vietcong}, published by \emph{Gathering of Developers} in 2003, do not specify a {\tt gamename} in their heartbeat, which does not make it possible to support the game on a masterserver for multiple gamenames. 
+In the past fifteen years, we have seen many different ways of formatting a heartbeat. It is worth noting that many game developers deviate from the specified protocol. Some games like \emph{Vietcong}, published by \emph{Gathering of Developers} in 2003, do not specify a gamename in their heartbeat, which does not make it possible to support the game on a masterserver for multiple gamenames. 
 
-Another game, \emph{Jetfighter IV: Fortress America} published by \emph{TalonSoft} in 2000, was originally developed with a single masterserver in mind, but did not follow protocol. The gameserver specifies the gamename \emph{jetfighter4} whereas the client specifies the gamename \emph{Jet Fighter IV} for the same game.
+Another game, \emph{Jetfighter IV: Fortress America} published by \emph{TalonSoft} in 2000, was originally developed with a single masterserver in mind, but did not follow protocol. The gameserver specifies the gamename {\tt jetfighter4} whereas the client specifies the gamename {\tt Jet Fighter IV} for the same game.
 
 These inconsistencies and/or deviations from the original protocol introduce unexpected obstacles in the development process of a replacement masterserver.
diff --git a/src/body/serverlist.tex b/src/body/serverlist.tex
index d7c0a64..5b17f4c 100755
--- a/src/body/serverlist.tex
+++ b/src/body/serverlist.tex
@@ -3,9 +3,9 @@
 
 introduction how game clients (``players'') get their list of servers.
 \begin{figure}[h]
-  \centering
-  \includegraphics[width=\textwidth]{img/overview-cms}
-  \caption{Focus on interaction between client and masterserver }\label{fig:overviewcms}
+\centering
+\input{tikz/overview-cms}
+\caption{Focus on interaction between client and masterserver }\label{fig:overviewcms}
 \end{figure}
 
 interaction, secure/validate, requests, TCP
@@ -14,7 +14,8 @@ procedure.
 
 
 \begin{figure}[H]
-  \centering
-  \includegraphics[width=\textwidth]{img/client-exchange}
-  \caption{Interaction between client and masterserver over time.}\label{fig:client}
+\centering
+\input{tikz/client-exchange}
+\caption{TCP interaction between the masterserver (left) and game client (right) over time.}
+\label{fig:client}
 \end{figure}
diff --git a/src/body/status.tex b/src/body/status.tex
index be0f264..133cb05 100755
--- a/src/body/status.tex
+++ b/src/body/status.tex
@@ -4,14 +4,15 @@
 client-gameserver interaction. status, info, rules, relevant information, what purpose does it serve, etc\cite{oldunreal1}.
 
 \begin{figure}[h]
-  \centering
-  \includegraphics[width=\textwidth]{img/overview-cgs}
-  \caption{Focus on interaction between client and gameserver}\label{fig:overviewcgs}
+\centering
+\input{tikz/overview-cgs}
+\caption{Focus on interaction between client and gameserver}\label{fig:overviewcgs}
 \end{figure}
 
 \begin{figure}[H]
-  \centering
-  \includegraphics[width=\textwidth]{img/status-exchange}
-  \caption{Interaction between client and gameserver over time.}\label{fig:status}
+\centering
+\input{tikz/status-exchange}
+\caption{UDP interaction between the game client (left) and gameserver (right) over time.}
+\label{fig:status}
 \end{figure}