From 2375bb932bd2e68a3aa7c9e4f774ac7bc976e526 Mon Sep 17 00:00:00 2001 From: Refik Hadzialic Date: Sat, 22 Oct 2011 23:18:43 +0200 Subject: Report writing --- notFinishedCode/Report/test.log | 4 ++-- notFinishedCode/Report/test.pdf | Bin 1481109 -> 1481113 bytes notFinishedCode/Report/test.tex | 2 +- notFinishedCode/Report/test.tex~ | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) (limited to 'notFinishedCode/Report') diff --git a/notFinishedCode/Report/test.log b/notFinishedCode/Report/test.log index b1b8cb9..21f7baa 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 23:06 +This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2011.9.27) 22 OCT 2011 23:18 entering extended mode %&-line parsing enabled. **test.tex @@ -425,7 +425,7 @@ r/fonts/pk/ljfour/jknappen/ec/ecrm1728.600pk> -Output written on test.pdf (30 pages, 1481109 bytes). +Output written on test.pdf (30 pages, 1481113 bytes). PDF statistics: 703 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 e395c76..d3347a3 100644 Binary files a/notFinishedCode/Report/test.pdf and b/notFinishedCode/Report/test.pdf differ diff --git a/notFinishedCode/Report/test.tex b/notFinishedCode/Report/test.tex index 7f8188a..0b8b1d0 100644 --- a/notFinishedCode/Report/test.tex +++ b/notFinishedCode/Report/test.tex @@ -313,7 +313,7 @@ response from the other side. Our approch to this problem was to build a simple 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\footnote{Design concepts and paradigms for the protocol design have been used from the -``Network Protocol Design and Evaluation'' course, lectured by Stefan R\"{u}hrup}. +``Network Protocol Design and Evaluation'' course, lectured by Dr. Stefan R\"{u}hrup}. 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 diff --git a/notFinishedCode/Report/test.tex~ b/notFinishedCode/Report/test.tex~ index 5e03427..7f8188a 100644 --- a/notFinishedCode/Report/test.tex~ +++ b/notFinishedCode/Report/test.tex~ @@ -312,7 +312,7 @@ 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\footnote{Design ideas and references for the protocol design have been used from the +protocol\footnote{Design concepts and paradigms for the protocol design have been used from the ``Network Protocol Design and Evaluation'' course, lectured by Stefan R\"{u}hrup}. 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 -- cgit v1.2.3-55-g7522