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