summaryrefslogtreecommitdiffstats
path: root/notFinishedCode/Report/test.tex.backup
diff options
context:
space:
mode:
authorRefik Hadzialic2011-10-22 17:59:01 +0200
committerRefik Hadzialic2011-10-22 17:59:01 +0200
commite59c0e5063ddd4a3d833a59da83196c9369089ac (patch)
tree044d6e1e395dafb78beeb9d300e14c23e88d70ad /notFinishedCode/Report/test.tex.backup
parentRerport writing (diff)
downloadgsm-selftest-e59c0e5063ddd4a3d833a59da83196c9369089ac.tar.gz
gsm-selftest-e59c0e5063ddd4a3d833a59da83196c9369089ac.tar.xz
gsm-selftest-e59c0e5063ddd4a3d833a59da83196c9369089ac.zip
Report writing
Diffstat (limited to 'notFinishedCode/Report/test.tex.backup')
-rw-r--r--notFinishedCode/Report/test.tex.backup12
1 files changed, 9 insertions, 3 deletions
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}