added server browser to background, write serverlist chapter

13 files changed, 115 insertions, 22 deletions

diff --git a/pdf/MasterServerDocs-v0.4.pdf b/pdf/MasterServerDocs-v0.4.pdf
deleted file mode 100644
index 30594b7..0000000
--- a/pdf/MasterServerDocs-v0.4.pdf
+++ /dev/null
diff --git a/pdf/MasterServerDocs-v0.5.pdf b/pdf/MasterServerDocs-v0.5.pdf
new file mode 100644
index 0000000..5e16a82
--- /dev/null
+++ b/pdf/MasterServerDocs-v0.5.pdf
diff --git a/src/body/background.tex b/src/body/background.tex
index 88bc72f..ba1cb5f 100755
--- a/src/body/background.tex
+++ b/src/body/background.tex
@@ -3,13 +3,35 @@
 
 In this chapter we introduce the concept of a masterserver and describe why legacy games depend on it.
 
+\section{Finding a game}
+The primary purpose that is to be accomplished, is to serve the paying customer, a choice in what game server he or she wants to join. Still as a business, the publisher's intended result is that a paying customer gets to play a game with other paying customers, who all involve others to buy the title and play too. The business model for this concept has changed significantly over the past two decades, but the focus is on the experience of the player.
+
+Many games provide the option to play with or against other players. Usually there is a menu item called ``Multiplayer'' or ``Online Game'', that presents the player with a list of game servers that are currently online. A few clicks later, the player can shoot other players or conquer an evil enemy together. The focus in this document is in describing how the mechanics of acquiring this list work. To illustrate various functions and events, we use screenshots and examples from the game title ``Unreal Tournament'', as many of the games of that particular era are either based on or heavily influenced by this title.
+
+\begin{figure}[h]
+\centering
+\includegraphics[width=0.7\textwidth]{./img/ubrowser}
+\caption{The Unreal Tournament server browser with several online gameservers.}
+\label{fig:ubrowser}
+\end{figure}
+
+When the player opens the multiplayer functionality, a list of online servers opens. We refer to this as the \emph{server browser}. Its main purpose is to provide the player with the available game servers and their individual properties, such as number of active players and current level or map. In figure \ref{fig:ubrowser} we see an example of such a server browser where we can identify three significant areas with information.
+
+In the area on top, we see a list of online game servers with the name of the server, network response time (ping), name of the map and number of players. With this information, the player can decide to join their favourite server by name or just join any of the populated servers to play. The second segment displays a list of players and detailed information per player, like his/her score, ping, model (body shape) and textures (looks). With this list, the player can assess whether their friends are already playing and waiting for them, browse different servers and find anyone with whom they have played before or decide to join new people with the same interest in the game.
+
+The last segment displays detailed server information, like the game type and playing style, team settings, server administrator details and a prominent server level screenshot. This segment provides a lot of detailed information that may be relevant to the more experienced players or people who are looking for a specific combination of mutators (game modifications). The combination of the information presented in these three segments drive the player to select a server of their choosing and join it.
+
 \section{Online games}
-The concept of online gaming is a bit vague. Everybody plays from their own computer and it is not always clear what interaction occurs at which side of the internet connection. In order to illustrate the different kinds of networking, we compare online games with their analogue variants: chess and poker. With chess, the two players could be playing on the same board or could be a large distance apart and communicate their moves by telephone: player one states he moves his rook from coordinates A3 to E3 and player two could respond by telling to move his pawn from C7 to C6. Both players are aware of the moves on the board and are playing the same game. With poker, on the other hand, it will be a lot more difficult to keep players appraised of the same game information without telling each other which cards they are holding. This requires of an independent party, the dealer. This dealer would communicate with each player individually which cards (s)he received from the deck and whether this person raises the pot. These analogue representations of multiplayer games can be described as peer-to-peer (chess) and server-client (poker) approaches. With a peer-to-peer game, players are directly connected to each other and are both aware of all aspects in the game. With a server-client game, each player has their unique response that the others are unaware of and only the server is capable of exchanging information between the others. 
+The concept of online gaming and communication of this information over the internet may be a bit vague at this point. Everybody plays from their own computer and it is not always clear what interaction occurs at which side of the internet connection. In order to illustrate the different kinds of networking, we compare online games with their analogue variants: chess and poker. With chess, the two players could be playing on the same board or could be a large distance apart and communicate their moves by telephone: player one states he moves his rook from coordinates A3 to E3 and player two could respond by telling to move his pawn from C7 to C6. Both players are aware of the moves on the board and are playing the same game. 
+
+With poker, it will be a lot more difficult to keep players appraised of the same game information without telling each other which cards they are holding. This requires of an independent party, the dealer. This dealer would communicate with each player individually which cards (s)he received from the deck and whether this person raises the pot. These analogue representations of multiplayer games can be described as peer-to-peer (chess) and server-client (poker) approaches. With a peer-to-peer game, players are directly connected to each other and are both aware of all aspects in the game. With a server-client game, each player has their unique response that the others are unaware of and only the server is capable of exchanging information between the others. 
 
 From the poker analogy, we continue to multiple games. In the local bar, several groups of people are playing different rounds of poker on each table in different room. Every room has its own table, dealer and participants, independent from all other rooms and tables. In order to participate in a round of poker, you therefore only need to remember the address of the bar in order to gain access to all of the poker tables. Once you enter the bar, you ask the barkeep in which rooms the poker tables are located. The barkeep will tell you which rooms there are and you can look around the rooms to decide which table you want to join. The barkeep represents the masterserver, who keeps a list of all servers (rooms or poker tables) that are available. You do not need to maintain a record of the ever changing room/table list, instead one can just access the information directly from the barkeep.
 
 \section{Game interactions}
