summaryrefslogtreecommitdiffstats
path: root/ausarbeitung/Friend_Finder.tex~
diff options
context:
space:
mode:
Diffstat (limited to 'ausarbeitung/Friend_Finder.tex~')
-rw-r--r--ausarbeitung/Friend_Finder.tex~196
1 files changed, 81 insertions, 115 deletions
diff --git a/ausarbeitung/Friend_Finder.tex~ b/ausarbeitung/Friend_Finder.tex~
index 6f800ac..ea0d0b1 100644
--- a/ausarbeitung/Friend_Finder.tex~
+++ b/ausarbeitung/Friend_Finder.tex~
@@ -1,23 +1,21 @@
\section{Friend Finder}
-Die Eingangs beschriebene Software trägt den Namen \textit{Friend Finder} und wurde im Rahmen dieser Arbeit mit fast allen
+Die beschriebene Software trägt den Namen \textit{Friend Finder} und wurde im Rahmen dieser Arbeit mit allen
aufgezählten Funktionen realisiert. Im folgenden wird auf die verwendeten Verfahren sowie Bibliotheken, die zur Realisierung
-notwendig waren, eingegangen.
+notwendig waren, eingegangen und die Programmstruktur aufgezeigt.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Verwendete Verfahren und Bibliotheken}
-\textit{Friend Finder} wurde so konzipiert, dass die Graphische Darstellung ohne großen Aufwand vom den restlichen
-Teilen der Software abgekoppelt und durch eine andere, darstellende Bibliothek ersetzt werden kann. Somit
-könnte man \textit{Enlightenment} durch eine andere Art der Darstellung austauschen, ohne dabei die Funktionalität der
-zugrunde liegenden Komponenten zu zerstören. \newline
-Da das Ver- und Entschlüsseln der Daten möglichst wenig Rechenaufwand erzeugen und der Schlüsselaustausch nicht zu
-kompliziert sein soll, nutzt das Programm ein symmetrisches Verschlüsselungsverfahren. \newline
-\textit{Abbildung 3} zeigt den Kommunikationsaustausch von \textit{Friend Finder}. Der \textit{Message Sender} ist für das
-Versenden und Empfangen der Textnachrichten zuständig, \textit{Sender} sendet die eigene Position, \textit{Receiver} empfängt
-die Positionen der anderen Nutzer und sendet Acknowledgements an die teilnehmenden \textit{Sender}. Alle drei Teile geben ihre
-empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{Enlightenment} ausgibt.
+\textit{Friend Finder} wurde so konzipiert, dass die Graphische Darstellung ohne großen Aufwand von den restlichen
+Teilen der Software abgekoppelt und durch eine andere Art der Darstellung ersetzt werden kann. Würde \textit{Enlightenment}
+austauschen, würde die Funktionsweise der zugrundeliegenden Komponenten zu verändern. \newline
+Neben dem \textit{Graphical User Interface (GUI)} besteht die Software aus drei unterschiedlichen Modulen. Der \textit{Message
+Sender} ist für das Versenden und Empfangen der Textnachrichten zuständig, \textit{Sender} sendet die eigene Position,
+\textit{Receiver} empfängt die Positionen der anderen Nutzer und sendet Acknowledgements an die teilnehmenden \textit{Sender}.
+Alle drei Teile geben ihre empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{Enlightenment} ausgibt.
+\textit{Abbildung 3} zeigt den Kommunikationsaustausch von \textit{Friend Finder}.
\begin{figure}[!ht]
\centering
@@ -29,13 +27,11 @@ empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{E
Zum Erstellen der Oberfläche wurde \textit{Enlightenment} verwendet. Diese Bibliothek stellt alle benötigten Funktionen bereit und
bietet eine Fülle an vordefinierten Bedienelement. Der gesammte Programmcode der Benutzeroberfläche wurde in einer Datei
-zusammengefast (\textit{gui.c}). Diese Tatsache vereinfacht das Erhalten der Modularität, da nur diese Datei
-durch eine andere ersetzt werden muss um einen anderen Typ von Oberfläche zu nutzen. \newline
-In der der Datei \textit{gui.c} sind alle Funktionen enthalten um die Oberflächenelement zu erzeugen und zu platzieren. Um die
-gewünschte Funktionalität der einzelnen Elemente zu realisieren wurden auch die Aufrufe der benötigten Funktionen aus anderen
+zusammengefast (\textit{gui.c}). \newline
+In dieser Datei sind alle Funktionen enthalten um die Oberflächenelement zu platzieren. Um die gewünschte Funktionalität der
+einzelnen Elemente zu realisieren wurden auch die Aufrufe der benötigten Funktionen aus anderen
Modulen in dieser Datei implementiert. \newline
-Wie schon erwähnt, wurde die Graphische Nutzeroberfläche mit Hilfe von Bibliotheken aus dem \textit{Elementary}-Paket
-realisiert. Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap} \citep{OSM} genutzt.
+Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap} \citep{OSM} genutzt.
\subsubsection{Versenden der Nachrichten}
@@ -46,20 +42,21 @@ Stabilität. Ein weiterer Vorteil ist, dass man Daten die an mehrere Benutzer ge
In der Datei \textit{msg\_sender.c} sind alle Funktionen und Aufrufe implementiert, welche nötig sind um die Verbindung zum
\textit{IRC-Server} zu erstellen und die Nachrichten zu verschicken. Um eine Verbindung zu einem gegebenen \textit{IRC-Server} zu
-erstellen muss eine \textit{IRC-Session} initialisiert werden. Diese \textit{Session} beinhaltet Informationen wie zum Beispiel
+etablieren, muss eine \textit{IRC-Session} initialisiert werden. Diese \textit{Session} beinhaltet Informationen wie zum Beispiel
den \textit{Nickname} des Benutzers oder die \textit{IP-Adresse} des Servers. Nachdem diese \textit{Session} gestartet wurde,
-kann man nun durch das Aufrufen der Funktion ``\textit{set\_txt\_msg(char* msg)}'' die Nachricht versenden. Wird eine Nachricht
-empfangen so wird diese an die Funktion ``\textit{show\_message(char* msg)}`` , welche zur Benutzeroberfläche gehört, übergeben.
+können nun Nachrichten versandt werden. Wird eine Nachricht empfangen so wird diese an die Benutzeroberfläche weitergereicht.
Bei der Implementerierung des Nachrichtenversandes ist eine Besonderheit zu erwähnen. Das genutzte Verschlüsselungsverfahren
\textit{Blowfish} \citep{blowfish} wurde seitens der \textit{OpenSSL}\citep{OpenSSL} Bibliothek als \textit{Blockcipher}
-implementiert. \textit{Blowfish} wurde Aufgrund der schnellen verschlüsselungsrate sowie einfachen Implementierung gewählt und
+implementiert. \textit{Blowfish} wurde Aufgrund der schnellen Verschlüsselungsrate sowie einfachen Implementierung gewählt und
ist ein symmetrisches Verschlüsselungsverfahren. Das bedeutet, das immer nur maximal 64 Bit Nachrichten verschlüsselt werden
-können. Da in der Programmiersprache \textit{C} dies genau acht ASCII-Zeichen entspricht, werden alle zu sendenden Nachrichten in
-Blöcke der Größe acht aufgeteilt, versandt und beim Empfänger wieder zusammengesetzt. \newline
+können. Aufgrund dieser Restriktion werden Textnachrichten in Blöcke der Zeichenlänge 6 aufgeteilt und anschliessend
+versandt. Um den die Codierung der Verschlüsselten Nachrichten zu erhalten werden alle versendeten Daten des Programmes in die
+\textit{Base64} \citep{base64} Darstellung umgewandelt. Dies ist notwendig, da die verschiedenen \textit{IRC}-Server
+unterschiedliche Zeichenkodierungen nutzen können.\newline
Ein weiterer wichtiger Unterschied zu den Modulen Senden und Empfangen von \textit{GPS}-Positionen ist die Tatsache, dass bei
diesem Programmteil Sender und Empfänger in der gleichen Datei implementiert wurden. Der Grund hierfür ist, dass man hier nicht
zwischen mehreren Sendern oder Empfängern unterscheiden muss, und diese zwei Teile hier somit nicht komplett getrennt voneinander
-arbeiten müssen. In der folgenden Abbildung ist eine Konversation über \textit{Friend Finder} zu sehen.\newline
+arbeiten müssen. In der folgenden Abbildung ist eine Textkonversation mit \textit{Friend Finder} zu sehen.\newline
\begin{figure}[!ht]
\centering
@@ -71,9 +68,7 @@ Um Nachrichten zu versenden wurde für dieses Projekt die \textit{IRC-Client Bib
Bibliothek bietet verschiedene Funktionen um eine Verbindung mit einem \textit{IRC-Server} zu erstellen und Nachrichten an
diesen zu senden, sowie eingehende Nachrichten zu empfangen.\newline
Zur Ver- und Entschlüsselung der gesendeten Nachrichten, sowie der Positionsdaten, wird die Bibliothek
-des \textit{OpenSSL-Projekts}\citep{OpenSSL}, namens \textit{libcrypto}, verwendet. Hierzu werden die Daten mit dem
-\textit{Blowfish-Algorithmus} verschlüsselt. Bei diesem Algorithmus handelt es sich um ein symmetrisches
-Verfahren, bei welchem alle Teilnehmer den gleichen privaten Schlüssel zum ver- sowie entschlüsseln nutzen.
+des \textit{OpenSSL-Projekts}\citep{OpenSSL}, namens \textit{libcrypto}, verwendet.
\subsubsection{Versenden der eigenen Position}
@@ -84,34 +79,28 @@ Allerdings muss auch hier, wie beim Versenden der Textnachrichten, darauf geacht
Länge 8 Byte verschlüsselt wird. Somit ist es auch hier nötig Längen- und Breitengrad in zwei Teile aufzuteilen und getrennt zu
versenden. Es werden für das Versenden einer Position insgesamt vier Nachrichten an den \textit{IRC}-Server übermittelt.
Wurden diese vier Nachrichten übermittelt, so werden solange keine Daten mehr gesendet, bis der Empfänger eine
-Bestätigung an den \textit{IRC-Kanal} sendet. Diese Bestätigung wird ebenfalls verschlüsselt versandt. Kommt dieses
-\textit{Acknowledgement} beim Sender an, so versendet dieser wieder ein \textit{Latitude/Longtitude} Paar.\newline
+Bestätigung für jedes Fragment an den \textit{IRC-Kanal} sendet. Diese Bestätigungen werden ebenfalls verschlüsselt versandt.
+Kommt dieses \textit{Acknowledgement} beim Sender an, so versendet dieser wieder ein \textit{Latitude/Longtitude} Paar.\newline
Auch hier wird, wie beim Versenden der Nachrichten zum Verschlüsseln der \textit{Blowfish-Algorithmus} aus
\textit{libcrypto}, sowie \textit{libircclient} zum versenden der Daten genutzt.
\subsubsection{Empfangen der eigenen Position}
-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, dass der Empfänger die Daten dem jeweiligen Absender zuordnen kann und diese auch wieder korrekt
-zusammensetzt. Um die einzelnen Fragmente wieder zuzordnen, werden an diese vor dem versenden Terminierungszeichen angefügt,
-welche zum Beispiel eindeutig als ersten Teil einer \textit{Longtitude}-Koordinate identifizieren. Wenn diese wieder zugeordnet
-wurden und sowohl \textit{Latitude} als auch \textit{Longtitude} Informationen vorhanden sind, werden diese Position
-an das Frontend weitergegeben. \newline
+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 gesendeten Fragmenten der Positionsdaten
+gefüllt. Sind alle Fragmente beim Empfänger angekommen so werden die benötigten Daten zur Visuallisierung weitergegeben. Um die
+einzelnen Positionsfragmente zuzordnen zu können, werden an diese vor dem versenden Terminierungszeichen angefügt. Diese
+Identifizieren zum Beispiel eindeutig einen ersten Teil einer \textit{Longtitude}-Koordinate.
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} angewandt.
\subsubsection{Erzeugen eines 2D-Barcodes}
-Die Datei \textit{barcode.c} beinhaltet die Funktionen zum Erstellen eines 2D-Barcodes. Hierzu wird die Funktion
-``\textit{generate\_barcode(char* key)}'', mit einer Zeichenkette als Übergabeparameter, aufgerufen. Aus dieser Zeichenkette wird
-im Anschluss ein Barcode erstellt, welcher im darauf folgenden Schritt als \textit{.png} Datei auf das Speichermedium geschrieben
-wird.
-Zum erstellen des Barcodes wurde die offene Bibliothek \textit{qrencode} \citep{qrencode} genutzt. Diese erstellt aus einer
+Die Datei \textit{barcode.c} beinhaltet die Funktionen zum Erstellen eines 2D-Barcodes. Aus einer Zeichenkette wird
+ein Barcode erstellt, welcher im darauf folgenden Schritt als \textit{.png} Datei auf das Speichermedium geschrieben
+wird. Zum erstellen des Barcodes wurde die offene Bibliothek \textit{qrencode} \citep{qrencode} genutzt. Diese erstellt aus einer
Zeichenkette einen 2D-Barcode. Aus den Bilddaten dieses Barcodes wurde mit \textit{libpng} \citep{PNG} eine \textit{.png} Datei
generiert. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er von \textit{Friend Finder} ausgegeben wird.
@@ -128,99 +117,76 @@ generiert. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er v
Das Ziel war es mit \textit{Friend Finder} Daten verschlüsselt zu übertragen. Es soll dabei ein möglichst geringer
Berechnungsaufwand entstehen um die Daten zu verschlüsseln, sowie möglichst wenig Datenoverhead produziert und versendet werden.
-Unter Datenoverhead werden die Hintergrunddaten gesehen, welche versendet werden um zum Beispiel die Verbindung
-zwischen Client und Server aufrecht zu erhalten oder um zu kontrollieren ob Server oder Client noch verfügbar sind. Diese Daten
- sind von Interesse da mit vielen versendeten Daten ein höherer Anspruch des Rechenkerns einhergeht, was wiederrum in einem
+Unter Datenoverhead werden Hintergrunddaten gesehen, welche versendet werden um zum Beispiel die Verbindung zwischen Client und
+Server aufrecht zu erhalten oder um zu kontrollieren ob Server oder Client noch verfügbar sind. Diese Daten
+sind von Interesse da mit vielen versendeten Daten ein höherer Anspruch des Rechenkerns einhergeht, was wiederrum in einem
höheren Stromverbrauch resultiert.\newline
Im folgenden Teil wird der erzeugte Datenverkehr von \textit{Friend Finder} analysiert. Ein Hauptaugenmerkt wird hierbei vor allem
auf die Packetgröße, sowie die Menge der versendeten Datenpakete geworfen. Der \textit{Traffic} wurde mit Hilfe des Programmes
\textit{Wireshark} \citep{Wireshark} untersucht.Wie bereits erwähnt wird zum Versenden der Nachrichten das \textit{IRC-Protokoll}
verwendet. In dieser Testumgebung wurde die Software \textit{IRCD-Hybrid} \citep{IRCD} genutzt. Der Server lief auf dem gleichen
-Computer wie der Client und der Client hat sich über das \textit{localhost} Interface mit dem Server verbunden. \newline
+Computer wie der Client. Der Client hat sich über das \textit{localhost} Interface mit dem Server verbunden. \newline
Die Analyse ist in drei Teile aufgeteilt. Als erstes wird auf den allgemein entstehenden Datenverkehr eingegangen, welcher
bei Verbindungsaufbau, sowie bei Beenden der Verbindung entsteht. Der zweite Teil beschäftigt sich mit dem Versenden sowie
-Empfangen von Nachrichten. Im letzten Teil dieser Analyse wird auch das dritte Feature, dass Versenden und Empfangen von
-Positionen, unter die Lupe genommen.
+Empfangen von Nachrichten. Im letzten Teil dieser Analyse wird das Versenden und Empfangen von Positionen, unter die Lupe
+genommen. Alle Größen innerhalb der Analyse beziehen sich nur auf die Größe des Datenfeldes, exklusiv der Header.
\subsubsection{Allgemeiner Datenverkehr}
-Bei Messung des allgemeinen Datenaufkommens mit eine normalen \textit{IRC-Clients}, hier \textit{X-Chat} \citep{xchat}, ergibt
-sich folgender Datenverkehr. \newline
-Beim Verbindungsaufbau sendet der \textit{IRC}-Server zuerst ein Paket mit Informationen wie Limit der \textit{Channels}
-oder Anzahl der aktiven Benutzer. Dieses Paket hatte in der Versuchsumgebung eine Größe von 1090 Bytes. Hiervon müssen noch 20
-Bytes \textit{IP-} und 32 Byte \textit{TCP-Header} abgezogen werden. Somit sind die hat das Datenfeld eine Größe von 1038 Bytes.
-Bei im folgenden genannten Paketgrößen sind diese 52 Byte schon abgezogen. \newline
-Wenn im nächsten Schritt der Benutzer nun eine \textit{Channel} beitritt, so sendet dieser drei Pakete an den Server. Diese
-beinhalten den Namen des \textit{Channels} dem beigetreten werden soll, eine Anfrage nach einer Liste der aktiven Nutzer in diesem
-\textit{Channel}sowie welche Rechte der beitretende Nutzer in diesem \textit{Channel} inne hat. Diese drei Pakete haben alle die
-Größe von 26 Byte. Ist die Verbindung zwischen Client und Server aufgebaut so sendet der Client alle 30 Sekunden ein \textit{Ping}
-Paket an den Server, welches dieser mit einem \textit{Pong} beantwortet. Diese Pakete haben eine Größe von 40 Byte für die
-\textit{Ping} Nachricht und 58 Byte für die beantwortende \textit{Pong} Nachricht. Alle 60 Sekunden versendet der Client eine
-Anfrage, welche Teilnehmer sich im \textit{Channel} befinden. Diese Nachricht von Client zu Server ist 25 Byte groß. Die Antwort
-hierzu ist abhängig von der Anzahl der Benutzer. Ist nur ein Benutzer im \textit{Channel} so ist sie 151 Bytes groß, bei zwei ist
-sie schon 233 Byte groß. Wird eine Verbindung beendet, so schickt der Client eine \textit{Quit} Nachricht an den Server.
-\newline
-
-Im Gegensatz zu diesem hohen Hintergrundverkehr benötigt \textit{Friend Finder} nur einen \textit{TCP-Handshake} um die
-Verbindung aufzubauen. Ist die Verbindung etabliert fallen keine weiteren Hintergrunddaten an. Der Nachteil hiervon ist, dass der
-Client nur bei einem auftretenden Fehler beim Versenden der Daten bemerkt, dass er nicht mehr verbunden ist. Allerdings wird
-hiermit auch Berechnungszeit und somit Akku gespart, da diese \textit{Keep-Alive} Nachrichten, sowie die zusätzliche
-Informationen über den Server im Rahmen von \textit{Friend Finder} nicht benötigt werden. Da die Positionsdaten mehrmals pro
-Minute übermittelt werden besteht somit immer Datenverkehr zwischen Sender und \textit{IRC}-Server und es kann schnell
-festgestellt werden ob eine Verbindung noch aktiv ist. \newline
+Der Allgemeine Hintergrundverkehr bei \textit{Friend Finder} besteht zum einen aus \textit{Keep-Alive} Nachrichten, sowie der
+Anfrage des Clients nach aktiven Nutzern in den \textit{Channels} in denen er selbst aktiv ist. Die \textit{Keep-Alive}
+Nachrichten werden alle 30 Sekunden zwischen Server und Client ausgetauscht. Die Größe des Datenfeldes einer
+solchen Nachricht beträgt also 24 Byte. Das Datenfeld der Pakete welche von Server an Client gesendet werden hat die Größe von 44
+Byte. \newline
+Die Anfragen nach den anderen Benutzern in einem \textit{Channel} werden alle 60 Sekunden versandt. Die Größe der Pakete welche
+von Client zu Server gesandt werden, betragen hierbei 10 Bytes. Die Größe der Antwort des Servers hängt von der Anzahl der
+aktiven Benutzer innerhalb eines Channels ab. Für zwei Benutzer ergibt sich ein Datenvolumen von 193 Byte, wobei diese
+Größe auch Abhängig von der Länge der Benutzernamen sowie des Namens des\textit{Channels} ist. \newline
\subsubsection{Versenden und Empfangen von Nachrichten}
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} abgezogen werden müssen. Somit haben die Daten eine Größe von insgesamt 81 Bytes.\newline
+\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. Dieses Paket hat ein Datenfeld der Größe von 99 Byte.\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ß. 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
+ist dieser unverschlüsselt elf 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 und im Anschluss die
+Konvertierung zur \textit{Base64}-Darstellung vorgenommen. Die \textit{Base64}-Darstellung vergrößert im Allgemeinen, aufgrund
+der Datenkonvertierung, das Datenvolumen um 36\%. Somit vergrößert sich eine Textnachricht circa um den Faktor $9$ sobald sie
+verschlüsselt, \textit{Base64}-kodiert und mit allen Zusatzinformationen erweitert wurde. \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 \cdot 7,4)$.
+ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 9)$.
\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 \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.
+beim Versenden der Textnachrichten werden diese vier Nachrichten auch hier in ein Paket gepackt. Bei der Messung wurden vier
+Verschiedene Pakete, mit jeweils unterschiedlichen versandten Positionen untersucht. Dabei betrug sich die Größe des Datenfeldes
+zwischen 431 Byte. Die Anzahl der unverschlüsselten Zeichen, die für ein \textit{Latitude}/\textit{Longtitude}-Paar zu
+senden sind, beträgt 21 Zeichen. Jedes Zeichen ist Byte groß, womit sich in der Summe eine Größe von 21 Byte ergibt.
+Durch die Verschlüsselung, \textit{Base64}-Kodierung sowie Zusatzinformationen vergrößert sich das Datenvolumen also um circa den
+Faktor zwanzig. 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 \cdot 20)$. Hinzu kommt noch, das für jedes empfangene
+Positions-Fragmeint ein Acknowledgement gesendet wird. Die Größe der eines Acknowledgment Paketes beträgt zwischen 147 und 153
+Byte. In einem solchen Paket werden vier Acknowledgments zusammengefasst.\newline
+Folglich kann aus Folgende Formel für den Datenverkehr über die Zeit hergeleitet werden: $((h + (t \cdot 20)) + (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}
-Im Bereich des Allgemeinen Datenverkehrs fällt kein Overhead durch \textit{Friend Finder} an. Hier werden nur dann Daten
-versandt, wenn dies auch vom Nutzer so gewollt sind und auch gebraucht werden. Dies hat den Vorteil, dass der Anwender die totale
-Kontrolle über die Daten, die er sendet, hat. Allerdings kann so auch erst beim Versenden von Daten festgestellt werden, ob die
-Verbindung unterbrochen wurde, da im Hintergrund die Verbindung nicht ständig überprüft wird. Aufgrund der Tatsache, dass
-Positionsdaten mehrmals pro Minute versandt werden, ist dies aber auch nicht wirklich nötig da durch das Versenden oder
-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. 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.\newline
-In der folgenden Abbildung ist an der X-Achse die Anzahl der Teilnehmer und an der Y-Achse die Anzahl der zu versendenden
-Dateneineheiten abgetragen. Hier ist deutlich zu sehen, dass bei steigender Teilnehmer Anzahl eine Lösung mit einer offenen
-Verbindung pro Benutzer soviel Datenpakete wie Nutzer versenden muss. Bei der Lösung mit einem zentralen \textit{Channel} müssen
-die Daten immer nur einmal versandt werden, unabhängig von der Nutzeranzahl.
-
-\begin{figure}[!ht]
-\centering
- \includegraphics[width=10cm]{Bilder/verbindungen}
- \caption{Vergleich von n-Verbindungen und \textit{Friend Finder}}
-\end{figure} \ No newline at end of file
+Die Hintergrunddaten welche vom \textit{IRC}-Protokoll versandt werden ergeben einen geringen, in Kauf zu nehmenden Datenoverhead.
+Zu beobachten ist, dass das Datenvolumen der Versendeten Daten, sowohl bei Positionsdaten als auch bei Textnachrichten, durch die
+Verschlüsselung und die anschliessende Konvertierung in die \textit{Base64}-Darstellung zunimmt. Als großen Vorteil kann hier aber
+gesehen werden, dass es mit einmaligem Versenden einer Position möglich ist $n$ Teilnehmer eines \textit{Channels} diese zu
+übermitteln, da alle die Nachrichten innerhalb dieses \textit{Channels} lesen können. Somit ergibt sich hier ein großer Vorteil
+gegenüber dem Aufbauen von $n$ einzelnen Verbindungen. Würde man einen solchen Ansatz wählen, müssten $n$ Verbindungen geöffnet
+werden und die Daten folglich auch $n$ Mal versandt werden. Der dabei entstehnde Datenverkehr steht in keiner Relation zu dem der
+gewählten Lösung. Somit stellt das \textit{IRC}-Protokoll eine hervorragende Lösung für Programme dieser Art dar.
+
+%\begin{figure}[!ht]
+%\centering
+% \includegraphics[width=10cm]{Bilder/verbindungen}
+% \caption{Vergleich von n-Verbindungen und \textit{Friend Finder}}
+%\end{figure}