jeena/GGS-report
1
0
Fork 0
Code Issues Pull requests Projects Packages Wiki Activity Actions

Revisited 3.3.1, 3.3.2 and 3.3.3

Browse source
This commit is contained in:
Niklas Landin 2011-05-12 20:48:22 +02:00
parent 3584c8fd8c
commit 9a1961e1d9
1 changed files with 33 additions and 34 deletions
Download patch file Download diff file Expand all files Collapse all files

67
report.lyx
View file

@ -4115,8 +4115,8 @@ Short introduction to the Erlang syntax
\end_layout \end_layout
\begin_layout Standard \begin_layout Standard
In order to understand examples in this thesis, a small subset of Erlang To understand the examples in this thesis, a small subset of Erlang must
must be understood. be understood.
In this section, the very syntactic basics of Erlang are given. In this section, the very syntactic basics of Erlang are given.
\end_layout \end_layout
@ -4333,7 +4333,7 @@ name "sec:The-modular-structure"
\end_layout \end_layout
\begin_layout Standard \begin_layout Standard
The separation of concerns, and principle of single responsibility The separation of concerns and principle of single responsibility
\begin_inset Foot \begin_inset Foot
status open status open
@ -4352,8 +4352,8 @@ target "http://www.objectmentor.com/resources/articles/srp.pdf"
are widely respected as good practices in the world of software engineering are widely respected as good practices in the world of software engineering
and development. and development.
By dividing the GGS up into modules each part of the GGS can be modified By dividing the GGS into modules each part of the GGS can be modified without
without damaging the rest of the system. damaging the rest of the system.
\end_layout \end_layout
\begin_layout Standard \begin_layout Standard
@ -4407,7 +4407,7 @@ The dispatcher module
\begin_layout Standard \begin_layout Standard
\begin_inset Note Note \begin_inset Note Note
status open status collapsed
\begin_layout Plain Layout \begin_layout Plain Layout
The discussion of the modules is divided into the following parts: The discussion of the modules is divided into the following parts:
@ -4448,7 +4448,7 @@ Is this the proper way to day the dispatcher greets connecting players?
system when working with sockets. system when working with sockets.
Operating system limits concerning the number of open files, or number Operating system limits concerning the number of open files, or number
of open sockets are handled here. of open sockets are handled here.
The operating system limits can impose problems on the GGS, this is discussed The operating system limits can impose problems in the GGS, this is discussed
more in detail in chapter more in detail in chapter
\begin_inset CommandInset ref \begin_inset CommandInset ref
LatexCommand vref LatexCommand vref
@ -4460,7 +4460,7 @@ reference "cha:Problems-of-implementation"
\end_layout \end_layout
\begin_layout Standard \begin_layout Standard
Should the dispatcher module fail to function, no new connections to the Should the dispatcher module fails to function, no new connections to the
GGS can be made. GGS can be made.
In the event of a crash in the dispatcher module, a supervisor process In the event of a crash in the dispatcher module, a supervisor process
immediately restarts the dispatcher. immediately restarts the dispatcher.
@ -4486,8 +4486,8 @@ Well..
\end_layout \end_layout
\begin_layout Standard \begin_layout Standard
Returning to scenario of the chess club, the dispatcher module is the doorman Returning to the scenario of the chess club, the dispatcher module is the
of the club. doorman of the club.
When a player enters the chess club, the player is greeted by the doorman, When a player enters the chess club, the player is greeted by the doorman,
letting the player in to the club. letting the player in to the club.
The actual letting in to the club is in the GGS represented by the creation The actual letting in to the club is in the GGS represented by the creation
@ -4499,8 +4499,8 @@ reference "sub:The-player-module"
\end_inset \end_inset
. .
The newly created player process is handed, and granted rights to, the The newly created player process is handed and granted rights to, the socket
socket of the newly connected player. of the newly connected player.
\end_layout \end_layout
\begin_layout Subsection \begin_layout Subsection
@ -4519,8 +4519,8 @@ The player module is responsible for representing a player in the system.
Each connected player has its own player process. Each connected player has its own player process.
The player process has access to the connection of the player it represents, The player process has access to the connection of the player it represents,
and can communicate with this player. and can communicate with this player.
In order to communicate with a player, the data to and from the player To communicate with a player, the data to and from the player object must
object must pass through a protocol parser module, discussed in pass through a protocol parser module, discussed in
\begin_inset CommandInset ref \begin_inset CommandInset ref
LatexCommand vref LatexCommand vref
reference "sub:The-protocol-parser" reference "sub:The-protocol-parser"
@ -4529,7 +4529,7 @@ reference "sub:The-protocol-parser"
. .
Raw communication, without passing the data through a protocol parser is Raw communication, without passing the data through a protocol parser is
in theory possible, but is not useful. in theory possible but it is not useful.
\end_layout \end_layout
\begin_layout Standard \begin_layout Standard
@ -4572,9 +4572,9 @@ The player process resumes operation, immediately starting a new protocol
\begin_layout Standard \begin_layout Standard
The window of time between the crash of the player process and the starting 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. 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 Since the connection changes owners for a short period of time but is never
never dropped, the implications of a crash are only noticed, at worst, dropped, the implications of a crash is only noticed, at worst, as choppy
as choppy gameplay for the client. gameplay for the client.
Note however that this crash recovery scheme is not implemented in the Note however that this crash recovery scheme is not implemented in the
GGS prototype. GGS prototype.
@ -4591,8 +4591,8 @@ Can we do this..? Seems a bit sneaky.
\end_layout \end_layout
\begin_layout Standard \begin_layout Standard
Moving back to the real world example, the player process represent an actual Moving back to the real world example, the player process represents an
person in the chess club. actual person in the chess club.
When a person sits down at a table in the chess club, the person does so 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 requesting a seat from some coordinating person, and is then seated
by the same coordinator. by the same coordinator.
@ -4615,16 +4615,15 @@ name "sub:The-protocol-parser"
\begin_layout Standard \begin_layout Standard
The protocol parser is an easily interchangeable module in the GGS, handling The protocol parser is an easily interchangeable module in the GGS, handling
the client-to-server, and server-to-client protocol parsing. the client-to-server, and server-to-client protocol parsing.
In the GGS prototype, there is only one protocol supported, namely the In the GGS prototype, there is only one protocol supported, the
\emph on \emph on
GGS Protocol GGS Protocol
\emph default \emph default
. .
The role of the protocol parser is to translate the meaning of packets The role of the protocol parser is to translate the meaning of packets
sent using the protocol in use to internal messages of the GGS system. sent, using the protocol in use, to internal messages of the GGS system.
The GGS protocol, discussed below is used as a sample protocol in order The GGS protocol, discussed below is used as a sample protocol to explain
to explain how protocol parsers can be built for the GGS. how protocol parsers can be built for the GGS.
\end_layout \end_layout
\begin_layout Subsubsection \begin_layout Subsubsection
@ -4642,16 +4641,16 @@ name "sub:The-structure-of"
The GGS protocol is modeled after the HTTP protocol. The GGS protocol is modeled after the HTTP protocol.
The main reason for this is the familiarity many developers already have The main reason for this is the familiarity many developers already have
with HTTP due to its presence in internet software. with HTTP due to its presence in internet software.
Each GGS protocol packet contains a headers section. Each GGS protocol packet contains a header section.
The headers section is followed by a data section. The header section is followed by a data section.
In the headers section, parameters concerning the packet is placed. In the header section, parameters concerning the packet is placed.
In the data section, the actual data payload of the packet is placed. In the data section, the actual data payload of the packet is placed.
\end_layout \end_layout
\begin_layout Standard \begin_layout Standard
There is no requirement of any specific order of the parameters in the headers There is no requirement of any specific order of the parameters in the header
section, however the data section must always follow directly after the section, however the data section must always follow directly after the
headers section. header section.
\end_layout \end_layout
\begin_layout Standard \begin_layout Standard
@ -4665,10 +4664,10 @@ In the example below, line 1 contains a Game-Command parameter.
Line 2 specifies a game token. Line 2 specifies a game token.
This is a UUID which is generated for each client upon authentication with This is a UUID which is generated for each client upon authentication with
the GGS. the GGS.
The GGS uses this token in case a client is disconnected and the new connection The GGS uses this token if a client is disconnected and the new connection
created when the client reconnects must be re-paired with the player object created when the client reconnects must be re-paired with the player object
inside the GGS. inside the GGS.
The UUID is also used as a unique ID within GDL VMs. The UUID is also used as an unique ID within GDL VMs.
\end_layout \end_layout
\begin_layout Standard \begin_layout Standard
@ -4683,14 +4682,14 @@ Line 3 specifies the content type of the payload of this particular packet.
\begin_layout Standard \begin_layout Standard
Line 4 specifies the content length of the payload following immediately Line 4 specifies the content length of the payload following immediately
after the headers section. after the header section.
\end_layout \end_layout
\begin_layout Standard \begin_layout Standard
The parser of the GGS protocol implemented in the GGS prototype is designed The parser of the GGS protocol implemented in the GGS prototype is designed
as a finite state machine using the gen_fsm behavior. as a finite state machine using the gen_fsm behavior.
When a full message has been parsed by the parser, the message is converted When a full message has been parsed by the parser, the message is converted
into the internal structure of the GGS messages, and sent in to the system into the internal structure of the GGS messages and sent in to the system
from the protocol parser using message passing. from the protocol parser using message passing.
\end_layout \end_layout