Merge branch 'master' of github.com:jeena/GGS-report
This commit is contained in:
commit
26e1274fd5
2 changed files with 399 additions and 618 deletions
98
report.lyx
98
report.lyx
|
@ -4375,7 +4375,20 @@ 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 up into modules each part of the GGS can be modified
|
||||||
without damaging the rest of the system.
|
without damaging, or requiring changes in the rest of the system.
|
||||||
|
Due to the hot code updates featured in Erlang, it is theoretically possible
|
||||||
|
to update parts of the GGS while the system is running, this has however
|
||||||
|
not been implemented in the prototype.
|
||||||
|
The modular composition of the GGS prototype should make a transition to
|
||||||
|
a folly hot code swappable system relatively easy.
|
||||||
|
Hot code replacements are discussed in more detail in section
|
||||||
|
\begin_inset CommandInset ref
|
||||||
|
LatexCommand ref
|
||||||
|
reference "sub:Hot-code-replacement"
|
||||||
|
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
.
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
\begin_layout Standard
|
||||||
|
@ -4393,7 +4406,8 @@ reference "cha:Theory"
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
\begin_layout Standard
|
||||||
In the text below the word module refers to the actual code of the discussed
|
In the text below the different modules of the GGS are presented.
|
||||||
|
In the text the word module refers to the actual code of the discussed
|
||||||
feature, while the word process is used when referring to a running instance
|
feature, while the word process is used when referring to a running instance
|
||||||
of the code.
|
of the code.
|
||||||
\begin_inset ERT
|
\begin_inset ERT
|
||||||
|
@ -4427,45 +4441,10 @@ textbf{Object Oriented Programming}}{A programming paradigm focusing on
|
||||||
The dispatcher module
|
The dispatcher module
|
||||||
\end_layout
|
\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
|
\begin_layout Standard
|
||||||
The dispatcher module is the first module to have contact with a player.
|
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
|
When a player connects to the GGS, the player is first greeted by the dispatche
|
||||||
module, which sets up an accepting socket for each player.
|
r 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
|
The dispatcher is the module which handles the interfacing to the operating
|
||||||
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
|
||||||
|
@ -4474,7 +4453,7 @@ Is this the proper way to day the dispatcher greets connecting players?
|
||||||
more in detail in chapter
|
more in detail in chapter
|
||||||
\begin_inset CommandInset ref
|
\begin_inset CommandInset ref
|
||||||
LatexCommand vref
|
LatexCommand vref
|
||||||
reference "cha:Problems-of-implementation"
|
reference "sec:Operating-system-limitations"
|
||||||
|
|
||||||
\end_inset
|
\end_inset
|
||||||
|
|
||||||
|
@ -4491,9 +4470,9 @@ Should the dispatcher module fail to function, no new connections to the
|
||||||
this window is the GGS unable to process new connection requests.
|
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
|
Due to the modular structure of the GGS, the rest of the system is not
|
||||||
harmed by the dispatcher process not functioning.
|
harmed by the dispatcher process not functioning.
|
||||||
The process does not contain a state, therefore a simple restart of the
|
The dispatcher process does not contain a state, therefore a simple restart
|
||||||
process is sufficient in restoring the GGS to a pristine state after a
|
of the process is sufficient in restoring the GGS to a pristine state after
|
||||||
dispatcher crash
|
a dispatcher crash
|
||||||
\begin_inset Note Note
|
\begin_inset Note Note
|
||||||
status open
|
status open
|
||||||
|
|
||||||
|
@ -4513,7 +4492,7 @@ Returning to scenario of the chess club, the dispatcher module is the doorman
|
||||||
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
|
||||||
of a player process discussed in
|
of a player process discussed in section
|
||||||
\begin_inset CommandInset ref
|
\begin_inset CommandInset ref
|
||||||
LatexCommand vref
|
LatexCommand vref
|
||||||
reference "sub:The-player-module"
|
reference "sub:The-player-module"
|
||||||
|
@ -6196,6 +6175,13 @@ To the left normal execution is pictured; the server state is backed up.
|
||||||
|
|
||||||
\begin_layout Subsection
|
\begin_layout Subsection
|
||||||
Hot code replacement
|
Hot code replacement
|
||||||
|
\begin_inset CommandInset label
|
||||||
|
LatexCommand label
|
||||||
|
name "sub:Hot-code-replacement"
|
||||||
|
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
\begin_layout Standard
|
||||||
|
@ -7282,6 +7268,30 @@ The use of Thrift, Google protocol buffers - which is a different approach
|
||||||
the writing of this thesis.
|
the writing of this thesis.
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Section
|
||||||
|
Operating system limitations
|
||||||
|
\begin_inset CommandInset label
|
||||||
|
LatexCommand label
|
||||||
|
name "sec:Operating-system-limitations"
|
||||||
|
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
\begin_inset Note Note
|
||||||
|
status open
|
||||||
|
|
||||||
|
\begin_layout Plain Layout
|
||||||
|
Describe file and socket limitations
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
|
||||||
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Chapter
|
\begin_layout Chapter
|
||||||
Results and discussion
|
Results and discussion
|
||||||
\begin_inset CommandInset label
|
\begin_inset CommandInset label
|
||||||
|
|
919
report.lyx.orig
919
report.lyx.orig
File diff suppressed because it is too large
Load diff
Loading…
Add table
Add a link
Reference in a new issue