From 96c831caf332c69752c028f23fb497ff4685c8f8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= Date: Thu, 28 Apr 2011 13:11:34 +0200 Subject: [PATCH] Added some text concerning the modular structure of the GGS --- report.lyx | 292 ++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 291 insertions(+), 1 deletion(-) diff --git a/report.lyx b/report.lyx index c86a2da..09423d1 100644 --- a/report.lyx +++ b/report.lyx @@ -3062,6 +3062,24 @@ reference "sec:The-modular-structure" after spawning is integrated in to the GGS by the coordinator process. \end_layout +\begin_layout Section +The usage of Erlang in the GGS +\end_layout + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Here we can have a more in-depth look at why Erlang was used, and outline + the characteristics of EWrlang that we make use of in the GGS. +\end_layout + +\end_inset + + +\end_layout + \begin_layout Section The modular structure of the GGS prototype \begin_inset CommandInset label @@ -3071,22 +3089,287 @@ name "sec:The-modular-structure" \end_inset +\end_layout + +\begin_layout Standard +The separation of concerns, and principle of single responsibility +\begin_inset Foot +status collapsed + +\begin_layout Plain Layout +More information on the SRP is available at: +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Insert adress! +\end_layout + +\end_inset + + +\end_layout + +\end_inset + + are widely respected as good practices in the world of software engineering + and development. + By dividing the GGS up into modules each part of the GGS can be modified + without damaging the rest of the system. +\end_layout + +\begin_layout Standard +The responsibility and concern of each module comes from the responsibility + and concern of the real-world entity the model represents. + The modelling of the GGS after a real world system was discussed in chapter + +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Theory" + +\end_inset + +. +\end_layout + +\begin_layout Standard +In the text below the word module refers to the actual code of the discussed + feature, while the word process is used when referring to a running instance + of the code. + Those familiar to object oriented programming may be helped by thinking + in the lines of classes and objects. +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Am I right here? +\end_layout + +\end_inset + + \end_layout \begin_layout Subsection The dispatcher module \end_layout +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Plain Layout +The discussion of the modules is divided into the following parts: +\end_layout + +\begin_layout Itemize +What does the module do? +\end_layout + +\begin_layout Itemize +What happens when the module fails? +\end_layout + +\begin_layout Itemize +How does the module correspond to the real-world scenario of the chess club? +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +The dispatcher module is the first module to have contact with a player. + When a player connects to the GGS, it is first greeted by the dispatcher + module, which sets up an accepting socket for each player. + +\begin_inset Note Note +status collapsed + +\begin_layout Plain Layout +Is this the proper way to day the dispatcher greets connecting players? +\end_layout + +\end_inset + + The dispatcher is the module which handles the interfacing to the operating + system when working with sockets. + Operating system limits concering the number of open files, or number of + open sockets are handled here. + The operating system limits can impose problems on the GGS, this is discussed + more in detail in chapter +\begin_inset CommandInset ref +LatexCommand vref +reference "cha:Problems-of-implementation" + +\end_inset + +. +\end_layout + +\begin_layout Standard +Should the dispatcher module fail to function, no new connections to the + GGS can be made. + In the event of a crash in the dispatcher module, a supervisor process + immediately restarts the dispatcher. + There exists a window of time between the crashing of the dispatcher and + the restarting of the dispatcher, this window is very short, and only during + this window is the GGS unable to process new connection requests. + Due to the modular structure of the GGS, the rest of the system is not + harmed by the dispatcher process not functioning. + The process does not contain a state, therefore a simple restart of the + process is sufficient in restoring the GGS to a pristine state after a + dispatcher crash +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Well.. + In theory.. +\end_layout + +\end_inset + +. +\end_layout + +\begin_layout Standard +Returning to scenario of the chess club, the dispatcher module is the doorman + of the club. + When a player enters the chess club, the player is greeted by the doorman, + letting the player in to the club. + The actual letting in to the club is in the GGS represented by the creation + of a player process discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-player-module" + +\end_inset + +. + The newly created player process is handed, and granted rights to, the + socket of the newly connected player. +\end_layout + \begin_layout Subsection The player module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-player-module" + +\end_inset + + +\end_layout + +\begin_layout Standard +The player module is responsible for representing a player in the system. + Each connected player has its own player process. + The player process has access to the connection of the player it represents, + and can communicate with this player. + In order to communicate with a player, the data to and from the player + object must pass through a protocol parser module, discussed in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-protocol-parser" + +\end_inset + +. + Raw communication, witout passing the data through a protocol parser is + in theory possible, but is not useful. +\end_layout + +\begin_layout Standard +In the creation of a player process, the coordinator process, discussed + in +\begin_inset CommandInset ref +LatexCommand vref +reference "sub:The-coordinator-module" + +\end_inset + +, is notified by the newly connected process. +\end_layout + +\begin_layout Standard +In the event of a crash in a player process, several things happen. + +\end_layout + +\begin_layout Enumerate +The player process, which is the only process with a reference to the socket + leading to the remote client software, passes this reference of the socket + to the coordinator process temporarily. +\end_layout + +\begin_layout Enumerate +The player process exits. +\end_layout + +\begin_layout Enumerate +The coordinator spawns a new player process, with the same socket reference + as the old player process had. +\end_layout + +\begin_layout Enumerate +The player process resumes operation, immediately starting a new protocol + parser process, and begind receiving and sending network messaged again. +\end_layout + +\begin_layout Standard +The window of time between the crash of the player process and the starting + of a new player process is, as with the dispatcher, very short. + Since the connection changes owners for a short period of time, but is + never dropped, the implications of a crash are only noticed, at worst, + as choppy gameplay for the client. + Note however that this crash recovery scheme is not implemented in the + GGS prototype. + +\begin_inset Note Note +status open + +\begin_layout Plain Layout +Can we do this..? Seems a bit sneaky. +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Moving back to the real world example, the player process represent an actual + person in the chess club. + When a person sits down at a table in the chess club, the person does so + by requesting a seat from some coordinating person, and is then seated + by the same coordinator. + Once seated, the player may make moves on the table he or she is seated + by, this corresponds clearly to how the GGS is structured, as can be seen + in the following sections. \end_layout \begin_layout Subsection The protocol parser module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-protocol-parser" + +\end_inset + + \end_layout \begin_layout Subsection The coordinator module +\begin_inset CommandInset label +LatexCommand label +name "sub:The-coordinator-module" + +\end_inset + + \end_layout \begin_layout Subsection @@ -3356,7 +3639,14 @@ User interface \end_layout \begin_layout Chapter -Problems of implementation +Problems of implementation +\begin_inset CommandInset label +LatexCommand label +name "cha:Problems-of-implementation" + +\end_inset + + \end_layout \begin_layout Section