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.tex73
1 files changed, 38 insertions, 35 deletions
diff --git a/ausarbeitung/Friend_Finder.tex b/ausarbeitung/Friend_Finder.tex
index 88fc5c9..6f800ac 100644
--- a/ausarbeitung/Friend_Finder.tex
+++ b/ausarbeitung/Friend_Finder.tex
@@ -1,8 +1,7 @@
\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, 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
+Die Eingangs beschriebene Software trägt den Namen \textit{Friend Finder} und wurde im Rahmen dieser Arbeit mit fast allen
+aufgezählten Funktionen realisiert. Im folgenden wird auf die verwendeten Verfahren sowie Bibliotheken, die zur Realisierung
notwendig waren, eingegangen.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -30,8 +29,8 @@ 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 einfach nur diese Datei
-durch eine andere ersetzt werden muss um einen anderen Typ von Oberfläche zu benutzen. \newline
+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
Modulen in dieser Datei implementiert. \newline
@@ -42,7 +41,7 @@ realisiert. Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \t
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. Ein weiterer Vorteil ist, dass man Daten die an mehrere Benutzer gesendet werden nur einmal an einen
+Stabilität. Ein weiterer Vorteil ist, dass man Daten die an mehrere Benutzer gesendet werden sollen, nur einmal an einen
\textit{Channel} senden muss und jeder Benutzer in diesem \textit{Channel} diese Daten empfangen kann.\newline
In der Datei \textit{msg\_sender.c} sind alle Funktionen und Aufrufe implementiert, welche nötig sind um die Verbindung zum
@@ -52,10 +51,11 @@ den \textit{Nickname} des Benutzers oder die \textit{IP-Adresse} des Servers. Na
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, versandt und beim
-Empfänger wieder zusammengesetzt. \newline
+\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
+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
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
@@ -68,9 +68,9 @@ arbeiten müssen. In der folgenden Abbildung ist eine Konversation über \textit
\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
+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
+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.
@@ -82,9 +82,9 @@ eine \textit{IRC-Session} initialisiert werden um danach die Position zu versend
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 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.
+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 ist wird unverschlüsselt versandt. Kommt dieses
+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
Auch hier wird, wie beim Versenden der Nachrichten zum Verschlüsseln der \textit{Blowfish-Algorithmus} aus
@@ -96,23 +96,24 @@ Das Verhalten des Empfängers beim Erhalten einer Nachricht ist etwas komplizier
\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
+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
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.
+\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
-dann ein Barcode erstellt, welcher im darauf folgenden Schritt als \textit{.png} Datei auf das Speichermedium geschrieben 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
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.
+generiert. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er von \textit{Friend Finder} ausgegeben wird.
\begin{figure}[!ht]
\centering
@@ -145,28 +146,30 @@ Positionen, unter die Lupe genommen.
\subsubsection{Allgemeiner Datenverkehr}
-Bei Messung des allgemeinen Datenaufkommens mit eine normalen \textit{IRC-Clients}, hier \textit{X-Chat} \citep{xchat}, ergeben
+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 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 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
+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 das er nicht mehr verbunden ist. Allerdings wird
+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 und somit immer Datenverkehr zwischen Sender und \textit{IRC}-Server vorhanden ist. \newline
+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
\subsubsection{Versenden und Empfangen von Nachrichten}