-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).
+To illustrate the more technical interactions between dealers, barkeep and player, we create three roles: {\bf gameserver}, {\bf masterserver}\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.} and {\bf client} in figure \ref{fig:totaloverview}. Everybody with an internet connection and a copy of the game could host their own gameserver. 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 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
@@ -19,7 +41,6 @@ To illustrate the more technical interactions between dealers, barkeep and playe
 
 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.
 
-
 \section{Networking}
 In the next chapters we address every interaction between gameserver, masterserver and client, but first we describe what we consider to be some required general knowledge about network communication and protocol. Since there is a variety of literature available for in-depth knowledge, we limit ourselves to the essential information that is necessary to understand the following chapters.\\
 
@@ -30,8 +51,14 @@ The other method would be for the speaker to ask the audience to walk up to him
 \section{Protocols}
 Any form of communication, whether it is on the street, in the shop or digitally between two or more computers, follows a certain communication structure. During any meeting we often shake hands \footnote{This was before the global nCovid-19 pandemic.} and introduce ourselves before getting to business. This is called a \emph{protocol}. A protocol is a set of agreements that all communicating parties follow in order to convey information.
 
-Many of the interactions that we discuss in this document follow the \emph{GameSpy} protocol. This protocol was, as the name suggests, developed by GameSpy Industries\cite{gs0} and contains a series of steps to perform the interactions as described in figure \ref{fig:totaloverview}. The formatting of these interactions are defined in the protocol and described in the next chapter as well.
+Many of the interactions that we discuss in this document follow the \emph{GameSpy} protocol. This protocol was, as the name suggests, developed by GameSpy Industries\cite{gs0} and contains a series of steps to perform the interactions as described in figure \ref{fig:totaloverview}. Many of the games published between 1995 and 2005 follow the GameSpy protocol and communicate in the same manner.
+
+The GameSpy protocol formats the messages or data packets 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 (line 1). Multiple keys and values can be appended to contain multiple game properties in a single message (line 2).
+
+\lstinputlisting[caption={Example of the GameSpy protocol message formatting.}, stepnumber=1, label={ls:gs0prot}]{lst/gs0protocol.txt}
+
+Digital data knows multiple data types, such as integers and floats for numbers, booleans for yes/no situations and strings for text. The GameSpy protocol has the versatility to transport all of these datatypes as plain text. Numbers can be conveyed as they are, either as integer (whole number) or float (decimal number) as seen in line 3. Boolean logic, like yes/no situations or 1/0 parameters are expressed through whole-word ``True'' or ``False'' values in line 4. Text is represented as-is and can contain spaces and special characters, as long as it is an ascii-character and not a backslash (line 5). 
 
