From 277a3e17dbd6ee47a974275f195f535b1819d49a Mon Sep 17 00:00:00 2001
From: Patrick Hornecker
Date: Mon, 15 Feb 2010 13:09:52 +0100
Subject: tex source

---
 ausarbeitung/Friend_Finder.tex | 34 ++++++++++++++++++++++------------
 1 file changed, 22 insertions(+), 12 deletions(-)

(limited to 'ausarbeitung/Friend_Finder.tex')

diff --git a/ausarbeitung/Friend_Finder.tex b/ausarbeitung/Friend_Finder.tex
index 85436d9..c90efe1 100644
--- a/ausarbeitung/Friend_Finder.tex
+++ b/ausarbeitung/Friend_Finder.tex
@@ -172,22 +172,29 @@ Minute übermittelt werden und somit immer Datenverkehr zwischen Sender und \tex
 Um das Versenden von Nachrichten zu evaluieren wurde ``Hello World`` als Testnachricht benutzt. Der \textit{Blockcipher} von
 \textit{Friend Finder} teilt den Satz "Hello World" in zwei Teile auf: ''Hello `` und ''World``. Diese werden dann von
 \textit{TCP} aufgrund der Fenstergröße in ein Paket gepackt. Das gesamte Paket hat die größe von 147 Bytes, wobei \textit{TCP-}
-und \textit{IP-Header} in der Summe auch wieder mit 52 Byte abzuziehen sind. Somit haben die Daten eine Größe von insgesamt 95
-Bytes.\newline
+und \textit{IP-Header} abgezogen werden müssen. Somit haben die Daten eine Größe von insgesamt 81 Bytes.\newline
 Beachtet man dass ein \textit{char} in \textit{C} die Größe von einem Byte hat und der Beispielsatz aus elf Zeichen besteht, so
-ist dieser unverschlüsselt 11 Byte groß. Somit vergrößern sich die Daten nach der Verschlüsselung um circa den Faktor 8,6.\newline
+ist dieser unverschlüsselt 11 Byte groß. Nach der Verschlüsselung werden beim Senden noch Informationen wie der
+\textit{Channel} und der Empfänger der Nachricht in das zu versendende \textit{IRC}-Paket geschrieben. Somit vergrößert
+sich eine Textnachricht circa um den Faktor 7,4, wenn sie verschlüsselt ist und alle Zusatzinformationen hineingepakt
+wurden. \newline
 Wenn $h$ die Größe des \textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht ist, so ergibt sie die
-Größe der zu versendenden Nachricht aus: $h + (t * 2,6)$.
+ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 7,4)$.
 
 \subsubsection{Versenden und Empfangen von Positionen}
 
-Wie schon erwähnt, werden die Positionsdaten beim Sender aufgeteilt und mit vier unterschiedlichen Nachrichten versandt. Diese
-vier Pakte unterliegen auch hier wieder der gleichen Formel wie das Versenden der Nachrichten. Sei $h$ die Größe des
+Wie schon erwähnt, werden die Positionsdaten beim Sender aufgeteilt und mit vier unterschiedlichen Nachrichten versandt. Wie
+beim Versenden der Textnachrichten werden diese vier Nachrichten auch hier in ein Paket gepakt. Dieses hat die Gesamtgröße
+von 235 Byte. Abzüglich der \textit{TCP-} und \textit{IP-Header} ergibt sich hier eine Datengröße von 169 Byte. Die Anzahl
+der unverschlüsselten Zeichen, die zu senden sind, beträgt 21 Zeichen. Diese sind jeweils 1 Byte groß, womit sie in der Summe
+also 21 Byte Größe haben. Durch die Verschlüsselung sowie die benötigten Zusatzinformationen, wie \textit{Channel} für
+den die Nachricht bestimmt ist, vergrößert sich das Datenvolumen also um circa den Faktor acht. Wenn $h$ die Größe des
 \textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht. Somit ergibt sich die Größe der versendeten
-Nachricht durch $h + (t * 2,6)$. Hinzu kommt noch, das für jedes Empfangene Fragment ein Acknowledgement gesendet wird. %größe
-%des ack packetes noch nachtragen.
-%formel für entsthenden verkehr aufstellen -> grafik erstellen.
-
+Nachricht circa durch $h + (t \cdot 8)$. Hinzu kommt noch, das für jedes empfangene Positions-Fragmeint ein Acknowledgement
+gesendet wird. Somit sind nach Empfangen aller vier Positionsteile vier Acknowledgements der Größe von 124 Bytes insgesamt und 58
+Bytes an Daten ohne Header gesendet worden.\newline
+Somit kann aus Folgende Formel für den Datenverkehr über die Zeit hergeleitet werden: $((h + (t \cdot 8)) + (4 \cdot a)) \cdot n$,
+wobei $a$ die Größe eines Acknowledgement-Paketes ist und $n$ die Anzahl der versandten Pakete repräsentiert. 
 
 \subsubsection{Fazit der Auswertung}
 
@@ -199,5 +206,8 @@ Positionsdaten mehrmals pro Minute versandt werden, ist dies aber auch nicht wir
 nicht Versenden dieser Daten auch ein Verbindungsproblem festgestellt werden könnte\newline
 Ein weiterer Vorteil von \textit{Friend Finder} ist das Verschicken von Daten an mehrere Benutzer. Hier muss der
 Client sein Paket nur einmal versenden und alle teilnehmenden Nutzer in einem Channel können diese Nachricht einsehen, sofern dies
-gewollt ist.
-
+gewollt ist. Würde man hier eine Verbindung pro Teilnehmer nutzen, so müsste man für $n$ Teilnehmer $n$ Verbindungen öffnen und
+auch $n$ Mal die Daten versenden. Dies würde ein nicht unerheblicher Berechnungsaufwand sowie Datenverkehr darstellen. Im
+Empfangen der Daten ergibt zwischen der Lösung durch \textit{Friend Finder} oder einer Verbindung pro Teilnehmer keinen
+Unterschied, da bei beiden Modellen diese Daten nur einmal empfangen werden.
+%Grafik erstellen
-- 
cgit v1.2.3-55-g7522

