From 51f9c4adf8a605bd955bfc4c2c09e7ff99808a0f Mon Sep 17 00:00:00 2001
From: Darkelarious <darkelarious@333networks.com>
Date: Sun, 20 Dec 2020 19:42:29 +0000
Subject: initial draft commit

---
 src/background.tex | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)
 create mode 100755 src/background.tex

(limited to 'src/background.tex')

diff --git a/src/background.tex b/src/background.tex
new file mode 100755
index 0000000..5121190
--- /dev/null
+++ b/src/background.tex
@@ -0,0 +1,26 @@
+\chapter{Background}
+\label{chap:bg}
+
+In this chapter we introduce the concept of a masterserver and describe why legacy games depend on 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. 
+
+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).
+
+\begin{figure}[h]
+  \centering
+  \includegraphics[width=\textwidth]{img/general-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.
+
+
+\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.\\
+
+There are multiple methods to send information over the internet between peers. The two most important methods are \emph{UDP} and \emph{TCP} communication. Imagine that there is a speaker in front of a large audience. In order to get to know the audience, the speaker could ask everyone to shout their names. Everyone would shout their names one by one to the speaker and hope that the speaker would hear them properly. The \emph{user datagram protocol} (UDP) is similar to this situation: a gameserver sends a heartbeat to the masterserver, but there is no guarantee that information is correctly received or in the correct order. Another method would be for the speaker to ask the audience to walk up to him one by one, shake hands and introduce themselves before sitting down again. The \emph{Transfer Control Protocol}  handles information in the same way: a client connects with the masterserver, identifies itself and retrieves the serverlist. As one could imagine, the information is conveyed correctly, but at the expense of a much larger duration of the interaction. The choice for either of these protocols in the game interactions is defined by the circumstances: some interactions require speed rather than precision, some interactions require precision over speed.
-- 
cgit v1.2.3