-Over the years, there have been iterations and expansions of this protocol, as well as completely new and different protocols by different third parties. The 333networks masterserver that we describe in the following chapters uses the GameSpy protocol as foundation and expands from there where necessary.
+The GameSpy protocol specifies a number of standardised key/value pairs that address the important functions in this infrastructure as we will be discussing in the next chapters. Over the years, there have been iterations and expansions of this protocol, as well as completely new and different protocols by different third parties. The 333networks masterserver that we describe in the following chapters uses the GameSpy protocol as foundation and expands from there where necessary.
 
 
diff --git a/src/body/heartbeat.tex b/src/body/heartbeat.tex
index 00430e3..52efa6a 100755
--- a/src/body/heartbeat.tex
+++ b/src/body/heartbeat.tex
@@ -28,24 +28,24 @@ This exchange is visualised in a diagram in figure \ref{fig:heartbeat} where the
 \section{Secure challenge}
 To authenticate the validity of gameserver, masterserver and client, the GameSpy protocol introduced the \emph{secure}-challenge. In the case of a heartbeat, the masterserver attempts to authenticate the gameserver by sending it a 6-character \emph{secure} word. Both the masterserver and gameserver have a 6-character \emph{cipher} that is associated with the unique game title and perform a series of mathematical operations on the combination of the secure word and cipher. The result is a unique 8-character \emph{validate} word. If the masterserver and gameserver both arrive at the same word, the gameserver validates as legitimate and is added to the list of online gameservers.
 
-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}.
+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 (forward) 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 of data}
+\section{Formatting of heartbeats}
 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}
+\lstinputlisting[caption={Example of the GameSpy protocol message formatting.}, stepnumber=1, label={ls:gs0heart}]{lst/gs0heartbeat.txt}
 
