From 88bb54e30a038269e33fd3b14f3bf321f0cb96c8 Mon Sep 17 00:00:00 2001 From: Patrick Hornecker Date: Thu, 18 Feb 2010 19:11:15 +0100 Subject: tex source --- ausarbeitung/Friend_Finder.tex.backup | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) (limited to 'ausarbeitung/Friend_Finder.tex.backup') diff --git a/ausarbeitung/Friend_Finder.tex.backup b/ausarbeitung/Friend_Finder.tex.backup index 7fb56c7..1f497e5 100644 --- a/ausarbeitung/Friend_Finder.tex.backup +++ b/ausarbeitung/Friend_Finder.tex.backup @@ -179,7 +179,7 @@ ist dieser unverschlüsselt 11 Byte groß. Nach der Verschlüsselung werden beim 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 -ungefähre Größe der zu versendenden Nachricht aus: $h + (t * 7,4)$. +ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 7,4)$. \subsubsection{Versenden und Empfangen von Positionen} @@ -190,13 +190,11 @@ der unverschlüsselten Zeichen, die zu senden sind, beträgt 21 Zeichen. Diese s 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 circa durch $h + (t * 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 * 8)) + (4 * a)) * n$, wobei $a$ -die Größe eines Acknowledgement-Paketes ist und $n$ die Anzahl der versandten Pakete repräsentiert. -%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} @@ -208,5 +206,13 @@ 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. +\begin{figure}[h] +\centering + \includegraphics[width=10cm]{Bilder/verbindungen} + \caption{Vergleich von n-Verbindungen und \textit{Friend Finder}} +\end{figure} \ No newline at end of file -- cgit v1.2.3-55-g7522