summaryrefslogtreecommitdiffstats
path: root/ausarbeitung
diff options
context:
space:
mode:
authorPatrick Hornecker2010-02-25 11:09:06 +0100
committerPatrick Hornecker2010-02-25 11:09:06 +0100
commitf8b9531d4d902babb7eccaa4c371f3ace720551d (patch)
tree8dc74d24a1b5d96df423fece3ec74341aa057fbd /ausarbeitung
parenttex source (diff)
downloadfriendfinder-f8b9531d4d902babb7eccaa4c371f3ace720551d.tar.gz
friendfinder-f8b9531d4d902babb7eccaa4c371f3ace720551d.tar.xz
friendfinder-f8b9531d4d902babb7eccaa4c371f3ace720551d.zip
tex source and code modifications
Diffstat (limited to 'ausarbeitung')
-rw-r--r--ausarbeitung/Anhang.aux6
-rw-r--r--ausarbeitung/Bilder/graph.pngbin0 -> 7086 bytes
-rw-r--r--ausarbeitung/Bilder/position.pngbin0 -> 359171 bytes
-rw-r--r--ausarbeitung/Einleitung.tex8
-rw-r--r--ausarbeitung/Einleitung.tex~2
-rw-r--r--ausarbeitung/Fazit.aux8
-rw-r--r--ausarbeitung/Fazit.tex10
-rw-r--r--ausarbeitung/Fazit.tex.backup3
-rw-r--r--ausarbeitung/Fazit.tex~25
-rw-r--r--ausarbeitung/Friend_Finder.aux25
-rw-r--r--ausarbeitung/Friend_Finder.tex206
-rw-r--r--ausarbeitung/Friend_Finder.tex.backup203
-rw-r--r--ausarbeitung/Friend_Finder.tex~206
-rw-r--r--ausarbeitung/Grundlagen.aux6
-rw-r--r--ausarbeitung/Grundlagen.tex160
-rw-r--r--ausarbeitung/Grundlagen.tex.backup132
-rw-r--r--ausarbeitung/Grundlagen.tex~163
-rw-r--r--ausarbeitung/Tutorial.aux15
-rw-r--r--ausarbeitung/Tutorial.tex121
-rw-r--r--ausarbeitung/Tutorial.tex.backup154
-rw-r--r--ausarbeitung/Tutorial.tex~122
-rw-r--r--ausarbeitung/literature.bib146
-rw-r--r--ausarbeitung/literature.bib.backup146
-rw-r--r--ausarbeitung/literature.bib~144
-rw-r--r--ausarbeitung/maindoc.aux42
-rw-r--r--ausarbeitung/maindoc.bbl97
-rw-r--r--ausarbeitung/maindoc.blg85
-rw-r--r--ausarbeitung/maindoc.log295
-rw-r--r--ausarbeitung/maindoc.out4
-rw-r--r--ausarbeitung/maindoc.pdfbin1475283 -> 1777057 bytes
-rw-r--r--ausarbeitung/maindoc.tex5
-rw-r--r--ausarbeitung/maindoc.tex~5
-rw-r--r--ausarbeitung/maindoc.toc14
33 files changed, 937 insertions, 1621 deletions
diff --git a/ausarbeitung/Anhang.aux b/ausarbeitung/Anhang.aux
index 3bb2fdb..fb73ab2 100644
--- a/ausarbeitung/Anhang.aux
+++ b/ausarbeitung/Anhang.aux
@@ -1,12 +1,12 @@
\relax
\@setckpt{Anhang}{
-\setcounter{page}{33}
+\setcounter{page}{34}
\setcounter{equation}{0}
\setcounter{enumi}{0}
\setcounter{enumii}{0}
\setcounter{enumiii}{0}
\setcounter{enumiv}{0}
-\setcounter{footnote}{0}
+\setcounter{footnote}{23}
\setcounter{mpfootnote}{0}
\setcounter{part}{0}
\setcounter{section}{0}
@@ -14,7 +14,7 @@
\setcounter{subsubsection}{4}
\setcounter{paragraph}{0}
\setcounter{subparagraph}{0}
-\setcounter{figure}{5}
+\setcounter{figure}{7}
\setcounter{table}{0}
\setcounter{NAT@ctr}{0}
\setcounter{parentequation}{0}
diff --git a/ausarbeitung/Bilder/graph.png b/ausarbeitung/Bilder/graph.png
new file mode 100644
index 0000000..9f0fcd0
--- /dev/null
+++ b/ausarbeitung/Bilder/graph.png
Binary files differ
diff --git a/ausarbeitung/Bilder/position.png b/ausarbeitung/Bilder/position.png
new file mode 100644
index 0000000..a0b5ae3
--- /dev/null
+++ b/ausarbeitung/Bilder/position.png
Binary files differ
diff --git a/ausarbeitung/Einleitung.tex b/ausarbeitung/Einleitung.tex
index a368adf..6acd457 100644
--- a/ausarbeitung/Einleitung.tex
+++ b/ausarbeitung/Einleitung.tex
@@ -16,7 +16,7 @@ Bewegungsprofile des Benutzers erstellt werden.\newline
Anwendungen dieser Art können also einen nützlichen Dienst erbringen, allerdings können die entstehenden Daten auch
missbraucht werden. Es ist also wichtig das die Positionsinformationen, die der Benutzer bereitstellt, als ein Teil seiner
Privatsphäre angesehen werden. \newline
-Das Ziel dieser Arbeit ist die Implementation eines Dienstes, welcher es ermöglicht anderen Benutzern die eigene Position zu
-senden, sowie deren anzuzeigen. Hierbei soll für den Benutzer möglichst viel Transparenz geboten sein, so dass er immer in der
-Lage ist nachzuvollziehen was mit seinen Daten geschieht. Diese sollen allerdings trotzdem durch Verschlüsselung soweit
-geschützt werden, als das der Anwender bestimmen kann für wenn diese einsehbar sind. \ No newline at end of file
+Das Ziel dieser Arbeit ist die Implementation einer Anwendung für mobile Geräte, welcher es ermöglicht anderen Benutzern die
+eigene Position zu senden, sowie deren anzuzeigen. Hierbei soll für den Benutzer möglichst viel Transparenz geboten sein, so dass
+er immer in der Lage ist nachzuvollziehen was mit seinen Daten geschieht. Diese sollen allerdings trotzdem durch Verschlüsselung
+soweit geschützt werden, als das der Anwender bestimmen kann für wenn diese einsehbar sind. \ No newline at end of file
diff --git a/ausarbeitung/Einleitung.tex~ b/ausarbeitung/Einleitung.tex~
index b9c10df..a368adf 100644
--- a/ausarbeitung/Einleitung.tex~
+++ b/ausarbeitung/Einleitung.tex~
@@ -18,5 +18,5 @@ missbraucht werden. Es ist also wichtig das die Positionsinformationen, die der
Privatsphäre angesehen werden. \newline
Das Ziel dieser Arbeit ist die Implementation eines Dienstes, welcher es ermöglicht anderen Benutzern die eigene Position zu
senden, sowie deren anzuzeigen. Hierbei soll für den Benutzer möglichst viel Transparenz geboten sein, so dass er immer in der
-Lage ist nachzuvollziehen was mit seinen Daten geschieht. Diese sollen allerdings trotz allem durch Verschlüsselung soweit
+Lage ist nachzuvollziehen was mit seinen Daten geschieht. Diese sollen allerdings trotzdem durch Verschlüsselung soweit
geschützt werden, als das der Anwender bestimmen kann für wenn diese einsehbar sind. \ No newline at end of file
diff --git a/ausarbeitung/Fazit.aux b/ausarbeitung/Fazit.aux
index 1ba57ac..f3d68a1 100644
--- a/ausarbeitung/Fazit.aux
+++ b/ausarbeitung/Fazit.aux
@@ -1,13 +1,13 @@
\relax
-\@writefile{toc}{\contentsline {section}{\numberline {5}Fazit}{20}{section.5}}
+\@writefile{toc}{\contentsline {section}{\numberline {5}Fazit}{21}{section.5}}
\@setckpt{Fazit}{
-\setcounter{page}{21}
+\setcounter{page}{22}
\setcounter{equation}{0}
\setcounter{enumi}{0}
\setcounter{enumii}{0}
\setcounter{enumiii}{0}
\setcounter{enumiv}{0}
-\setcounter{footnote}{0}
+\setcounter{footnote}{23}
\setcounter{mpfootnote}{0}
\setcounter{part}{0}
\setcounter{section}{5}
@@ -15,7 +15,7 @@
\setcounter{subsubsection}{4}
\setcounter{paragraph}{0}
\setcounter{subparagraph}{0}
-\setcounter{figure}{5}
+\setcounter{figure}{7}
\setcounter{table}{0}
\setcounter{NAT@ctr}{0}
\setcounter{parentequation}{0}
diff --git a/ausarbeitung/Fazit.tex b/ausarbeitung/Fazit.tex
index 60602c2..c9e6dd5 100644
--- a/ausarbeitung/Fazit.tex
+++ b/ausarbeitung/Fazit.tex
@@ -1,2 +1,12 @@
\section{Fazit}
+Im Rahmen dieser Arbeit konnte gezeigt werden, dass es möglich ist einen Dienst zu entwickeln welcher die eigene Position und die
+anderer Teilnehmer anzeigt und dabei eine offene Struktur, in Form des \textit{IRC}-Netzwerkes, nutzt. Dem Anwender ist somit die
+Möglichkeit gegeben die Kontrolle über die Nutzung seiner Daten zu wahren, da er seine versendeten Daten dank der genutzten
+Struktur stets einsehen kann. Des Weiteren kann er, durch Weitergabe der Schlüssel, bestimmen wer Einsicht in seine
+Positionsinformationen erlangen darf. Der Austausch der Schlüssel wurde mit der Methode der 2D-Barcodes so gelößt, dass dieser
+spontan und im mobilen Umfeld stattfinden kann, ohne dabei eine langfristige Vorausplanung zu benötigen. \newline
+Es wurde aufgezeigt, dass die Implementierung eines solchen Dienstes mit bereits vorhandenen Algorithmen und Bibliotheken
+sinvoll umsetzbar ist. In der Analyse des Datenverkehrs wurde aufgezeigt, dass das \textit{IRC}-Netzwerk beim versenden von Daten
+nur einen geringen Datenoverhead produziert. Des weiteren eignet es sich für die Kommunikation mit mehreren Teilnehmern, da hier
+nur eine Verbindung geöffnet werden muss. \ No newline at end of file
diff --git a/ausarbeitung/Fazit.tex.backup b/ausarbeitung/Fazit.tex.backup
index c17630d..60602c2 100644
--- a/ausarbeitung/Fazit.tex.backup
+++ b/ausarbeitung/Fazit.tex.backup
@@ -1 +1,2 @@
-\section{Fazit} \ No newline at end of file
+\section{Fazit}
+
diff --git a/ausarbeitung/Fazit.tex~ b/ausarbeitung/Fazit.tex~
index 629ccfb..fd15118 100644
--- a/ausarbeitung/Fazit.tex~
+++ b/ausarbeitung/Fazit.tex~
@@ -1,17 +1,12 @@
\section{Fazit}
-Anhaden der Anforderungen und der implementierten Features von \textit{Friend Finder} ist ersichtbar das es möglich ist einen
-sicheren Dienst, welcher die \textit{location privacy} achtet, zu entwerfen und programmieren. Dieser verschlüsselt die
-versendeten Nachrichten und
-verzichtet auf einen zentralisierten Dienst ohne dabei an Verlässlichkeit einzubüßen. Auch das Datenaufkommen, sowie die
-Berechnungszeit der Verschlüsselung kann bei richtiger Implementierung gering gehalten werden. Somit wird auch der Akku von
-mobilen Geräten geschont. \newline
-Es ist also möglich solche Dienste, die die Privatsphäre eines Nutzers betreffen, auch unter dem Aspekt der Sicherheit zu
-implementieren und somit diese zu Garantieren. Die gegebenen Möglichkeiten eines Missbrauchs der versandten Daten sind
-somit stark eingeschränkt und diese können nicht mehr ohne weiteres eingesehen werden. Des weiteren können mit Hilfe von
-2D-Barcodes die, zur Verschlüsselung benötigten, Schlüssel einfach und ohne Risiko ausgetauscht werden. \newline
-Bei richtiger Wahl der Programmiersprache sowie der Schnittstellen und genutzten Bibliotheken kann man des weiteren eine größere
-Menge von Betriebssystemen für Smart Phones abdecken und somit mehr Nutzer erreichen, ohne die Software in unterschiedlichen
-Sprachen und mit unterschiedlichen Bibliotheken implementieren zu müssen. Gerade diese und die Tatsache das die Betriebsysteme für
-mobile Geräte immer mehr die gleichen Schnittstellen nutzen, zum Beispiel den \textit{POSIX-Layer} könnte es in der Zukunft
-ermöglichen Programme noch einfacher zu portieren und den Aufwand bei Entwurf und Design geringer zu halten. \ No newline at end of file
+Im Rahmen dieser Arbeit konnte gezeigt werden, dass es möglich ist einen Dienst zu entwickeln welcher die eigene Position und die
+anderer Teilnehmer anzeigt und dabei eine offene Struktur, in Form des \textit{IRC}-Netzwerkes, nutzt. Dem Anwender ist somit die
+Möglichkeit gegeben die Kontrolle über die Nutzung seiner Daten zu wahren, da er seine versendeten Daten dank der genutzten
+Struktur stets einsehen kann. Des Weiteren kann er, durch Weitergabe der Schlüssel, bestimmen wer Einsicht in seine
+Positionsinformationen erlangen darf. Der Austausch der Schlüssel wurde mit der Methode der 2D-Barcodes so gelößt, dass dieser
+spontan und im mobilen Umfeld stattfinden kann, ohne dabei eine langfristige Vorausplanung zu benötigen. \newline
+Es wurde aufgezeigt, dass die Implementierung eines solchen Dienstes mit bereits vorhandenen Algorithmen und Bibliotheken
+sinvoll umsetzbar ist. In der Analyse des Datenverkehrs wurde aufgezeigt, dass das \textit{IRC}-Netzwerk beim versenden von Daten
+nur einen geringen Datenoverhead produziert. Des weiteren eignet es sich für die Kommunikation mit mehreren Teilnehmern, ohne das
+dabei zusätzliche Verbindungen eröffnet werden müssen. \ No newline at end of file
diff --git a/ausarbeitung/Friend_Finder.aux b/ausarbeitung/Friend_Finder.aux
index f0ab058..f5d7ead 100644
--- a/ausarbeitung/Friend_Finder.aux
+++ b/ausarbeitung/Friend_Finder.aux
@@ -1,37 +1,30 @@
\relax
-\citation{OSM}
\citation{blowfish}
-\citation{OpenSSL}
-\citation{base64}
\@writefile{toc}{\contentsline {section}{\numberline {4}Friend Finder}{13}{section.4}}
\@writefile{toc}{\contentsline {subsection}{\numberline {4.1}Verwendete Verfahren und Bibliotheken}{13}{subsection.4.1}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.1}Grafisches Benutzeroberfl\IeC {\"a}che}{13}{subsubsection.4.1.1}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.2}Versenden der Nachrichten}{13}{subsubsection.4.1.2}}
\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces \textit {Friend Finder} Nachrichtenaustausch}}{14}{figure.3}}
-\citation{libircclient}
-\citation{OpenSSL}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.3}Versenden der eigenen Position}{14}{subsubsection.4.1.3}}
\@writefile{lof}{\contentsline {figure}{\numberline {4}{\ignorespaces Versenden von Chatnachrichten}}{15}{figure.4}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.3}Versenden der eigenen Position}{15}{subsubsection.4.1.3}}
-\citation{qrencode}
-\citation{PNG}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.4}Empfangen der eigenen Position}{16}{subsubsection.4.1.4}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.4}Empfangen von Positionen}{15}{subsubsection.4.1.4}}
+\@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces Ausgabe einer Benutzerposition}}{16}{figure.5}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.5}Erzeugen eines 2D-Barcodes}{16}{subsubsection.4.1.5}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {4.2}Analyse}{16}{subsection.4.2}}
-\citation{Wireshark}
-\citation{IRCD}
-\@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces 2D-Barcode mit \textit {Friend Finder}}}{17}{figure.5}}
+\@writefile{lof}{\contentsline {figure}{\numberline {6}{\ignorespaces 2D-Barcode mit \textit {Friend Finder}}}{17}{figure.6}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.2}Analyse}{17}{subsection.4.2}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.1}Allgemeiner Datenverkehr}{18}{subsubsection.4.2.1}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.2}Versenden und Empfangen von Nachrichten}{18}{subsubsection.4.2.2}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.3}Versenden und Empfangen von Positionen}{18}{subsubsection.4.2.3}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.4}Fazit der Auswertung}{19}{subsubsection.4.2.4}}
+\@writefile{lof}{\contentsline {figure}{\numberline {7}{\ignorespaces Vergleich von $n$-Verbindungen und \textit {Friend Finder}}}{20}{figure.7}}
\@setckpt{Friend_Finder}{
-\setcounter{page}{20}
+\setcounter{page}{21}
\setcounter{equation}{0}
\setcounter{enumi}{0}
\setcounter{enumii}{0}
\setcounter{enumiii}{0}
\setcounter{enumiv}{0}
-\setcounter{footnote}{0}
+\setcounter{footnote}{23}
\setcounter{mpfootnote}{0}
\setcounter{part}{0}
\setcounter{section}{4}
@@ -39,7 +32,7 @@
\setcounter{subsubsection}{4}
\setcounter{paragraph}{0}
\setcounter{subparagraph}{0}
-\setcounter{figure}{5}
+\setcounter{figure}{7}
\setcounter{table}{0}
\setcounter{NAT@ctr}{0}
\setcounter{parentequation}{0}
diff --git a/ausarbeitung/Friend_Finder.tex b/ausarbeitung/Friend_Finder.tex
index ea0d0b1..727ae69 100644
--- a/ausarbeitung/Friend_Finder.tex
+++ b/ausarbeitung/Friend_Finder.tex
@@ -1,16 +1,15 @@
\section{Friend Finder}
-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 und die Programmstruktur aufgezeigt.
+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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Verwendete Verfahren und Bibliotheken}
-\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
+\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.\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}.
@@ -25,38 +24,28 @@ Alle drei Teile geben ihre empfangenen Daten an die \textit{GUI} weiter, welche
\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 Bedienelement. Der gesammte Programmcode der Benutzeroberfläche wurde in einer Datei
-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
-Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap} \citep{OSM} genutzt.
+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.
\subsubsection{Versenden der Nachrichten}
-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 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
-\textit{IRC-Server} zu erstellen und die Nachrichten zu verschicken. Um eine Verbindung zu einem gegebenen \textit{IRC-Server} zu
-etablieren, muss eine \textit{IRC-Session} initialisiert werden. Diese \textit{Session} beinhaltet Informationen wie zum Beispiel
+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
+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. 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
-ist ein symmetrisches Verschlüsselungsverfahren. Das bedeutet, das immer nur maximal 64 Bit Nachrichten verschlüsselt werden
-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 Textkonversation mit \textit{Friend Finder} zu sehen.\newline
+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
+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.
\begin{figure}[!ht]
\centering
@@ -64,45 +53,44 @@ arbeiten müssen. In der folgenden Abbildung ist eine Textkonversation mit \text
\caption{Versenden von Chatnachrichten}
\end{figure}
-Um Nachrichten zu versenden wurde für dieses Projekt die \textit{IRC-Client Bibliothek}\citep{libircclient} verwendet. Diese
-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.
-
\subsubsection{Versenden der eigenen Position}
-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.
+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 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 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}
+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.
+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.
+
+\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
+einer Position eines anderen Benutzers.
-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.
+\begin{figure}[!ht]
+\centering
+ \includegraphics[width=8cm]{Bilder/position}
+ \caption{Ausgabe einer Benutzerposition}
+\end{figure}
\subsubsection{Erzeugen eines 2D-Barcodes}
-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.
+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.
\begin{figure}[!ht]
\centering
@@ -115,27 +103,27 @@ generiert. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er v
\subsection{Analyse}
-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 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
-
+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
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. Der Client hat sich über das \textit{localhost} Interface mit dem Server verbunden. \newline
-
+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
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 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.
+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.
\subsubsection{Allgemeiner Datenverkehr}
-Der Allgemeine Hintergrundverkehr bei \textit{Friend Finder} besteht zum einen aus \textit{Keep-Alive} Nachrichten, sowie der
+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
@@ -143,20 +131,17 @@ 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
+Größe auch Abhängig von der Länge der Benutzernamen sowie des Namens des\textit{Channels} 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``. 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 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
+\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
+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)$.
\subsubsection{Versenden und Empfangen von Positionen}
@@ -164,29 +149,34 @@ ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 9)$.
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
-zwischen 431 Byte. Die Anzahl der unverschlüsselten Zeichen, die für ein \textit{Latitude}/\textit{Longtitude}-Paar zu
+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.
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
+Positions-Fragmeint 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 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.
+Folglich 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.
-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}
+Allerdings ist der große Vorteil von \textit{IRC}, 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
+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)$.
+
+\begin{figure}[!ht]
+\centering
+ \includegraphics[width=10cm]{Bilder/graph}
+ \caption{Vergleich von $n$-Verbindungen und \textit{Friend Finder}}
+\end{figure}
diff --git a/ausarbeitung/Friend_Finder.tex.backup b/ausarbeitung/Friend_Finder.tex.backup
index 3519707..f354280 100644
--- a/ausarbeitung/Friend_Finder.tex.backup
+++ b/ausarbeitung/Friend_Finder.tex.backup
@@ -1,16 +1,15 @@
\section{Friend Finder}
-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 und die Programmstruktur aufgezeigt.
+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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Verwendete Verfahren und Bibliotheken}
-\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
+\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.\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}.
@@ -25,38 +24,28 @@ Alle drei Teile geben ihre empfangenen Daten an die \textit{GUI} weiter, welche
\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 Bedienelement. Der gesammte Programmcode der Benutzeroberfläche wurde in einer Datei
-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
-Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap} \citep{OSM} genutzt.
+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.
\subsubsection{Versenden der Nachrichten}
-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 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
-\textit{IRC-Server} zu erstellen und die Nachrichten zu verschicken. Um eine Verbindung zu einem gegebenen \textit{IRC-Server} zu
-etablieren, muss eine \textit{IRC-Session} initialisiert werden. Diese \textit{Session} beinhaltet Informationen wie zum Beispiel
+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
+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. 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
-ist ein symmetrisches Verschlüsselungsverfahren. Das bedeutet, das immer nur maximal 64 Bit Nachrichten verschlüsselt werden
-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 Textkonversation mit \textit{Friend Finder} zu sehen.\newline
+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
+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.
\begin{figure}[!ht]
\centering
@@ -64,45 +53,37 @@ arbeiten müssen. In der folgenden Abbildung ist eine Textkonversation mit \text
\caption{Versenden von Chatnachrichten}
\end{figure}
-Um Nachrichten zu versenden wurde für dieses Projekt die \textit{IRC-Client Bibliothek}\citep{libircclient} verwendet. Diese
-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.
-
\subsubsection{Versenden der eigenen Position}
-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.
+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 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 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}
-
-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.
+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.
+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.
+
+\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.
\subsubsection{Erzeugen eines 2D-Barcodes}
-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.
+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.
\begin{figure}[!ht]
\centering
@@ -115,27 +96,27 @@ generiert. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er v
\subsection{Analyse}
-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 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
-
+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
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. Der Client hat sich über das \textit{localhost} Interface mit dem Server verbunden. \newline
-
+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 einem Programm verhält, welches 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
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 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.
+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.
\subsubsection{Allgemeiner Datenverkehr}
-Der Allgemeine Hintergrundverkehr bei \textit{Friend Finder} besteht zum einen aus \textit{Keep-Alive} Nachrichten, sowie der
+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
@@ -143,20 +124,17 @@ 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
+Größe auch Abhängig von der Länge der Benutzernamen sowie des Namens des\textit{Channels} 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``. 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 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
+\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
+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)$.
\subsubsection{Versenden und Empfangen von Positionen}
@@ -164,27 +142,36 @@ ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 9)$.
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
-zwischen 431 Byte. Die Anzahl der unverschlüsselten Zeichen, die für ein \textit{Latitude}/\textit{Longtitude}-Paar zu
+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.
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
+Positions-Fragmeint 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 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.
+Folglich 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}
-Aufgrund der geringen Anzahl der versendeten Hintergrunddaten eignet sich das \textit{IRC}-Protokoll hervorragend für Dienste
-dieser Art, da der Datenoverhead sich in annehmbaren Grenzen hält. 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
-möglich einer Position möglich ist $n$ Teilnehmer diese zu übermitteln, da sie alle die Nachrichten innerhalb eines
-\textit{Channels} lesen können.
-
-%\begin{figure}[!ht]
-%\centering
-% \includegraphics[width=10cm]{Bilder/verbindungen}
-% \caption{Vergleich von n-Verbindungen und \textit{Friend Finder}}
-%\end{figure}
+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. Allerdings ist der große Vorteil
+von \textit{IRC}, dass die \textit{Channels} als \textit{Broadcast}-Medium genutzt werden. Diese Tatsache macht es möglich, Daten
+an $n$ Teilnehmer zu versenden und dabei die Daten 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
+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)$.
+
+\begin{figure}[!ht]
+\centering
+ \includegraphics[width=10cm]{Bilder/graph}
+ \caption{Vergleich von $n$-Verbindungen und \textit{Friend Finder}}
+\end{figure}
diff --git a/ausarbeitung/Friend_Finder.tex~ b/ausarbeitung/Friend_Finder.tex~
index ea0d0b1..0cf5f3e 100644
--- a/ausarbeitung/Friend_Finder.tex~
+++ b/ausarbeitung/Friend_Finder.tex~
@@ -1,16 +1,15 @@
\section{Friend Finder}
-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 und die Programmstruktur aufgezeigt.
+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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Verwendete Verfahren und Bibliotheken}
-\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
+\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.\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}.
@@ -25,38 +24,28 @@ Alle drei Teile geben ihre empfangenen Daten an die \textit{GUI} weiter, welche
\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 Bedienelement. Der gesammte Programmcode der Benutzeroberfläche wurde in einer Datei
-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
-Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap} \citep{OSM} genutzt.
+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.
\subsubsection{Versenden der Nachrichten}
-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 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
-\textit{IRC-Server} zu erstellen und die Nachrichten zu verschicken. Um eine Verbindung zu einem gegebenen \textit{IRC-Server} zu
-etablieren, muss eine \textit{IRC-Session} initialisiert werden. Diese \textit{Session} beinhaltet Informationen wie zum Beispiel
+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
+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. 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
-ist ein symmetrisches Verschlüsselungsverfahren. Das bedeutet, das immer nur maximal 64 Bit Nachrichten verschlüsselt werden
-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 Textkonversation mit \textit{Friend Finder} zu sehen.\newline
+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
+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.
\begin{figure}[!ht]
\centering
@@ -64,45 +53,44 @@ arbeiten müssen. In der folgenden Abbildung ist eine Textkonversation mit \text
\caption{Versenden von Chatnachrichten}
\end{figure}
-Um Nachrichten zu versenden wurde für dieses Projekt die \textit{IRC-Client Bibliothek}\citep{libircclient} verwendet. Diese
-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.
-
\subsubsection{Versenden der eigenen Position}
-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.
+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 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 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}
+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.
+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.
+
+\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
+einer Position eines anderen Benutzers.
-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.
+\begin{figure}[!ht]
+\centering
+ \includegraphics[width=8cm]{Bilder/position}
+ \caption{Ausgabe einer Benutzerposition}
+\end{figure}
\subsubsection{Erzeugen eines 2D-Barcodes}
-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.
+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.
\begin{figure}[!ht]
\centering
@@ -115,27 +103,27 @@ generiert. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er v
\subsection{Analyse}
-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 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
-
+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
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. Der Client hat sich über das \textit{localhost} Interface mit dem Server verbunden. \newline
-
+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 einem Programm verhält, welches 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
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 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.
+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.
\subsubsection{Allgemeiner Datenverkehr}
-Der Allgemeine Hintergrundverkehr bei \textit{Friend Finder} besteht zum einen aus \textit{Keep-Alive} Nachrichten, sowie der
+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
@@ -143,20 +131,17 @@ 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
+Größe auch Abhängig von der Länge der Benutzernamen sowie des Namens des\textit{Channels} 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``. 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 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
+\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
+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)$.
\subsubsection{Versenden und Empfangen von Positionen}
@@ -164,29 +149,34 @@ ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 9)$.
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
-zwischen 431 Byte. Die Anzahl der unverschlüsselten Zeichen, die für ein \textit{Latitude}/\textit{Longtitude}-Paar zu
+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.
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
+Positions-Fragmeint 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 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.
+Folglich 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.
-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}
+Allerdings ist der große Vorteil von \textit{IRC}, 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
+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)$.
+
+\begin{figure}[!ht]
+\centering
+ \includegraphics[width=10cm]{Bilder/graph}
+ \caption{Vergleich von $n$-Verbindungen und \textit{Friend Finder}}
+\end{figure}
diff --git a/ausarbeitung/Grundlagen.aux b/ausarbeitung/Grundlagen.aux
index 6e62e5a..f81425c 100644
--- a/ausarbeitung/Grundlagen.aux
+++ b/ausarbeitung/Grundlagen.aux
@@ -1,19 +1,17 @@
\relax
\citation{privacy}
\citation{geocaching}
-\citation{Latitude}
\citation{SPALS}
\citation{dummy}
\citation{kprivacy}
\citation{kanonymity}
\citation{quadtree}
\@writefile{toc}{\contentsline {section}{\numberline {2}Grundlagen}{3}{section.2}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Aktueller Stand}{3}{subsection.2.1}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Aktuelle Entwicklungen}{3}{subsection.2.1}}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Vorraussetzungen}{4}{subsection.2.2}}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}Ziele}{5}{subsection.2.3}}
\citation{symm}
\citation{bluetooth}
-\citation{qrcode}
\citation{IRC}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.4}Verfahren}{6}{subsection.2.4}}
\@setckpt{Grundlagen}{
@@ -23,7 +21,7 @@
\setcounter{enumii}{0}
\setcounter{enumiii}{0}
\setcounter{enumiv}{0}
-\setcounter{footnote}{0}
+\setcounter{footnote}{2}
\setcounter{mpfootnote}{0}
\setcounter{part}{0}
\setcounter{section}{2}
diff --git a/ausarbeitung/Grundlagen.tex b/ausarbeitung/Grundlagen.tex
index f193e69..bd62571 100644
--- a/ausarbeitung/Grundlagen.tex
+++ b/ausarbeitung/Grundlagen.tex
@@ -1,145 +1,133 @@
\section{Grundlagen}
-\textit{Location privacy} wird von Duckham und Kulik durch ``\textit{... a special type of information
+\textit{Location privacy} wird von Duckham und Kulik durch \begin{quote}... a special type of information
privacy which concerns the claim of individuals to determine for themselves when, how, and to what extent location
-information about them is communicated to others.}'' \citep{privacy} definiert. Ein Anwender sollte also in der Lage sein den
-Zeitpunkt, wie und in welchem Umfang Positionsdaten über sie verbreitet werden, selbst festzulegen. Es stellt sich die
+information about them is communicated to others. \end{quote} \citep{privacy} definiert. Ein Anwender sollte also in der Lage
+sein den Zeitpunkt, wie und in welchem Umfang Positionsdaten über sie verbreitet werden, selbst festzulegen. Es stellt sich die
Frage, wie der Benutzer in der Lage ist dieser drei Punkte zu kontrollieren. Dabei soll er den
Zeitpunkt frei bestimmen könnnen, wann und auf welche Art und Weiße er die Daten versendet und wieviele andere Benutzer oder
Institutionen darauf Zugriff haben.
-Im ersten Teil wird der momentane Stand von \textit{location privacy} Software auf mobilen
+Im ersten Teil wird die aktuelle Entwicklung von \textit{location privacy} Software auf mobilen
Geräten aufgezeigt. Des weiteren werden die Anforderungen, die an ein Programm dieser Art gestellt werden, analysiert und mögliche
Ziele einer solchen Software beschrieben.
-\subsection{Aktueller Stand}
+\subsection{Aktuelle Entwicklungen}
-Da so gut wie alle aktuellen Smartphones mit dem \textit{Global Positioning System (GPS)} ausgestattet sind, existieren für die
+Da so gut wie alle aktuellen Smartphones mit dem \textit{Global Positioning System (GPS)} ausgestattet sind, so gibt es für die
verschiedenen Betriebssysteme mittlerweile eine Reihe von Anwendungen die Funktionalitäten rund um die eigene Position bieten. So
-existieren Anwendungen um sich Routen erstellen zu lassen, die eigene Position zu bestimmen oder um \textit{Geocaching}
+gibt es Anwendungen um sich Routen erstellen zu lassen, die eigene Position zu bestimmen oder um \textit{Geocaching}
\citep{geocaching} zu betreiben.\newline
-Zum Beispiel bietet \textit{Google} den Dienst \textit{Google Latitude} \citep{Latitude} an. Bei diesem Programm
+Zum Beispiel bietet \textit{Google} den Dienst \textit{Google Latitude}
+\footnote{\url{http://www.google.com/intl/en_us/latitude/intro.html}} an. Bei diesem Programm
ist es möglich die Position von Freunden, die diesen Dienst auch nutzen, auf einer Karte anzeigen zu lassen. Es besteht hierbei
die Möglichkeit die eigene Position per \textit{GPS} oder mit Hilfe von Daten der \textit{GSM-Funkzelle} zu bestimmen.\newline
-Vergleicht man \textit{Google Latitude} mit der Defintion von \textit{location privacy} durch Duckham und Kulik, so stellt man
-fest dass der Anwender hier nur den Zeitpunkt, zu dem die Positionsinformationen versendet werden, bestimmen kann. Dies
-geschieht genau dann, wenn sie das Programm starten. Nutzen sie das Programm, so werden die Daten an \textit{Google} gesendet.
-Die einzige Einsicht die der Benutzer in diesen Vorgang hat, ist die dass er befreundete Teilnehmer auf seinem Display und diese
-ihn auf ihrem Display sehen. Er hat also keinerlei Kontrolle darüber, was mit den Daten nach dem Absenden passiert, da diese
-an \textit{Google} gesendet werden, wo sie dann durch ein interenes, ihm unbekanntes System an die anderen Nutzern weitergereicht
-werden. Wie dieses von statten geht, weiß der Anwender nicht. Der Anwender kann also weder festlegen, wie noch in
-welchem Umfang er die Daten versenden möchte, da er keinen Einblick in diesen Teil der Strukturen von \textit{Google} hat.
-\newline
-An genau diesem Punkt schliesst die Arbeit \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS} an. Hier werden die
+Betrachtet man ein solches Programm unter den obigen Gesichtspunkten von Duckham und Kulik,
+so stellt man fest dass der Anwender hier nur den Zeitpunkt, zu dem die Positionsinformationen versendet werden, bestimmen kann.
+Nutzen Anwender das Programm, so werden die Daten an den Anbieter eines solchen Dienstes gesendet. Diesem Anbieter obliegen die
+Rechte über die Daten ab diesem Zeitpunkt. Die einzige Einsicht die der Benutzer in diesen Vorgang hat, ist die dass er
+befreundete Teilnehmer auf seinem Display und diese ihn auf ihrem Display sehen. Er hat also keinerlei Kontrolle darüber, was mit
+den Daten nach dem Absenden passiert, da diese an den Anbieter gesendet werden, wo sie dann durch ein interenes, ihm
+unbekanntes System an die anderen Nutzern weitergereicht werden. Wie dieses im genauen abläuft, weiß der Anwender nicht. Der
+Benutzer kann also weder festlegen, wie noch in welchem Umfang er die Daten versenden möchte, da er keinen Einblick in diesen Teil
+der Strukturen der Institution, die den Dienst zur Verfügung stellt, hat.\newline
+An genau diesem Punkt schließt die Arbeit \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS} an. Hier werden die
Daten über ein offenes und frei zugängliches System versendet. Da, dass zum Versenden genutzte, System offen zugänglich ist,
müssen diese Daten zusätzlich verschlüsselt werden, da ansonsten jederman Zugang zu ihnen hätte. \newline
Zum Verschleiern der Position nutzen Kido u.a. \citep{dummy} Datensätze die falsche Positionsangaben beinhalten. Diese werden
-an einen Dienst gesandt, welcher auf alle antwortet. Nur der Client weiß, welche der empfangenen Daten auf der
-eigentlichen Position basieren. Mit dieser Lösung ist es zwar möglich Positionsdaten zu verschleiern, allerdings wird
-hiermit nicht das Problem gelöst, dass der Nutzer die Kontrolle darüber hat, wie seine Daten versendet und genutzt werden.\newline
+an einen Dienst gesandt, welcher auf all diese Datensätze antwortet, egal ob diese die richtigen oder die falschen Daten
+beinhalten. Nur der Client weiß, welche der empfangenen Daten auf der eigentlichen Position basieren. Mit dieser Lösung ist es
+zwar möglich Positionsdaten zu verschleiern, allerdings wird hiermit nicht das Problem gelöst, dass der Nutzer keine Kontrolle
+darüber hat, wie seine Daten versendet und genutzt werden.\newline
Einen anderer Ansatz verfolgen Gruteser und Grundwald \citep{kprivacy}. Sie versuchen mit Hilfe von \textit{k-anonymity}
\citep{kanonymity} die Position zu verschleiern. Man versteht unter \textit{k-anonymity}, dass in
einer Menge von $k$ Personen ein Teilnehmer nicht von den anderen $k-1$ Teilnehmern unterschieden werden kann. Gruteser und
Grundwald haben hierfür einen \textit{quadtree} \citep{quadtree} genutzt um bestimmte Bereiche zu erstellen. Diese Bereiche haben
nur eine Vorraussetzung, sie müssen $k$ Personen enthalten. Somit kann nicht festgestellt werden, welche Person
-eines Bereiches die Daten versandt hat. Allerdings kann dieses Vorgehen nicht für einen Dienst mit der Funktionalität von
-\textit{Google Latitude} genutzt werden, da es mit diesem Ansatz nicht möglich ist Positionsdaten von einzelnen Personen zu
-versenden. Zusätzlich ist auch hier nicht gegeben, dass die Anwender Einsicht in die Verwendung und Verbreitung ihrer Daten
-erhalten.\newline
-
+eines Bereiches die Daten versandt hat. Allerdings kann dieses Vorgehen nicht für eine Anwendung mit der Funktionalität eines
+Dienstes, der gezielt Positionen einzelner andere Benutzer anzeigt, genutzt werden. Der Grund dafür ist, dass es mit diesem
+Ansatz nicht möglich ist Positionsdaten von einzelnen Personen zu versenden. Zusätzlich ist auch hier nicht gegeben, dass die
+Anwender Einsicht in die Verwendung und Verbreitung ihrer Daten erhalten.
\subsection{Vorraussetzungen}
-Da die Verbreitung von mobilen Geräten in den letzten Jahren beständig zugenommen hat und
-alle neueren Modelle ein \textit{GPS}-Modul besitzen, sind die Vorraussetzungen für Anwendungen die Positionsdaten nutzen,
-gegeben. Auch im Rahmen der Datenübertragung sind alle modernen Geräte in der Lage, Daten sowohl über den \textit{3G}-Standard
+Im Rahmen der Datenübertragung sind alle modernen Geräte in der Lage, Daten sowohl über den \textit{3G}-Standard
sowie per \textit{WLAN} zu übertragen. \newline
Wenn nun ein sicherer Austausch von Positionsdaten erfolgen soll, so müssen neben der Hardware, auch andere Rahmenbedingungen
gegeben sein. Da man durch Positionsdaten die aktuelle Position erfahren oder Bewegungsprofile erstellen kann, sollten der Zugang
-zu ihnen nur dann erlaubt sein wenn der betreffende Benutzer damit einverstanden ist. Die Daten müssen also soweit entfremdet oder
-abgeändert werden damit nur eine vom Nutzer bestimmte Gruppe diese wieder rekonstruieren kann. Somit ist gegeben, dass der Nutzer
-über das Ausmaß der Verbreitung seiner Daten die Kontrolle bewahren kann.\newline
-Der Anwender sollte in der Lage zu sein Daten zu jedem von ihm gewünschten Zeitpunkt zu versenden. Er muss also in der Lage sein
+zu diesen nur dann erlaubt sein wenn der Benutzer der sie versendet damit einverstanden ist. Die Daten müssen also soweit
+entfremdet oder abgeändert werden damit nur eine vom Nutzer bestimmte Gruppe diese wieder rekonstruieren kann. Somit ist gegeben,
+dass der Nutzer über das Ausmaß der Verbreitung seiner Daten die Kontrolle bewahren kann.\newline
+Der Anwender muss Daten zu jedem von ihm gewünschten Zeitpunkt zu versenden können. Er muss also in der Lage sein
die dafür benötigten Parameter zu sofort zu erstellen und weiterzugeben. Somit kann er den Zeitpunkt, zu welchem er seine Daten
versenden möchte, frei wählen.\newline
-Ist dies gegeben, sollen die Daten im nächsten Schritt versendet werden. Auch hier sollte ein Weg gefunden werden mit dem der
+Ist dies gegeben, werden die Daten im nächsten Schritt versendet. Auch hier muss ein Weg gefunden werden mit dem der
Nutzer möglichst viel Kontrolle über seine Datensätze inne hat. Um diese Kontrolle zu wahren, müssen die Informationen mit
-einer möglichst transparenten und doch verlässlichen Methode verteilt werden. Hierbei darf die Möglichkeit der Speicherung der
-Daten über die Zeit nicht ausser Acht gelassen werden. Um dies zu erschweren sollte man zum Übertragen der Informationen
-nicht nur auf einen zentralen Knoten angewiesen sein, sondern nutzt im optimalen Fall ein ganzes Netzwerk von solchen
-Knotenpunkten. Bei diesem Netzwerk sollen allerdings alle Knotenpunkt einsehbar sein, damit der Nutzer zu jedem Zeitpunkt weiß,
-was mit seinen Daten geschieht. Ist dies gegeben so ist der Nutzer in der Lage zu kontrollieren wie seine Daten versandt
-werden.\newline
-
+einer möglichst transparenten und doch verlässlichen Methode verschickt werden.
+Zum Weiteren Schutz der verschlüsselten Daten darf man zum Übertragen der Informationen nicht nur auf einen zentralen Knoten
+angewiesen sein, sondern nutzt im optimalen Fall ein ganzes Netzwerk von solchen Knotenpunkten. Bei diesem Netzwerk sind
+allerdings alle Knotenpunkt einsehbar, damit der Nutzer zu jedem Zeitpunkt weiß, was mit seinen Daten geschieht. Ist dies
+gegeben so ist der Nutzer in der Lage zu kontrollieren wie seine Daten versandt werden.
\subsection{Ziele}
Zusammenfassend kann also gesagt werden, dass eine Software mit den beschriebenen Eigenschaften die Sicherheit der
-Daten, in Bezug auf Zugänglichkeit, und das Vermeiden von Datenspeicherung zum Ziel haben sollte. Dem
-Anwender soll es aber trotz allem einfach gemacht werden dieses Programm zu nutzen. Die Inhalte der Anwendung sollen also soweit
-abstrahiert werden, als dass auch ein Benutzer ohne Fachkenntnis alle Features nutzen kann, ohne dass die obigen Punkte ausser
-Kraft treten. \newline
-
+Daten, in Bezug auf Zugänglichkeit, und das Vermeiden von Datenspeicherung zum Ziel hat. Anwender soll es aber trotz allem einfach
+gemacht werden dieses Programm zu nutzen. Die Inhalte der Anwendung müssen also soweit abstrahiert werden, als dass auch ein
+Benutzer ohne Fachkenntnis alle Funktionen der Anwendung nutzen kann, ohne dass die obigen Punkte ausser Kraft treten. \newline
Zum Versenden der Daten muss eine offene Struktur genutzt werden, in welche jeder Einsicht hat und welche frei genutzt werden
-kann. Es soll gewährleistet sein das jeder Teilnehmer dieser sofort beitreten kann, ohne das für ihn Restriktionen, wie zum
+kann. Es muss gewährleistet sein das jeder Teilnehmer dieser sofort beitreten kann, ohne das für ihn Restriktionen, wie zum
Beispiel ein Benutzeraccount, gelten. Diese Struktur sollte über ein Protokoll verfügen das verlässlich, stabil und auch für
langsame Netzwerke optimiert ist. Eine reibungslose Kommunikation kann somit garantiert werden. \newline
-Um die Kommunikation zwischen verschiedenen Teilnehmern zu ermöglichen soll es möglich sein Chatnachrichten auszutauschen. Die
-Interaktion zwischen den Anwendern und somit der Nutzen des Dienstes kann dadurch weiter gesteigert werden.\newline
-
-Durch die Nutzung einer, für alle, offenen Struktur ist es von Nöten, dass die Daten verschlüsselt werden. Da bei
+Um die Kommunikation zwischen verschiedenen Teilnehmern zu ermöglichen muss es möglich sein Chatnachrichten auszutauschen. Die
+Interaktion zwischen den Anwendern und somit der Nutzen des Dienstes kann hierdurch weiter gesteigert werden.\newline
+Durch die Nutzung einer, für alle, offene Struktur ist es von Nöten, dass die Daten verschlüsselt werden. Da bei
Verschlüsselungen der Austausch von Schlüsseln voraussetzt wird, muss ein Verfahren genutzt werden welches den Austausch von zwei
-Schlüsseln auf einfache Weise ermöglicht. Gleichzeitig muss garantiert sein dass die Schlüssel während des Austauschs nicht von
-unbefugten Personen abgefangen werden. \newline
+Schlüsseln auf einfache Weise ermöglicht. Da diese Software für mobile Geräte ausgelegt ist, müssen die benötigten Schlüssel
+spontan ausgetauscht werden können, da der Anwender die Nutzung eines solchen Dienstes nicht immer im Vorraus planen möchte und
+kann. Gleichzeitig muss garantiert sein dass die Schlüssel während des Austauschs nicht von unbefugten Personen abgefangen werden.
+\newline
Ist ein solches Verfahren gegeben, so kann ein Algorithmus genutzt werden der sowohl sicher ist, als auch mit möglichst geringem
Aufwand die Daten ver- und entschlüsselt. \newline
-Da Positionsdaten versendet werden, sollte die Applikation in der Lage sein die Standorte anderer Nutzer anzuzeigen. Da aus
-Gründen der Nutzbarkeit die Positionen der Teilnehmer auf einer Karte dargestellt werden sollen, muss ein Format für die Karte
-genutzt werden, welches auf dem mobilen Gerät darstellbar und einfach auf den neusten Stand zu bringen ist.\newline
+Da Positionsdaten versendet werden, müssen diese visualisiert werden. Somit muss die Applikation in der Lage sein die Standorte
+anderer Nutzer anzuzeigen. Da aus Gründen der Nutzbarkeit die Positionen der Teilnehmer auf einer Karte dargestellt werden sollen,
+muss ein Format für die Karte genutzt werden, welches auf dem mobilen Gerät darstellbar und einfach auf den neusten Stand zu
+bringen ist.\newline
Benutzer die sich in größeren Entfernungen befinden sind für Programme dieser Art nur begrenzt interessant, da sie mit zunehmender
Entfernung immer schwerer zu erreichen sind. Deshalb werden nur Teilnehmer innerhalb eines bestimmten Radius angezeigt.\newline
-
Ein weiterer Punkt ist die Plattformunabhängigkeit. Diese steht zwar nicht in Verbindung mit der Privatsphäre der Benutzer,
-allerdings sollt ein solches Programm unter möglichst vielen Plattformumgebungen lauffähig sein. Zum Einen wird somit der Aufwand
+allerdings sollte ein solches Programm unter möglichst vielen Plattformumgebungen lauffähig sein. Zum Einen wird somit der Aufwand
der Implementierung verringert, da die Software nicht mehrmals implementiert werden muss. Zum Anderen werden möglichst viele
Benutzer erreicht und es kann auch Kommunikation unter Besitzern von unterschiedlichen Typen von Mobiltelefonen
stattfinden.\newline
-Die Software möglichst modular gehalten werden, damit es auch zu einem späteren Zeitpunkt leicht fällt Programmteile
-auszutauschen oder zu erweitern. So wäre es zum Beispiel denkbar verschiedene Algorithmen zur Verschlüsselung oder ein anderes
-Protokoll zum Versenden der Daten, zusätzlich zu implementieren. \newline
+Die Struktur der Software muss möglichst modular gehalten werden, damit es auch zu einem späteren Zeitpunkt leicht fällt
+Programmteile auszutauschen oder zu erweitern. So wäre es zum Beispiel denkbar verschiedene Algorithmen zur Verschlüsselung oder
+ein anderes Protokoll zum Versenden der Daten, zusätzlich zu implementieren.
\subsection{Verfahren}
Anhand der Anforderungen müssen nun geeignete Verfahren und Protokolle sowohl für Kommunikation als auch für Verschlüsselung
gewählt werden. Da man mit mehreren Benutzern oder auch mehreren Benutzergruppen kommunizieren kann, können mehrere Schlüssel
-anfallen. Somit sollte der Aufwand um diese Schlüssel zu speichern, zu löschen oder neu zuzuordnen möglichst gering ausfallen. Aus
-Gründen der Schlüsselverwaltung ist daher ein symmetrisches Verfahren besser geeignet als ein asymmetrisches. Es ist einfacher
-einen Schlüssel pro Gruppe zu verwalten als einen privaten, einen öffentlichen sowie unter Umständen noch ein Zertifikat. Des
-Weiteren sind symmetrische Verfahren nicht so berrechnungsintensiv wie asymmetrische \citep{symm}, was einen
-wichtigen Punkt auf mobilen Geräten darstellt. \newline
-
+anfallen. Somit soll der Aufwand, für den Anwender, um diese Schlüssel zu speichern, zu löschen oder neu zuzuordnen möglichst
+gering gehalten werden. Symmetrische Verfahren nicht so berrechnungsintensiv wie asymmetrische \citep{symm}, was einen
+wichtigen Punkt auf mobilen Geräten darstellt. Aufgrund dieser Tatsache wird eine symmetrische Verschlüsselung genutzt.\newline
Da der Schlüsselaustausch spontan durchführbar sein soll, muss dieser zu jedem Zeitpunkt möglich sein ohne das dafür
Vorbereitungen getroffen werden müssen. So könnte man die Schlüssel per \textit{Bluetooth} übertragen, da eine solche
Verbindung ohne Vorarbeit aufgebaut werden kann. Allerdings stellt \textit{Bluetooth} ein unsicheres Medium dar
-\citep{bluetooth}, da der \textit{Bluetooth-Sitzungs-PIN} per Daten-Phishing wiederhergestellt werden kann. Eine andere
-Möglichkeit, die ebenfalls keine Vorarbeit benötigt, ist das Erstellen eines 2D-Barcodes \citep{qrcode} aus einer Zeichenkette.
+\citep{bluetooth}, da der \textit{Bluetooth-Sitzungs-PIN} per \textit{Daten-Phishing} wiederhergestellt werden kann. Eine andere
+Möglichkeit, die ebenfalls keine Vorarbeit benötigt, ist das Erstellen eines 2D-Barcodes \footnote{QR Code
+\url{http://www.denso-wave.com/qrcode/qrstandard-e.html}} aus einer Zeichenkette.
Dieser kann fotographieren und wieder in eine Zeichenkette umwandelt werden. Da keine Kommunikation über einen
-unsicheren Kanal zwischen den Geräten stattfindet sind die Barcodes bestens zum Schlüsselaustausch geeignet, da der Schlüssel auf
+unsicheren Kanal zwischen den Geräten stattfindet sind die Barcodes optimal zum Schlüsselaustausch geeignet, da der Schlüssel auf
diesem Wege nicht abgefangen werden kann. \newline
-
-Ein vorhandenes, nutzbares Protokoll welches ein aktives Netzwerk bereitstellt ist das \textit{IRC}-Protokoll \citep{IRC}. Es
-stehen bereits mehrere Server zur Verfügung und jeder Nutzer kann einen eigenen Server bereitstellen. Die Server sind in
-Netzwerken organisiert, wodurch der Ausfall eines Servers nicht zum Beenden der gesamten Kommuniktion führt. Nachrichten
-werden innerhalb des Netzwerkes von Server zu Server weitergeleitet bis diese auf dem Zielserver ankommen. Innerhalb der
-\textit{IRC}-Netzwerke werden verschiedene \textit{Channels} bereitgestellt, an welche die Nachrichten gesendet werden können.
-Des weiteren steht es jedem Benutzer frei, eigene \textit{Channels} zu öffnen. Gesendete Nachrichten werden in diesen
-\textit{Channels} ausgegeben. Somit ist zu jedem Zeitpunkt einsehbar was mit versandten Daten passiert.\newline
+Aufgrund der Möglichkeit das jeder Nutzer beliebig beitreten und Daten in dieser Struktur austauschen kann, fiel die Wahl zum
+versenden der Daten auf das \textit{IRC}-Protokoll. Des weiteren spricht für diese Entscheidung, dass das
+\textit{IRC}-Protokoll \citep{IRC} weit verbreitet ist und eine ausgedehnte Serverstruktur zu Grunde liegt. Auch die Stabilität
+und Verlässlichkeit des Protokolles ist gegeben. Da die \textit{IRC}-Server in Netzwerken organisiert sind führt der Ausfall eines
+Servers nicht zur Beendigung der gesamten Kommuniktion. Innerhalb der \textit{IRC}-Netzwerke werden verschiedene \textit{Channels}
+bereitgestellt, an welche Nachrichten gesendet werden können. Ein weiterer Vorteil von \textit{IRC} ist, wenn Daten an
+mehrere Benutzer gesendet werden sollen, diese nur einmal an einen \textit{Channel} versandt werden müssen und jeder Benutzer in
+diesem \textit{Channel} diese Daten empfangen kann. Des weiteren steht es jedem Benutzer frei, eigene \textit{Channels} zu
+öffnen.\newline
In der beschriebenen Software werden die Positionsdaten als Zeichenfolge an einen dieser \textit{Channels} gesendet und können
dort von beliebig vielen anderen Instanzen der Software ausgelesen werden. Diese verarbeiten die Daten im Anschluss, so dass diese
-dann als Position auf einer Karte ausgegeben werden können. Beim Versenden der Textnachrichten ist die vorgehensweiße equivalent.
-\newline
-
-Durch diesen Lösungsansatz werden die Berechnungszeiten durch ein symmetrisches Verfahren niedrig gehalten. Der
-Verwaltungsaufwand für die Schlüssel ist ebenfalls gering und die Verteilung selbiger kann durch die angesprochenen Barcodes
-erfolgen. Bei der Kommunikation gibt es keinen einzelnen zentralen Server der den gesamten Datenverkehr einsehen kann. Die Daten
-werden nur in verschlüsselter Form über die \textit{IRC}-Server versendet. Folglich kann jedes beliebige \textit{IRC}-Netzwerk zur
-Kommunikation gewählt werden. \ No newline at end of file
+dann als Position auf einer Karte ausgegeben werden können. Beim Versenden der Textnachrichten ist die vorgehensweiße equivalent. \ No newline at end of file
diff --git a/ausarbeitung/Grundlagen.tex.backup b/ausarbeitung/Grundlagen.tex.backup
index 365bf6e..f9647d2 100644
--- a/ausarbeitung/Grundlagen.tex.backup
+++ b/ausarbeitung/Grundlagen.tex.backup
@@ -1,89 +1,92 @@
\section{Grundlagen}
-\textit{Location privacy} wird von Duckham und Kulik durch ``\textit{... a special type of information
+\textit{Location privacy} wird von Duckham und Kulik durch \begin{quote}... a special type of information
privacy which concerns the claim of individuals to determine for themselves when, how, and to what extent location
-information about them is communicated to others.}'' \citep{privacy} definiert. Ein Anwender sollte also in der Lage sein den
-Zeitpunkt, wie und in welchem Umfang Positionsdaten über sie verbreitet werden, selbst festzulegen. Es stellt sich die
+information about them is communicated to others. \end{quote} \citep{privacy} definiert. Ein Anwender sollte also in der Lage
+sein den Zeitpunkt, wie und in welchem Umfang Positionsdaten über sie verbreitet werden, selbst festzulegen. Es stellt sich die
Frage, wie der Benutzer in der Lage ist dieser drei Punkte zu kontrollieren. Dabei soll er den
Zeitpunkt frei bestimmen könnnen, wann und auf welche Art und Weiße er die Daten versendet und wieviele andere Benutzer oder
Institutionen darauf Zugriff haben.
-Im ersten Teil wird der momentane Stand von \textit{location privacy} Software auf mobilen
+Im ersten Teil wird die aktuelle Entwicklung von \textit{location privacy} Software auf mobilen
Geräten aufgezeigt. Des weiteren werden die Anforderungen, die an ein Programm dieser Art gestellt werden, analysiert und mögliche
Ziele einer solchen Software beschrieben.
-\subsection{Aktueller Stand}
+\subsection{Aktuelle Entwicklungen}
-Da so gut wie alle aktuellen Smartphones mit dem \textit{Global Positioning System (GPS)} ausgestattet sind, existieren für die
+Da so gut wie alle aktuellen Smartphones mit dem \textit{Global Positioning System (GPS)} ausgestattet sind, so gibt es für die
verschiedenen Betriebssysteme mittlerweile eine Reihe von Anwendungen die Funktionalitäten rund um die eigene Position bieten. So
-existieren Anwendungen um sich Routen erstellen zu lassen, die eigene Position zu bestimmen oder um \textit{Geocaching}
+gibt es Anwendungen um sich Routen erstellen zu lassen, die eigene Position zu bestimmen oder um \textit{Geocaching}
\citep{geocaching} zu betreiben.\newline
-Zum Beispiel bietet \textit{Google} den Dienst \textit{Google Latitude} \citep{Latitude} an. Bei diesem Programm
+Zum Beispiel bietet \textit{Google} den Dienst \textit{Google Latitude}
+\footnode{\url{http://www.google.com/intl/en_us/latitude/intro.html}} an. Bei diesem Programm
ist es möglich die Position von Freunden, die diesen Dienst auch nutzen, auf einer Karte anzeigen zu lassen. Es besteht hierbei
die Möglichkeit die eigene Position per \textit{GPS} oder mit Hilfe von Daten der \textit{GSM-Funkzelle} zu bestimmen.\newline
-Vergleicht man \textit{Google Latitude} mit der Defintion von \textit{location privacy} durch Duckham und Kulik, so stellt man
-fest dass der Anwender hier nur den Zeitpunkt, zu dem die Positionsinformationen versendet werden, bestimmen kann. Dies
-geschieht genau dann, wenn sie das Programm starten. Nutzen sie das Programm, so werden die Daten an \textit{Google} gesendet.
-Die einzige Einsicht die der Benutzer in diesen Vorgang hat, ist die dass er befreundete Teilnehmer auf seinem Display und diese
-ihn auf ihrem Display sehen. Er hat also keinerlei Kontrolle darüber, was mit den Daten nach dem Absenden passiert, da diese
-an \textit{Google} gesendet werden, wo sie dann durch ein interenes, ihm unbekanntes System an die anderen Nutzern weitergereicht
-werden. Wie dieses von statten geht, weiß der Anwender nicht. Der Anwender kann also weder festlegen, wie noch in
-welchem Umfang er die Daten versenden möchte, da er keinen Einblick in diesen Teil der Strukturen von \textit{Google} hat.
-\newline
-An genau diesem Punkt setzt die Arbeit \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS} ein. Hier werden die
+Betrachtet man ein solches Programm unter den obigen Gesichtspunkten von Duckham und Kulik,
+so stellt man fest dass der Anwender hier nur den Zeitpunkt, zu dem die Positionsinformationen versendet werden, bestimmen kann.
+Nutzen Anwender das Programm, so werden die Daten an den Anbieter eines solchen Dienstes gesendet. Diesem Anbieter obliegen die
+Rechte über die Daten ab diesem Zeitpunkt. Die einzige Einsicht die der Benutzer in diesen Vorgang hat, ist die dass er
+befreundete Teilnehmer auf seinem Display und diese ihn auf ihrem Display sehen. Er hat also keinerlei Kontrolle darüber, was mit
+den Daten nach dem Absenden passiert, da diese an den Anbieter gesendet werden, wo sie dann durch ein interenes, ihm
+unbekanntes System an die anderen Nutzern weitergereicht werden. Wie dieses im genauen abläuft, weiß der Anwender nicht. Der
+Benutzer kann also weder festlegen, wie noch in welchem Umfang er die Daten versenden möchte, da er keinen Einblick in diesen Teil
+der Strukturen der Institution, die den Dienst zur Verfügung stellt, hat.\newline
+An genau diesem Punkt schließt die Arbeit \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS} an. Hier werden die
Daten über ein offenes und frei zugängliches System versendet. Da, dass zum Versenden genutzte, System offen zugänglich ist,
müssen diese Daten zusätzlich verschlüsselt werden, da ansonsten jederman Zugang zu ihnen hätte. \newline
Zum Verschleiern der Position nutzen Kido u.a. \citep{dummy} Datensätze die falsche Positionsangaben beinhalten. Diese werden
-an einen Dienst gesandt, welcher auf alle antwortet. Nur der Client weiß, welche der empfangenen Daten auf der
-eigentlichen Position basieren. Mit dieser Lösung ist es zwar möglich Positionsdaten zu verschleiern, allerdings wird
-hiermit nicht das Problem gelöst, dass der Nutzer die Kontrolle darüber hat, wie seine Daten versendet und genutzt werden.\newline
+an einen Dienst gesandt, welcher auf all diese Datensätze antwortet, egal ob diese die richtigen oder die falschen Daten
+beinhalten. Nur der Client weiß, welche der empfangenen Daten auf der eigentlichen Position basieren. Mit dieser Lösung ist es
+zwar möglich Positionsdaten zu verschleiern, allerdings wird hiermit nicht das Problem gelöst, dass der Nutzer die Kontrolle
+darüber hat, wie seine Daten versendet und genutzt werden.\newline
Einen anderer Ansatz verfolgen Gruteser und Grundwald \citep{kprivacy}. Sie versuchen mit Hilfe von \textit{k-anonymity}
\citep{kanonymity} die Position zu verschleiern. Man versteht unter \textit{k-anonymity}, dass in
einer Menge von $k$ Personen ein Teilnehmer nicht von den anderen $k-1$ Teilnehmern unterschieden werden kann. Gruteser und
Grundwald haben hierfür einen \textit{quadtree} \citep{quadtree} genutzt um bestimmte Bereiche zu erstellen. Diese Bereiche haben
nur eine Vorraussetzung, sie müssen $k$ Personen enthalten. Somit kann nicht festgestellt werden, welche Person
eines Bereiches die Daten versandt hat. Allerdings kann dieses Vorgehen nicht für einen Dienst mit der Funktionalität von
-\textit{Google Latitude} genutzt werden, da es mit diesem Ansatz nicht möglich ist Positionsdaten von einzelnen Personen zu
-versenden. Zusätzlich ist auch hier nicht gegeben, dass die Anwender Einsicht in die Verwendung und Verbreitung ihrer Daten
-erhalten.\newline
-
+eines Dienstes, der gezielt Positionen einzelner andere Benutzer anzeigt, genutzt werden. Der Grund dafür ist, dass es mit diesem
+Ansatz nicht möglich ist Positionsdaten von einzelnen Personen zu versenden. Zusätzlich ist auch hier nicht gegeben, dass die
+Anwender Einsicht in die Verwendung und Verbreitung ihrer Daten erhalten.
-%anderer titel der section
\subsection{Vorraussetzungen}
-Da die Verbreitung von mobilen Geräten in den letzten Jahren beständig zugenommen hat und
-alle neueren Modelle ein \textit{GPS}-Modul besitzen, sind die Vorraussetzungen für Anwendungen die Positionsdaten nutzen,
-gegeben. Auch im Rahmen der Datenübertragung sind alle modernen Geräte in der Lage, Daten sowohl über den \textit{3G}-Standard
+Im Rahmen der Datenübertragung sind alle modernen Geräte in der Lage, Daten sowohl über den \textit{3G}-Standard
sowie per \textit{WLAN} zu übertragen. \newline
Wenn nun ein sicherer Austausch von Positionsdaten erfolgen soll, so müssen neben der Hardware, auch andere Rahmenbedingungen
gegeben sein. Da man durch Positionsdaten die aktuelle Position erfahren oder Bewegungsprofile erstellen kann, sollten der Zugang
-zu ihnen nur dann erlaubt sein wenn der betreffende Benutzer damit einverstanden ist. Die Daten müssen also soweit entfremdet oder
-abgeändert werden damit nur eine vom Nutzer bestimmte Gruppe diese wieder rekonstruieren kann. Somit ist gegeben, dass der Nutzer
-über das Ausmaß der Verbreitung seiner Daten die Kontrolle bewahren kann.\newline
+zu diesen nur dann erlaubt sein wenn der Benutzer der sie versendet damit einverstanden ist. Die Daten müssen also soweit
+entfremdet oder abgeändert werden damit nur eine vom Nutzer bestimmte Gruppe diese wieder rekonstruieren kann. Somit ist gegeben,
+dass der Nutzer über das Ausmaß der Verbreitung seiner Daten die Kontrolle bewahren kann.\newline
Der Anwender sollte in der Lage zu sein Daten zu jedem von ihm gewünschten Zeitpunkt zu versenden. Er muss also in der Lage sein
die dafür benötigten Parameter zu sofort zu erstellen und weiterzugeben. Somit kann er den Zeitpunkt, zu welchem er seine Daten
versenden möchte, frei wählen.\newline
Ist dies gegeben, sollen die Daten im nächsten Schritt versendet werden. Auch hier sollte ein Weg gefunden werden mit dem der
Nutzer möglichst viel Kontrolle über seine Datensätze inne hat. Um diese Kontrolle zu wahren, müssen die Informationen mit
-einer möglichst transparenten und doch verlässlichen Methode verteilt werden. Hierbei darf die Möglichkeit der Speicherung der
-Daten über die Zeit nicht ausser Acht gelassen werden. Um dies zu erschweren sollte man zum Übertragen der Informationen
-nicht nur auf einen zentralen Knoten angewiesen sein, sondern nutzt im optimalen Fall ein ganzes Netzwerk von solchen
-Knotenpunkten. Bei diesem Netzwerk sollen allerdings alle Knotenpunkt einsehbar sein, damit der Nutzer zu jedem Zeitpunkt weiß,
-was mit seinen Daten geschieht. Ist dies gegeben so ist der Nutzer in der Lage zu kontrollieren wie seine Daten versandt
-werden.\newline
-
+einer möglichst transparenten und doch verlässlichen Methode verschickt werden. %ÜBERARBEITEN DU ARSCH
+Zum Weiteren Schutz der verschlüsselten Daten sollte man zum Übertragen der Informationen nicht nur auf einen zentralen Knoten
+angewiesen sein, sondern nutzt im optimalen Fall ein ganzes Netzwerk von solchen Knotenpunkten. Bei diesem Netzwerk sollen
+allerdings alle Knotenpunkt einsehbar sein, damit der Nutzer zu jedem Zeitpunkt weiß, was mit seinen Daten geschieht. Ist dies
+gegeben so ist der Nutzer in der Lage zu kontrollieren wie seine Daten versandt
+werden.
\subsection{Ziele}
Zusammenfassend kann also gesagt werden, dass eine Software mit den beschriebenen Eigenschaften die Sicherheit der
Daten, in Bezug auf Zugänglichkeit, und das Vermeiden von Datenspeicherung zum Ziel haben sollte. Dem
Anwender soll es aber trotz allem einfach gemacht werden dieses Programm zu nutzen. Die Inhalte der Anwendung sollen also soweit
-abstrahiert werden, als dass auch ein Benutzer ohne Fachkenntnis alle Features nutzen kann, ohne dass die obigen Punkte ausser
+abstrahiert werden, als dass auch ein Benutzer ohne Fachkenntnis alle Funktionen der Anwendung nutzen kann, ohne dass die obigen
+Punkte ausser
Kraft treten. \newline
-
-Damit die Positionsdaten nicht für alle zugänglich sind sollen diese verschlüsselt werden. Da bei Verschlüsselungen der Austausch
-von Schlüsseln voraussetzt wird, muss ein Verfahren genutzt werden welches den Austausch von zwei Schlüsseln auf einfache Weise
-ermöglicht. Gleichzeitig muss garantiert sein dass die Schlüssel während des Austauschs nicht von unbefugten Personen abgefangen
-werden. \newline
+Zum Versenden der Daten muss eine offene Struktur genutzt werden, in welche jeder Einsicht hat und welche frei genutzt werden
+kann. Es soll gewährleistet sein das jeder Teilnehmer dieser sofort beitreten kann, ohne das für ihn Restriktionen, wie zum
+Beispiel ein Benutzeraccount, gelten. Diese Struktur sollte über ein Protokoll verfügen das verlässlich, stabil und auch für
+langsame Netzwerke optimiert ist. Eine reibungslose Kommunikation kann somit garantiert werden. \newline
+Um die Kommunikation zwischen verschiedenen Teilnehmern zu ermöglichen soll es möglich sein Chatnachrichten auszutauschen. Die
+Interaktion zwischen den Anwendern und somit der Nutzen des Dienstes kann dadurch weiter gesteigert werden.\newline
+Durch die Nutzung einer, für alle, offene Struktur ist es von Nöten, dass die Daten verschlüsselt werden. Da bei
+Verschlüsselungen der Austausch von Schlüsseln voraussetzt wird, muss ein Verfahren genutzt werden welches den Austausch von zwei
+Schlüsseln auf einfache Weise ermöglicht. Gleichzeitig muss garantiert sein dass die Schlüssel während des Austauschs nicht von
+unbefugten Personen abgefangen werden. \newline
Ist ein solches Verfahren gegeben, so kann ein Algorithmus genutzt werden der sowohl sicher ist, als auch mit möglichst geringem
Aufwand die Daten ver- und entschlüsselt. \newline
Da Positionsdaten versendet werden, sollte die Applikation in der Lage sein die Standorte anderer Nutzer anzuzeigen. Da aus
@@ -91,14 +94,6 @@ Gründen der Nutzbarkeit die Positionen der Teilnehmer auf einer Karte dargestel
genutzt werden, welches auf dem mobilen Gerät darstellbar und einfach auf den neusten Stand zu bringen ist.\newline
Benutzer die sich in größeren Entfernungen befinden sind für Programme dieser Art nur begrenzt interessant, da sie mit zunehmender
Entfernung immer schwerer zu erreichen sind. Deshalb werden nur Teilnehmer innerhalb eines bestimmten Radius angezeigt.\newline
-
-Zum Versenden der Daten muss eine offene Struktur genutzt werden, in welche jeder Einsicht hat und welche frei genutzt werden
-kann. Es soll gewährleistet sein das jeder Teilnehmer dieser sofort beitreten kann, ohne das für ihn Restriktionen, wie zum
-Beispiel ein Benutzeraccount, gelten. Diese Struktur sollte über ein Protokoll verfügen das verlässlich, stabil und auch für
-langsame Netzwerke optimiert ist. Eine reibungslose Kommunikation kann somit garantiert werden. \newline
-Um die Kommunikation zwischen verschiedenen Teilnehmern zu ermöglichen soll es möglich sein Chatnachrichten auszutauschen. Die
-Interaktion zwischen den Anwendern und somit der Nutzen des Dienstes kann dadurch weiter gesteigert werden.\newline
-
Ein weiterer Punkt ist die Plattformunabhängigkeit. Diese steht zwar nicht in Verbindung mit der Privatsphäre der Benutzer,
allerdings sollt ein solches Programm unter möglichst vielen Plattformumgebungen lauffähig sein. Zum Einen wird somit der Aufwand
der Implementierung verringert, da die Software nicht mehrmals implementiert werden muss. Zum Anderen werden möglichst viele
@@ -106,27 +101,25 @@ Benutzer erreicht und es kann auch Kommunikation unter Besitzern von unterschied
stattfinden.\newline
Die Software möglichst modular gehalten werden, damit es auch zu einem späteren Zeitpunkt leicht fällt Programmteile
auszutauschen oder zu erweitern. So wäre es zum Beispiel denkbar verschiedene Algorithmen zur Verschlüsselung oder ein anderes
-Protokoll zum Versenden der Daten, zusätzlich zu implementieren. \newline
+Protokoll zum Versenden der Daten, zusätzlich zu implementieren.
\subsection{Verfahren}
Anhand der Anforderungen müssen nun geeignete Verfahren und Protokolle sowohl für Kommunikation als auch für Verschlüsselung
-gewählt werden. Da man mit mehreren Benutzern oder auch mehreren Benutzergruppen kommunizieren können mehrere Schlüssel
-anfallen. Somit sollte der Aufwand um diese Schlüssel zu speichern, zu löschen oder neu zuzuordnen möglichst gering ausfallen. Aus
-Gründen der Schlüsselverwaltung ist daher ein symmetrisches Verfahren besser geeignet als ein asymmetrisches. Es ist einfacher
-einen Schlüssel pro Gruppe zu verwalten als einen privaten, einen öffentlichen sowie unter Umständen noch ein Zertifikat. Des
-Weiteren sind symmetrische Verfahren nicht so berrechnungsintensiv wie asymmetrische \citep{symm}, was einen
+gewählt werden. Da man mit mehreren Benutzern oder auch mehreren Benutzergruppen kommunizieren kann, können mehrere Schlüssel
+anfallen. Somit sollte der Aufwand, für den Anwender, um diese Schlüssel zu speichern, zu löschen oder neu zuzuordnen möglichst
+gering gehalten werden. Aus
+Gründen der Schlüsselverwaltung ist daher ein symmetrisches Verfahren besser geeignet als ein asymmetrisches. Des Weiteren sind
+symmetrische Verfahren nicht so berrechnungsintensiv wie asymmetrische \citep{symm}, was einen
wichtigen Punkt auf mobilen Geräten darstellt. \newline
-
-Der Austausch der Schlüssel könnte theoretisch auf mehreren Wegen geschehen. Da er allerdings spontan durchführbar
-sein soll, muss dies zu jedem Zeitpunkt möglich sein. So könnte man sie per \textit{Bluetooth} übertragen, da eine solche
+Da der Schlüsselaustausch spontan durchführbar sein soll, muss dieser zu jedem Zeitpunkt möglich sein ohne das dafür
+Vorbereitungen getroffen werden müssen. So könnte man die Schlüssel per \textit{Bluetooth} übertragen, da eine solche
Verbindung ohne Vorarbeit aufgebaut werden kann. Allerdings stellt \textit{Bluetooth} ein unsicheres Medium dar
-\citep{bluetooth}da der \textit{Bluetooth-Sitzungs-PIN} per Daten-Phishing wiederhergestellt werden kann. Eine andere
-Möglichkeit die ebenfalls keine Vorarbeit benötigt ist das erstellen eines 2D-Barcodes \citep{qrcode} aus einer Zeichenkette
-dar. Dieser kann fotographieren und wieder in eine Zeichenkette umwandelt werden. Da keine keine Kommunikation über einen
-unsicheren Kanal zwischen den Geräten stattfindet sind die Barcodes bestens zum Schlüsselaustausch geeignet, da der auf diesem
-Wege nicht abgefangen werden kann. \newline
-
+\citep{bluetooth}, da der \textit{Bluetooth-Sitzungs-PIN} per Daten-Phishing wiederhergestellt werden kann. Eine andere
+Möglichkeit, die ebenfalls keine Vorarbeit benötigt, ist das Erstellen eines 2D-Barcodes \citep{qrcode} aus einer Zeichenkette.
+Dieser kann fotographieren und wieder in eine Zeichenkette umwandelt werden. Da keine Kommunikation über einen
+unsicheren Kanal zwischen den Geräten stattfindet sind die Barcodes bestens zum Schlüsselaustausch geeignet, da der Schlüssel auf
+diesem Wege nicht abgefangen werden kann. \newline
Ein vorhandenes, nutzbares Protokoll welches ein aktives Netzwerk bereitstellt ist das \textit{IRC}-Protokoll \citep{IRC}. Es
stehen bereits mehrere Server zur Verfügung und jeder Nutzer kann einen eigenen Server bereitstellen. Die Server sind in
Netzwerken organisiert, wodurch der Ausfall eines Servers nicht zum Beenden der gesamten Kommuniktion führt. Nachrichten
@@ -138,8 +131,7 @@ In der beschriebenen Software werden die Positionsdaten als Zeichenfolge an eine
dort von beliebig vielen anderen Instanzen der Software ausgelesen werden. Diese verarbeiten die Daten im Anschluss, so dass diese
dann als Position auf einer Karte ausgegeben werden können. Beim Versenden der Textnachrichten ist die vorgehensweiße equivalent.
\newline
-
-Durch diesen Lösungsansatz werden sowohl die Berechnungszeiten durch ein symmetrisches Verfahren niedrig gehalten. Der
+Durch diesen Lösungsansatz werden die Berechnungszeiten durch ein symmetrisches Verfahren niedrig gehalten. Der
Verwaltungsaufwand für die Schlüssel ist ebenfalls gering und die Verteilung selbiger kann durch die angesprochenen Barcodes
erfolgen. Bei der Kommunikation gibt es keinen einzelnen zentralen Server der den gesamten Datenverkehr einsehen kann. Die Daten
werden nur in verschlüsselter Form über die \textit{IRC}-Server versendet. Folglich kann jedes beliebige \textit{IRC}-Netzwerk zur
diff --git a/ausarbeitung/Grundlagen.tex~ b/ausarbeitung/Grundlagen.tex~
index c5f6a4e..c25ccec 100644
--- a/ausarbeitung/Grundlagen.tex~
+++ b/ausarbeitung/Grundlagen.tex~
@@ -1,148 +1,133 @@
\section{Grundlagen}
-\textit{Location privacy} wird von Duckham und Kulik durch ``\textit{... a special type of information
+\textit{Location privacy} wird von Duckham und Kulik durch \begin{quote}... a special type of information
privacy which concerns the claim of individuals to determine for themselves when, how, and to what extent location
-information about them is communicated to others.}'' \citep{privacy} definiert. Ein Anwender sollte also in der Lage sein den
-Zeitpunkt, wie und in welchem Umfang Positionsdaten über sie verbreitet werden, selbst festzulegen. Es stellt sich die
+information about them is communicated to others. \end{quote} \citep{privacy} definiert. Ein Anwender sollte also in der Lage
+sein den Zeitpunkt, wie und in welchem Umfang Positionsdaten über sie verbreitet werden, selbst festzulegen. Es stellt sich die
Frage, wie der Benutzer in der Lage ist dieser drei Punkte zu kontrollieren. Dabei soll er den
Zeitpunkt frei bestimmen könnnen, wann und auf welche Art und Weiße er die Daten versendet und wieviele andere Benutzer oder
Institutionen darauf Zugriff haben.
-Im ersten Teil wird der momentane Stand von \textit{location privacy} Software auf mobilen
+Im ersten Teil wird die aktuelle Entwicklung von \textit{location privacy} Software auf mobilen
Geräten aufgezeigt. Des weiteren werden die Anforderungen, die an ein Programm dieser Art gestellt werden, analysiert und mögliche
Ziele einer solchen Software beschrieben.
-\subsection{Aktueller Stand}
+\subsection{Aktuelle Entwicklungen}
-Da so gut wie alle aktuellen Smartphones mit dem \textit{Global Positioning System (GPS)} ausgestattet sind, existieren für die
+Da so gut wie alle aktuellen Smartphones mit dem \textit{Global Positioning System (GPS)} ausgestattet sind, so gibt es für die
verschiedenen Betriebssysteme mittlerweile eine Reihe von Anwendungen die Funktionalitäten rund um die eigene Position bieten. So
-existieren Anwendungen um sich Routen erstellen zu lassen, die eigene Position zu bestimmen oder um \textit{Geocaching}
+gibt es Anwendungen um sich Routen erstellen zu lassen, die eigene Position zu bestimmen oder um \textit{Geocaching}
\citep{geocaching} zu betreiben.\newline
-Zum Beispiel bietet \textit{Google} den Dienst \textit{Google Latitude} \citep{Latitude} an. Bei diesem Programm
+Zum Beispiel bietet \textit{Google} den Dienst \textit{Google Latitude}
+\footnote{\url{http://www.google.com/intl/en_us/latitude/intro.html}} an. Bei diesem Programm
ist es möglich die Position von Freunden, die diesen Dienst auch nutzen, auf einer Karte anzeigen zu lassen. Es besteht hierbei
die Möglichkeit die eigene Position per \textit{GPS} oder mit Hilfe von Daten der \textit{GSM-Funkzelle} zu bestimmen.\newline
-Vergleicht man \textit{Google Latitude} mit der Defintion von \textit{location privacy} durch Duckham und Kulik, so stellt man
-fest dass der Anwender hier nur den Zeitpunkt, zu dem die Positionsinformationen versendet werden, bestimmen kann. Dies
-geschieht genau dann, wenn sie das Programm starten. Nutzen sie das Programm, so werden die Daten an \textit{Google} gesendet.
-Die einzige Einsicht die der Benutzer in diesen Vorgang hat, ist die dass er befreundete Teilnehmer auf seinem Display und diese
-ihn auf ihrem Display sehen. Er hat also keinerlei Kontrolle darüber, was mit den Daten nach dem Absenden passiert, da diese
-an \textit{Google} gesendet werden, wo sie dann durch ein interenes, ihm unbekanntes System an die anderen Nutzern weitergereicht
-werden. Wie dieses von statten geht, weiß der Anwender nicht. Der Anwender kann also weder festlegen, wie noch in
-welchem Umfang er die Daten versenden möchte, da er keinen Einblick in diesen Teil der Strukturen von \textit{Google} hat.
-\newline
-An genau diesem Punkt schliesst die Arbeit \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS} an. Hier werden die
+Betrachtet man ein solches Programm unter den obigen Gesichtspunkten von Duckham und Kulik,
+so stellt man fest dass der Anwender hier nur den Zeitpunkt, zu dem die Positionsinformationen versendet werden, bestimmen kann.
+Nutzen Anwender das Programm, so werden die Daten an den Anbieter eines solchen Dienstes gesendet. Diesem Anbieter obliegen die
+Rechte über die Daten ab diesem Zeitpunkt. Die einzige Einsicht die der Benutzer in diesen Vorgang hat, ist die dass er
+befreundete Teilnehmer auf seinem Display und diese ihn auf ihrem Display sehen. Er hat also keinerlei Kontrolle darüber, was mit
+den Daten nach dem Absenden passiert, da diese an den Anbieter gesendet werden, wo sie dann durch ein interenes, ihm
+unbekanntes System an die anderen Nutzern weitergereicht werden. Wie dieses im genauen abläuft, weiß der Anwender nicht. Der
+Benutzer kann also weder festlegen, wie noch in welchem Umfang er die Daten versenden möchte, da er keinen Einblick in diesen Teil
+der Strukturen der Institution, die den Dienst zur Verfügung stellt, hat.\newline
+An genau diesem Punkt schließt die Arbeit \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS} an. Hier werden die
Daten über ein offenes und frei zugängliches System versendet. Da, dass zum Versenden genutzte, System offen zugänglich ist,
müssen diese Daten zusätzlich verschlüsselt werden, da ansonsten jederman Zugang zu ihnen hätte. \newline
Zum Verschleiern der Position nutzen Kido u.a. \citep{dummy} Datensätze die falsche Positionsangaben beinhalten. Diese werden
-an einen Dienst gesandt, welcher auf alle antwortet. Nur der Client weiß, welche der empfangenen Daten auf der
-eigentlichen Position basieren. Mit dieser Lösung ist es zwar möglich Positionsdaten zu verschleiern, allerdings wird
-hiermit nicht das Problem gelöst, dass der Nutzer die Kontrolle darüber hat, wie seine Daten versendet und genutzt werden.\newline
+an einen Dienst gesandt, welcher auf all diese Datensätze antwortet, egal ob diese die richtigen oder die falschen Daten
+beinhalten. Nur der Client weiß, welche der empfangenen Daten auf der eigentlichen Position basieren. Mit dieser Lösung ist es
+zwar möglich Positionsdaten zu verschleiern, allerdings wird hiermit nicht das Problem gelöst, dass der Nutzer keine Kontrolle
+darüber hat, wie seine Daten versendet und genutzt werden.\newline
Einen anderer Ansatz verfolgen Gruteser und Grundwald \citep{kprivacy}. Sie versuchen mit Hilfe von \textit{k-anonymity}
\citep{kanonymity} die Position zu verschleiern. Man versteht unter \textit{k-anonymity}, dass in
einer Menge von $k$ Personen ein Teilnehmer nicht von den anderen $k-1$ Teilnehmern unterschieden werden kann. Gruteser und
Grundwald haben hierfür einen \textit{quadtree} \citep{quadtree} genutzt um bestimmte Bereiche zu erstellen. Diese Bereiche haben
nur eine Vorraussetzung, sie müssen $k$ Personen enthalten. Somit kann nicht festgestellt werden, welche Person
-eines Bereiches die Daten versandt hat. Allerdings kann dieses Vorgehen nicht für einen Dienst mit der Funktionalität von
-\textit{Google Latitude} genutzt werden, da es mit diesem Ansatz nicht möglich ist Positionsdaten von einzelnen Personen zu
-versenden. Zusätzlich ist auch hier nicht gegeben, dass die Anwender Einsicht in die Verwendung und Verbreitung ihrer Daten
-erhalten.\newline
-
+eines Bereiches die Daten versandt hat. Allerdings kann dieses Vorgehen nicht für eine Anwendung mit der Funktionalität eines
+Dienstes, der gezielt Positionen einzelner andere Benutzer anzeigt, genutzt werden. Der Grund dafür ist, dass es mit diesem
+Ansatz nicht möglich ist Positionsdaten von einzelnen Personen zu versenden. Zusätzlich ist auch hier nicht gegeben, dass die
+Anwender Einsicht in die Verwendung und Verbreitung ihrer Daten erhalten.
-%anderer titel der section
\subsection{Vorraussetzungen}
-Da die Verbreitung von mobilen Geräten in den letzten Jahren beständig zugenommen hat und
-alle neueren Modelle ein \textit{GPS}-Modul besitzen, sind die Vorraussetzungen für Anwendungen die Positionsdaten nutzen,
-gegeben. Auch im Rahmen der Datenübertragung sind alle modernen Geräte in der Lage, Daten sowohl über den \textit{3G}-Standard
+Im Rahmen der Datenübertragung sind alle modernen Geräte in der Lage, Daten sowohl über den \textit{3G}-Standard
sowie per \textit{WLAN} zu übertragen. \newline
Wenn nun ein sicherer Austausch von Positionsdaten erfolgen soll, so müssen neben der Hardware, auch andere Rahmenbedingungen
gegeben sein. Da man durch Positionsdaten die aktuelle Position erfahren oder Bewegungsprofile erstellen kann, sollten der Zugang
-zu ihnen nur dann erlaubt sein wenn der betreffende Benutzer damit einverstanden ist. Die Daten müssen also soweit entfremdet oder
-abgeändert werden damit nur eine vom Nutzer bestimmte Gruppe diese wieder rekonstruieren kann. Somit ist gegeben, dass der Nutzer
-über das Ausmaß der Verbreitung seiner Daten die Kontrolle bewahren kann.\newline
-Der Anwender sollte in der Lage zu sein Daten zu jedem von ihm gewünschten Zeitpunkt zu versenden. Er muss also in der Lage sein
+zu diesen nur dann erlaubt sein wenn der Benutzer der sie versendet damit einverstanden ist. Die Daten müssen also soweit
+entfremdet oder abgeändert werden damit nur eine vom Nutzer bestimmte Gruppe diese wieder rekonstruieren kann. Somit ist gegeben,
+dass der Nutzer über das Ausmaß der Verbreitung seiner Daten die Kontrolle bewahren kann.\newline
+Der Anwender muss Daten zu jedem von ihm gewünschten Zeitpunkt zu versenden können. Er muss also in der Lage sein
die dafür benötigten Parameter zu sofort zu erstellen und weiterzugeben. Somit kann er den Zeitpunkt, zu welchem er seine Daten
versenden möchte, frei wählen.\newline
-Ist dies gegeben, sollen die Daten im nächsten Schritt versendet werden. Auch hier sollte ein Weg gefunden werden mit dem der
+Ist dies gegeben, werden die Daten im nächsten Schritt versendet. Auch hier muss ein Weg gefunden werden mit dem der
Nutzer möglichst viel Kontrolle über seine Datensätze inne hat. Um diese Kontrolle zu wahren, müssen die Informationen mit
-einer möglichst transparenten und doch verlässlichen Methode verteilt werden. Hierbei darf die Möglichkeit der Speicherung der
-Daten über die Zeit nicht ausser Acht gelassen werden. Um dies zu erschweren sollte man zum Übertragen der Informationen
-nicht nur auf einen zentralen Knoten angewiesen sein, sondern nutzt im optimalen Fall ein ganzes Netzwerk von solchen
-Knotenpunkten. Bei diesem Netzwerk sollen allerdings alle Knotenpunkt einsehbar sein, damit der Nutzer zu jedem Zeitpunkt weiß,
-was mit seinen Daten geschieht. Ist dies gegeben so ist der Nutzer in der Lage zu kontrollieren wie seine Daten versandt
-werden.\newline
-
+einer möglichst transparenten und doch verlässlichen Methode verschickt werden.
+Zum Weiteren Schutz der verschlüsselten Daten darf man zum Übertragen der Informationen nicht nur auf einen zentralen Knoten
+angewiesen sein, sondern nutzt im optimalen Fall ein ganzes Netzwerk von solchen Knotenpunkten. Bei diesem Netzwerk sind
+allerdings alle Knotenpunkt einsehbar, damit der Nutzer zu jedem Zeitpunkt weiß, was mit seinen Daten geschieht. Ist dies
+gegeben so ist der Nutzer in der Lage zu kontrollieren wie seine Daten versandt werden.
\subsection{Ziele}
Zusammenfassend kann also gesagt werden, dass eine Software mit den beschriebenen Eigenschaften die Sicherheit der
-Daten, in Bezug auf Zugänglichkeit, und das Vermeiden von Datenspeicherung zum Ziel haben sollte. Dem
-Anwender soll es aber trotz allem einfach gemacht werden dieses Programm zu nutzen. Die Inhalte der Anwendung sollen also soweit
-abstrahiert werden, als dass auch ein Benutzer ohne Fachkenntnis alle Features nutzen kann, ohne dass die obigen Punkte ausser
-Kraft treten. \newline
-
+Daten, in Bezug auf Zugänglichkeit, und das Vermeiden von Datenspeicherung zum Ziel hat. Anwender soll es aber trotz allem einfach
+gemacht werden dieses Programm zu nutzen. Die Inhalte der Anwendung müssen also soweit abstrahiert werden, als dass auch ein
+Benutzer ohne Fachkenntnis alle Funktionen der Anwendung nutzen kann, ohne dass die obigen Punkte ausser Kraft treten. \newline
Zum Versenden der Daten muss eine offene Struktur genutzt werden, in welche jeder Einsicht hat und welche frei genutzt werden
-kann. Es soll gewährleistet sein das jeder Teilnehmer dieser sofort beitreten kann, ohne das für ihn Restriktionen, wie zum
+kann. Es muss gewährleistet sein das jeder Teilnehmer dieser sofort beitreten kann, ohne das für ihn Restriktionen, wie zum
Beispiel ein Benutzeraccount, gelten. Diese Struktur sollte über ein Protokoll verfügen das verlässlich, stabil und auch für
langsame Netzwerke optimiert ist. Eine reibungslose Kommunikation kann somit garantiert werden. \newline
-Um die Kommunikation zwischen verschiedenen Teilnehmern zu ermöglichen soll es möglich sein Chatnachrichten auszutauschen. Die
-Interaktion zwischen den Anwendern und somit der Nutzen des Dienstes kann dadurch weiter gesteigert werden.\newline
-
-Durch die Nutzung einer, für alle, offenen Struktur ist es von Nöten, dass die Daten verschlüsselt werden. Da bei
+Um die Kommunikation zwischen verschiedenen Teilnehmern zu ermöglichen muss es möglich sein Chatnachrichten auszutauschen. Die
+Interaktion zwischen den Anwendern und somit der Nutzen des Dienstes kann hierdurch weiter gesteigert werden.\newline
+Durch die Nutzung einer, für alle, offene Struktur ist es von Nöten, dass die Daten verschlüsselt werden. Da bei
Verschlüsselungen der Austausch von Schlüsseln voraussetzt wird, muss ein Verfahren genutzt werden welches den Austausch von zwei
-Schlüsseln auf einfache Weise ermöglicht. Gleichzeitig muss garantiert sein dass die Schlüssel während des Austauschs nicht von
-unbefugten Personen abgefangen werden. \newline
+Schlüsseln auf einfache Weise ermöglicht. Da diese Software für mobile Geräte ausgelegt ist, müssen die benötigten Schlüssel
+spontan ausgetauscht werden können, da der Anwender die Nutzung eines solchen Dienstes nicht immer im Vorraus planen möchte und
+kann. Gleichzeitig muss garantiert sein dass die Schlüssel während des Austauschs nicht von unbefugten Personen abgefangen werden.
+\newline
Ist ein solches Verfahren gegeben, so kann ein Algorithmus genutzt werden der sowohl sicher ist, als auch mit möglichst geringem
Aufwand die Daten ver- und entschlüsselt. \newline
-Da Positionsdaten versendet werden, sollte die Applikation in der Lage sein die Standorte anderer Nutzer anzuzeigen. Da aus
-Gründen der Nutzbarkeit die Positionen der Teilnehmer auf einer Karte dargestellt werden sollen, muss ein Format für die Karte
-genutzt werden, welches auf dem mobilen Gerät darstellbar und einfach auf den neusten Stand zu bringen ist.\newline
+Da Positionsdaten versendet werden, müssen diese visualisiert werden. Somit muss die Applikation in der Lage sein die Standorte
+anderer Nutzer anzuzeigen. Da aus Gründen der Nutzbarkeit die Positionen der Teilnehmer auf einer Karte dargestellt werden sollen,
+muss ein Format für die Karte genutzt werden, welches auf dem mobilen Gerät darstellbar und einfach auf den neusten Stand zu
+bringen ist.\newline
Benutzer die sich in größeren Entfernungen befinden sind für Programme dieser Art nur begrenzt interessant, da sie mit zunehmender
Entfernung immer schwerer zu erreichen sind. Deshalb werden nur Teilnehmer innerhalb eines bestimmten Radius angezeigt.\newline
-
-
-
Ein weiterer Punkt ist die Plattformunabhängigkeit. Diese steht zwar nicht in Verbindung mit der Privatsphäre der Benutzer,
-allerdings sollt ein solches Programm unter möglichst vielen Plattformumgebungen lauffähig sein. Zum Einen wird somit der Aufwand
+allerdings sollte ein solches Programm unter möglichst vielen Plattformumgebungen lauffähig sein. Zum Einen wird somit der Aufwand
der Implementierung verringert, da die Software nicht mehrmals implementiert werden muss. Zum Anderen werden möglichst viele
Benutzer erreicht und es kann auch Kommunikation unter Besitzern von unterschiedlichen Typen von Mobiltelefonen
stattfinden.\newline
-Die Software möglichst modular gehalten werden, damit es auch zu einem späteren Zeitpunkt leicht fällt Programmteile
-auszutauschen oder zu erweitern. So wäre es zum Beispiel denkbar verschiedene Algorithmen zur Verschlüsselung oder ein anderes
-Protokoll zum Versenden der Daten, zusätzlich zu implementieren. \newline
+Die Struktur der Software muss möglichst modular gehalten werden, damit es auch zu einem späteren Zeitpunkt leicht fällt
+Programmteile auszutauschen oder zu erweitern. So wäre es zum Beispiel denkbar verschiedene Algorithmen zur Verschlüsselung oder
+ein anderes Protokoll zum Versenden der Daten, zusätzlich zu implementieren.
\subsection{Verfahren}
Anhand der Anforderungen müssen nun geeignete Verfahren und Protokolle sowohl für Kommunikation als auch für Verschlüsselung
gewählt werden. Da man mit mehreren Benutzern oder auch mehreren Benutzergruppen kommunizieren kann, können mehrere Schlüssel
-anfallen. Somit sollte der Aufwand um diese Schlüssel zu speichern, zu löschen oder neu zuzuordnen möglichst gering ausfallen. Aus
-Gründen der Schlüsselverwaltung ist daher ein symmetrisches Verfahren besser geeignet als ein asymmetrisches. Es ist einfacher
-einen Schlüssel pro Gruppe zu verwalten als einen privaten, einen öffentlichen sowie unter Umständen noch ein Zertifikat. Des
-Weiteren sind symmetrische Verfahren nicht so berrechnungsintensiv wie asymmetrische \citep{symm}, was einen
-wichtigen Punkt auf mobilen Geräten darstellt. \newline
-
+anfallen. Somit soll der Aufwand, für den Anwender, um diese Schlüssel zu speichern, zu löschen oder neu zuzuordnen möglichst
+gering gehalten werden. Symmetrische Verfahren nicht so berrechnungsintensiv wie asymmetrische \citep{symm}, was einen
+wichtigen Punkt auf mobilen Geräten darstellt. Aufgrund dieser Tatsache wird eine symmetrische Verschlüsselung genutzt.\newline
Da der Schlüsselaustausch spontan durchführbar sein soll, muss dieser zu jedem Zeitpunkt möglich sein ohne das dafür
Vorbereitungen getroffen werden müssen. So könnte man die Schlüssel per \textit{Bluetooth} übertragen, da eine solche
Verbindung ohne Vorarbeit aufgebaut werden kann. Allerdings stellt \textit{Bluetooth} ein unsicheres Medium dar
-\citep{bluetooth}, da der \textit{Bluetooth-Sitzungs-PIN} per Daten-Phishing wiederhergestellt werden kann. Eine andere
-Möglichkeit, die ebenfalls keine Vorarbeit benötigt, ist das Erstellen eines 2D-Barcodes \citep{qrcode} aus einer Zeichenkette.
+\citep{bluetooth}, da der \textit{Bluetooth-Sitzungs-PIN} per \textit{Daten-Phishing} wiederhergestellt werden kann. Eine andere
+Möglichkeit, die ebenfalls keine Vorarbeit benötigt, ist das Erstellen eines 2D-Barcodes \footnote{QR Code
+\url{http://www.denso-wave.com/qrcode/qrstandard-e.html}} aus einer Zeichenkette.
Dieser kann fotographieren und wieder in eine Zeichenkette umwandelt werden. Da keine Kommunikation über einen
-unsicheren Kanal zwischen den Geräten stattfindet sind die Barcodes bestens zum Schlüsselaustausch geeignet, da der Schlüssel auf
+unsicheren Kanal zwischen den Geräten stattfindet sind die Barcodes optimal zum Schlüsselaustausch geeignet, da der Schlüssel auf
diesem Wege nicht abgefangen werden kann. \newline
-
-Ein vorhandenes, nutzbares Protokoll welches ein aktives Netzwerk bereitstellt ist das \textit{IRC}-Protokoll \citep{IRC}. Es
-stehen bereits mehrere Server zur Verfügung und jeder Nutzer kann einen eigenen Server bereitstellen. Die Server sind in
-Netzwerken organisiert, wodurch der Ausfall eines Servers nicht zum Beenden der gesamten Kommuniktion führt. Nachrichten
-werden innerhalb des Netzwerkes von Server zu Server weitergeleitet bis diese auf dem Zielserver ankommen. Innerhalb der
-\textit{IRC}-Netzwerke werden verschiedene \textit{Channels} bereitgestellt, an welche die Nachrichten gesendet werden können.
-Des weiteren steht es jedem Benutzer frei, eigene \textit{Channels} zu öffnen. Gesendete Nachrichten werden in diesen
-\textit{Channels} ausgegeben. Somit ist zu jedem Zeitpunkt einsehbar was mit versandten Daten passiert.\newline
+Aufgrund der Möglichkeit das jeder Nutzer beliebig beitreten und Daten in dieser Struktur austauschen kann, fiel die Wahl zum
+versenden der Daten auf das \textit{IRC}-Protokoll. Des weiteren spricht für diese Entscheidung, dass das
+\textit{IRC}-Protokoll \citep{IRC} weit verbreitet ist und eine ausgedehnte Serverstruktur zu Grunde liegt. Auch die Stabilität
+und Verlässlichkeit des Protokolles ist gegeben. Da die \textit{IRC}-Server in Netzwerken organisiert sind führt der Ausfall eines
+Servers nicht zur Beendigung der gesamten Kommuniktion. Innerhalb der \textit{IRC}-Netzwerke werden verschiedene \textit{Channels}
+bereitgestellt, an welche Nachrichten gesendet werden können. Ein weiterer Vorteil von \textit{IRC} ist, dass wenn Daten an
+mehrere Benutzer gesendet werden sollen, diese nur einmal an einen \textit{Channel} versandt werden müssen und jeder Benutzer in
+diesem \textit{Channel} diese Daten empfangen kann. Des weiteren steht es jedem Benutzer frei, eigene \textit{Channels} zu
+öffnen.\newline
In der beschriebenen Software werden die Positionsdaten als Zeichenfolge an einen dieser \textit{Channels} gesendet und können
dort von beliebig vielen anderen Instanzen der Software ausgelesen werden. Diese verarbeiten die Daten im Anschluss, so dass diese
-dann als Position auf einer Karte ausgegeben werden können. Beim Versenden der Textnachrichten ist die vorgehensweiße equivalent.
-\newline
-
-Durch diesen Lösungsansatz werden die Berechnungszeiten durch ein symmetrisches Verfahren niedrig gehalten. Der
-Verwaltungsaufwand für die Schlüssel ist ebenfalls gering und die Verteilung selbiger kann durch die angesprochenen Barcodes
-erfolgen. Bei der Kommunikation gibt es keinen einzelnen zentralen Server der den gesamten Datenverkehr einsehen kann. Die Daten
-werden nur in verschlüsselter Form über die \textit{IRC}-Server versendet. Folglich kann jedes beliebige \textit{IRC}-Netzwerk zur
-Kommunikation gewählt werden. \ No newline at end of file
+dann als Position auf einer Karte ausgegeben werden können. Beim Versenden der Textnachrichten ist die vorgehensweiße equivalent. \ No newline at end of file
diff --git a/ausarbeitung/Tutorial.aux b/ausarbeitung/Tutorial.aux
index aa134cd..1935343 100644
--- a/ausarbeitung/Tutorial.aux
+++ b/ausarbeitung/Tutorial.aux
@@ -1,23 +1,16 @@
\relax
-\citation{POSIX}
-\citation{CeGCC}
\@writefile{toc}{\contentsline {section}{\numberline {3}Technische Grundlagen}{8}{section.3}}
\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Betriebsysteme f\IeC {\"u}r mobile Ger\IeC {\"a}te}{8}{subsection.3.1}}
-\citation{Android}
-\citation{WebOS}
-\citation{iPhoneOS}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.1}Windows Mobile}{9}{subsubsection.3.1.1}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.2}Android}{9}{subsubsection.3.1.2}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.3}WebOS}{9}{subsubsection.3.1.3}}
-\citation{SymbianOS}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.4}iPhone OS}{10}{subsubsection.3.1.4}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.4}iPhone OS}{9}{subsubsection.3.1.4}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.5}Symbian OS}{10}{subsubsection.3.1.5}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.6}Zielplattform}{10}{subsubsection.3.1.6}}
\@writefile{toc}{\contentsline {subsection}{\numberline {3.2}Softwaregrundlagen}{10}{subsection.3.2}}
-\citation{efl}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.2.1}CeGCC}{11}{subsubsection.3.2.1}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.2.1}CeGCC}{10}{subsubsection.3.2.1}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.2.2}Enlightenment}{11}{subsubsection.3.2.2}}
-\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Beispiele verschiedener \textit {Elementary} Icons}}{12}{figure.1}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Beispiele verschiedener \textit {Elementary} Icons}}{11}{figure.1}}
\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Aufbau von \textit {Enlightenment}}}{12}{figure.2}}
\@setckpt{Tutorial}{
\setcounter{page}{13}
@@ -26,7 +19,7 @@
\setcounter{enumii}{0}
\setcounter{enumiii}{0}
\setcounter{enumiv}{0}
-\setcounter{footnote}{0}
+\setcounter{footnote}{15}
\setcounter{mpfootnote}{0}
\setcounter{part}{0}
\setcounter{section}{3}
diff --git a/ausarbeitung/Tutorial.tex b/ausarbeitung/Tutorial.tex
index f366c88..f4ffcc7 100644
--- a/ausarbeitung/Tutorial.tex
+++ b/ausarbeitung/Tutorial.tex
@@ -1,24 +1,24 @@
\section{Technische Grundlagen}
-Die Wahl der Plattform hängt von zwei verschiedenen Faktoren ab. Zum einen stellt sich die Frage, ob die Handymodelle die
-benötigte Hardware, wie zum Beispiel \textit{GPS} oder eine Kamera besitzen, zum anderen ob Schnittstellen vorhanden sind um das
+Die Wahl der Plattform hängt von zwei verschiedenen Faktoren ab. Zum Einen stellt sich die Frage, ob die Handymodelle die
+benötigte Hardware, wie zum Beispiel \textit{GPS} oder eine Kamera besitzen, zum Anderen ob Schnittstellen vorhanden sind um das
Programm für das System zu entwickeln. \newline
-
Die Problematik der Plattformwahl aufgrund von vorhandener oder nicht vorhandener Hardware ist nicht allzu groß. Die meisten
aktuellen Geräte haben mittlerweile eine ähnliche Ausstattung was Speicher und Prozessorleistung angeht.Auch erweiterte Features
wie \textit{GPS} oder Lagesensoren sind in den meisten, aktuellen Geräten vorhanden oder werden in der nächsten Generation, des
jeweiligen Herstellers, vorhanden sein.\newline
-
-Es gestalltet sich schon schwieriger eine Plattform aufgrund des Betriebssystemes zu wählen. Bei geeigneter Auswahl ist es
-möglich die Software auf mehrere Betriebssysteme für Smartphones zu portieren und somit eine mehrfache Implementation zu
-vermeiden. Es wäre somit auch möglich viele Nutzer zu erreichen und die Kommunikation zwischen einem Besitzer eines
-\textit{iPhones} sowie dem Besitzer eines \textit{Palm Pre's} sicherzustellen.\newline
-Des weiteren ist es auch von Interesse, ob andere Programme und Bibliotheken auf den jeweiligen Systemen ausführbar sind.
-Es wäre also ein \textit{Layer} von Interesse mit welchem immer die gleichen Programmbibliotheken genutzen werden können. Dabei
-sollte das zugrundeliegende System unabhängig von diesem \textit{Layer} sein. Es soll also damit vom zugrundeliegenden
+Da die gegebenen Hardwareunterschiede minimal sind, wird eine Plattform aufgrund des Betriebssystemes ausgewählt. Bei
+geeigneter Wahl ist es möglich die Software auf mehrere Betriebssysteme für Smartphones zu portieren und somit eine mehrfache
+Implementation zu vermeiden. Es wäre somit auch möglich viele Nutzer zu erreichen und die Kommunikation zwischen einem Besitzer
+eines \textit{iPhones} sowie dem Besitzer eines \textit{Palm Pre's} sicherzustellen.\newline
+Ein weiterer Punkt der zu einer Entscheidung beiträgt ist die Frage ob andere Programme und Bibliotheken auf den jeweiligen
+Systemen ausführbar sind. Es wird also ein \textit{Layer} benötigt, mit welchem immer die gleichen Programmbibliotheken
+genutzen werden können. Dabei sollte das zugrundeliegende System unabhängig von diesem \textit{Layer} sein. Es soll also damit vom
+zugrundeliegenden
Betriebssystem abstrahiert werden. Ein entsprechender \textit{Layer} stellt der \textit{Portable Operating System Interface for
-Unix Layer (POSIX Layer)} \citep{POSIX} dar. Mit diesem \textit{Layer} stehen eine große Menge an aktuellen
-Bibliotheken aus der \textit{Open-Source} Gemeinde zur Verfügung. Diese haben den Vorteil, dass sie aktiv
+Unix Layer (POSIX Layer)} \footnote{POSIX \url{http://standards.ieee.org/regauth/posix/}} dar. Mit diesem \textit{Layer} stehen
+eine große Menge an aktuellen Bibliotheken aus der \textit{Open-Source} Gemeinde zur Verfügung. Diese haben den Vorteil, dass sie
+aktiv
weiterentwickelt werden und auch ständig neue Bibliotheken hinzukommen. Anwendungen, die auf einem \textit{Linux}-System
entwickelt wurden können somit ohne weiteres auf ein anderes, \textit{POSIX} kompatibles System, portiert werden, ohne das
die genutzten Bibliotheken ausgetauscht werden müssen.\newline
@@ -34,55 +34,55 @@ eingegangen.
\subsubsection{Windows Mobile}
-Das von Microsoft entwickelte \textit{Windows Mobile} in der aktuellen Version 6.5 verfügbar. Das gesamte Betriebssystem basiert
-auf der \textit{Windows Win32 API} und lässt Ähnlichkeiten zu den Desktop-Varianten der Windows-Familie erkennen. \textit{Windows
-Phone} besitzt keinen \textit{POSIX Layer}, allerdings existiert ein \textit{Cross-Compiler} names \textit{CeGCC} \citep{CeGCC},
-mit welchem Programme die in \textit{C}/\textit{C++} geschrieben wurden für diese Plattform kompiliert werden können.\newline
+Das von Microsoft entwickelte \textit{Windows Mobile}
+\footnote{Windows Mobile \url{http://www.microsoft.com/windowsmobile/de-de/default.mspx}} in der aktuellen Version 6.5 verfügbar.
+Das gesamte Betriebssystem basiert
+auf der \textit{Windows Win32 API} und lässt Ähnlichkeiten zu den Desktop-Varianten der Windows-Familie erkennen. Es existiert
+ein \textit{Cross-Compiler} names \textit{CeGCC} \footnote{CeGCC \url{http://cegcc.sourceforge.net/}},
+mit welchem Programme die in \textit{C}/\textit{C++} geschrieben wurden für diese Plattform kompiliert werden können.
\subsubsection{Android}
-Das von \textit{Google} entwickelte \textit{Android} \citep{Android} setzt auf einen Linux-Kernel der Version 2.6 auf. Dieser
-Kernel kümmert sich um die Prozess- und Speicherverwaltung, Kommunikation sowie um die Hardwareabstraktion. Auf diese Grundlage
-setzt eine virtuelle Java-Maschine auf, in welcher \textit{Android} läuft.\newline
-
+Das von \textit{Google} entwickelte \textit{Android} \footnote{Android \url{http://www.android.com/}} setzt auf einen
+\textit{Linux-Kernel} der Version 2.6 auf. Dieser \textit{Kernel} kümmert sich um die Prozess- und Speicherverwaltung,
+Kommunikation sowie um die Hardwareabstraktion. Auf diese Grundlage setzt eine virtuelle Java-Maschine auf, in welcher
+\textit{Android} läuft.\newline
Zum Implementieren von Anwendungen stellt \textit{Google} eigens ein \textit{SDK} bereit. Dieses greift allerdings nur auf
\textit{Java}-Bibliotheken zurück, womit sich die Anzahl der nutzbaren Sprachen im Moment eben auf diese eine beschränkt. Des
-weiteren bietet \textit{Google} mittlerweile ein \textit{NDK} an, mit desen Hilfe es auch möglich ist Programme in \textit{C} oder
-\textit{C++} zu schreiben. \textit{Google} rät allerdings von der Nutzung anderer Bibliotheken ab, da nur im \textit{NDK}
-enthaltenen, laut Hersteller, stabil auf den Geräten laufen.
-Allerdings ergeben sich hier für die Zukunft, sobald mehr Bibliotheken unterstützt werden, sicher interessante Möglichkeiten für
-Entwicklung und Portierung von Anwendungen.\newline
+weiteren bietet \textit{Google} ein \textit{NDK} an, mit desen Hilfe es auch möglich ist Programme in \textit{C} oder
+\textit{C++} zu schreiben.
\subsubsection{WebOS}
-\textit{WebOS} \citep{WebOS} wurde von \textit{Palm} als Nachfolger von \textit{PalmOS} entwickelt und ist momentan nur auf zwei
-Geräten zu finden: Auf dem \textit{Palm Pre} und dem \textit{Palm Pixi}.\newline
+\textit{WebOS} \footnote{WebOS \url{http://palmwebos.org/}} wurde von \textit{Palm} als Nachfolger von \textit{PalmOS}
+\footnote{PalmOS \url{http://www.palm.com/}} entwickelt und ist momentan nur auf zwei Geräten zu finden: Auf dem \textit{Palm Pre}
+und dem \textit{Palm Pixi}.\newline
+Unter der Benutzeroberfläche von \textit{WebOS} arbeitet ein \textit{Linux-Kernel} in der Version 2.6. Somit ist es möglich, wenn
+man Zugriff auf diesen Kernel hat, \textit{POSIX}-kompatible Software unter \textit{WebOS} zu betreiben.
Für dieses Betriebssystem existiert ein \textit{SDK} für \textit{HTML5}, \textit{CSS} und \textit{Java}. Ein weiteres, welches im
-März 2010 veröffentlicht wird, soll die \textit{C} und \textit{C++} Entwicklung ermöglichen. Des weiteren beinhaltet
-\textit{WebOS} einen \textit{POSIX Layers}. Somit werden mehrere Programmiersprachen unterstützt und es besteht die
-Möglichkeit den \textit{POSIX Layer} zu nutzen.\newline
+März 2010 veröffentlicht wird, soll die \textit{C} und \textit{C++} Entwicklung ermöglichen.
\subsubsection{iPhone OS}
-Bei \textit{iPhoneOS} \citep{iPhoneOS} handelt es sich um eine abgeänderte und angepasste Version von MacOS. Es wurde eigens für
-das iPhone entwickelt. Auch für dieses System existiert ein \textit{SDK}, welches allerdings nur die Sprache \textit{Objective-C}
-unterstützt. Des weiteren fehlt auch eine Unterstützung des \textit{POSIX Layers} oder einer anderen Abstraktion dieser Art. Der
-größte Kritikpunkt an diesem System dürfte allerdings das fehlen von \textit{Multitasking}-Unterstützung sein. Somit ist es nicht
+Bei \textit{iPhoneOS} \footnote{iPhoneOS \url{http://www.apple.com/de/iphone/}} handelt es sich um eine abgeänderte und angepasste
+Version von MacOS. Somit bassiert auch der Kernel von \textit{iPhoneOS} sowohl auf teilen eines \textit{BSD}- \footnote{BSD
+\url{https://www.bsdwiki.de/}} sowie \textit{Mach}-Kernels
+\footnote{Mach \url{http://www.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html}}. Dieses Betriebssystem wurde eigens für das
+iPhone entwickelt. Auch für dieses System existiert ein \textit{SDK}, welches allerdings nur die Sprache \textit{Objective-C}
+unterstützt. Der größte Kritikpunkt an diesem System ist das Fehlen von \textit{Multitasking}-Unterstützung. Somit ist es nicht
möglich zwei Anwendungen parallel auszuführen, was gerade \textit{location awareness} Anwendungen stark einschränkt, da hier
-häufig weitere Dienste im Hintergrund aktiv sein sollten.\newline
+häufig weitere Dienste im Hintergrund aktiv sein sollten.
\subsubsection{Symbian OS}
-\textit{SymbianOS} \citep{SymbianOS} ist eine Betriebssystem welches vorzugsweise auf Geräten der Firma \textit{Nokia} zum
+\textit{SymbianOS} \footnote{SymbianOS \url{http://www.symbian.org/}} ist eine Betriebssystem welches vorzugsweise auf Geräten der
+Firma \textit{Nokia} zum
Einsatz kommt. Es existiert ein \textit{SDK}, was neben \textit{C}/\textit{C++} auch noch weitere Sprachen wie zum Beispiel
\textit{Python} oder \textit{Java} unterstützt. Mit dem \textit{SDK} wird auch ein \textit{Cross-Compiler} angeboten, welcher es
-ermöglicht Programme direkt zu portieren. Des weitern besitzt \textit{Symian OS} auch einen \textit{POSIX Layer}.
+ermöglicht Programme direkt zu portieren. Des weitern besitzt \textit{Symian OS} einen \textit{POSIX Layer}.
\subsubsection{Zielplattform}
-Die Wahl der Zielplattform ist auf \textit{Windows Mobile} gefallen, da es hier möglich ist die Anwendung in \textit{C} zu
-implementieren. Da mit Hilfe des \textit{CeGCC} die Anwendung portiert werden kann, kann diese auch in einer
-\textit{Linux}-Umgebung entwickelt werden.\newline
\textit{iPhoneOS} wurde aufgrund seiner mangelnden \textit{Multitasking}-Unterstützung ausgeschlossen. Diese ist für den
geplanten Dienst wichtig, da bei diesem Prozesse im Hintergund notwendig sind und dies auf einem solchen System nicht
realisierbar wäre. \textit{Android} hat zwar eine \textit{C} Unterstützung, allerdings gibt der Hersteller an das nur die
@@ -98,29 +98,38 @@ jeweiligen Plattformen zu kompilieren, sowie die graphischen Elemente auf den Pl
\subsubsection{CeGCC}
-Da \textit{Windows Mobile} und die Programmiersprache \textit{C} genutzt wird, wird der \textit{CeGCC} als
-\textit{Cross-Compiler} verwendet. Mit ihm ist es möglich \textit{C} Programmcode, der unter \textit{Linux} entwickelt wurde, nach
+Mit dem \textit{CeGCC} ist es möglich \textit{C} Programmcode, der unter \textit{Linux} entwickelt wurde, nach
\textit{Windows Mobile} zu portieren. Bei \textit{CeGCC} handelt es sich um ein \textit{Open-Source} Projekt, bassierend auf dem
\textit{GCC}. Mit diesem Tool können in einer \textit{Linux} Umgebung die für \textit{Windows Mobile} benötigten Bibliotheken und
ausführbaren Dateien erstellt werden.\newline
+Der \textit{CeGCC} kann in zwei unterschiedlichen Versionen genutzt werden. Zum einen bietet der \textit{wince-mingw32ce} eine
+Menge an Tools mit welchen man native \textit{Windows Mobile} Applikationen erstellen kann. Hierzu wird eine
+Portierung der \textit{GNU} \footnote{GNU \url{http://www.gnu.org/}} Enwicklungswergzeuge aus dem \textit{MinGW} \footnote{MinGW
+http://mingw.org/} Projekt genutzt. Diese kompilieren und linken Code, um diesen unter \textit{Windows Mobile} ausführbar zu
+machen. Die andere Möglichkeit stellt die Nutzung des \textit{arm-cegcc} dar. Mit diesem kann \textit{POSIX}
+kompatibler Programmcoder nach \textit{Windows Mobile} portiert werden. %verfeinern
+
+%# arm-mingw32ce : toolset to build native Windows CE applications
+%# arm-cegcc : toolset to port unix source to Windows CE
-Es wird zwischen zwei verschiedenen Arten des \textit{CeGCC's} unterschieden. Zum Einen \textit{CeGCC} und zum Anderen
-\textit{mingw32ce}.
-Der Unterschied zwischen diesen beiden Kompilern besteht darin, dass ersterer nur dann benutzt wird, wenn man nur Linux
-Bibliotheken einbinden möchte. Der \textit{mingw32ce}-Kompiler wird dann gebraucht, wenn auch \textit{Windows Mobile}
-Bibliotheken zum Einstatz kommen.\newline
+% Remember that arm-wince-cegcc implements a unix-like layer on top of Windows CE, and that arm-wince-mingw32ce implements the
+%native CE API.
-Soll das Programm nun für \textit{WebOS} oder \textit{SymbianOS} portiert werden, kann dies auf unter \textit{Linux} normal
-kompiliert werden.
+%The unix-like layer is only provided in the arm-wince-cegcc tools, the arm-wince-mingw32ce deliberately lack this as they attempt
+%to provide a development environment that is as close to Windows CE as possible.
+% Part of the code in this directory is required to be able to create executables that start a program in a consistent way (e.g.
+% crt0.o, the startup code in an executable), but another part of this code provides a unix like layer with functionalities absent
+% in Windows CE.
\subsubsection{Enlightenment}
Neben einem \textit{Cross-Compiler} wird noch ein geeignetes Frontend benötigt, um das Programm auch für den Benutzer
ansprechend darzustellen und eine einfache Bedienbarkeit zu garantieren. Dieses Frontend sollte auch in \textit{C} oder
-\textit{C++} geschrieben sein, um auch hier die Portierbarkeit für die gewünschten Plattformen zu erhalten. Hier fiel die Wahl
-auf das freie, seit 1997 existierende, \textit{Enlightenment} \citep{efl} Projekt. Dieses Softwarepaket unterstützt alle gängigen
-Plattformen wie Windows, Linux, BSD und MacOS. Es beinhaltet einen eigenen \textit{Window-Manager} names \textit{Elementary}.
-\textit{Elementary} bietet ein umfangreiches Paket an grafischen Elementen die genutzt und frei angeordnet werden können.
+\textit{C++} geschrieben sein, um auch hier die Portierbarkeit für die gewünschten Plattformen zu erhalten. Genutzt wird das
+freie, seit 1997 existierende, \textit{Enlightenment} \footnote{Elementray \url{http://www.enlightenment.org/}} Projekt. Dieses
+Softwarepaket unterstützt alle gängigen Plattformen wie Windows, Linux, BSD und MacOS. Es beinhaltet einen eigenen
+\textit{Window-Manager} names \textit{Elementary}. \textit{Elementary} bietet ein umfangreiches Paket an grafischen Elementen die
+genutzt und frei angeordnet werden können.
\begin{figure}[h]
\centering
@@ -138,8 +147,8 @@ Pakete \textit{Evil, Eina, Eet, Embryo, Evas, Ecore, Edje} und\textit{Elementary
\caption{Aufbau von \textit{Enlightenment}}
\end{figure}
-Bei \textit{Ecore} handelt es sich um eine Bibliothek, welche das serialisieren von mehreren Programmteilen ermöglicht und
-für den Betrieb auf mobilen Geräten optimiert wurde. \textit{Edje} ist eine komplexe grafische Design und Layout Bibliothek,
+Bei \textit{Ecore} handelt es sich um eine Bibliothek, welche das Serialisieren von mehreren Programmteilen ermöglicht und
+für den Betrieb auf mobilen Geräten optimiert wurde. \textit{Edje} ist eine grafische Design und Layout Bibliothek,
welche mit einer internen \textit{state machine} und einem Zustandsgraphen speichert was wo, in welcher Farbe und wie sichtbar
ist und gezeichnet werden soll. Die Bibliothek \textit{Evas} ist eine \textit{canvas}-Bibliothek, welche sich um Effekte wie
Alpha-Blending oder das skalieren von Bildern kümmert. \textit{Eina} stellt verschiedene, optimierte Datentypen und Tools
diff --git a/ausarbeitung/Tutorial.tex.backup b/ausarbeitung/Tutorial.tex.backup
index c4ee8cb..b838aa8 100644
--- a/ausarbeitung/Tutorial.tex.backup
+++ b/ausarbeitung/Tutorial.tex.backup
@@ -1,102 +1,92 @@
\section{Technische Grundlagen}
-Die Wahl der Plattform hängt von zwei verschiedenen Faktoren ab. Zum einen stellt sich die Frage, ob die Handymodelle die
+Die Wahl der Plattform hängt von zwei verschiedenen Faktoren ab. Zum Einen stellt sich die Frage, ob die Handymodelle die
benötigte Hardware, wie zum Beispiel \textit{GPS} oder eine Kamera besitzen, zum anderen ob Schnittstellen vorhanden sind um das
Programm für das System zu entwickeln. \newline
-
Die Problematik der Plattformwahl aufgrund von vorhandener oder nicht vorhandener Hardware ist nicht allzu groß. Die meisten
aktuellen Geräte haben mittlerweile eine ähnliche Ausstattung was Speicher und Prozessorleistung angeht.Auch erweiterte Features
wie \textit{GPS} oder Lagesensoren sind in den meisten, aktuellen Geräten vorhanden oder werden in der nächsten Generation, des
jeweiligen Herstellers, vorhanden sein.\newline
-
-Es gestalltet sich schon schwieriger eine Plattform aufgrund des Betriebssystemes zu wählen. Bei geeigneter Auswahl ist es
-möglich die Software auf mehrere Betriebssysteme für Smartphones zu portieren und somit eine mehrfache Implementation zu
-vermeiden. Es wäre somit auch möglich viele Nutzer zu erreichen und die Kommunikation zwischen einem Besitzer eines
-\textit{iPhones} sowie dem Besitzer eines \textit{Palm Pre's} sicherzustellen.\newline
-Des weiteren ist es auch von Interesse, ob andere Programme und Bibliotheken auf den jeweiligen Systemen ausführbar sind.
-Es wäre also ein \textit{Layer} von Interesse mit welchem immer die gleichen Programmbibliotheken genutzen werden können. Dabei
-sollte das zugrundeliegende System unabhängig von diesem \textit{Layer} sein. Es soll also damit vom zugrundeliegenden
+Da die gegebenen Hardwareunterschiede minimal sind, wird eine Plattform aufgrund des Betriebssystemes ausgewählt. Bei
+geeigneter Wahl ist es möglich die Software auf mehrere Betriebssysteme für Smartphones zu portieren und somit eine mehrfache
+Implementation zu vermeiden. Es wäre somit auch möglich viele Nutzer zu erreichen und die Kommunikation zwischen einem Besitzer
+eines \textit{iPhones} sowie dem Besitzer eines \textit{Palm Pre's} sicherzustellen.\newline
+Ein weiterer Punkt der zu einer Entscheidung beiträgt ist die Frage ob andere Programme und Bibliotheken auf den jeweiligen
+Systemen ausführbar sind. Es wird also ein \textit{Layer} benötigt, mit welchem immer die gleichen Programmbibliotheken
+genutzen werden können. Dabei sollte das zugrundeliegende System unabhängig von diesem \textit{Layer} sein. Es soll also damit vom
+zugrundeliegenden
Betriebssystem abstrahiert werden. Ein entsprechender \textit{Layer} stellt der \textit{Portable Operating System Interface for
-Unix Layer (POSIX Layer)} \citep{POSIX} dar. Mit diesem \textit{Layer} stehen eine große Menge an aktuellen
-Bibliotheken aus der \textit{Open-Source} Gemeinde zur Verfügung. Diese haben den Vorteil, dass sie aktiv
+Unix Layer (POSIX Layer)} \footnote{POSIX \url{http://standards.ieee.org/regauth/posix/}} dar. Mit diesem \textit{Layer} stehen
+eine große Menge an aktuellen Bibliotheken aus der \textit{Open-Source} Gemeinde zur Verfügung. Diese haben den Vorteil, dass sie
+aktiv
weiterentwickelt werden und auch ständig neue Bibliotheken hinzukommen. Anwendungen, die auf einem \textit{Linux}-System
entwickelt wurden können somit ohne weiteres auf ein anderes, \textit{POSIX} kompatibles System, portiert werden, ohne das
die genutzten Bibliotheken ausgetauscht werden müssen.\newline
-Auch die Frage der unterstützten Programmiersprachen stellt sich, da das Programm nicht ständig neu implementiert werden soll
-wenn es auf ein neues Gerät portiert wird.\newline
+Zusätzlich stellt sich auch die Frage der zu nutzenden Programmiersprache. Diese sollte von einer möglichst großen Mengen an
+Betriebsystemen unterstützt werden. Man müsste das, wenn man das Programm für ein neues Gerät portieren möchte, das Progamm somit
+nicht immer komplett neu implementieren.
\subsection{Betriebsysteme für mobile Geräte}
-Wie schon erwähnt ist die Wahl einer geeigneten Plattform von nicht unerheblicher Wichtigkeit, da hier schon indirekt eine
-Vorauswahl an Nutzbaren Bibliotheken und Programmiersprachen getroffen wird. Im Folgenden werden fünf Betriebssysteme für mobile
-Plattformen vorgestellt und auf deren Portierungsmöglichkeiten eingegangen.
+Durch die Wahl eines Betriebsystemes wird schon indirekt eine Vorauswahl an Nutzbaren Bibliotheken und Programmiersprachen
+getroffen wird. Im Folgenden werden fünf Betriebssysteme für mobile Plattformen vorgestellt und auf deren Portierungsmöglichkeiten
+eingegangen.
\subsubsection{Windows Mobile}
-Der wohl bekannteste Vertreter ist \textit{Windows Mobile}. Die aktuelle Version 6.5 wurde von Microsoft
-mit \textit{Windows Phone} betitelt. Das gesamte Betriebssystem basiert auf der \textit{Windows Win32 API} und lässt
-Ähnlichkeiten zu den Desktop-Varianten der Windows-Familie erkennen. \textit{Windows Phone} besitzt keinen
-\textit{POSIX Layer}, allerdings existiert ein \textit{Cross-Compiler} names \textit{CeGCC} \citep{CeGCC}, mit welchem
-Programme die in \textit{C}/\textit{C++} geschrieben wurden für diese Plattform kompiliert werden können.\newline
-
-%Will man für dieses Betriebssystem Anwendungen entwickeln so bietet Microsoft eine eigenes \textit{Software Development Kit
-%(SDK)}
-%an, welches auch jeder frei nutzen kann. Bei der Programmierung kann hierbei sowohl auf \textit{C}/\textit{C++},
-%sowie auch auf Java zurückgegriffen werden. Allerdings ist die \textit{Win32 API} nich kompatibel mit der Desktopversion, weshalb
-%Anwendungen getrennt entwickelt oder portiert werden müssen.\newline
-
-%Wie Im Kapitel Tutorial schon erwähnt, lässt sich mit Hilfe eines \textit{Cross-Compilers} das \textit{Enlightenment}-Paket für
-%dieses System, mit etwas Aufwand, portieren. Durch diese Tatsache und der Unterstützung von \textit{C}/\textit{C++}
-%eignet sich Windows Mobile sehr gut als Plattform für Anwendungen, welche nich unbedingt von vorne herein für diese entwickelt
-%wurden.
+Das von Microsoft entwickelte \textit{Windows Mobile}
+\footnote{Windows Mobile \url{http://www.microsoft.com/windowsmobile/de-de/default.mspx}} in der aktuellen Version 6.5 verfügbar.
+Das gesamte Betriebssystem basiert
+auf der \textit{Windows Win32 API} und lässt Ähnlichkeiten zu den Desktop-Varianten der Windows-Familie erkennen. Es existiert
+ein \textit{Cross-Compiler} names \textit{CeGCC} \footnote{CeGCC \url{http://cegcc.sourceforge.net/}},
+mit welchem Programme die in \textit{C}/\textit{C++} geschrieben wurden für diese Plattform kompiliert werden können.
\subsubsection{Android}
-Das von \textit{Google} entwickelte \textit{Android} \citep{Android} setzt auf einen Linux-Kernel der Version 2.6 auf. Dieser
-Kernel kümmert sich um die Prozess- und Speicherverwaltung, Kommunikation sowie um die Hardwareabstraktion. Auf diese Grundlage
-setzt eine virtuelle Java-Maschine auf, in welcher \textit{Android} läuft.\newline
-
+Das von \textit{Google} entwickelte \textit{Android} \footnote{Android \url{http://www.android.com/}} setzt auf einen
+\textit{Linux-Kernel} der Version 2.6 auf. Dieser \textit{Kernel} kümmert sich um die Prozess- und Speicherverwaltung,
+Kommunikation sowie um die Hardwareabstraktion. Auf diese Grundlage setzt eine virtuelle Java-Maschine auf, in welcher
+\textit{Android} läuft.\newline
Zum Implementieren von Anwendungen stellt \textit{Google} eigens ein \textit{SDK} bereit. Dieses greift allerdings nur auf
-\textit{Java}-Bibliotheken zurück, womit sich die nutzbaren Sprachen im Moment eben auf diese beschränken. Des weiteren bietet
-\textit{Google} mittlerweile ein \textit{NDK} an, mit desen Hilfe es auch möglich ist Programme in \textit{C} oder \textit{C++}
-zu schreiben. In diesem Paket werden auch eine Hand voll Bibliotheken mitgeliefert, welchen stabil laufen. \textit{Google} rät
-allerdings von der Nutzung anderer Bibliotheken ab, da nur die mit dem \textit{NDK} laut Hersteller stabil auf den Geräten laufen.
-Allerdings ergeben sich hier für die Zukunft, sobald mehr Bibliotheken unterstützt werden, sicher
-interessante Möglichkeiten für Anwendungsentwicklung und Portierung.\newline
+\textit{Java}-Bibliotheken zurück, womit sich die Anzahl der nutzbaren Sprachen im Moment eben auf diese eine beschränkt. Des
+weiteren bietet \textit{Google} ein \textit{NDK} an, mit desen Hilfe es auch möglich ist Programme in \textit{C} oder
+\textit{C++} zu schreiben.
\subsubsection{WebOS}
-\textit{WebOS} \citep{WebOS} wurde von \textit{Palm} als Nachfolger von \textit{PalmOS} entwickelt und ist momentan nur auf zwei
-Geräten zu finden: Auf dem \textit{Palm Pre} und dem \textit{Palm Pixi}.\newline
-Für dieses Betriebssystem existiert sowohl ein \textit{SDK} für \textit{HTML5}, \textit{CSS} und \textit{Java} sowie ein
-weiteres, welches im März 2010 veröffentlicht wird, für \textit{C} und \textit{C++}. Des weiteren beinhaltet \textit{WebOS} einen
-einen \textit{POSIX Layers}. Somit werden mehrere Programmiersprachen unterstützt und es besteht die Möglichkeit den \textit{POSIX
-Layer} zu nutzen.\newline
+\textit{WebOS} \footnote{WebOS \url{http://palmwebos.org/}} wurde von \textit{Palm} als Nachfolger von \textit{PalmOS}
+\footnote{PalmOS \url{http://www.palm.com/}} entwickelt und ist momentan nur auf zwei Geräten zu finden: Auf dem \textit{Palm Pre}
+und dem \textit{Palm Pixi}.\newline
+Unter der Benutzeroberfläche von \textit{WebOS} arbeitet ein \textit{Linux-Kernel} in der Version 2.6. Somit ist es möglich, wenn
+man Zugriff auf diesen Kernel hat, \textit{POSIX}-kompatible Software unter \textit{WebOS} zu betreiben.
+Für dieses Betriebssystem existiert ein \textit{SDK} für \textit{HTML5}, \textit{CSS} und \textit{Java}. Ein weiteres, welches im
+März 2010 veröffentlicht wird, soll die \textit{C} und \textit{C++} Entwicklung ermöglichen.
\subsubsection{iPhone OS}
-Bei \textit{iPhoneOS} \citep{iPhoneOS} handelt es sich um eine abgeänderte und angepasste Version von MacOS. Es wurde eigens für
+Bei \textit{iPhoneOS} \footnote{iPhoneOS \url{http://www.apple.com/de/iphone/}} handelt es sich um eine abgeänderte und angepasste
+Version von MacOS. Es wurde eigens für
das iPhone entwickelt. Auch für dieses System existiert ein \textit{SDK}, welches allerdings nur die Sprache \textit{Objective-C}
-unterstützt. Des weiteren fehlt auch eine Unterstützung des \textit{POSIX Layers} oder einer anderen Abstraktion dieser Art. Der
-größte Kritikpunkt an diesem System dürfte allerdings das fehlen von \textit{Multitasking}-Unterstützung sein. Somit ist es nicht
+unterstützt. . Der
+größte Kritikpunkt an diesem System ist das Fehlen von \textit{Multitasking}-Unterstützung. Somit ist es nicht
möglich zwei Anwendungen parallel auszuführen, was gerade \textit{location awareness} Anwendungen stark einschränkt, da hier
-häufig weitere Dienste im Hintergrund aktiv sein sollten.\newline
+häufig weitere Dienste im Hintergrund aktiv sein sollten.
\subsubsection{Symbian OS}
-\textit{SymbianOS} \citep{SymbianOS} ist eine Betriebssystem welches vorzugsweise auf Geräten der Firma \textit{Nokia} zum
+\textit{SymbianOS} \footnote{SymbianOS \url{http://www.symbian.org/}} ist eine Betriebssystem welches vorzugsweise auf Geräten der
+Firma \textit{Nokia} zum
Einsatz kommt. Es existiert ein \textit{SDK}, was neben \textit{C}/\textit{C++} auch noch weitere Sprachen wie zum Beispiel
\textit{Python} oder \textit{Java} unterstützt. Mit dem \textit{SDK} wird auch ein \textit{Cross-Compiler} angeboten, welcher es
-ermöglicht Programme direkt zu portieren. Des weitern besitzt \textit{Symian OS} auch einen \textit{POSIX Layer}.
+ermöglicht Programme direkt zu portieren. Des weitern besitzt \textit{Symian OS} einen \textit{POSIX Layer}.
\subsubsection{Zielplattform}
-Die Wahl der Zielplattform ist auf \textit{Windows Mobile} gefallen, da es hier möglich ist das Programm in \textit{C} zu
-schreiben und dann im Anschluss zu portieren. \newline
\textit{iPhoneOS} wurde aufgrund seiner mangelnden \textit{Multitasking}-Unterstützung ausgeschlossen. Diese ist für den
-geplanten Dienst wichtig, da hier Prozesse im Hintergund stattfinden werden und dies auf einem solchen System nicht realisierbar
-wäre. \textit{Android} hat zwar eine \textit{C} Unterstützung, allerdings gibt der Hersteller an das nicht alle Bibliotheken
-stabil sind.\newline
+geplanten Dienst wichtig, da bei diesem Prozesse im Hintergund notwendig sind und dies auf einem solchen System nicht
+realisierbar wäre. \textit{Android} hat zwar eine \textit{C} Unterstützung, allerdings gibt der Hersteller an das nur die
+mit dem \textit{NDK} verfügbaren Bibliotheken zum momentanen Zeitpunkt stabil verfügbar sind. Dies schränkt die
+Entwicklung stark ein und ist für das zu entwickelnde Programm nicht geeignet.\newline
Aufgrund der Implementierung in \textit{C} ist es auch möglich das Programm für \textit{WebOS} und \textit{SymbianOS} zu
kompilieren.
@@ -107,29 +97,38 @@ jeweiligen Plattformen zu kompilieren, sowie die graphischen Elemente auf den Pl
\subsubsection{CeGCC}
-Da \textit{Windows Mobile} und die Programmiersprache \textit{C} genutzt wird, wird der \textit{CeGCC} als
-\textit{Cross-Compiler} verwendet. Mit ihm ist es möglich \textit{C} Programmcode, der unter \textit{Linux} entwickelt wurde, nach
+Mit dem \textit{CeGCC} ist es möglich \textit{C} Programmcode, der unter \textit{Linux} entwickelt wurde, nach
\textit{Windows Mobile} zu portieren. Bei \textit{CeGCC} handelt es sich um ein \textit{Open-Source} Projekt, bassierend auf dem
\textit{GCC}. Mit diesem Tool können in einer \textit{Linux} Umgebung die für \textit{Windows Mobile} benötigten Bibliotheken und
ausführbaren Dateien erstellt werden.\newline
+Der \textit{CeGCC} kann in zwei unterschiedlichen Versionen genutzt werden. Zum einen bietet der \textit{wince-mingw32ce} eine
+Menge an Tools mit welchen man native \textit{Windows Mobile} Applikationen erstellen kann. Hierzu wird eine
+Portierung der \textit{GNU} \footnote{GNU \url{http://www.gnu.org/}} Enwicklungswergzeuge aus dem \textit{MinGW} \footnote{MinGW
+http://mingw.org/} Projekt genutzt. Diese kompilieren und linken Code, um diesen unter \textit{Windows Mobile} ausführbar zu
+machen. Die andere Möglichkeit stellt die Nutzung des \textit{arm-cegcc} dar. Mit diesem kann \textit{POSIX}
+kompatibler Programmcoder nach \textit{Windows Mobile} portiert werden. %verfeinern
+
+# arm-mingw32ce : toolset to build native Windows CE applications
+# arm-cegcc : toolset to port unix source to Windows CE
-Es wird zwischen zwei verschiedenen Arten des \textit{CeGCC's} unterschieden. Zum Einen \textit{CeGCC}, zum Anderen
-\textit{mingw32ce}.
-Der Unterschied zwischen diesen beiden Kompilern besteht darin, dass ersterer nur dann benutzt wird, wenn man nur Linux
-Bibliotheken einbinden möchte. Der \textit{mingw32ce}-Kompiler wird dann gebraucht, wenn auch \textit{Windows Mobile}
-Bibliotheken zum Einstatz kommen.\newline
+ Remember that arm-wince-cegcc implements a unix-like layer on top of Windows CE, and that arm-wince-mingw32ce implements the
+native CE API.
-Soll das Programm nun für \textit{WebOS} oder \textit{SymbianOS} portiert werden, kann dies auf unter \textit{Linux} normal
-kompiliert werden.
+The unix-like layer is only provided in the arm-wince-cegcc tools, the arm-wince-mingw32ce deliberately lack this as they attempt
+to provide a development environment that is as close to Windows CE as possible.
+Part of the code in this directory is required to be able to create executables that start a program in a consistent way (e.g.
+crt0.o, the startup code in an executable), but another part of this code provides a unix like layer with functionalities absent
+in Windows CE.
\subsubsection{Enlightenment}
Neben einem \textit{Cross-Compiler} wird noch ein geeignetes Frontend benötigt, um das Programm auch für den Benutzer
-ansprechend darzustellen sowie eine einfache Bedienbarkeit zu garantieren. Dieses Frontend sollte auch in \textit{C} oder
-\textit{C++} geschrieben sein, um auch hier die Portierbarkeit für die gewünschten Plattformen zu garantieren. Hier fiel die Wahl
-auf das freie, seit 1997 existierende, \textit{Enlightenment} \citep{efl} Projekt. Dieses Softwarepaket unterstützt alle gängigen
-Plattformen wie Windows, Linux, BSD und MacOS. Es beinhaltet einen eigenen \textit{Window-Manager} names \textit{Elementary}.
-\textit{Elementary} bietet ein umfangreiches Paket an grafischen Elementen die genutzt und frei angeordnet werden können.
+ansprechend darzustellen und eine einfache Bedienbarkeit zu garantieren. Dieses Frontend sollte auch in \textit{C} oder
+\textit{C++} geschrieben sein, um auch hier die Portierbarkeit für die gewünschten Plattformen zu erhalten. Genutzt wird das
+freie, seit 1997 existierende, \textit{Enlightenment} \footnote{Elementray \url{http://www.enlightenment.org/}} Projekt. Dieses
+Softwarepaket unterstützt alle gängigen Plattformen wie Windows, Linux, BSD und MacOS. Es beinhaltet einen eigenen
+\textit{Window-Manager} names \textit{Elementary}. \textit{Elementary} bietet ein umfangreiches Paket an grafischen Elementen die
+genutzt und frei angeordnet werden können.
\begin{figure}[h]
\centering
@@ -147,11 +146,12 @@ Pakete \textit{Evil, Eina, Eet, Embryo, Evas, Ecore, Edje} und\textit{Elementary
\caption{Aufbau von \textit{Enlightenment}}
\end{figure}
-Bei \textit{Ecore} handelt es sich um eine Bibliothek, welche das serialisieren von mehreren Programmteilen ermöglicht und
-für den Betrieb auf mobilen Geräten optimiert wurde. \textit{Edje} ist eine komplexe grafische Design und Layout Bibliothek,
+Bei \textit{Ecore} handelt es sich um eine Bibliothek, welche das Serialisieren von mehreren Programmteilen ermöglicht und
+für den Betrieb auf mobilen Geräten optimiert wurde. \textit{Edje} ist eine grafische Design und Layout Bibliothek,
welche mit einer internen \textit{state machine} und einem Zustandsgraphen speichert was wo, in welcher Farbe und wie sichtbar
ist und gezeichnet werden soll. Die Bibliothek \textit{Evas} ist eine \textit{canvas}-Bibliothek, welche sich um Effekte wie
Alpha-Blending oder das skalieren von Bildern kümmert. \textit{Eina} stellt verschiedene, optimierte Datentypen und Tools
bereit.\newline
-Im Anhang 1 sind genaue Anweisungen zu finden, um \textit{Enlightenment} für \textit{Windows Mobile} zu portieren. \ No newline at end of file
+Im Anhang 1 sind genaue Anweisungen zu finden mit deren Hilfe es möglich ist \textit{Elementary} nach \textit{Windows Mobile} zu
+portieren. \ No newline at end of file
diff --git a/ausarbeitung/Tutorial.tex~ b/ausarbeitung/Tutorial.tex~
index 5560397..febf0dc 100644
--- a/ausarbeitung/Tutorial.tex~
+++ b/ausarbeitung/Tutorial.tex~
@@ -1,24 +1,24 @@
\section{Technische Grundlagen}
-Die Wahl der Plattform hängt von zwei verschiedenen Faktoren ab. Zum einen stellt sich die Frage, ob die Handymodelle die
+Die Wahl der Plattform hängt von zwei verschiedenen Faktoren ab. Zum Einen stellt sich die Frage, ob die Handymodelle die
benötigte Hardware, wie zum Beispiel \textit{GPS} oder eine Kamera besitzen, zum anderen ob Schnittstellen vorhanden sind um das
Programm für das System zu entwickeln. \newline
-
Die Problematik der Plattformwahl aufgrund von vorhandener oder nicht vorhandener Hardware ist nicht allzu groß. Die meisten
aktuellen Geräte haben mittlerweile eine ähnliche Ausstattung was Speicher und Prozessorleistung angeht.Auch erweiterte Features
wie \textit{GPS} oder Lagesensoren sind in den meisten, aktuellen Geräten vorhanden oder werden in der nächsten Generation, des
jeweiligen Herstellers, vorhanden sein.\newline
-
-Es gestalltet sich schon schwieriger eine Plattform aufgrund des Betriebssystemes zu wählen. Bei geeigneter Auswahl ist es
-möglich die Software auf mehrere Betriebssysteme für Smartphones zu portieren und somit eine mehrfache Implementation zu
-vermeiden. Es wäre somit auch möglich viele Nutzer zu erreichen und die Kommunikation zwischen einem Besitzer eines
-\textit{iPhones} sowie dem Besitzer eines \textit{Palm Pre's} sicherzustellen.\newline
-Des weiteren ist es auch von Interesse, ob andere Programme und Bibliotheken auf den jeweiligen Systemen ausführbar sind.
-Es wäre also ein \textit{Layer} von Interesse mit welchem immer die gleichen Programmbibliotheken genutzen werden können. Dabei
-sollte das zugrundeliegende System unabhängig von diesem \textit{Layer} sein. Es soll also damit vom zugrundeliegenden
+Da die gegebenen Hardwareunterschiede minimal sind, wird eine Plattform aufgrund des Betriebssystemes ausgewählt. Bei
+geeigneter Wahl ist es möglich die Software auf mehrere Betriebssysteme für Smartphones zu portieren und somit eine mehrfache
+Implementation zu vermeiden. Es wäre somit auch möglich viele Nutzer zu erreichen und die Kommunikation zwischen einem Besitzer
+eines \textit{iPhones} sowie dem Besitzer eines \textit{Palm Pre's} sicherzustellen.\newline
+Ein weiterer Punkt der zu einer Entscheidung beiträgt ist die Frage ob andere Programme und Bibliotheken auf den jeweiligen
+Systemen ausführbar sind. Es wird also ein \textit{Layer} benötigt, mit welchem immer die gleichen Programmbibliotheken
+genutzen werden können. Dabei sollte das zugrundeliegende System unabhängig von diesem \textit{Layer} sein. Es soll also damit vom
+zugrundeliegenden
Betriebssystem abstrahiert werden. Ein entsprechender \textit{Layer} stellt der \textit{Portable Operating System Interface for
-Unix Layer (POSIX Layer)} \citep{POSIX} dar. Mit diesem \textit{Layer} stehen eine große Menge an aktuellen
-Bibliotheken aus der \textit{Open-Source} Gemeinde zur Verfügung. Diese haben den Vorteil, dass sie aktiv
+Unix Layer (POSIX Layer)} \footnote{POSIX \url{http://standards.ieee.org/regauth/posix/}} dar. Mit diesem \textit{Layer} stehen
+eine große Menge an aktuellen Bibliotheken aus der \textit{Open-Source} Gemeinde zur Verfügung. Diese haben den Vorteil, dass sie
+aktiv
weiterentwickelt werden und auch ständig neue Bibliotheken hinzukommen. Anwendungen, die auf einem \textit{Linux}-System
entwickelt wurden können somit ohne weiteres auf ein anderes, \textit{POSIX} kompatibles System, portiert werden, ohne das
die genutzten Bibliotheken ausgetauscht werden müssen.\newline
@@ -34,55 +34,55 @@ eingegangen.
\subsubsection{Windows Mobile}
-Das von Microsoft entwickelte \textit{Windows Mobile} in der aktuellen Version 6.5 verfügbar. Das gesamte Betriebssystem basiert
-auf der \textit{Windows Win32 API} und lässt Ähnlichkeiten zu den Desktop-Varianten der Windows-Familie erkennen. \textit{Windows
-Phone} besitzt keinen \textit{POSIX Layer}, allerdings existiert ein \textit{Cross-Compiler} names \textit{CeGCC} \citep{CeGCC},
-mit welchem Programme die in \textit{C}/\textit{C++} geschrieben wurden für diese Plattform kompiliert werden können.\newline
+Das von Microsoft entwickelte \textit{Windows Mobile}
+\footnote{Windows Mobile \url{http://www.microsoft.com/windowsmobile/de-de/default.mspx}} in der aktuellen Version 6.5 verfügbar.
+Das gesamte Betriebssystem basiert
+auf der \textit{Windows Win32 API} und lässt Ähnlichkeiten zu den Desktop-Varianten der Windows-Familie erkennen. Es existiert
+ein \textit{Cross-Compiler} names \textit{CeGCC} \footnote{CeGCC \url{http://cegcc.sourceforge.net/}},
+mit welchem Programme die in \textit{C}/\textit{C++} geschrieben wurden für diese Plattform kompiliert werden können.
\subsubsection{Android}
-Das von \textit{Google} entwickelte \textit{Android} \citep{Android} setzt auf einen Linux-Kernel der Version 2.6 auf. Dieser
-Kernel kümmert sich um die Prozess- und Speicherverwaltung, Kommunikation sowie um die Hardwareabstraktion. Auf diese Grundlage
-setzt eine virtuelle Java-Maschine auf, in welcher \textit{Android} läuft.\newline
-
+Das von \textit{Google} entwickelte \textit{Android} \footnote{Android \url{http://www.android.com/}} setzt auf einen
+\textit{Linux-Kernel} der Version 2.6 auf. Dieser \textit{Kernel} kümmert sich um die Prozess- und Speicherverwaltung,
+Kommunikation sowie um die Hardwareabstraktion. Auf diese Grundlage setzt eine virtuelle Java-Maschine auf, in welcher
+\textit{Android} läuft.\newline
Zum Implementieren von Anwendungen stellt \textit{Google} eigens ein \textit{SDK} bereit. Dieses greift allerdings nur auf
\textit{Java}-Bibliotheken zurück, womit sich die Anzahl der nutzbaren Sprachen im Moment eben auf diese eine beschränkt. Des
-weiteren bietet \textit{Google} mittlerweile ein \textit{NDK} an, mit desen Hilfe es auch möglich ist Programme in \textit{C} oder
-\textit{C++} zu schreiben. \textit{Google} rät allerdings von der Nutzung anderer Bibliotheken ab, da nur im \textit{NDK}
-enthaltenen, laut Hersteller, stabil auf den Geräten laufen.
-Allerdings ergeben sich hier für die Zukunft, sobald mehr Bibliotheken unterstützt werden, sicher interessante Möglichkeiten für
-Entwicklung und Portierung von Anwendungen.\newline
+weiteren bietet \textit{Google} ein \textit{NDK} an, mit desen Hilfe es auch möglich ist Programme in \textit{C} oder
+\textit{C++} zu schreiben.
\subsubsection{WebOS}
-\textit{WebOS} \citep{WebOS} wurde von \textit{Palm} als Nachfolger von \textit{PalmOS} entwickelt und ist momentan nur auf zwei
-Geräten zu finden: Auf dem \textit{Palm Pre} und dem \textit{Palm Pixi}.\newline
+\textit{WebOS} \footnote{WebOS \url{http://palmwebos.org/}} wurde von \textit{Palm} als Nachfolger von \textit{PalmOS}
+\footnote{PalmOS \url{http://www.palm.com/}} entwickelt und ist momentan nur auf zwei Geräten zu finden: Auf dem \textit{Palm Pre}
+und dem \textit{Palm Pixi}.\newline
+Unter der Benutzeroberfläche von \textit{WebOS} arbeitet ein \textit{Linux-Kernel} in der Version 2.6. Somit ist es möglich, wenn
+man Zugriff auf diesen Kernel hat, \textit{POSIX}-kompatible Software unter \textit{WebOS} zu betreiben.
Für dieses Betriebssystem existiert ein \textit{SDK} für \textit{HTML5}, \textit{CSS} und \textit{Java}. Ein weiteres, welches im
-März 2010 veröffentlicht wird, soll die \textit{C} und \textit{C++} Entwicklung ermöglichen. Des weiteren beinhaltet
-\textit{WebOS} einen \textit{POSIX Layers}. Somit werden mehrere Programmiersprachen unterstützt und es besteht die
-Möglichkeit den \textit{POSIX Layer} zu nutzen.\newline
+März 2010 veröffentlicht wird, soll die \textit{C} und \textit{C++} Entwicklung ermöglichen.
\subsubsection{iPhone OS}
-Bei \textit{iPhoneOS} \citep{iPhoneOS} handelt es sich um eine abgeänderte und angepasste Version von MacOS. Es wurde eigens für
-das iPhone entwickelt. Auch für dieses System existiert ein \textit{SDK}, welches allerdings nur die Sprache \textit{Objective-C}
-unterstützt. Des weiteren fehlt auch eine Unterstützung des \textit{POSIX Layers} oder einer anderen Abstraktion dieser Art. Der
-größte Kritikpunkt an diesem System dürfte allerdings das fehlen von \textit{Multitasking}-Unterstützung sein. Somit ist es nicht
+Bei \textit{iPhoneOS} \footnote{iPhoneOS \url{http://www.apple.com/de/iphone/}} handelt es sich um eine abgeänderte und angepasste
+Version von MacOS. Somit bassiert auch der Kernel von \textit{iPhoneOS} sowohl auf teilen eines \textit{BSD}- \footnote{BSD
+\url{https://www.bsdwiki.de/}} sowie \textit{Mach}-Kernels
+\footnote{Mach \url{http://www.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html}}. Dieses Betriebssystem wurde eigens für das
+iPhone entwickelt. Auch für dieses System existiert ein \textit{SDK}, welches allerdings nur die Sprache \textit{Objective-C}
+unterstützt. Der größte Kritikpunkt an diesem System ist das Fehlen von \textit{Multitasking}-Unterstützung. Somit ist es nicht
möglich zwei Anwendungen parallel auszuführen, was gerade \textit{location awareness} Anwendungen stark einschränkt, da hier
-häufig weitere Dienste im Hintergrund aktiv sein sollten.\newline
+häufig weitere Dienste im Hintergrund aktiv sein sollten.
\subsubsection{Symbian OS}
-\textit{SymbianOS} \citep{SymbianOS} ist eine Betriebssystem welches vorzugsweise auf Geräten der Firma \textit{Nokia} zum
+\textit{SymbianOS} \footnote{SymbianOS \url{http://www.symbian.org/}} ist eine Betriebssystem welches vorzugsweise auf Geräten der
+Firma \textit{Nokia} zum
Einsatz kommt. Es existiert ein \textit{SDK}, was neben \textit{C}/\textit{C++} auch noch weitere Sprachen wie zum Beispiel
\textit{Python} oder \textit{Java} unterstützt. Mit dem \textit{SDK} wird auch ein \textit{Cross-Compiler} angeboten, welcher es
-ermöglicht Programme direkt zu portieren. Des weitern besitzt \textit{Symian OS} auch einen \textit{POSIX Layer}.
+ermöglicht Programme direkt zu portieren. Des weitern besitzt \textit{Symian OS} einen \textit{POSIX Layer}.
\subsubsection{Zielplattform}
-Die Wahl der Zielplattform ist auf \textit{Windows Mobile} gefallen, da es hier möglich ist die Anwendung in \textit{C} zu
-implementieren. Da mit Hilfe des \textit{CeGCC} die Anwendung portiert werden kann, kann diese auch in einer
-\textit{Linux}-Umgebung entwickelt werden.\newline
\textit{iPhoneOS} wurde aufgrund seiner mangelnden \textit{Multitasking}-Unterstützung ausgeschlossen. Diese ist für den
geplanten Dienst wichtig, da bei diesem Prozesse im Hintergund notwendig sind und dies auf einem solchen System nicht
realisierbar wäre. \textit{Android} hat zwar eine \textit{C} Unterstützung, allerdings gibt der Hersteller an das nur die
@@ -98,29 +98,38 @@ jeweiligen Plattformen zu kompilieren, sowie die graphischen Elemente auf den Pl
\subsubsection{CeGCC}
-Da \textit{Windows Mobile} und die Programmiersprache \textit{C} genutzt wird, wird der \textit{CeGCC} als
-\textit{Cross-Compiler} verwendet. Mit ihm ist es möglich \textit{C} Programmcode, der unter \textit{Linux} entwickelt wurde, nach
+Mit dem \textit{CeGCC} ist es möglich \textit{C} Programmcode, der unter \textit{Linux} entwickelt wurde, nach
\textit{Windows Mobile} zu portieren. Bei \textit{CeGCC} handelt es sich um ein \textit{Open-Source} Projekt, bassierend auf dem
\textit{GCC}. Mit diesem Tool können in einer \textit{Linux} Umgebung die für \textit{Windows Mobile} benötigten Bibliotheken und
ausführbaren Dateien erstellt werden.\newline
+Der \textit{CeGCC} kann in zwei unterschiedlichen Versionen genutzt werden. Zum einen bietet der \textit{wince-mingw32ce} eine
+Menge an Tools mit welchen man native \textit{Windows Mobile} Applikationen erstellen kann. Hierzu wird eine
+Portierung der \textit{GNU} \footnote{GNU \url{http://www.gnu.org/}} Enwicklungswergzeuge aus dem \textit{MinGW} \footnote{MinGW
+http://mingw.org/} Projekt genutzt. Diese kompilieren und linken Code, um diesen unter \textit{Windows Mobile} ausführbar zu
+machen. Die andere Möglichkeit stellt die Nutzung des \textit{arm-cegcc} dar. Mit diesem kann \textit{POSIX}
+kompatibler Programmcoder nach \textit{Windows Mobile} portiert werden. %verfeinern
+
+%# arm-mingw32ce : toolset to build native Windows CE applications
+%# arm-cegcc : toolset to port unix source to Windows CE
-Es wird zwischen zwei verschiedenen Arten des \textit{CeGCC's} unterschieden. Zum Einen \textit{CeGCC} und zum Anderen
-\textit{mingw32ce}.
-Der Unterschied zwischen diesen beiden Kompilern besteht darin, dass ersterer nur dann benutzt wird, wenn man nur Linux
-Bibliotheken einbinden möchte. Der \textit{mingw32ce}-Kompiler wird dann gebraucht, wenn auch \textit{Windows Mobile}
-Bibliotheken zum Einstatz kommen.\newline
+% Remember that arm-wince-cegcc implements a unix-like layer on top of Windows CE, and that arm-wince-mingw32ce implements the
+%native CE API.
-Soll das Programm nun für \textit{WebOS} oder \textit{SymbianOS} portiert werden, kann dies auf unter \textit{Linux} normal
-kompiliert werden.
+%The unix-like layer is only provided in the arm-wince-cegcc tools, the arm-wince-mingw32ce deliberately lack this as they attempt
+%to provide a development environment that is as close to Windows CE as possible.
+% Part of the code in this directory is required to be able to create executables that start a program in a consistent way (e.g.
+% crt0.o, the startup code in an executable), but another part of this code provides a unix like layer with functionalities absent
+% in Windows CE.
\subsubsection{Enlightenment}
Neben einem \textit{Cross-Compiler} wird noch ein geeignetes Frontend benötigt, um das Programm auch für den Benutzer
ansprechend darzustellen und eine einfache Bedienbarkeit zu garantieren. Dieses Frontend sollte auch in \textit{C} oder
-\textit{C++} geschrieben sein, um auch hier die Portierbarkeit für die gewünschten Plattformen zu erhalten. Hier fiel die Wahl
-auf das freie, seit 1997 existierende, \textit{Enlightenment} \citep{efl} Projekt. Dieses Softwarepaket unterstützt alle gängigen
-Plattformen wie Windows, Linux, BSD und MacOS. Es beinhaltet einen eigenen \textit{Window-Manager} names \textit{Elementary}.
-\textit{Elementary} bietet ein umfangreiches Paket an grafischen Elementen die genutzt und frei angeordnet werden können.
+\textit{C++} geschrieben sein, um auch hier die Portierbarkeit für die gewünschten Plattformen zu erhalten. Genutzt wird das
+freie, seit 1997 existierende, \textit{Enlightenment} \footnote{Elementray \url{http://www.enlightenment.org/}} Projekt. Dieses
+Softwarepaket unterstützt alle gängigen Plattformen wie Windows, Linux, BSD und MacOS. Es beinhaltet einen eigenen
+\textit{Window-Manager} names \textit{Elementary}. \textit{Elementary} bietet ein umfangreiches Paket an grafischen Elementen die
+genutzt und frei angeordnet werden können.
\begin{figure}[h]
\centering
@@ -138,11 +147,12 @@ Pakete \textit{Evil, Eina, Eet, Embryo, Evas, Ecore, Edje} und\textit{Elementary
\caption{Aufbau von \textit{Enlightenment}}
\end{figure}
-Bei \textit{Ecore} handelt es sich um eine Bibliothek, welche das serialisieren von mehreren Programmteilen ermöglicht und
-für den Betrieb auf mobilen Geräten optimiert wurde. \textit{Edje} ist eine komplexe grafische Design und Layout Bibliothek,
+Bei \textit{Ecore} handelt es sich um eine Bibliothek, welche das Serialisieren von mehreren Programmteilen ermöglicht und
+für den Betrieb auf mobilen Geräten optimiert wurde. \textit{Edje} ist eine grafische Design und Layout Bibliothek,
welche mit einer internen \textit{state machine} und einem Zustandsgraphen speichert was wo, in welcher Farbe und wie sichtbar
ist und gezeichnet werden soll. Die Bibliothek \textit{Evas} ist eine \textit{canvas}-Bibliothek, welche sich um Effekte wie
Alpha-Blending oder das skalieren von Bildern kümmert. \textit{Eina} stellt verschiedene, optimierte Datentypen und Tools
bereit.\newline
-Im Anhang 1 sind genaue Anweisungen zu finden, um \textit{Enlightenment} für \textit{Windows Mobile} zu portieren. \ No newline at end of file
+Im Anhang 1 sind genaue Anweisungen zu finden mit deren Hilfe es möglich ist \textit{Elementary} nach \textit{Windows Mobile} zu
+portieren. \ No newline at end of file
diff --git a/ausarbeitung/literature.bib b/ausarbeitung/literature.bib
index d92eff0..ee9fcd4 100644
--- a/ausarbeitung/literature.bib
+++ b/ausarbeitung/literature.bib
@@ -1,124 +1,7 @@
-@misc{efl,
-Title = {Enlightenment},
-url = {http://www.enlightenment.org/},
-Note = {[Online; letzter Aufruf 20.11.2009]},
-}
-
-@misc{CeGCC,
-Title = {CeGCC},
-url = {http://cegcc.sourceforge.net/},
-Note = {[Online; letzter Aufruf 20.11.2009]},
-}
-
-@misc{libircclient,
-Title = {libircclient},
-url = {http://libircclient.sourceforge.net/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{OpenSSL,
-Title = {libCrypto},
-url = {http://www.openssl.org/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{Wireshark,
-Title = {Wireshark},
-url = {http://www.wireshark.org/},
-Note = {[Online; letzter Aufruf 27.01.2010]},
-}
-
@misc{IRC,
-Title = {IRC-Protokoll},
-url = {http://www.irc.org/},
-Note = {[Online; letzter Aufruf 27.01.2010]},
-}
-
-@misc{Windows,
-Title = {Windows Mobile},
-url = {http://www.microsoft.com/windowsmobile/de-de/default.mspx},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{Android,
-Title = {Android},
-url = {http://www.android.com/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{WebOS,
-Title = {WebOS},
-url = {http://palmwebos.org/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{PalmOS,
-Title = {PalmOS},
-url = {http://www.palm.com/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{FriendSensing,
-title = {FriendSensing: Recommending Friends Using Mobile Phones},
-author = {Daniele Quercia and Licia Capra},
-year = {2009},
-organization = {MIT SENSEable City Laboratory, Cambridge, USA und Dept.of Computer Sience, University College London, UK},
-url = {web.mit.edu/quercia/www/publications/friendSensing_short.pdf},
-note = {[Online; letzter Aufruf 27.01.2010]},
-}
-
-@misc{Latitude,
-title = {Google Latitude},
-url = {http://www.google.com/intl/en_us/latitude/intro.html},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{POSIX,
-title = {Portable Operating System Interface for Unix Layer},
-url = {http://standards.ieee.org/regauth/posix/},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{qrencode,
-title = {libqrencode},
-url = {http://megaui.net/fukuchi/works/qrencode/index.en.html},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{qrcode,
-title = {QR Code},
-url = {http://www.denso-wave.com/qrcode/qrstandard-e.html},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{PNG,
-title = {libpng},
-url = {http://www.libpng.org/},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{IRCD,
-title = {IRCD-Hybrid},
-url = {http://www.ircd-hybrid.org/},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{XChat,
-title = {X-Chat},
-url = {http://xchat.org/},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{iPhoneOS,
-Title = {iPhone OS},
-url = {http://www.apple.com/de/iphone/},
-Note = {[Online; letzter Aufruf 03.02.2010]},
-}
-
-@misc{SymbianOS,
-Title = {Symbian OS},
-OPTurl = {http://www.symbian.org/},
-Note = {[Online; letzter Aufruf 03.02.2010]},
+title = {RFC 1459 Internet Relay Chat},
+author = {J. Oikarinen and D. Reed},
+year = {2003},
}
@misc{SPALS,
@@ -136,12 +19,6 @@ year = {2006},
pages = {34-51},
}
-@misc{OSM,
-Title = {OpenStreetMap},
-url = {http://www.openstreetmap.de/},
-Note = {[Online; letzter Aufruf 13.02.2010]},
-}
-
@article{bluetooth,
title = {Cracking the Bluetooth PIN},
author = {Yaniv Shaked and Avishai Wool},
@@ -151,16 +28,6 @@ year = {2005},
pages = {39-50},
}
-@article{location,
-title = {User needs for location-aware mobile services},
-author = {Eija Kaasinen},
-year = {2003},
-journal = {Personal and Ubiquitous Computing},
-pages = {70-79},
-volume = {Volume 7},
-number = {1},
-}
-
@article{blowfish,
title = {Description of a New Variable-Length Key, 64-Bit Block Cipher (Blowfish)},
author = {Bruce Schneier},
@@ -211,12 +78,7 @@ volume = {Volume 46},
number = {2},
}
-@misc{base64,
-titel = {RFC 4648},
-year = {2006},
-}
-
-@misc{symm,
+@article{symm,
author = {Günter Müller},
howpublished = {Vorlesung IT-Sicherheit},
year = {2009},
diff --git a/ausarbeitung/literature.bib.backup b/ausarbeitung/literature.bib.backup
index 0e2b720..13969e0 100644
--- a/ausarbeitung/literature.bib.backup
+++ b/ausarbeitung/literature.bib.backup
@@ -1,126 +1,9 @@
-@misc{efl,
-Title = {Enlightenment},
-url = {http://www.enlightenment.org/},
-Note = {[Online; letzter Aufruf 20.11.2009]},
-}
-
-@misc{CeGCC,
-Title = {CeGCC},
-url = {http://cegcc.sourceforge.net/},
-Note = {[Online; letzter Aufruf 20.11.2009]},
-}
-
-@misc{libircclient,
-Title = {libircclient},
-url = {http://libircclient.sourceforge.net/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{OpenSSL,
-Title = {libCrypto},
-url = {http://www.openssl.org/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{Wireshark,
-Title = {Wireshark},
-url = {http://www.wireshark.org/},
-Note = {[Online; letzter Aufruf 27.01.2010]},
-}
-
-@misc{IRC,
-Title = {IRC-Protokoll},
-url = {http://www.irc.org/},
-Note = {[Online; letzter Aufruf 27.01.2010]},
-}
-
-@misc{Windows,
-Title = {Windows Mobile},
-url = {http://www.microsoft.com/windowsmobile/de-de/default.mspx},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{Android,
-Title = {Android},
-url = {http://www.android.com/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{WebOS,
-Title = {WebOS},
-url = {http://palmwebos.org/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{PalmOS,
-Title = {PalmOS},
-url = {http://www.palm.com/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{FriendSensing,
-title = {FriendSensing: Recommending Friends Using Mobile Phones},
-author = {Daniele Quercia and Licia Capra},
-year = {2009},
-organization = {MIT SENSEable City Laboratory, Cambridge, USA und Dept.of Computer Sience, University College London, UK},
-url = {web.mit.edu/quercia/www/publications/friendSensing_short.pdf},
-note = {[Online; letzter Aufruf 27.01.2010]},
-}
-
-@misc{Latitude,
-title = {Google Latitude},
-url = {http://www.google.com/intl/en_us/latitude/intro.html},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{POSIX,
-title = {Portable Operating System Interface for Unix Layer},
-url = {http://standards.ieee.org/regauth/posix/},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{qrencode,
-title = {libqrencode},
-url = {http://megaui.net/fukuchi/works/qrencode/index.en.html},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
@misc{qrcode,
title = {QR Code},
url = {http://www.denso-wave.com/qrcode/qrstandard-e.html},
Note = {[Online; letzter Aufruf 11.02.2010]},
}
-@misc{PNG,
-title = {libpng},
-url = {http://www.libpng.org/},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{IRCD,
-title = {IRCD-Hybrid},
-url = {http://www.ircd-hybrid.org/},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{XChat,
-title = {X-Chat},
-url = {http://xchat.org/},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{iPhoneOS,
-Title = {iPhone OS},
-url = {http://www.apple.com/de/iphone/},
-Note = {[Online; letzter Aufruf 03.02.2010]},
-}
-
-@misc{SymbianOS,
-Title = {Symbian OS},
-OPTurl = {http://www.symbian.org/},
-Note = {[Online; letzter Aufruf 03.02.2010]},
-}
-
@misc{SPALS,
title = {Spontaneous Privacy-Aware Location Sharing},
author = {Konstantin Welke and Klaus Rechert},
@@ -131,15 +14,9 @@ year = {2009},
@article{privacy,
title = {Location privacy and locationaware computing},
author = {Matt Duckham and Lars Kulik},
-journal = {IEEE Pervasive Computing Magazine},
-year = {2003},
-pages = {46-55},
-}
-
-@misc{OSM,
-Title = {OpenStreetMap},
-url = {http://www.openstreetmap.de/},
-Note = {[Online; letzter Aufruf 13.02.2010]},
+journal = {Dynamic and mobile GIS: investigating change in space and time},
+year = {2006},
+pages = {34-51},
}
@article{bluetooth,
@@ -151,16 +28,6 @@ year = {2005},
pages = {39-50},
}
-@article{location,
-title = {User needs for location-aware mobile services},
-author = {Eija Kaasinen},
-year = {2003},
-journal = {Personal and Ubiquitous Computing},
-pages = {70-79},
-volume = {Volume 7},
-number = {1},
-}
-
@article{blowfish,
title = {Description of a New Variable-Length Key, 64-Bit Block Cipher (Blowfish)},
author = {Bruce Schneier},
@@ -211,12 +78,7 @@ volume = {Volume 46},
number = {2},
}
-@misc{base64,
-titel = {RFC 4648},
-year = {2006},
-}
-
-@misc{symm,
+@article{symm,
author = {Günter Müller},
howpublished = {Vorlesung IT-Sicherheit},
year = {2009},
diff --git a/ausarbeitung/literature.bib~ b/ausarbeitung/literature.bib~
index 51c4364..3db6531 100644
--- a/ausarbeitung/literature.bib~
+++ b/ausarbeitung/literature.bib~
@@ -1,124 +1,13 @@
-@misc{efl,
-Title = {Enlightenment},
-url = {http://www.enlightenment.org/},
-Note = {[Online; letzter Aufruf 20.11.2009]},
-}
-
-@misc{CeGCC,
-Title = {CeGCC},
-url = {http://cegcc.sourceforge.net/},
-Note = {[Online; letzter Aufruf 20.11.2009]},
-}
-
-@misc{libircclient,
-Title = {libircclient},
-url = {http://libircclient.sourceforge.net/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{OpenSSL,
-Title = {libCrypto},
-url = {http://www.openssl.org/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{Wireshark,
-Title = {Wireshark},
-url = {http://www.wireshark.org/},
-Note = {[Online; letzter Aufruf 27.01.2010]},
-}
-
-@misc{IRC,
-Title = {IRC-Protokoll},
-url = {http://www.irc.org/},
-Note = {[Online; letzter Aufruf 27.01.2010]},
-}
-
-@misc{Windows,
-Title = {Windows Mobile},
-url = {http://www.microsoft.com/windowsmobile/de-de/default.mspx},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{Android,
-Title = {Android},
-url = {http://www.android.com/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{WebOS,
-Title = {WebOS},
-url = {http://palmwebos.org/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{PalmOS,
-Title = {PalmOS},
-url = {http://www.palm.com/},
-Note = {[Online; letzter Aufruf 25.01.2010]},
-}
-
-@misc{FriendSensing,
-title = {FriendSensing: Recommending Friends Using Mobile Phones},
-author = {Daniele Quercia and Licia Capra},
-year = {2009},
-organization = {MIT SENSEable City Laboratory, Cambridge, USA und Dept.of Computer Sience, University College London, UK},
-url = {web.mit.edu/quercia/www/publications/friendSensing_short.pdf},
-note = {[Online; letzter Aufruf 27.01.2010]},
-}
-
-@misc{Latitude,
-title = {Google Latitude},
-url = {http://www.google.com/intl/en_us/latitude/intro.html},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{POSIX,
-title = {Portable Operating System Interface for Unix Layer},
-url = {http://standards.ieee.org/regauth/posix/},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{qrencode,
-title = {libqrencode},
-url = {http://megaui.net/fukuchi/works/qrencode/index.en.html},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
@misc{qrcode,
title = {QR Code},
url = {http://www.denso-wave.com/qrcode/qrstandard-e.html},
Note = {[Online; letzter Aufruf 11.02.2010]},
}
-@misc{PNG,
-title = {libpng},
-url = {http://www.libpng.org/},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{IRCD,
-title = {IRCD-Hybrid},
-url = {http://www.ircd-hybrid.org/},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{XChat,
-title = {X-Chat},
-url = {http://xchat.org/},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
-@misc{iPhoneOS,
-Title = {iPhone OS},
-url = {http://www.apple.com/de/iphone/},
-Note = {[Online; letzter Aufruf 03.02.2010]},
-}
-
-@misc{SymbianOS,
-Title = {Symbian OS},
-OPTurl = {http://www.symbian.org/},
-Note = {[Online; letzter Aufruf 03.02.2010]},
+@misc{IRC,
+title = {RFC 1459 Internet Relay Chat},
+author = {J. Oikarinen and D. Reed},
+year = {2003},
}
@misc{SPALS,
@@ -131,17 +20,11 @@ year = {2009},
@article{privacy,
title = {Location privacy and locationaware computing},
author = {Matt Duckham and Lars Kulik},
-journal = {Dynamic and &mobile GIS: investigating change in space and time},
+journal = {Dynamic and mobile GIS: investigating change in space and time},
year = {2006},
pages = {34-51},
}
-@misc{OSM,
-Title = {OpenStreetMap},
-url = {http://www.openstreetmap.de/},
-Note = {[Online; letzter Aufruf 13.02.2010]},
-}
-
@article{bluetooth,
title = {Cracking the Bluetooth PIN},
author = {Yaniv Shaked and Avishai Wool},
@@ -151,16 +34,6 @@ year = {2005},
pages = {39-50},
}
-@article{location,
-title = {User needs for location-aware mobile services},
-author = {Eija Kaasinen},
-year = {2003},
-journal = {Personal and Ubiquitous Computing},
-pages = {70-79},
-volume = {Volume 7},
-number = {1},
-}
-
@article{blowfish,
title = {Description of a New Variable-Length Key, 64-Bit Block Cipher (Blowfish)},
author = {Bruce Schneier},
@@ -211,12 +84,7 @@ volume = {Volume 46},
number = {2},
}
-@misc{base64,
-titel = {RFC 4648},
-year = {2006},
-}
-
-@misc{symm,
+@article{symm,
author = {Günter Müller},
howpublished = {Vorlesung IT-Sicherheit},
year = {2009},
diff --git a/ausarbeitung/maindoc.aux b/ausarbeitung/maindoc.aux
index 79c5dab..90595f5 100644
--- a/ausarbeitung/maindoc.aux
+++ b/ausarbeitung/maindoc.aux
@@ -25,39 +25,17 @@
\@input{Fazit.aux}
\@input{Anhang.aux}
\bibdata{literature}
-\bibcite{Android}{{1}{}{{}}{{}}}
-\bibcite{CeGCC}{{2}{}{{}}{{}}}
-\bibcite{efl}{{3}{}{{}}{{}}}
-\bibcite{Latitude}{{4}{}{{}}{{}}}
-\bibcite{iPhoneOS}{{5}{}{{}}{{}}}
+\bibcite{kanonymity}{{1}{}{{}}{{}}}
+\bibcite{privacy}{{2}{}{{}}{{}}}
+\bibcite{kprivacy}{{3}{}{{}}{{}}}
+\bibcite{dummy}{{4}{}{{}}{{}}}
+\bibcite{symm}{{5}{}{{}}{{}}}
\bibcite{IRC}{{6}{}{{}}{{}}}
-\bibcite{IRCD}{{7}{}{{}}{{}}}
-\bibcite{OpenSSL}{{8}{}{{}}{{}}}
-\bibcite{libircclient}{{9}{}{{}}{{}}}
-\bibcite{PNG}{{10}{}{{}}{{}}}
-\bibcite{qrencode}{{11}{}{{}}{{}}}
-\bibcite{OSM}{{12}{}{{}}{{}}}
-\bibcite{PalmOS}{{13}{}{{}}{{}}}
-\bibcite{POSIX}{{14}{}{{}}{{}}}
-\bibcite{qrcode}{{15}{}{{}}{{}}}
-\bibcite{SymbianOS}{{16}{}{{}}{{}}}
-\bibcite{WebOS}{{17}{}{{}}{{}}}
-\bibcite{Windows}{{18}{}{{}}{{}}}
-\bibcite{Wireshark}{{19}{}{{}}{{}}}
-\bibcite{XChat}{{20}{}{{}}{{}}}
-\bibcite{base64}{{21}{}{{}}{{}}}
-\bibcite{kanonymity}{{22}{}{{}}{{}}}
-\bibcite{privacy}{{23}{}{{}}{{}}}
-\bibcite{kprivacy}{{24}{}{{}}{{}}}
-\bibcite{location}{{25}{}{{}}{{}}}
-\bibcite{dummy}{{26}{}{{}}{{}}}
-\bibcite{symm}{{27}{}{{}}{{}}}
-\bibcite{FriendSensing}{{28}{}{{}}{{}}}
-\bibcite{quadtree}{{29}{}{{}}{{}}}
-\bibcite{blowfish}{{30}{}{{}}{{}}}
-\bibcite{bluetooth}{{31}{}{{}}{{}}}
-\bibcite{geocaching}{{32}{}{{}}{{}}}
-\bibcite{SPALS}{{33}{}{{}}{{}}}
+\bibcite{quadtree}{{7}{}{{}}{{}}}
+\bibcite{blowfish}{{8}{}{{}}{{}}}
+\bibcite{bluetooth}{{9}{}{{}}{{}}}
+\bibcite{geocaching}{{10}{}{{}}{{}}}
+\bibcite{SPALS}{{11}{}{{}}{{}}}
\bibstyle{plain}
\citation{*}
\global\NAT@numberstrue
diff --git a/ausarbeitung/maindoc.bbl b/ausarbeitung/maindoc.bbl
index 4eb15bf..6ea8704 100644
--- a/ausarbeitung/maindoc.bbl
+++ b/ausarbeitung/maindoc.bbl
@@ -1,88 +1,5 @@
\begin{thebibliography}{10}
-\bibitem{Android}
-Android.
-\newblock [Online; letzter Aufruf 25.01.2010].
-
-\bibitem{CeGCC}
-Cegcc.
-\newblock [Online; letzter Aufruf 20.11.2009].
-
-\bibitem{efl}
-Enlightenment.
-\newblock [Online; letzter Aufruf 20.11.2009].
-
-\bibitem{Latitude}
-Google latitude.
-\newblock [Online; letzter Aufruf 11.02.2010].
-
-\bibitem{iPhoneOS}
-iphone os.
-\newblock [Online; letzter Aufruf 03.02.2010].
-
-\bibitem{IRC}
-Irc-protokoll.
-\newblock [Online; letzter Aufruf 27.01.2010].
-
-\bibitem{IRCD}
-Ircd-hybrid.
-\newblock [Online; letzter Aufruf 11.02.2010].
-
-\bibitem{OpenSSL}
-libcrypto.
-\newblock [Online; letzter Aufruf 25.01.2010].
-
-\bibitem{libircclient}
-libircclient.
-\newblock [Online; letzter Aufruf 25.01.2010].
-
-\bibitem{PNG}
-libpng.
-\newblock [Online; letzter Aufruf 11.02.2010].
-
-\bibitem{qrencode}
-libqrencode.
-\newblock [Online; letzter Aufruf 11.02.2010].
-
-\bibitem{OSM}
-Openstreetmap.
-\newblock [Online; letzter Aufruf 13.02.2010].
-
-\bibitem{PalmOS}
-Palmos.
-\newblock [Online; letzter Aufruf 25.01.2010].
-
-\bibitem{POSIX}
-Portable operating system interface for unix layer.
-\newblock [Online; letzter Aufruf 11.02.2010].
-
-\bibitem{qrcode}
-Qr code.
-\newblock [Online; letzter Aufruf 11.02.2010].
-
-\bibitem{SymbianOS}
-Symbian os.
-\newblock [Online; letzter Aufruf 03.02.2010].
-
-\bibitem{WebOS}
-Webos.
-\newblock [Online; letzter Aufruf 25.01.2010].
-
-\bibitem{Windows}
-Windows mobile.
-\newblock [Online; letzter Aufruf 25.01.2010].
-
-\bibitem{Wireshark}
-Wireshark.
-\newblock [Online; letzter Aufruf 27.01.2010].
-
-\bibitem{XChat}
-X-chat.
-\newblock [Online; letzter Aufruf 11.02.2010].
-
-\bibitem{base64}
-2006.
-
\bibitem{kanonymity}
Valentina Ciriani, Sabrina De~Capitani di~Vimercati, Sara Foresti, and
Pierangela Samarati.
@@ -103,11 +20,6 @@ Marco Gruteser and Dirk Grunwald.
\newblock {\em Proceedings of the 1st international conference on Mobile
systems, applications and services}, pages 31--42, 2003.
-\bibitem{location}
-Eija Kaasinen.
-\newblock User needs for location-aware mobile services.
-\newblock {\em Personal and Ubiquitous Computing}, Volume 7(1):70--79, 2003.
-
\bibitem{dummy}
Hidetoshi Kido, Yutaka Yanagisawa, and Tetsuji Satoh.
\newblock An anonymous communication technique using dummies for location-based
@@ -117,12 +29,11 @@ Hidetoshi Kido, Yutaka Yanagisawa, and Tetsuji Satoh.
\bibitem{symm}
Günter Müller.
-\newblock Vorlesung IT-Sicherheit, 2009.
+\newblock 2009.
-\bibitem{FriendSensing}
-Daniele Quercia and Licia Capra.
-\newblock Friendsensing: Recommending friends using mobile phones, 2009.
-\newblock [Online; letzter Aufruf 27.01.2010].
+\bibitem{IRC}
+J.~Oikarinen and D.~Reed.
+\newblock Rfc 1459 internet relay chat, 2003.
\bibitem{quadtree}
Hanan Samet.
diff --git a/ausarbeitung/maindoc.blg b/ausarbeitung/maindoc.blg
index d07038d..4b926ce 100644
--- a/ausarbeitung/maindoc.blg
+++ b/ausarbeitung/maindoc.blg
@@ -10,66 +10,47 @@ A level-1 auxiliary file: Fazit.aux
A level-1 auxiliary file: Anhang.aux
The style file: plain.bst
Database file #1: literature.bib
-Warning--to sort, need author or key in Latitude
-Warning--to sort, need author or key in qrcode
-Warning--to sort, need author or key in IRC
-Warning--to sort, need author or key in POSIX
-Warning--to sort, need author or key in CeGCC
-Warning--to sort, need author or key in Android
-Warning--to sort, need author or key in WebOS
-Warning--to sort, need author or key in iPhoneOS
-Warning--to sort, need author or key in SymbianOS
-Warning--to sort, need author or key in efl
-Warning--to sort, need author or key in OSM
-Warning--to sort, need author or key in OpenSSL
-Warning--to sort, need author or key in base64
-Warning--to sort, need author or key in libircclient
-Warning--to sort, need author or key in qrencode
-Warning--to sort, need author or key in PNG
-Warning--to sort, need author or key in Wireshark
-Warning--to sort, need author or key in IRCD
-Warning--to sort, need author or key in Windows
-Warning--to sort, need author or key in PalmOS
-Warning--to sort, need author or key in XChat
-You've used 33 entries,
+Warning--empty title in symm
+Warning--empty journal in symm
+You've used 11 entries,
2118 wiz_defined-function locations,
- 630 strings with 6610 characters,
-and the built_in function-call counts, 7137 in all, are:
-= -- 675
-> -- 162
+ 566 strings with 5720 characters,
+and the built_in function-call counts, 3574 in all, are:
+= -- 354
+> -- 134
< -- 6
-+ -- 79
-- -- 44
-* -- 316
-:= -- 950
-add.period$ -- 75
-call.type$ -- 33
-change.case$ -- 119
++ -- 55
+- -- 42
+* -- 197
+:= -- 571
+add.period$ -- 30
+call.type$ -- 11
+change.case$ -- 53
chr.to.int$ -- 0
-cite$ -- 54
-duplicate$ -- 312
-empty$ -- 799
-format.name$ -- 44
-if$ -- 1673
+cite$ -- 13
+duplicate$ -- 157
+empty$ -- 286
+format.name$ -- 42
+if$ -- 792
int.to.chr$ -- 0
-int.to.str$ -- 33
+int.to.str$ -- 11
missing$ -- 9
-newline$ -- 144
-num.names$ -- 24
-pop$ -- 297
+newline$ -- 55
+num.names$ -- 22
+pop$ -- 64
preamble$ -- 1
-purify$ -- 88
+purify$ -- 43
quote$ -- 0
-skip$ -- 278
+skip$ -- 143
stack$ -- 0
-substring$ -- 339
-swap$ -- 79
+substring$ -- 214
+swap$ -- 56
text.length$ -- 6
text.prefix$ -- 0
top$ -- 0
-type$ -- 132
-warning$ -- 21
-while$ -- 38
-width$ -- 35
-write$ -- 272
-(There were 21 warnings)
+type$ -- 44
+warning$ -- 2
+while$ -- 35
+width$ -- 13
+write$ -- 113
+(There were 2 warnings)
diff --git a/ausarbeitung/maindoc.log b/ausarbeitung/maindoc.log
index 49b2fce..d4e694b 100644
--- a/ausarbeitung/maindoc.log
+++ b/ausarbeitung/maindoc.log
@@ -1,4 +1,4 @@
-This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) (format=pdflatex 2009.12.22) 23 FEB 2010 22:12
+This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) (format=pdflatex 2009.12.22) 24 FEB 2010 22:08
entering extended mode
%&-line parsing enabled.
**maindoc
@@ -468,21 +468,21 @@ Package: subfigure 2002/03/15 v2.1.5 subfigure package
(./Tutorial.aux) (./Friend_Finder.aux) (./Fazit.aux) (./Anhang.aux))
\openout1 = `maindoc.aux'.
-LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 107.
-LaTeX Font Info: ... okay on input line 107.
-LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 107.
-LaTeX Font Info: ... okay on input line 107.
-LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 107.
-LaTeX Font Info: ... okay on input line 107.
-LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 107.
-LaTeX Font Info: ... okay on input line 107.
-LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 107.
-LaTeX Font Info: ... okay on input line 107.
-LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 107.
-LaTeX Font Info: ... okay on input line 107.
-LaTeX Font Info: Checking defaults for PD1/pdf/m/n on input line 107.
-LaTeX Font Info: ... okay on input line 107.
-LaTeX Font Info: Try loading font information for OT1+ptm on input line 107.
+LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 108.
+LaTeX Font Info: ... okay on input line 108.
+LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 108.
+LaTeX Font Info: ... okay on input line 108.
+LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 108.
+LaTeX Font Info: ... okay on input line 108.
+LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 108.
+LaTeX Font Info: ... okay on input line 108.
+LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 108.
+LaTeX Font Info: ... okay on input line 108.
+LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 108.
+LaTeX Font Info: ... okay on input line 108.
+LaTeX Font Info: Checking defaults for PD1/pdf/m/n on input line 108.
+LaTeX Font Info: ... okay on input line 108.
+LaTeX Font Info: Try loading font information for OT1+ptm on input line 108.
(/usr/share/texmf-texlive/tex/latex/psnfss/ot1ptm.fd
@@ -511,7 +511,7 @@ File: color.cfg 2007/01/18 v1.5 color configuration of teTeX/TeXLive
)
Package color Info: Driver file: pdftex.def on input line 130.
)
-Package hyperref Info: Link coloring ON on input line 107.
+Package hyperref Info: Link coloring ON on input line 108.
(/usr/share/texmf-texlive/tex/latex/hyperref/nameref.sty
Package: nameref 2006/12/27 v2.28 Cross-referencing by name of section
@@ -521,8 +521,8 @@ Package: refcount 2006/02/20 v3.0 Data extraction from references (HO)
)
\c@section@level=\count138
)
-LaTeX Info: Redefining \ref on input line 107.
-LaTeX Info: Redefining \pageref on input line 107.
+LaTeX Info: Redefining \ref on input line 108.
+LaTeX Info: Redefining \pageref on input line 108.
(./maindoc.out)
(./maindoc.out)
\@outlinefile=\write3
@@ -589,7 +589,7 @@ File: uni-0.def 2004/10/17 UCS: Unicode data U+0000..U+00FF
s been already used, duplicate ignored
<to be read again>
\relax
-l.118 \include{Erklaerung}
+l.119 \include{Erklaerung}
[1
@@ -597,7 +597,7 @@ l.118 \include{Erklaerung}
\openout2 = `Einleitung.aux'.
(./Einleitung.tex)
-Overfull \hbox (28.31004pt too wide) in paragraph at lines 3--119
+Overfull \hbox (28.31004pt too wide) in paragraph at lines 3--120
\OT1/ptm/m/n/12 Durch den fortschre-i-t-en-den En-twick-lung der mod-er-nen Tec
h-nik ist es m[]oglich im-mer leis-tungsst[]arkere,
[]
@@ -609,232 +609,142 @@ h-nik ist es m[]oglich im-mer leis-tungsst[]arkere,
\openout2 = `Grundlagen.aux'.
(./Grundlagen.tex
-Underfull \hbox (badness 10000) in paragraph at lines 16--48
-
- []
-
-[3
-
-
-]
-Underfull \hbox (badness 10000) in paragraph at lines 52--72
-
- []
-
-[4]
-Underfull \hbox (badness 10000) in paragraph at lines 76--81
-
- []
+LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <10> not available
+(Font) Font shape `OT1/ptm/b/n' tried instead on input line 21.
+LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <7.4> not available
+(Font) Font shape `OT1/ptm/b/n' tried instead on input line 21.
+LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <6> not available
+(Font) Font shape `OT1/ptm/b/n' tried instead on input line 21.
+ [3
-Underfull \hbox (badness 10000) in paragraph at lines 82--88
-
+] [4]
+Overfull \hbox (5.40251pt too wide) in paragraph at lines 73--105
+\OT1/ptm/m/n/12 fahren genutzt wer-den welch-es den Aus-tausch von zwei Schl[]u
+sseln auf ein-fache Weise erm[]oglicht.
[]
-
-Underfull \hbox (badness 10000) in paragraph at lines 89--100
-
+[5])
+Overfull \hbox (7.5748pt too wide) in paragraph at lines 108--121
+\OT1/ptm/m/n/12 Da der Schl[]usselaustausch spon-tan durchf[]uhrbar sein soll,
+muss dieser zu je-dem Zeit-punkt m[]oglich
[]
-
-Underfull \hbox (badness 10000) in paragraph at lines 101--109
-
- []
-
-[5]
-Underfull \hbox (badness 10000) in paragraph at lines 112--119
-
- []
-
-
-Overfull \hbox (9.99126pt too wide) in paragraph at lines 120--128
-\OT1/ptm/m/n/12 m[]oglich sein ohne das daf[]ur Vor-bere-itun-gen getrof-fen we
-r-den m[]ussen. So k[]onnte man die Schl[]ussel
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 120--128
-
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 129--140
-
- []
-
-[6]) [7]
+[6] [7]
\openout2 = `Tutorial.aux'.
(./Tutorial.tex
-Underfull \hbox (badness 10000) in paragraph at lines 3--6
-
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 7--11
-
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 37--41
-
+Overfull \hbox (8.55022pt too wide) in paragraph at lines 37--43
+\OT1/ptm/m/n/12 Desktop-Varianten der Windows-Familie erken-nen. Es ex-istiert
+ein \OT1/ptm/m/it/12 Cross-Compiler \OT1/ptm/m/n/12 names \OT1/ptm/m/it/12 CeGC
+C
[]
[8
-]
-Underfull \hbox (badness 10000) in paragraph at lines 44--47
-
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 48--55
-
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 58--64
-
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 67--73
-
- []
-
-[9]
-Overfull \hbox (0.91805pt too wide) in paragraph at lines 83--93
+] [9]
+Overfull \hbox (0.91805pt too wide) in paragraph at lines 86--93
\OT1/ptm/m/it/12 iPhoneOS \OT1/ptm/m/n/12 wurde auf-grund sein-er man-gel-nden
\OT1/ptm/m/it/12 Mul-ti-task-ing\OT1/ptm/m/n/12 -Unterst[]utzung aus-geschlosse
n. Diese
[]
-
-Underfull \hbox (badness 10000) in paragraph at lines 101--106
-
- []
-
-[10]
-Underfull \hbox (badness 10000) in paragraph at lines 107--112
-
- []
-
-<Bilder/elm-app-01_2.png, id=251, 133.35536pt x 185.83714pt>
+[10] <Bilder/elm-app-01_2.png, id=249, 133.35536pt x 185.83714pt>
File: Bilder/elm-app-01_2.png Graphic file (type png)
<use Bilder/elm-app-01_2.png>
-<Bilder/elm-app-02_2.png, id=252, 206.48572pt x 405.22821pt>
+<Bilder/elm-app-02_2.png, id=250, 206.48572pt x 405.22821pt>
File: Bilder/elm-app-02_2.png Graphic file (type png)
-<use Bilder/elm-app-02_2.png>
-
-LaTeX Warning: `h' float specifier changed to `ht'.
-
-<Bilder/efl.png, id=253, 48.18pt x 72.27pt>
+<use Bilder/elm-app-02_2.png> <Bilder/efl.png, id=251, 48.18pt x 72.27pt>
File: Bilder/efl.png Graphic file (type png)
- <use Bilder/efl.png>
+
+<use Bilder/efl.png>
LaTeX Warning: `h' float specifier changed to `ht'.
-Underfull \hbox (badness 10000) in paragraph at lines 141--147
+Underfull \hbox (badness 10000) in paragraph at lines 150--156
[]
-) [11] [12 <./Bilder/elm-app-01_2.png> <./Bilder/elm-app-02_2.png> <./Bilder/ef
-l.png>]
+[11 <./Bilder/elm-app-01_2.png> <./Bilder/elm-app-02_2.png>]) [12 <./Bilder/efl
+.png>]
\openout2 = `Friend_Finder.aux'.
(./Friend_Finder.tex
-Overfull \hbox (12.09158pt too wide) in paragraph at lines 11--19
+Overfull \hbox (12.09158pt too wide) in paragraph at lines 11--18
\OT1/ptm/m/n/12 Mod-ulen. Der \OT1/ptm/m/it/12 Mes-sage Sender \OT1/ptm/m/n/12
ist f[]ur das Versenden und Emp-fan-gen der Textnachricht-en zust[]andig,
[]
-<Bilder/ablauf.png, id=269, 546.54187pt x 597.73312pt>
+<Bilder/ablauf.png, id=266, 546.54187pt x 597.73312pt>
File: Bilder/ablauf.png Graphic file (type png)
<use Bilder/ablauf.png>
-Overfull \hbox (19.98601pt too wide) in paragraph at lines 28--35
-\OT1/ptm/m/n/12 Zum Er-stellen der Ober-fl[]ache wurde \OT1/ptm/m/it/12 En-ligh
-t-en-ment \OT1/ptm/m/n/12 ver-wen-det. Diese Bib-lio-thek stellt alle ben[]otig
-ten
- []
-
-
-Overfull \hbox (1.8149pt too wide) in paragraph at lines 28--35
-\OT1/ptm/m/n/12 Zur Darstel-lung der Karte wur-den Dat-en des of-fe-nen Karten-
-pro-jek-ts \OT1/ptm/m/it/12 Open-StreetMap \OT1/ptm/m/n/12 [[]] genutzt.
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 38--42
-
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 43--60
-
+Overfull \hbox (12.08994pt too wide) in paragraph at lines 27--32
+\OT1/ptm/m/n/12 er Datei zusam-menge-fast. In dieser Datei sind alle Funk-tio-n
+en en-thal-ten um die Ober-fl[]achenelement
[]
[13
-] [14 <./Bilder/ablauf.png>]
-<Bilder/chat.png, id=288, 338.76563pt x 450.18187pt>
+] <Bilder/chat.png, id=276, 338.76563pt x 450.18187pt>
File: Bilder/chat.png Graphic file (type png)
- <use Bilder/chat.png>
-Underfull \hbox (badness 10000) in paragraph at lines 75--84
+<use Bilder/chat.png>
+Overfull \hbox (4.14699pt too wide) in paragraph at lines 58--70
+\OT1/ptm/m/n/12 Der \OT1/ptm/m/it/12 Sender \OT1/ptm/m/n/12 ist zust[]andig f[]
+ur das Versenden der Po-si-tions-dat-en. Auch hi-er muss vor dem Versenden
[]
-[15 <./Bilder/chat.png>]
-Overfull \hbox (17.9312pt too wide) in paragraph at lines 85--87
-[]\OT1/ptm/m/n/12 Auch hi-er wird, wie beim Versenden der Nachricht-en zum Ver-
-schl[]usseln der \OT1/ptm/m/it/12 Blowfish-Algorithmus
- []
+[14 <./Bilder/ablauf.png>] [15 <./Bilder/chat.png>]
+<Bilder/position.png, id=289, 338.76563pt x 447.92343pt>
+File: Bilder/position.png Graphic file (type png)
-<Bilder/barcode.png, id=300, 337.26pt x 450.9347pt>
+<use Bilder/position.png> <Bilder/barcode.png, id=292, 337.26pt x 450.9347pt>
File: Bilder/barcode.png Graphic file (type png)
- <use Bilder/barcode.png>
-Underfull \hbox (badness 10000) in paragraph at lines 118--124
-
- []
-
-[16]
-Underfull \hbox (badness 10000) in paragraph at lines 125--130
+<use Bilder/barcode.png>
+Overfull \hbox (2.70879pt too wide) in paragraph at lines 106--123
+\OT1/ptm/m/n/12 und versendet wer-den. Unter Daten-over-head wer-den Hin-ter-gr
+und-dat-en gese-hen, welche versendet
[]
-[17 <./Bilder/barcode.png>]
-Overfull \hbox (13.04648pt too wide) in paragraph at lines 138--147
+[16 <./Bilder/position.png>] [17 <./Bilder/barcode.png>]
+Overfull \hbox (15.05054pt too wide) in paragraph at lines 126--135
\OT1/ptm/m/n/12 Der All-ge-meine Hin-ter-grund-verkehr bei \OT1/ptm/m/it/12 Fri
-end Find-er \OT1/ptm/m/n/12 beste-ht zum einen aus \OT1/ptm/m/it/12 Keep-Alive
+end Find-er \OT1/ptm/m/n/12 beste-ht zum Einen aus \OT1/ptm/m/it/12 Keep-Alive
\OT1/ptm/m/n/12 Nachricht-
[]
-Underfull \hbox (badness 10000) in paragraph at lines 138--147
-
+Overfull \hbox (0.66324pt too wide) in paragraph at lines 138--146
+\OT1/ptm/m/n/12 Ver-schl[]usselung wer-den beim Senden noch In-for-ma-tio-nen b
+ez[]uglich \OT1/ptm/m/it/12 Chan-nel \OT1/ptm/m/n/12 und der Empf[]anger
[]
-Overfull \hbox (4.52718pt too wide) in paragraph at lines 150--161
+Overfull \hbox (4.52718pt too wide) in paragraph at lines 138--146
\OT1/ptm/m/n/12 Wenn $\OML/ztmcm/m/it/12 h$ \OT1/ptm/m/n/12 die Gr[]o^^Ye des \
OT1/ptm/m/it/12 TCP-Headers \OT1/ptm/m/n/12 und $\OML/ztmcm/m/it/12 t$ \OT1/ptm
/m/n/12 die An-zahl der Ze-ichen der un-ver-schl[]usselten Nachricht
[]
-Overfull \hbox (15.74675pt too wide) in paragraph at lines 164--176
+Overfull \hbox (15.74675pt too wide) in paragraph at lines 149--163
\OT1/ptm/m/n/12 Wie schon erw[]ahnt, wer-den die Po-si-tions-dat-en beim Sender
aufgeteilt und mit vi-er un-ter-schiedlichen
[]
-[18]) [19]
+[18] <Bilder/graph.png, id=313, 642.4pt x 481.8pt>
+File: Bilder/graph.png Graphic file (type png)
+ <use Bilder/graph.png>)
+[19] [20 <./Bilder/graph.png (PNG copy)>]
\openout2 = `Fazit.aux'.
- (./Fazit.tex) [20
+ (./Fazit.tex) [21
]
@@ -845,10 +755,10 @@ Underfull \hbox (badness 10000) in paragraph at lines 9--13
[]
-[21
+[22
-] [22] [23] [24]
+] [23] [24] [25]
Overfull \hbox (13.83946pt too wide) in paragraph at lines 202--205
\OT1/ptm/m/n/12 be-liebi-gen Ed-i-tor ge[]offnet wer-den und in bei-den Dateien
der Wert von ''pre-fix`` auf ''WINCE[]PATH``
@@ -866,13 +776,13 @@ Overfull \hbox (169.12907pt too wide) in paragraph at lines 239--239
d.h $WINCE_PATH/freetype-2.3.7-dev/include[]
[]
-[25] [26]
+[26] [27]
Overfull \hbox (40.46509pt too wide) in paragraph at lines 323--326
\OT1/ptm/m/n/12 muss man im in der Datei ``Make-file.am'' im Ord-ner ``sr-c/bin
/'' alle Vorkomm-nisse von ``test[]fileselector.c''
[]
-[27]
+[28]
LaTeX Font Info: Try loading font information for OMS+ptm on input line 362.
(/usr/share/texmf-texlive/tex/latex/psnfss/omsptm.fd
@@ -916,7 +826,7 @@ Overfull \hbox (19.92868pt too wide) in paragraph at lines 378--380
ported % 20packages / freetype-[]2 .
[]
-[28]
+[29]
Overfull \hbox (7.57867pt too wide) in paragraph at lines 380--382
[][]$\OT1/cmtt/m/n/12 http : / / sourceforge . net / projects / cegcc / files /
ported % 20packages / libpng-[]1 .
@@ -928,7 +838,7 @@ Overfull \hbox (7.57867pt too wide) in paragraph at lines 382--384
ported % 20packages / libpng-[]1 .
[]
-[29] [30] [31]
+[30] [31] [32]
Overfull \hbox (2.40399pt too wide) in paragraph at lines 513--513
[]\OT1/cmtt/m/n/12 arm-mingw32ce-strip efl/evas/modules/savers/eet/mingw32ce-ar
m/saver_eet.dll[]
@@ -940,28 +850,29 @@ Overfull \hbox (2.40399pt too wide) in paragraph at lines 513--513
m/saver_png.dll[]
[]
-) [32] (./maindoc.bbl [33
+) [33] (./maindoc.bbl) [34
-]) [34] (./maindoc.aux (./Title.aux) (./Erklaerung.aux) (./Einleitung.aux) (./G
-rundlagen.aux) (./Tutorial.aux) (./Friend_Finder.aux)
+] (./maindoc.aux (./Title.aux) (./Erklaerung.aux)
+(./Einleitung.aux) (./Grundlagen.aux) (./Tutorial.aux) (./Friend_Finder.aux)
(./Fazit.aux) (./Anhang.aux)) )
Here is how much of TeX's memory you used:
- 8738 strings out of 95086
- 119802 string characters out of 1183254
- 201030 words of memory out of 1500000
- 11543 multiletter control sequences out of 10000+50000
- 23012 words of font info for 60 fonts, out of 1200000 for 2000
+ 8746 strings out of 95086
+ 120103 string characters out of 1183254
+ 199704 words of memory out of 1500000
+ 11564 multiletter control sequences out of 10000+50000
+ 37618 words of font info for 93 fonts, out of 1200000 for 2000
28 hyphenation exceptions out of 8191
35i,11n,46p,303b,538s stack positions out of 5000i,500n,6000p,200000b,5000s
{/usr/share/texmf-texlive/fonts/enc/dvips/base/8
r.enc}</usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmr10.pfb></usr/share/te
xmf-texlive/fonts/type1/bluesky/cm/cmssbx10.pfb></usr/share/texmf-texlive/fonts
/type1/bluesky/cm/cmsy10.pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/c
-mtt12.pfb></usr/share/texmf-texlive/fonts/type1/urw/times/utmr8a.pfb></usr/shar
-e/texmf-texlive/fonts/type1/urw/times/utmri8a.pfb>
-Output written on maindoc.pdf (36 pages, 1475283 bytes).
+mtt10.pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmtt12.pfb></usr/sha
+re/texmf-texlive/fonts/type1/urw/times/utmr8a.pfb></usr/share/texmf-texlive/fon
+ts/type1/urw/times/utmri8a.pfb>
+Output written on maindoc.pdf (36 pages, 1777057 bytes).
PDF statistics:
- 475 PDF objects out of 1000 (max. 8388607)
- 121 named destinations out of 1000 (max. 131072)
- 292 words of extra memory for PDF output out of 10000 (max. 10000000)
+ 461 PDF objects out of 1000 (max. 8388607)
+ 101 named destinations out of 1000 (max. 131072)
+ 302 words of extra memory for PDF output out of 10000 (max. 10000000)
diff --git a/ausarbeitung/maindoc.out b/ausarbeitung/maindoc.out
index fe8e152..5a3580f 100644
--- a/ausarbeitung/maindoc.out
+++ b/ausarbeitung/maindoc.out
@@ -1,6 +1,6 @@
\BOOKMARK [1][-]{section.1}{Einleitung}{}
\BOOKMARK [1][-]{section.2}{Grundlagen}{}
-\BOOKMARK [2][-]{subsection.2.1}{Aktueller Stand}{section.2}
+\BOOKMARK [2][-]{subsection.2.1}{Aktuelle Entwicklungen}{section.2}
\BOOKMARK [2][-]{subsection.2.2}{Vorraussetzungen}{section.2}
\BOOKMARK [2][-]{subsection.2.3}{Ziele}{section.2}
\BOOKMARK [2][-]{subsection.2.4}{Verfahren}{section.2}
@@ -20,7 +20,7 @@
\BOOKMARK [3][-]{subsubsection.4.1.1}{Grafisches Benutzeroberfl\344che}{subsection.4.1}
\BOOKMARK [3][-]{subsubsection.4.1.2}{Versenden der Nachrichten}{subsection.4.1}
\BOOKMARK [3][-]{subsubsection.4.1.3}{Versenden der eigenen Position}{subsection.4.1}
-\BOOKMARK [3][-]{subsubsection.4.1.4}{Empfangen der eigenen Position}{subsection.4.1}
+\BOOKMARK [3][-]{subsubsection.4.1.4}{Empfangen von Positionen}{subsection.4.1}
\BOOKMARK [3][-]{subsubsection.4.1.5}{Erzeugen eines 2D-Barcodes}{subsection.4.1}
\BOOKMARK [2][-]{subsection.4.2}{Analyse}{section.4}
\BOOKMARK [3][-]{subsubsection.4.2.1}{Allgemeiner Datenverkehr}{subsection.4.2}
diff --git a/ausarbeitung/maindoc.pdf b/ausarbeitung/maindoc.pdf
index c4f6366..e4d1e8d 100644
--- a/ausarbeitung/maindoc.pdf
+++ b/ausarbeitung/maindoc.pdf
Binary files differ
diff --git a/ausarbeitung/maindoc.tex b/ausarbeitung/maindoc.tex
index fbaac79..6a43d67 100644
--- a/ausarbeitung/maindoc.tex
+++ b/ausarbeitung/maindoc.tex
@@ -19,13 +19,14 @@
%erlaubt Graphiken einzubinden
\usepackage{graphicx}
\usepackage{url}
+%\usepackage[german]{todonotes}
%erm�glicht verschiedene Stile des Literaturverzeichnises
%\usepackage{jurabib}
%\usepackage{plain}
%weitere Stile auf der
-%\usepackage[sectionbib,square]{natbib}
-\usepackage{natbib}
+\usepackage[sectionbib,square]{natbib}
+%\usepackage{natbib}
\usepackage{a4wide}
\usepackage{amsfonts}
diff --git a/ausarbeitung/maindoc.tex~ b/ausarbeitung/maindoc.tex~
index fbaac79..49d0949 100644
--- a/ausarbeitung/maindoc.tex~
+++ b/ausarbeitung/maindoc.tex~
@@ -19,13 +19,14 @@
%erlaubt Graphiken einzubinden
\usepackage{graphicx}
\usepackage{url}
+\usepackage[german]{todonotes}
%erm�glicht verschiedene Stile des Literaturverzeichnises
%\usepackage{jurabib}
%\usepackage{plain}
%weitere Stile auf der
-%\usepackage[sectionbib,square]{natbib}
-\usepackage{natbib}
+\usepackage[sectionbib,square]{natbib}
+%\usepackage{natbib}
\usepackage{a4wide}
\usepackage{amsfonts}
diff --git a/ausarbeitung/maindoc.toc b/ausarbeitung/maindoc.toc
index 5d941cb..25e4e66 100644
--- a/ausarbeitung/maindoc.toc
+++ b/ausarbeitung/maindoc.toc
@@ -1,7 +1,7 @@
\select@language {ngerman}
\contentsline {section}{\numberline {1}Einleitung}{2}{section.1}
\contentsline {section}{\numberline {2}Grundlagen}{3}{section.2}
-\contentsline {subsection}{\numberline {2.1}Aktueller Stand}{3}{subsection.2.1}
+\contentsline {subsection}{\numberline {2.1}Aktuelle Entwicklungen}{3}{subsection.2.1}
\contentsline {subsection}{\numberline {2.2}Vorraussetzungen}{4}{subsection.2.2}
\contentsline {subsection}{\numberline {2.3}Ziele}{5}{subsection.2.3}
\contentsline {subsection}{\numberline {2.4}Verfahren}{6}{subsection.2.4}
@@ -10,22 +10,22 @@
\contentsline {subsubsection}{\numberline {3.1.1}Windows Mobile}{9}{subsubsection.3.1.1}
\contentsline {subsubsection}{\numberline {3.1.2}Android}{9}{subsubsection.3.1.2}
\contentsline {subsubsection}{\numberline {3.1.3}WebOS}{9}{subsubsection.3.1.3}
-\contentsline {subsubsection}{\numberline {3.1.4}iPhone OS}{10}{subsubsection.3.1.4}
+\contentsline {subsubsection}{\numberline {3.1.4}iPhone OS}{9}{subsubsection.3.1.4}
\contentsline {subsubsection}{\numberline {3.1.5}Symbian OS}{10}{subsubsection.3.1.5}
\contentsline {subsubsection}{\numberline {3.1.6}Zielplattform}{10}{subsubsection.3.1.6}
\contentsline {subsection}{\numberline {3.2}Softwaregrundlagen}{10}{subsection.3.2}
-\contentsline {subsubsection}{\numberline {3.2.1}CeGCC}{11}{subsubsection.3.2.1}
+\contentsline {subsubsection}{\numberline {3.2.1}CeGCC}{10}{subsubsection.3.2.1}
\contentsline {subsubsection}{\numberline {3.2.2}Enlightenment}{11}{subsubsection.3.2.2}
\contentsline {section}{\numberline {4}Friend Finder}{13}{section.4}
\contentsline {subsection}{\numberline {4.1}Verwendete Verfahren und Bibliotheken}{13}{subsection.4.1}
\contentsline {subsubsection}{\numberline {4.1.1}Grafisches Benutzeroberfl\IeC {\"a}che}{13}{subsubsection.4.1.1}
\contentsline {subsubsection}{\numberline {4.1.2}Versenden der Nachrichten}{13}{subsubsection.4.1.2}
-\contentsline {subsubsection}{\numberline {4.1.3}Versenden der eigenen Position}{15}{subsubsection.4.1.3}
-\contentsline {subsubsection}{\numberline {4.1.4}Empfangen der eigenen Position}{16}{subsubsection.4.1.4}
+\contentsline {subsubsection}{\numberline {4.1.3}Versenden der eigenen Position}{14}{subsubsection.4.1.3}
+\contentsline {subsubsection}{\numberline {4.1.4}Empfangen von Positionen}{15}{subsubsection.4.1.4}
\contentsline {subsubsection}{\numberline {4.1.5}Erzeugen eines 2D-Barcodes}{16}{subsubsection.4.1.5}
-\contentsline {subsection}{\numberline {4.2}Analyse}{16}{subsection.4.2}
+\contentsline {subsection}{\numberline {4.2}Analyse}{17}{subsection.4.2}
\contentsline {subsubsection}{\numberline {4.2.1}Allgemeiner Datenverkehr}{18}{subsubsection.4.2.1}
\contentsline {subsubsection}{\numberline {4.2.2}Versenden und Empfangen von Nachrichten}{18}{subsubsection.4.2.2}
\contentsline {subsubsection}{\numberline {4.2.3}Versenden und Empfangen von Positionen}{18}{subsubsection.4.2.3}
\contentsline {subsubsection}{\numberline {4.2.4}Fazit der Auswertung}{19}{subsubsection.4.2.4}
-\contentsline {section}{\numberline {5}Fazit}{20}{section.5}
+\contentsline {section}{\numberline {5}Fazit}{21}{section.5}