-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.
+A simple heartbeat is represented on line 1 in example \ref{ls:gs0heart}: 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 2 and 3.
 
 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:gs0heart}, line 2). 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 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 {\tt jetfighter4} whereas the client specifies the gamename {\tt 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 and thus 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/introduction.tex b/src/body/introduction.tex
index 153195e..93b1237 100755
--- a/src/body/introduction.tex
+++ b/src/body/introduction.tex
@@ -1,5 +1,5 @@
 \chapter{Introduction}
-\label{introduction}
+\label{chap:intro}
 \pagenumbering{arabic}
 \setcounter{page}{6}
 
diff --git a/src/body/serverlist.tex b/src/body/serverlist.tex
index 5b17f4c..6255b0e 100755
--- a/src/body/serverlist.tex
+++ b/src/body/serverlist.tex
@@ -1,17 +1,34 @@
 \chapter{Serverlist}
 \label{chap:serverlist}
 
-introduction how game clients (``players'') get their list of servers.
+In this chapter, we discuss the interaction between the game client and masterserver to retrieve a list of gameservers.
+
 \begin{figure}[h]
 \centering
 \input{tikz/overview-cms}
-\caption{Focus on interaction between client and masterserver }\label{fig:overviewcms}
+\caption{Focus on interaction between game client and masterserver.}
+\label{fig:overviewcms}
 \end{figure}
 
-interaction, secure/validate, requests, TCP
-\\
-procedure.
+\section{List transfer}
+In the previous chapter, we discussed how heartbeats sent to the masterserver result in a complete list of online gameservers at the side of the masterserver. In this chapter we discuss how the list of gameserver addresses is transferred to the game client as seen in step (2) in figure \ref{fig:overviewcms}. The request is initiated when the user opens the \emph{server browser} in the game environment (further discussed in chapter \ref{chap:status}). The serverlist merely contains a list of IP-addresses and query ports. When the client requests the serverlist from the masterserver, the list of addresses is transmitted.
+
+In contrary to heartbeats, which are sent over UDP, the serverlist is sent over TCP. The integrity of the rather large serverlist is important and must be preserved during the transfer, usually split over multiple packets. To protect the data, GameSpy preferred the slower but more reliable TCP transfer for this part in the process.
+
+
+\section{Procedure}
+As soon as the user requests the serverlist, the client initiates a request to the masterserver by opening a connection to one or more of the configured masterservers. In listing \ref{ls:gs0servlist}, the exchange of the GameSpy protocol is detailed. After a TCP connection is established, the masterserver opens the exchange with a request for the basic client information (gamename, game version) and authentication via the \emph{secure} challenge that was also used by the masterserver to authenticate heartbeats (line 1).
 
+The client returns the basic game information and generated validate keyword in the same packet to the masterserver. As the client and the masterserver both possess the game cipher and secure keyword, as well as the gamename from the masterserver's request for basic client information, both the masterserver and the client can calculate the correct \emph{validate} keyword to complete the authentication (lines 2 and 3).
+\lstinputlisting[caption={Example of the GameSpy protocol message formatting.},
+                 stepnumber=1, 
+                 xleftmargin=1.8cm,
+                 xrightmargin=1.8cm,
+                 label={ls:gs0servlist}
+                ]{lst/gs0serverlist.txt}
+The client then proceeds with requesting the serverlist and the format in which the client would like to receive this information (line 4 or 5). If the client properly authenticated with the secure/validate keyword, the masterserver will start sending the serverlist over multiple packets. This could be a plaintext list, or compressed list as described in the following section (line 6). The masterserver appends the {\tt final} keyword to serverlist, to indicate that the last address has been received. Immediately after sending the last packet, the masterserver closes the TCP connection.
+
+The client will continue to receive data until the {\tt final} keyword has arrived. If due to network disruption the {\tt final} does not arrive, the client will attempt to receive until a timeout occurs. The addresses that are intact are processed for display to the user, missing addresses are ignored. Many games do \emph{not} throw an error or warning when the received list was incomplete, but fail silently. 
 
 \begin{figure}[H]
 \centering
@@ -19,3 +36,36 @@ procedure.
 \caption{TCP interaction between the masterserver (left) and game client (right) over time.}
 \label{fig:client}
 \end{figure}
+
+\section{Compressed serverlist}
+Gameserver addresses are usually expressed as an IP-address and query port with a colon ({\tt :}) as separator in a plaintext string. The length of this string is up to 21 characters, with a 4- or 5-digit query port as seen in the addresses at line 6 in listing \ref{ls:gs0servlist}. To separate multiple addresses, the {\tt ip} keyword was added for every new address in the list, adding another 4 characters to the plaintext address. Every character requires a single byte to transfer. In the time that the GameSpy protocol was drafted, bandwidth was scarce. With more than two thousand servers during its popular period, a serverlist for Unreal Tournament could easily be $50,000$ characters large and take several seconds to transmit on a dial-up connection.
+
+To reduce the size of the data stream, the \emph{compressed} serverlist was provided as alternative. By specifying the {\tt cmp} value for the {\tt list} keyword (line 5), the masterserver would send a compressed serverlist where the gameserver addresses were not sent as plaintext, but as byte values. 
+
+A single byte can hold $2^8$ or 256 values. With the inclusion of the zero, that leads to a value range between 0 and 255, including both values. An IP-address consists of four octets (groups of numbers) with the values 0 to 255, joined by periods. Conveniently, every individual octet can fit inside a single fixed-length byte, despite the lexical length being two (e.g. $99$) or three (e.g. $101$) digits. As we know that every new byte is a new octet, it is no longer necessary to join the octets by periods in their text representation. 
+
+\begin{table}[h]
+\centering
+\begin{tabular}{ |c|c|c|c |c|c|c| c |c|c|c| c |c|c|c| c |c|c|c| c |c|c|c|c|c|c| }
+\hline
+\textbackslash&i&p&\textbackslash&2&5&5&.&2&5&5&.&2&5&5&.&2&5&5&
+:&1&2&\multicolumn{2}{|c|}{5}&5&6\\
+\hline
+\multicolumn{4}{|c|}{} & 
+\multicolumn{3}{|c|}{0xFF}& &
+\multicolumn{3}{|c|}{0xFF}& & 
+\multicolumn{3}{|c|}{0xFF}& & 
+\multicolumn{3}{|c|}{0xFF}& & 
+\multicolumn{2}{|c}{0x31}& &  % dirty fix: no left cell wall to create "half" a cell below the 5
+\multicolumn{3}{|c|}{0x0C}\\
+\hline
+\end{tabular}
+\caption{Data allocation in a gameserver address (every cell represents 1 byte).}
+\label{tab:plaintextip}
+\end{table}
+
+The query port consists of a number larger than 255 and can therefore not be represented with a single byte. The concept of splicing the query port number into two new numbers is difficult to grasp when we consider the decimal counting system. Therefore we make a detour through the hexadecimal counting system: a single hexadecimal digit can hold 16 values, ranging {\tt 0x0-0xF} or 0--15\footnote{to avoid confusion between different counting bases, we use the prefix {\tt 0x} for hexadecimal numbers. This prefix holds no numerical value. The first two digit in the value {\tt 0x1E62} is {\tt 1E} and not {\tt 0x}.}. Two hexadecimal digits can hold the values between 0x00 and 0xFF or 0--255. With the understanding that two hexadecimal digits can be represented exactly in one single byte, we can now express any number larger than 255 in pairs of hexadecimal digits and thus in multiple bytes.
+
+The query port is an \emph{unsigned short integer} and requires 2 bytes to be represented. The query ports 7778 and 12556 can now be represented as {\tt 0x1E62} and {\tt 0x310C}, where the first byte holds the value {\tt 0x1E} and the second byte {\tt 0x62}. In table \ref{tab:plaintextip} we represented the same IP-address as plaintext (top) and hexadecimal values (bottom), where every occupied table cell is a byte. As seen, the bottom row requires significantly less bytes to store the same data.
+
+Earlier we derived that a plaintext gameserver address with {\tt ip} key prefix can occupy up to 25 characters/bytes. With the hexadecimal representation, we compressed the same address to a fixed length of 6 bytes, which means that the same Unreal Tournament serverlist could now be compressed into a $12,000$-byte data string, a reduction of more than two-thirds of the original plaintext data transfer.
diff --git a/src/body/status.tex b/src/body/status.tex
index 133cb05..f68995c 100755
--- a/src/body/status.tex
+++ b/src/body/status.tex
@@ -9,6 +9,8 @@ client-gameserver interaction. status, info, rules, relevant information, what p
 \caption{Focus on interaction between client and gameserver}\label{fig:overviewcgs}
 \end{figure}
 
+focus on transferring the detailed information from the gameserver to the game client and populating the fields in the server browser interface.
+
 \begin{figure}[H]
 \centering
 \input{tikz/status-exchange}
@@ -16,3 +18,4 @@ client-gameserver interaction. status, info, rules, relevant information, what p
 \label{fig:status}
 \end{figure}
 
+discussion of common fields and the information they represent, player information and how using backslashes in hostnames/playernames breaks part of the query.
diff --git a/src/img/ubrowser.jpg b/src/img/ubrowser.jpg
new file mode 100755
index 0000000..3cd77e2
--- /dev/null
+++ b/src/img/ubrowser.jpg
diff --git a/src/layout/contact.tex b/src/layout/contact.tex
index 0099e23..fe29dd9 100755
--- a/src/layout/contact.tex
+++ b/src/layout/contact.tex
@@ -7,7 +7,7 @@
 {\bf Title}             & : & An introduction to the masterserver.\\
 {\bf Subtitle}          & : & Reference for heartbeats, serverlists, status and implementation.\\
 \\
-{\bf Revision}          & : & 0.3\\
+{\bf Revision}          & : & 0.5\\
 {\bf Date}              & : & \today\\
 \\
 {\bf Author}            & : & Darkelarious\\
diff --git a/src/layout/headers.tex b/src/layout/headers.tex
index 88709cb..85cb86a 100755
--- a/src/layout/headers.tex
+++ b/src/layout/headers.tex
@@ -53,9 +53,11 @@
 \renewcommand{\headrulewidth}{0pt}
 \renewcommand{\footrulewidth}{0pt}
 
-%misc
 \hbadness 10000
 
+% do not reset footnote counter
+\counterwithout{footnote}{chapter}
+
 \hypersetup{
   colorlinks=true,
   linkcolor=black,
diff --git a/src/lst/gs0heartbeat.txt b/src/lst/gs0heartbeat.txt
new file mode 100644
index 0000000..488ccf9
--- /dev/null
+++ b/src/lst/gs0heartbeat.txt
@@ -0,0 +1,3 @@
+\heartbeat\7778\gamename\ut
+\secure\wookie\enctype\0
+\validate\2/TYFMRc
diff --git a/src/lst/gs0protocol.txt b/src/lst/gs0protocol.txt
index a7052d9..8258eaa 100644
--- a/src/lst/gs0protocol.txt
+++ b/src/lst/gs0protocol.txt
@@ -1,4 +1,6 @@
 \key\value
-\heartbeat\7778\gamename\ut
-\secure\wookie\enctype\0
-\validate\2/TYFMRc
+\key_1\value_1\key_2\value_2
+\queryid\11.1
+\tournament\False
+\echo\some text
+
diff --git a/src/lst/gs0serverlist.txt b/src/lst/gs0serverlist.txt
new file mode 100644
index 0000000..354f914
--- /dev/null
+++ b/src/lst/gs0serverlist.txt
@@ -0,0 +1,6 @@
+\basic\\secure\wookie\final\
+\gamename\ut\gamever\348\minnetver\348\location\0\queryid\11.1
+\validate\2/TYFMRc\final\\queryid\11.2
+\list\\gamename\ut
+\list\cmp\gamename\serioussam
+\ip\255.255.255.255:7778\ip\255.255.255.255:12556\...\final\