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.tex147
1 files changed, 92 insertions, 55 deletions
diff --git a/ausarbeitung/Friend_Finder.tex b/ausarbeitung/Friend_Finder.tex
index 727ae69..c5a361c 100644
--- a/ausarbeitung/Friend_Finder.tex
+++ b/ausarbeitung/Friend_Finder.tex
@@ -1,6 +1,6 @@
\section{Friend Finder}
-Die beschriebene Software trägt den Namen \textit{Friend Finder} und wurde im Rahmen dieser Arbeit realisiert. Im folgenden wird
+Die beschriebene Software trägt den Namen \textit{Friend Finder} und wurde im Rahmen dieser Arbeit realisiert. Im Folgenden wird
auf die verwendeten Verfahren sowie Bibliotheken, die zur Realisierung notwendig waren, eingegangen und die Programmstruktur
aufgezeigt.
@@ -14,12 +14,17 @@ Neben dem \textit{Graphical User Interface (GUI)} besteht die Software aus drei
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}.
+Abbildung \ref{ablauf} zeigt den Kommunikationsaustausch von \textit{Friend Finder}. In dieser Graphik sind die Module zweier
+Instanzen von \textit{Friend Finder} abgebildet. Es ist ersichtlicht, dass die Kommunikation für Positionsdaten zwischen
+\textit{Sender} und \textit{Empfänger} stattfindet. Textnachrichten werden zwischen den \textit{Message Sendern} ausgetauscht.
+Des Weiteren geben \textit{Sender}, \textit{Empfänger} und \textit{Message Sender} die entschlüsselten Daten an die \textit{GUI}
+weiter.
\begin{figure}[!ht]
\centering
\includegraphics[width=10cm]{Bilder/ablauf}
\caption{\textit{Friend Finder} Nachrichtenaustausch}
+ \label{ablauf}
\end{figure}
\subsubsection{Grafisches Benutzeroberfläche}
@@ -27,30 +32,34 @@ Alle drei Teile geben ihre empfangenen Daten an die \textit{GUI} weiter, welche
Um die Modularität zu wahren wird der gesammte Programmcode der Benutzeroberfläche in einer Datei zusammengefast. 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
-Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap} \footnote{OpenStreetMap
-\url{http://www.openstreetmap.de/}} genutzt.
+Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap}\footnote{OpenStreetMap
+http://www.openstreetmap.de/ [Online; letzter Aufruf 13.02.2010]} genutzt.
\subsubsection{Versenden der Nachrichten}
Der \textit{Message Sender} kümmert sich um das Versenden von Nachrichten. Um das Versenden und Empfangen der Daten zu
-implementieren wurde \textit{libircclient} \footnote{libircclien \url{http://libircclient.sourceforge.net/}} genutzt. Im ersten
+implementieren wurde \textit{libircclient}\footnote{libircclien http://libircclient.sourceforge.net/ [Online; letzter Aufruf
+25.01.2010]} genutzt. Im ersten
Schritt baut dieser eine Verbindung zum \textit{IRC-Server} auf. Um eine Verbindung mit einem \textit{IRC-Server} zu 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,
können nun Nachrichten versandt werden. Textnachrichten müssen vor dem Versenden in Blöcke aufgeteilt werden, da das genutze
Verschlüsselungsverfahren \textit{Blowfish} \citep{blowfish} maximal 64 Bit lange Zeichenkette verschlüsselt. Das verwendete
-Verfahren stammt aus der \textit{OpenSSL}\footnote{OpenSSL \url{http://www.openssl.org/}} Bibliothek. Diese Implementierung wurde
-wurde Aufgrund der schnellen Verschlüsselungsrate sowie einfachen Implementierung gewählt. Da das \textit{IRC}-Protokoll nicht
-alle Zeichen darstellen kann oder als Präfix vor einem Kommando nutzen werden alle versendeten Daten des Programmes in
-die \textit{Base64} \footnote{Base64 RFC 4648} Darstellung umgewandelt.\newline
+Verfahren stammt aus der \textit{OpenSSL}\footnote{OpenSSL http://www.openssl.org/ [Online; letzter Aufruf 25.01.2010]}
+Bibliothek. Diese Implementierung wurde wurde Aufgrund der schnellen Verschlüsselungsrate sowie einfachen
+Implementierungsmöglichkeiten gewählt. Da das \textit{IRC}-Protokoll nicht alle Zeichen darstellen kann oder bestimmte Zeichen als
+Präfixe vor einem Kommando nutzt werden, alle versendeten Daten des Programmes in die \textit{Base64}\citep{Base64} Darstellung
+umgewandelt.\newline
Wird nun von einer anderen Instanz des \textit{Message Senders} eine Nachricht empfangen, so setzt er die Teilstücke zusammen.
Dies geschieht solange, bis ein vom Nachrichtentext getrennt gesendetes Terminierungszeichen empfangen wird. Wurde dieses Zeichen
-empfangen, so gilt die Textnachricht als wiederhergestellt und wird an die Benutzeroberfläche weitergereicht.
+empfangen, so gilt die Textnachricht als wiederhergestellt und wird an die Benutzeroberfläche weitergereicht. \newline
+In Abbildung \ref{chat} ist das die graphische Darstellung eines Nachrichtenaustausches abgebildet.
\begin{figure}[!ht]
\centering
\includegraphics[width=8cm]{Bilder/chat}
\caption{Versenden von Chatnachrichten}
+ \label{chat}
\end{figure}
\subsubsection{Versenden der eigenen Position}
@@ -58,44 +67,61 @@ empfangen, so gilt die Textnachricht als wiederhergestellt und wird an die Benut
Der \textit{Sender} ist zuständig für das Versenden der Positionsdaten. Auch hier muss vor dem Versenden von Daten eine
\textit{IRC-Session} initialisiert werden. Der Ablauf beim Senden der Positionen erfolgt in einer vorgegebenen Reihenfolge. Zuerst
wird der verschlüsselte Längengrad, danach der verschlüsselte Breitengrade gesendet.
-Allerdings muss auch hier, wie beim Versenden der Textnachrichten, darauf geachtet werden dass maximal eine Zeichenkette der
-Länge von 64 Bit verschlüsselt wird. Somit ist es auch hier nötig Längen- und Breitengrad in zwei Teile aufzuteilen und getrennt
-zu versenden. An jedes Ende, dieser insgesamt vier Fragmente, wird ein zusätzlicher, jeweils unterschiedlicher Buchstaben
-angehängt. Da sich diese vier Buchstaben unterscheiden können die Positionsfragmente später identifiziert und eindeutig
-festgestellt werden ob es sich zum Beispiel um den ersten Teil einer \textit{Longtitude}-Koordinate handelt. Somit werden für das
-Versenden von einer Position insgesamt vier Nachrichten an den \textit{IRC}-Server übermittelt.
+Allerdings muss auch hier, wie beim Versenden der Textnachrichten, darauf geachtet werden, dass maximal eine Zeichenkette der
+Länge 64 Bit verschlüsselt wird. Somit ist es auch hier nötig Längen- und Breitengrad in zwei Teile aufzuteilen und getrennt
+zu versenden. An jedes Ende, dieser insgesamt vier Fragmente, wird ein zusätzlicher, jeweils unterschiedlicher Suffix angehängt.
+Da sich diese vier Suffixe unterscheiden, können die Positionsfragmente später eindeutig zugeordnet werden. Beispielsweise hat
+eine \textit{Latitude}-Koordinate den Wert $47.996578$. Dieser Koordinate wird nun in $47.99$ und $6578$ aufgeteilt. Nach dem
+Anhängen der Suffixe werden $47.99a$ und $6578b$ versendet und können anhand der Suffix ``a'' und ``b'' als erster, bzw zweiter
+Teil der \textit{Longtitude}-Koordinate identifiziert und zugeordnet werden. Somit werden für das Versenden von 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 \textit{Empfänger} eine
Bestätigung für jedes Fragment an den \textit{IRC-Channel} sendet. Kommt diese Bestätigung beim \textit{Sender} an, so
-versendet dieser wieder ein \textit{Latitude/Longtitude} Paar.
+versendet dieser wieder ein \textit{Latitude/Longtitude} Paar. Abbildung \ref{protocol} zeigt, das Versenden von Positionsdaten
+des \textit{Senders} über einen \textit{IRC-Channel} an den \textit{Empfänger}. Dieser schickt im Anschluss auf gleichem Weg
+\textit{Acknowledgements} an den \textit{Sender}.
-\subsubsection{Empfangen von Positionen}
+\begin{figure}[!ht]
+\centering
+ \includegraphics[width=10cm]{Bilder/protocol}
+ \caption{Versenden von Chatnachrichten}
+ \label{protocol}
+\end{figure}
+
+\subsubsection{Empfangen von Positionen}
Auch beim \textit{Empfänger} muss im ersten Schritt eine \textit{IRC-Session} initialisiert werden. Da mehrere
Benutzer Positionsdaten senden können legt der \textit{Empfänger} für jeden \textit{Sender} einen Datensatz an. Wird nun ein
Fragment der Positionsdaten empfangen, so kann der dies anhanden des Buchstabensuffix zuordnen. Sind alle Fragmente einer
Position empfangen worden, so werden die benötigten Daten zur Visuallisierung weitergereicht und ein \textit{Acknowledgement}
-gesendet. Dieses \textit{Acknowledgement} beinhaltet, verschlüsselter Form, den Namen des \textit{Senders} der Nachricht. Somit
-kann der \textit{Sender} die für ihn bestimmten \textit{Acknowledgements} zuordnen. Die folgende Abbildung zeigt die Darstellung
+gesendet. Dieses \textit{Acknowledgement} beinhaltet, in verschlüsselter Form, den Namen des \textit{Senders} der Nachricht. Somit
+kann der \textit{Sender} die für ihn bestimmten \textit{Acknowledgements} zuordnen. Abbildung \ref{position} zeigt die Darstellung
einer Position eines anderen Benutzers.
\begin{figure}[!ht]
\centering
\includegraphics[width=8cm]{Bilder/position}
\caption{Ausgabe einer Benutzerposition}
+ \label{position}
\end{figure}
\subsubsection{Erzeugen eines 2D-Barcodes}
Um einen 2D-Barcode zu erstellen wird eine Zeichenkette benötigt. Aus dieser werden durch die Nutzung von \textit{qrencode}
-\footnote{libqrencode \url{http://megaui.net/fukuchi/works/qrencode/index.en.html}} Bilddaten generiert. Diese werden im
-nächsten Schritt durch \textit{libpng} \footnote{libpng \url{http://www.libpng.org/}} gerendert und auf das Speichermedium
-geschrieben. Dieses Bild wird dann durch die \textit{GUI} geladen und ausgegeben. Die folgende Abbildung zeigt einen solchen
-erstellten Barcode, wie er von \textit{Friend Finder} ausgegeben wird.
+\footnote{libqrencode http://megaui.net/fukuchi/works/qrencode/index.en.html\newline[Online; letzter Aufruf 11.02.2010]}
+Bilddaten
+generiert. Diese werden im nächsten Schritt durch \textit{libpng}\footnote{libpng http://www.libpng.org/ [Online; letzter
+Aufruf 11.02.2010]} gerendert und auf das Speichermedium geschrieben. Dieses Bild wird dann durch die \textit{GUI} geladen und
+ausgegeben. Die Abbildung \ref{barcode} zeigt einen solchen erstellten Barcode, wie er von \textit{Friend Finder} ausgegeben wird.
+Wenn nun Schlüssel ausgetauscht werden so kann nun ein anderer Nutzer den ausgegebenen Barcode mit der Kamera seines
+Mobiltelefones fotographieren. Im Anschluss kann aus dem auf dem Foto abgebildeten 2D-Barcode, mit Hilfe von \textit{qrencode},
+wieder eine Zeichenkette erstellt und als Schlüssel genutzt werden.
\begin{figure}[!ht]
\centering
\includegraphics[width=8cm]{Bilder/barcode}
\caption{2D-Barcode mit \textit{Friend Finder}}
+ \label{barcode}
\end{figure}
@@ -103,80 +129,91 @@ erstellten Barcode, wie er von \textit{Friend Finder} ausgegeben wird.
\subsection{Analyse}
-Beim versenden der Daten durch \textit{Friend Finder} soll möglichst wenig Datenoverhead produziert und
+Beim Versenden der Daten durch \textit{Friend Finder} soll möglichst wenig Datenoverhead produziert und
versendet werden. Unter Datenoverhead werden Hintergrunddaten gesehen, welche versendet werden um die Verbindung aufrecht zu
-erhalten oder um die Anzahl der verfügbaren Teilnehmer zu überprüfen. \newline
+erhalten oder um die Anzahl der verfügbaren Teilnehmer zu überprüfen, aber nichts mit den eigentlichen Daten zu tun haben.
+\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. Ein Interessanter Punkt stellt die Frage dar, wie sich
das versendete Datenaufkommen im Vergleich zu einer Lösung verhält, welche die Daten an jeden Teilnehmer einzeln verschickt.
Hier ist besonders von Interesse, ob der Datenoverhead den Vorteil eines \textit{Broadcast}-Mediums wie ein \textit{IRC}-Channel
revidiert oder nicht. \newline
-Der \textit{Traffic} wurde mit Hilfe des Programmes \textit{Wireshark} \footnote {Wireshark \url{http://www.wireshark.org/}}
-untersucht. Wie bereits erwähnt wird zum Versenden der Nachrichten das \textit{IRC}-Protokoll verwendet. In dieser Testumgebung
-wurde die Software \textit{IRCD-Hybrid} \footnote{IRCD \url{http://www.ircd-hybrid.org/}} genutzt. Der Server lief auf dem
-gleichen Computer wie der Client. Der Client hat sich in diesem Szenario über das \textit{localhost} Interface mit dem Server
-verbunden. \newline
+Der \textit{Traffic} wurde mit Hilfe des Programmes \textit{Wireshark}\footnote {Wireshark http://www.wireshark.org/
+[Online; letzter Aufruf 27.01.2010]} untersucht. Wie bereits erwähnt wird zum Versenden der Nachrichten das \textit{IRC}-Protokoll
+verwendet. In dieser Testumgebung wurde die Software \textit{IRCD-Hybrid}\footnote{IRCD http://www.ircd-hybrid.org/
+[Online; letzter Aufruf 27.01.2010]} genutzt. Der Server lief auf dem gleichen Computer wie der Client. Der Client hat sich in
+diesem Szenario ü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 der Datenverkehr beim Versenden und Empfangen von Positionen
-genauer betrachtet. Alle folgenden Größen sich nur auf die Größe des Datenfeldes, exklusiv der Header.
+genauer betrachtet. Alle folgenden Größen beziehen sich nur auf die Größe des Datenfeldes, exklusive der Header.
\subsubsection{Allgemeiner Datenverkehr}
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
+Nachrichten werden alle 30 Sekunden zwischen Server und Client ausgetauscht. Die Größe einer
+solchen Nachricht beträgt 24 Byte. Das Antwortpaket, welches vom Server an den Client gesendet wird, 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.
+Größe auch Abhängig von der Länge der Benutzernamen sowie des Namens des \textit{Channels} und Servers ist.
\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``. Dieses Paket hat ein Datenfeld
-der Größe von 99 Byte.\newline
+\textit{Friend Finder} teilt den Satz ''Hello World`` in zwei Teile auf: ''Hello `` und ''World``. Das resultierende Paket hat
+eine Größe von 99 Byte.\newline
Die versendete Textnachricht hat im unverschlüsselten Format die Größe von elf Byte. Nach der Verschlüsselung werden beim Senden
noch Informationen bezüglich \textit{Channel} und der Empfänger der Nachricht in das zu versendende \textit{IRC}-Paket
-geschrieben. Nach der \textit{Base64}-Kodierung hat sich die Größe der Nachricht circa um den Faktor $9$ vergrößert.\newline
-Wenn $h$ die Größe des \textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht ist, so ergibt sich die
-ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 9)$.
+geschrieben. Nach der \textit{Base64}-Kodierung hat sich die Größe der Nachricht circa um den Faktor neun vergrößert.\newline
+Wenn $h$ die Größe des \textit{TCP-Headers} und $t$ die Anzahl der Zeichen einer unverschlüsselten Nachricht repräsentiert, so
+ergibt sich die 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 gepackt. Bei der Messung wurden vier
-Verschiedene Pakete, mit jeweils unterschiedlichen versandten Positionen untersucht. Dabei betrug sich die Größe des Datenfeldes
-um die 430 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.
+Wie schon erwähnt, werden die Positionsdaten beim Sender aufgeteilt und mit vier unterschiedlichen Nachrichten versandt. Bei der
+Messung wurden vier Verschiedene Pakete, mit jeweils unterschiedlichen versandten Positionen untersucht. Dabei betrug sich die
+Größe des Datenfeldes im Mittel um die 430 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 1 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 \textit{Acknowledgement} gesendet wird. Die Größe der eines \textit{Acknowledgment} Paketes beträgt
-zwischen 147 und 153
+Faktor zwanzig. Wenn $h$ die Größe des \textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht
+darstellt, ergibt sich die Größe der versendeten Nachricht circa durch $h + (t \cdot 20)$. Hinzu kommt noch, das für jedes
+empfangene Positions-Fragment ein \textit{Acknowledgement} gesendet wird. Die Größe der eines \textit{Acknowledgment} Paketes
+beträgt zwischen 147 und 153
Byte. In einem solchen Paket werden vier Acknowledgments zusammengefasst.\newline
-Folglich kann Folgende Formel für den Datenverkehr pro versendeter Position, bei $n$ Teilnehmern hergeleitet werden:
+Daraus kann Folgende Formel für den Datenverkehr pro versendeter Position, bei $n$ Teilnehmern 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}
Die Hintergrunddaten welche vom \textit{IRC}-Protokoll versandt werden ergeben einen geringen, in Kauf zu nehmenden Datenoverhead.
-Allerdings ist der große Vorteil von \textit{IRC}, dass die \textit{Channels} als \textit{Broadcast}-Medium genutzt werden können.
+Der große Vorteil von \textit{IRC} ist, dass die \textit{Channels} als \textit{Broadcast}-Medium genutzt werden können.
Diese Tatsache macht es möglich, Daten $n$ Teilnehmer zugänglich zu machen und dabei diese nur einmal, über eine aktive
Verbindung, zu senden. Berücksichtigt man dies, so fällt, der ohnehin geringe Datenoverhead, nicht mehr ins Gewicht. Würde man
diese Daten über $n$ getrennte Verbindungen an die Teilnehmer versenden, so müssten ebensoviele Verbindungen geöffnet werden und
die Daten anstelle von einmal, $n$ Mal versandt werden.\newline
-In der folgenden Graphik wird das Versenden der Daten über $n$ getrennte Verbindungen, sowie die in\textit{Friend Finder}
-implementierte Methode verglichen. Es wird angenommen das die versandten Positionsdaten eine Größe von 430 Byte, und ein
-\textit{Acknowledgement} 150 Byte haben. Des weiteren wird angenommen dass alle Nutzer die Daten
+In der folgenden Graphik \ref{graph} wird das Versenden der Daten über $n$ getrennte Verbindungen, sowie die in \textit{Friend
+Finder} implementierte Methode, zu einem beliebigen Zeitpunkt $t$ verglichen. Es wird angenommen das die versandten Positionsdaten
+eine Größe von 430 Byte, und ein \textit{Acknowledgement} 150 Byte haben. Des weiteren wird angenommen dass alle Nutzer die Daten
empfangen auch Positionsdaten senden und somit auch $4 \cdot n$ \textit{Acknowledgements} versandt werden müssen. Daraus ergibt
-sich die Formel $(n \cdot 430) + (n \cdot 4 \cdot 150)$.
+sich die Formel $(n \cdot 430) + (n \cdot 4 \cdot 150)$, welche als Grundlage für die Abbildung \ref{graph} dient. Die Abbildung
+\ref{graph2} zeigt dass Datenaufkommen der zwei verschiedenen Methoden innerhalb eines Zeitraums von 25 Sekunden, gegeben dass die
+Positionsdaten alle drei Sekunden versandt werden.
\begin{figure}[!ht]
\centering
\includegraphics[width=10cm]{Bilder/graph}
\caption{Vergleich von $n$-Verbindungen und \textit{Friend Finder}}
+ \label{graph}
\end{figure}
+
+\begin{figure}[!ht]
+\centering
+ \includegraphics[width=10cm]{Bilder/graph2}
+ \caption{Versandte Daten über die Zeit von $n$-Verbindungen und \textit{Friend Finder}}
+ \label{graph2}
+\end{figure} \ No newline at end of file