summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRefik Hadzialic2011-10-22 17:59:01 +0200
committerRefik Hadzialic2011-10-22 17:59:01 +0200
commite59c0e5063ddd4a3d833a59da83196c9369089ac (patch)
tree044d6e1e395dafb78beeb9d300e14c23e88d70ad
parentRerport writing (diff)
downloadgsm-selftest-e59c0e5063ddd4a3d833a59da83196c9369089ac.tar.gz
gsm-selftest-e59c0e5063ddd4a3d833a59da83196c9369089ac.tar.xz
gsm-selftest-e59c0e5063ddd4a3d833a59da83196c9369089ac.zip
Report writing
-rw-r--r--notFinishedCode/Report/test.aux4
-rw-r--r--notFinishedCode/Report/test.log14
-rw-r--r--notFinishedCode/Report/test.pdfbin1472608 -> 1473279 bytes
-rw-r--r--notFinishedCode/Report/test.tex9
-rw-r--r--notFinishedCode/Report/test.tex.backup12
-rw-r--r--notFinishedCode/Report/test.tex~14
-rw-r--r--notFinishedCode/Report/test.toc2
7 files changed, 38 insertions, 17 deletions
diff --git a/notFinishedCode/Report/test.aux b/notFinishedCode/Report/test.aux
index ed3b617..746c38b 100644
--- a/notFinishedCode/Report/test.aux
+++ b/notFinishedCode/Report/test.aux
@@ -51,9 +51,9 @@
\@writefile{toc}{\contentsline {section}{\numberline {6}Communication protocol}{17}}
\@writefile{toc}{\contentsline {subsection}{\numberline {6.1}Handler side}{17}}
\@writefile{lof}{\contentsline {figure}{\numberline {14}{\ignorespaces }}{17}}
-\@writefile{lof}{\contentsline {figure}{\numberline {15}{\ignorespaces }}{17}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {6.2}Verification of the protocol}{17}}
+\@writefile{lof}{\contentsline {figure}{\numberline {15}{\ignorespaces }}{18}}
\@writefile{lof}{\contentsline {figure}{\numberline {16}{\ignorespaces }}{18}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.2}Verification of the protocol}{18}}
\citation{sshTunnel}
\@writefile{toc}{\contentsline {section}{\numberline {7}Security and safety of the system}{20}}
\@writefile{toc}{\contentsline {subsection}{\numberline {7.1}Encryption of the communication channels}{20}}
diff --git a/notFinishedCode/Report/test.log b/notFinishedCode/Report/test.log
index 17b764d..fdfbb8e 100644
--- a/notFinishedCode/Report/test.log
+++ b/notFinishedCode/Report/test.log
@@ -1,4 +1,4 @@
-This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2011.9.27) 22 OCT 2011 15:54
+This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2011.9.27) 22 OCT 2011 17:57
entering extended mode
%&-line parsing enabled.
**test.tex
@@ -378,25 +378,25 @@ File: protocolCommunicationcControllerReceiver.png Graphic file (type png)
File: protocolCommunicationcControllerCaller.png Graphic file (type png)
<use protocolCommunicationcControllerCaller.png> [17
- <./protocolCommunicationHandler.png (PNG copy)> <./protocolCommunicationcContr
-ollerReceiver.png (PNG copy)>] [18 <./protocolCommunicationcControllerCaller.pn
+ <./protocolCommunicationHandler.png (PNG copy)>] [18 <./protocolCommunicationc
+ControllerReceiver.png (PNG copy)> <./protocolCommunicationcControllerCaller.pn
g (PNG copy)>] [19]
<sshTunnel.png, id=98, 696.6025pt x 152.57pt>
File: sshTunnel.png Graphic file (type png)
<use sshTunnel.png> [20
<./sshTunnel.png (PNG copy)>] [21] [22]
-LaTeX Font Info: Try loading font information for OMS+cmr on input line 517.
+LaTeX Font Info: Try loading font information for OMS+cmr on input line 524.
(/usr/share/texmf-texlive/tex/latex/base/omscmr.fd
File: omscmr.fd 1999/05/25 v2.5h Standard LaTeX font definitions
)
LaTeX Font Info: Font shape `OMS/cmr/m/n' in size <9> not available
-(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 517.
+(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 524.
[23] [24] [25]
LaTeX Font Info: Font shape `OMS/cmr/m/n' in size <10.95> not available
-(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 589.
+(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 596.
<resultsImage.png, id=118, 702.625pt x 431.6125pt>
File: resultsImage.png Graphic file (type png)
@@ -425,7 +425,7 @@ r/fonts/pk/ljfour/jknappen/ec/ecrm1728.600pk></usr/share/texmf-texlive/fonts/ty
pe1/public/amsfonts/cm/cmmi10.pfb></usr/share/texmf-texlive/fonts/type1/public/
amsfonts/cm/cmsy10.pfb></usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm
/cmsy9.pfb>
-Output written on test.pdf (29 pages, 1472608 bytes).
+Output written on test.pdf (29 pages, 1473279 bytes).
PDF statistics:
686 PDF objects out of 1000 (max. 8388607)
0 named destinations out of 1000 (max. 500000)
diff --git a/notFinishedCode/Report/test.pdf b/notFinishedCode/Report/test.pdf
index a2e983b..95dff4e 100644
--- a/notFinishedCode/Report/test.pdf
+++ b/notFinishedCode/Report/test.pdf
Binary files differ
diff --git a/notFinishedCode/Report/test.tex b/notFinishedCode/Report/test.tex
index 38e4a52..dfcc87f 100644
--- a/notFinishedCode/Report/test.tex
+++ b/notFinishedCode/Report/test.tex
@@ -312,9 +312,16 @@ When defining these rules, it is important to define a limited state space for e
response from the other side. Our approch to this problem was to build a simple synchronous protocol, where every expected message is
confirmed or otherwise the connection between two sides is immediatelly terminated. Since designing protocols is a demanding and challenging
topic which requires years of experience and verification, we do not expect that we had developed the best possible and an optimum protocol.
-In the following paragraphs we will try to give you a brief introduction of how our protocol works.
+In the following paragraphs we will try to clarify how our protocol works. Before we start to go into detail how the protocol works,
+it is important to remember that we differentiate two sides, handler and the controller side. The handler side represent the device
+that physically handles the call (e.g. the BeagleBoard) whereas the controller (i.e. the main test software), is the test software
+controlling the handler side and assigning the task to it.
\subsection{Handler side}
+The handler side is always in the waiting mode, by waiting we denote the mode where the socket is already created and it is waiting
+for a connection to be accepted at the defined port. Subsequently, after the connection has been established, it is waiting for a
+message to be received. The first message has to be 13 characters long and include the following content \emph{HELLO HANDLER}.
+Thereupon, after the message has been validated the handler side sends the controller side a response, \emph{HELLO CONTROLLER}.
\begin{figure}[ht!]
\centering
\includegraphics[width=130mm]{protocolCommunicationHandler.png}
diff --git a/notFinishedCode/Report/test.tex.backup b/notFinishedCode/Report/test.tex.backup
index cf2dcca..8cecd2c 100644
--- a/notFinishedCode/Report/test.tex.backup
+++ b/notFinishedCode/Report/test.tex.backup
@@ -308,11 +308,17 @@ We were given an old Pentium 3 computer where we installed Ubuntu Linux. Configu
\section{Communication protocol}
A communication protocol represents a set of well defined rules by whose help two or more computing systems exchange information inbetween.
-When defining these rules, it is important to define a limited state space for every possible event, no matter did we get the appropriate response from the other side.
-Our approch to this problem was build a simple synchronous protocol, where every expected message is confirmed or otherwise the connection between two sides is immediatelly terminated.
-In the following paragraphs we will try t
+When defining these rules, it is important to define a limited state space for every possible event, no matter did we get the appropriate
+response from the other side. Our approch to this problem was to build a simple synchronous protocol, where every expected message is
+confirmed or otherwise the connection between two sides is immediatelly terminated. Since designing protocols is a demanding and challenging
+topic which requires years of experience and verification, we do not expect that we had developed the best possible and an optimum protocol.
+In the following paragraphs we will try to clarify how our protocol works. Before we start to go into detail how the protocol works,
+it is important to remember that we differentiate two sides, handler and the controller side. The handler side represent the device
+that physically handles the call (e.g. the BeagleBoard) whereas the controller (i.e. the main test software), is the test software
+controlling the handler side and assigning the task to it.
\subsection{Handler side}
+The handler side is always in the waiting mode, by waiting we denote the mode where it is waiting for a connection to accept at the defined port.
\begin{figure}[ht!]
\centering
\includegraphics[width=130mm]{protocolCommunicationHandler.png}
diff --git a/notFinishedCode/Report/test.tex~ b/notFinishedCode/Report/test.tex~
index 5748edc..b7364d9 100644
--- a/notFinishedCode/Report/test.tex~
+++ b/notFinishedCode/Report/test.tex~
@@ -308,11 +308,19 @@ We were given an old Pentium 3 computer where we installed Ubuntu Linux. Configu
\section{Communication protocol}
A communication protocol represents a set of well defined rules by whose help two or more computing systems exchange information inbetween.
-When defining these rules, it is important to define a limited state space for every possible event, no matter did we get the appropriate response from the other side.
-Our approch to this problem was to build a simple synchronous protocol, where every expected message is confirmed or otherwise the connection between two sides is immediatelly terminated.
-In the following paragraphs we will try to give you a brief introduction of
+When defining these rules, it is important to define a limited state space for every possible event, no matter did we get the appropriate
+response from the other side. Our approch to this problem was to build a simple synchronous protocol, where every expected message is
+confirmed or otherwise the connection between two sides is immediatelly terminated. Since designing protocols is a demanding and challenging
+topic which requires years of experience and verification, we do not expect that we had developed the best possible and an optimum protocol.
+In the following paragraphs we will try to clarify how our protocol works. Before we start to go into detail how the protocol works,
+it is important to remember that we differentiate two sides, handler and the controller side. The handler side represent the device
+that physically handles the call (e.g. the BeagleBoard) whereas the controller (i.e. the main test software), is the test software
+controlling the handler side and assigning the task to it.
\subsection{Handler side}
+The handler side is always in the waiting mode, by waiting we denote the mode where the socket is already created and it is waiting
+for a connection to be accepted at the defined port. Subsequently, after the connection has been established, it is waiting for a
+message to be received. The first message has to be 13 characters long and include the following content \emph{HELLO HANDLER}.
\begin{figure}[ht!]
\centering
\includegraphics[width=130mm]{protocolCommunicationHandler.png}
diff --git a/notFinishedCode/Report/test.toc b/notFinishedCode/Report/test.toc
index a27dd04..fb9be1e 100644
--- a/notFinishedCode/Report/test.toc
+++ b/notFinishedCode/Report/test.toc
@@ -19,7 +19,7 @@
\contentsline {subsection}{\numberline {5.4}Server}{16}
\contentsline {section}{\numberline {6}Communication protocol}{17}
\contentsline {subsection}{\numberline {6.1}Handler side}{17}
-\contentsline {subsection}{\numberline {6.2}Verification of the protocol}{18}
+\contentsline {subsection}{\numberline {6.2}Verification of the protocol}{17}
\contentsline {section}{\numberline {7}Security and safety of the system}{20}
\contentsline {subsection}{\numberline {7.1}Encryption of the communication channels}{20}
\contentsline {subsection}{\numberline {7.2}Security on the web site}{21}