summaryrefslogtreecommitdiffstats
path: root/ausarbeitung/Friend_Finder.tex.backup
diff options
context:
space:
mode:
authorPatrick Hornecker2010-02-15 13:09:52 +0100
committerPatrick Hornecker2010-02-15 13:09:52 +0100
commit277a3e17dbd6ee47a974275f195f535b1819d49a (patch)
tree265e905664e993f170f970273dea23e593c8081e /ausarbeitung/Friend_Finder.tex.backup
parentimproved sender and receiver (diff)
downloadfriendfinder-277a3e17dbd6ee47a974275f195f535b1819d49a.tar.gz
friendfinder-277a3e17dbd6ee47a974275f195f535b1819d49a.tar.xz
friendfinder-277a3e17dbd6ee47a974275f195f535b1819d49a.zip
tex source
Diffstat (limited to 'ausarbeitung/Friend_Finder.tex.backup')
-rw-r--r--ausarbeitung/Friend_Finder.tex.backup38
1 files changed, 33 insertions, 5 deletions
diff --git a/ausarbeitung/Friend_Finder.tex.backup b/ausarbeitung/Friend_Finder.tex.backup
index 16fe9ee..7fb56c7 100644
--- a/ausarbeitung/Friend_Finder.tex.backup
+++ b/ausarbeitung/Friend_Finder.tex.backup
@@ -91,7 +91,18 @@ Auch hier wird, wie beim Versenden der Nachrichten zum Verschlüsseln der \texti
\subsubsection{Empfangen der eigenen Position}
-noch nicht final....empfänger empfängt nachricht, ordnet sie, leitet sie zum zeichnen weiter....grob gesehen
+Das Verhalten des Empfängers beim Erhalten einer Nachricht ist etwas komplizierter. Im ersten Schritt muss auch hier eine
+\textit{IRC-Session} initialisiert werden. Da mehrere Benutzer Positionsdaten senden können legt der Empfänger für jeden Sender
+einen Datensatz an. Dieser wird nach und nach mit den Positionsdaten gefüllt und die benötigten Daten weitergegeben, sobald alle
+vorhanden sind. Da der Sender seine Daten, aufgrund der Restrektion der Länge der zu verschlüsselnden Zeichenkette, gestückelt
+sendet ist es von Nöten das der Empfänger die Daten dem jeweiligen Absender zuordnen kann und diese auch wieder korrekt
+zusammensetzt. Dies geschieht mit Hilfe von Terminierungszeichen am Ende eines jeden Positionsbruchstückes. Dieses Zeichen wurde
+vom Sender angehängt und der Empfänger kann mit dieser Hilfe erkennen wie die gesendeten Daten zugeordnet werden müssen. Wenn dies
+geschehen ist und sowohl \textit{Latitude} als auch \textit{Longtitude} Informationen vorhanden sind, werden diese Position an das
+Frontend weitergegeben. \newline
+
+Zur Realisierung des Empfängers werden die gleichen Bibliotheken wie beim Sender genutzt. Auch hier wird zur Entschlüsselung der
+\textit{Blowfish-Algorithmus} von \textit{libcrypto} genutzt.
\subsubsection{Erzeugen eines 2D-Barcodes}
@@ -161,15 +172,32 @@ 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
-Länge der zu versendenden Nachricht aus: $h + (t * 2,6)$.
+ungefähre Größe der zu versendenden Nachricht aus: $h + (t * 7,4)$.
\subsubsection{Versenden und Empfangen von Positionen}
+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 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.
+
+
\subsubsection{Fazit der Auswertung}
Im Bereich des Allgemeinen Datenverkehrs fällt kein Overhead durch \textit{Friend Finder} an. Hier werden nur dann Daten