summaryrefslogtreecommitdiffstats
path: root/ausarbeitung/Friend_Finder.tex.backup
diff options
context:
space:
mode:
authorPatrick Hornecker2010-02-14 16:47:11 +0100
committerPatrick Hornecker2010-02-14 16:47:11 +0100
commitd87ceaf676e137bffa3e6fb57ee3260a92db0f28 (patch)
tree0de81397eb0b529fd4c40ea886bb9b90cd59a4bd /ausarbeitung/Friend_Finder.tex.backup
parenttex source (diff)
downloadfriendfinder-d87ceaf676e137bffa3e6fb57ee3260a92db0f28.tar.gz
friendfinder-d87ceaf676e137bffa3e6fb57ee3260a92db0f28.tar.xz
friendfinder-d87ceaf676e137bffa3e6fb57ee3260a92db0f28.zip
improved sender and receiver
Diffstat (limited to 'ausarbeitung/Friend_Finder.tex.backup')
-rw-r--r--ausarbeitung/Friend_Finder.tex.backup104
1 files changed, 65 insertions, 39 deletions
diff --git a/ausarbeitung/Friend_Finder.tex.backup b/ausarbeitung/Friend_Finder.tex.backup
index 33904f7..16fe9ee 100644
--- a/ausarbeitung/Friend_Finder.tex.backup
+++ b/ausarbeitung/Friend_Finder.tex.backup
@@ -1,8 +1,9 @@
\section{Friend Finder}
Die eingangs beschriebene Software hat den Namen \textit{Friend Finder} und wurde im Rahmen dieser Arbeit mit fast allen
-aufgezählten Funktionen realisiert. Das fotographieren des Barcodes sowie der Gruppenchat sind in der Implementation nicht
-enthalten. Im folgenden wird auf die Verwendeten Verfahren sowie Bibliotheken, die zur Realisierung notwendig waren, eingegangen.
+aufgezählten Funktionen realisiert. Das fotographieren des Barcodes, der Gruppenchat sowie das Setzen von Marken auf der Kartesind
+in der Implementation nicht enthalten. Im folgenden wird auf die Verwendeten Verfahren sowie Bibliotheken, die zur Realisierung
+notwendig waren, eingegangen.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -12,7 +13,7 @@ enthalten. Im folgenden wird auf die Verwendeten Verfahren sowie Bibliotheken, d
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
+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
@@ -21,25 +22,25 @@ empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{E
\begin{figure}[h]
\centering
- \includegraphics[width=10cm]{Bilder/ablauf}
+ \includegraphics[width=7cm]{Bilder/ablauf}
\caption{\textit{Friend Finder} Nachrichtenaustausch}
\end{figure}
\subsubsection{Grafisches Benutzeroberfläche}
-Zum erstellen der Oberfläche wurde \textit{Enlightenment} verwendet. Diese Bibliothek stellt alle benötigten Funktionen bereit und
-bietet eine Fülle an vordefinierten Oberflächenelement. Der gesammte Programmcode der Benutzeroberfläche wurde in einer Datei
+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 einfach nur diese Datei
-durch eine andere ersetzen werden muss um einen anderen Typ von Oberfläche zu benutzen. \newline
+durch eine andere ersetzt werden muss um einen anderen Typ von Oberfläche zu benutzen. \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
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.
+realisiert. Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap} \citep{OSM} genutzt.
\subsubsection{Versenden der Nachrichten}
-Um Daten im Allgemeinen zu versenden wurde das \textit{IRC}-Protokoll \citep{IRC} verwendet. Die
+Um Daten im Allgemeinen zu versenden wurde das \textit{IRC}-Protokoll verwendet. Die
Vorteile dieses Protokolles liegen in seiner weiten Verbreitung, einer ausgedehnten Serverstruktur, sowie in dessen
Stabilität.\newline
@@ -47,17 +48,23 @@ In der Datei \textit{msg\_sender.c} sind alle Funktionen und Aufrufe implementie
\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
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)}" , welcher zur Benutzeroberfläche gehört, übergeben.
+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.
Bei der Implementerierung des Nachrichtenversandes ist eine Besonderheit zu erwähnen. Das genutzte Verschlüsselungsverfahren
\textit{Blowfish} wurde seitens der \textit{OpenSSL}\citep{OpenSSL} Bibliothek als \textit{Blockcipher} implementiert. 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, versendet und beim
+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
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.\newline
+arbeiten müssen. In der folgenden Abbildung ist eine Konversation über \textit{Friend Finder} zu sehen.\newline
+
+\begin{figure}[h]
+\centering
+ \includegraphics[width=5cm]{Bilder/chat}
+ \caption{Versenden von Chatnachrichten}
+\end{figure}
Um Nachrichten zu versenden wurde für dieses Projekt die \textit{IRC-Client Bibliothek}\citep{libircclient} verwendet. Diese
\textit{library} bietet verschiedene Funktionen um eine Verbindung mit einem \textit{IRC-Server} zu erstellen und Nachrichten an
@@ -72,12 +79,15 @@ Verfahren, bei welchem alle Teilnehmer den gleichen privaten Schlüssel zum ver-
Der benötigte Programmcode zum Versenden der eigenen Position ist in der Datei \textit{sender.c} zu finden. Auch hier muss zuerst
eine \textit{IRC-Session} initialisiert werden um danach die Position zu versenden. Der Ablauf beim Senden der Positionen erfolgt
in einer vorgegebenen Reihenfolge. Zuerst wird der verschlüsselte Längengrad, danach der verschlüsselte Breitengrade gesendet.
-Daraufhin werden solange keine Daten mehr gesendet, bis der Empfänger eine Bestätigung an den \textit{IRC-Kanal} sendet. Diese
-Bestätigung ist unverschlüssel. Kommt dieses \textit{Acknowledgement} beim Sender an, so versendet dieser wieder ein
-\textit{Latitude/Longtitude Paar}.\newline
+Allerdings muss auch hier, wie beim Versenden der Textnachrichten, darauf geachtet werden dass maximal eine Zeichenkette der
+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. Somit werden für das Versenden einer Position insgesamt acht 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 ist wird unverschlü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.
+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}
@@ -85,11 +95,19 @@ noch nicht final....empfänger empfängt nachricht, ordnet sie, leitet sie zum z
\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
+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
dann 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} genutzt. Diese erstellt aus einer Zeichenkette einen
-2D-Barcode. Aus den Bilddaten dieses Barcodes wurde mit \textit{libpng} eine \textit{.png} Datei erstellt.
+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
+erstellt. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er von \textit{Friend Finder} ausgegeben wird.
+
+\begin{figure}[h]
+\centering
+ \includegraphics[width=5cm]{Bilder/barcode}
+ \caption{2D-Barcode mit \textit{Friend Finder}}
+\end{figure}
+
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -105,8 +123,8 @@ 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} genutzt. Der Server lief auf dem gleichen Computer wie
-der Client und wurde über das \textit{localhost} Interface mit dem Client verbunden. \newline
+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
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
@@ -115,8 +133,8 @@ Positionen, unter die Lupe genommen.
\subsubsection{Allgemeiner Datenverkehr}
-Bei Messung des allgemeinen Datenaufkommens mit eine normalen \textit{IRC-Clients}, hier \textit{X-Chat}, ergeben sich folgender
-Datenverkehr. \newline
+Bei Messung des allgemeinen Datenaufkommens mit eine normalen \textit{IRC-Clients}, hier \textit{X-Chat} \citep{xchat}, ergeben
+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.
@@ -124,18 +142,25 @@ Bei im folgenden genannten Paketgrößen sind diese 52 Byte schon abgezogen. \ne
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 der aktiven Nutzer in diesem \textit{Channel}
sowie welche Rechter 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 Server alle 30 Sekunden ein \textit{Ping} Paket an den
-Client, welches dieser mit einem \textit{Pong} beantwortet. Diese Pakete haben eine Größe von 40 Byte für die \textit{Ping}
+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 noch 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 das 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 und somit immer Datenverkehr zwischen Sender und \textit{IRC}-Server vorhanden 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-}
+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
Beachtet man dass ein \textit{char} in \textit{C} die Größe von einem Byte hat und der Beispielsatz aus elf Zeichen besteht, so
@@ -147,12 +172,13 @@ Länge der zu versendenden Nachricht aus: $h + (t * 2,6)$.
\subsubsection{Fazit der Auswertung}
-Zur Analyse des Allgemeinen Datenverkehrs ist zu sagen dass Aufgrund der Tatsache dass das \textit{IRC-Protokoll}
-auf \textit{TCP/IP} bassiert, eine großer Overhead an Paketen versandt wird. Somit werde wesentlich mehr Pakete als
-nur die benötigten Daten verschickt. Hinzu kommen noch Pakete welche zur ständigen Kommunikation zwischen Server und
-Client ausgetauscht werden.
+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.
-Um den den von \textit{TCP} generierten Datenoverhead zu minimieren, wäre auch das versenden von Daten über \textit{UDP}
-interessant. Dies gilt weniger für das versenden der Textnachrichten sondern eher für das versenden der Positionen. Hier werden,
-wenn mehrere User aktiv sind, ständig Positionsdaten und Acknowledgements zwischen Server und Clients ausgetauscht. Somit könnte
-durch die Nutzung von \textit{UDP} hier einiges an versendeten Packeten gespart werden.\newline