summaryrefslogtreecommitdiffstats
path: root/ausarbeitung
diff options
context:
space:
mode:
authorPatrick Hornecker2010-02-23 22:14:07 +0100
committerPatrick Hornecker2010-02-23 22:14:07 +0100
commit9eaae350070e4163dfb2695ac45878302832e3f3 (patch)
tree377971c59aa57a630b3a345297638be4c7de8d49 /ausarbeitung
parentfixes and tex source (diff)
downloadfriendfinder-9eaae350070e4163dfb2695ac45878302832e3f3.tar.gz
friendfinder-9eaae350070e4163dfb2695ac45878302832e3f3.tar.xz
friendfinder-9eaae350070e4163dfb2695ac45878302832e3f3.zip
tex source
Diffstat (limited to 'ausarbeitung')
-rw-r--r--ausarbeitung/Anhang.aux6
-rw-r--r--ausarbeitung/Anhang.tex1
-rw-r--r--ausarbeitung/Anhang.tex~20
-rw-r--r--ausarbeitung/Einleitung.aux2
-rw-r--r--ausarbeitung/Einleitung.tex24
-rw-r--r--ausarbeitung/Einleitung.tex.backup22
-rw-r--r--ausarbeitung/Einleitung.tex~24
-rw-r--r--ausarbeitung/Erklaerung.aux2
-rw-r--r--ausarbeitung/Fazit.aux8
-rw-r--r--ausarbeitung/Fazit.tex15
-rw-r--r--ausarbeitung/Fazit.tex~2
-rw-r--r--ausarbeitung/Friend_Finder.aux23
-rw-r--r--ausarbeitung/Friend_Finder.tex186
-rw-r--r--ausarbeitung/Friend_Finder.tex.backup220
-rw-r--r--ausarbeitung/Friend_Finder.tex~196
-rw-r--r--ausarbeitung/Grundlagen.aux17
-rw-r--r--ausarbeitung/Grundlagen.tex228
-rw-r--r--ausarbeitung/Grundlagen.tex.backup249
-rw-r--r--ausarbeitung/Grundlagen.tex~227
-rw-r--r--ausarbeitung/Title.aux2
-rw-r--r--ausarbeitung/Tutorial.aux2
-rw-r--r--ausarbeitung/Tutorial.tex101
-rw-r--r--ausarbeitung/Tutorial.tex.backup100
-rw-r--r--ausarbeitung/Tutorial.tex~100
-rw-r--r--ausarbeitung/literature.bib31
-rw-r--r--ausarbeitung/literature.bib.backup70
-rw-r--r--ausarbeitung/literature.bib~39
-rw-r--r--ausarbeitung/maindoc.aux23
-rw-r--r--ausarbeitung/maindoc.bbl23
-rw-r--r--ausarbeitung/maindoc.blg67
-rw-r--r--ausarbeitung/maindoc.log374
-rw-r--r--ausarbeitung/maindoc.out3
-rw-r--r--ausarbeitung/maindoc.pdfbin1496046 -> 1475283 bytes
-rw-r--r--ausarbeitung/maindoc.tex1
-rw-r--r--ausarbeitung/maindoc.tex~3
-rw-r--r--ausarbeitung/maindoc.toc19
36 files changed, 1217 insertions, 1213 deletions
diff --git a/ausarbeitung/Anhang.aux b/ausarbeitung/Anhang.aux
index c7ea42a..3bb2fdb 100644
--- a/ausarbeitung/Anhang.aux
+++ b/ausarbeitung/Anhang.aux
@@ -1,6 +1,6 @@
\relax
\@setckpt{Anhang}{
-\setcounter{page}{35}
+\setcounter{page}{33}
\setcounter{equation}{0}
\setcounter{enumi}{0}
\setcounter{enumii}{0}
@@ -14,13 +14,13 @@
\setcounter{subsubsection}{4}
\setcounter{paragraph}{0}
\setcounter{subparagraph}{0}
-\setcounter{figure}{6}
+\setcounter{figure}{5}
\setcounter{table}{0}
\setcounter{NAT@ctr}{0}
\setcounter{parentequation}{0}
-\setcounter{Item}{0}
\setcounter{lstlisting}{0}
\setcounter{lstnumber}{1}
+\setcounter{Item}{0}
\setcounter{subfigure}{0}
\setcounter{lofdepth}{1}
\setcounter{subtable}{0}
diff --git a/ausarbeitung/Anhang.tex b/ausarbeitung/Anhang.tex
index 07efc57..878d84b 100644
--- a/ausarbeitung/Anhang.tex
+++ b/ausarbeitung/Anhang.tex
@@ -14,6 +14,7 @@ Systemverzeichniss entpackt werden.\newline
Bevor man mit dem nächsten Schritt fortfahren kann, müssen noch ein paar benötigte Packete aus dem Ubuntu-Repository installiert
werden.
+%\begin + end{listings
\begin{verbatim}
sudo apt-get install build-essential make gcc bison flex subversion
autoconf libtool gettext libfreetype6-dev libpng12-dev zlib1g-dev
diff --git a/ausarbeitung/Anhang.tex~ b/ausarbeitung/Anhang.tex~
index f1e709d..83efac2 100644
--- a/ausarbeitung/Anhang.tex~
+++ b/ausarbeitung/Anhang.tex~
@@ -14,13 +14,13 @@ Systemverzeichniss entpackt werden.\newline
Bevor man mit dem nächsten Schritt fortfahren kann, müssen noch ein paar benötigte Packete aus dem Ubuntu-Repository installiert
werden.
-\begin{verbatim}
+\begin{lstlisting}
sudo apt-get install build-essential make gcc bison flex subversion
autoconf libtool gettext libfreetype6-dev libpng12-dev zlib1g-dev
libjpeg-dev libtiff-dev libungif4-dev librsvg2-dev xorg-dev
libltdl3-dev libcurl4-dev cvs subversion git-core doxygen proj
libsqlite3-0 libsqlite3-dev
-\end{verbatim}
+\end{lstlisting}
Nachdem diese Pakete installiert wurden kann man sich nun die einzelnen Packete aus dem \textit{Subversion-Repository} der
Entwickler herunterladen.\newline
@@ -359,13 +359,13 @@ Mobile Gerät kopiert und entpackt werden.
Archive für \textit{Eet}:
\begin{itemize}
\item zlib-1.2.3-bin.tar.bz2:
-\newline \url{http://sourceforge.net/projects/cegcc/files/ported\\%20packages/zlib-1.2.3/zlib-1.2.3-bin.tar.bz2/download}
+\newline \url{http://sourceforge.net/projects/cegcc/files/ported%20packages/zlib-1.2.3/zlib-1.2.3-bin.tar.bz2/download}
\item zlib-1.2.3-dev.tar.bz2:
-\newline \url{http://sourceforge.net/projects/cegcc/files/ported\\%20packages/zlib-1.2.3/zlib-1.2.3-dev.tar.bz2/download}
+\newline \url{http://sourceforge.net/projects/cegcc/files/ported%20packages/zlib-1.2.3/zlib-1.2.3-dev.tar.bz2/download}
\item libjpeg-6b-bin.tar.bz2:
-\newline \url{http://sourceforge.net/projects/cegcc/files/ported\\%20packages/libjpeg-6b/libjpeg-6b-bin.tar.bz2/download}
+\newline \url{http://sourceforge.net/projects/cegcc/files/ported%20packages/libjpeg-6b/libjpeg-6b-bin.tar.bz2/download}
\item libjepg-6b-dev.tar.bz2:
-\newline \url{http://sourceforge.net/projects/cegcc/files/ported\\%20packages/libjpeg-6b/libjpeg-6b-dev.tar.bz2/download}
+\newline \url{http://sourceforge.net/projects/cegcc/files/ported%20packages/libjpeg-6b/libjpeg-6b-dev.tar.bz2/download}
\end{itemize}
\subsection*{Anhang 3}
@@ -373,13 +373,13 @@ Archive für \textit{Eet}:
Archive für \textit{Evas}:
\begin{itemize}
\item freetype-2.3.7-bin.tar.bz2:
-\newline \url{http://sourceforge.net/projects/cegcc/files/ported\\%20packages/freetype-2.3.7/freetype-2.3.7-bin.tar.bz2/download}
+\newline \url{http://sourceforge.net/projects/cegcc/files/ported%20packages/freetype-2.3.7/freetype-2.3.7-bin.tar.bz2/download}
\item freetype-2.3.7-dev.tar.bz2:
-\newline \url{http://sourceforge.net/projects/cegcc/files/ported\\%20packages/freetype-2.3.7/freetype-2.3.7-dev.tar.bz2/download}
+\newline \url{http://sourceforge.net/projects/cegcc/files/ported%20packages/freetype-2.3.7/freetype-2.3.7-dev.tar.bz2/download}
\item libpng-1.2.33-bin.tar.bz2:
-\newline \url{http://sourceforge.net/projects/cegcc/files/ported\\%20packages/libpng-1.2.33/libpng-1.2.33-bin.tar.bz2/download}
+\newline \url{http://sourceforge.net/projects/cegcc/files/ported%20packages/libpng-1.2.33/libpng-1.2.33-bin.tar.bz2/download}
\item libpng-1.2.33-dev.tar.bz2:
-\newline \url{http://sourceforge.net/projects/cegcc/files/ported\\%20packages/libpng-1.2.33/libpng-1.2.33-dev.tar.bz2/download}
+\newline \url{http://sourceforge.net/projects/cegcc/files/ported%20packages/libpng-1.2.33/libpng-1.2.33-dev.tar.bz2/download}
\end{itemize}
\subsection*{Anhang 4}
diff --git a/ausarbeitung/Einleitung.aux b/ausarbeitung/Einleitung.aux
index 06e6eca..f3dcbce 100644
--- a/ausarbeitung/Einleitung.aux
+++ b/ausarbeitung/Einleitung.aux
@@ -19,9 +19,9 @@
\setcounter{table}{0}
\setcounter{NAT@ctr}{0}
\setcounter{parentequation}{0}
-\setcounter{Item}{0}
\setcounter{lstlisting}{0}
\setcounter{lstnumber}{1}
+\setcounter{Item}{0}
\setcounter{subfigure}{0}
\setcounter{lofdepth}{1}
\setcounter{subtable}{0}
diff --git a/ausarbeitung/Einleitung.tex b/ausarbeitung/Einleitung.tex
index 77806d1..a368adf 100644
--- a/ausarbeitung/Einleitung.tex
+++ b/ausarbeitung/Einleitung.tex
@@ -1,18 +1,22 @@
\section{Einleitung}
-Durch den fortschreitenden Stand der modernen Technik ist es möglich immer leistungsstärkere, mobile Geräte zu bauen. So geht die
+Durch den fortschreitenden Entwicklung der modernen Technik ist es möglich immer
+leistungsstärkere, mobile Geräte zu bauen. So geht die
Funktionalität moderner Handys weit über das Telefonieren und Schreiben von SMS hinaus. Aktuellen Modellen, dieser sogennanten
Smartphones, ist es zum Beispiel möglich sich mit einem \textit{WLAN} zu verbinden, die eigene Position mittels \textit{GPS} zu
-ermitteln oder per \textit{3G}-Standart Daten zu übertragen.\newline
+ermitteln oder per \textit{3G}-Standard Daten zu übertragen.\newline
Aus dieser Fülle an Funktionen und den verschiedenen angebotenen Smartphones ergibt sich somit eine immense Menge an möglichen
Anwendungsgebieten. \newline
-Auch positionsabhängige Dienste verbreiten sich, dank \textit{GPS}-Funktionen der Smartphones, immer weiter. So ist es mit
+Auch positionsabhängige Dienste verbreiten sich, dank \textit{GPS}-Funktionen der
+Smartphones, immer weiter. So ist es mit
bestimmten Programmen zum Beispiel möglich eine zurückgelegte Strecke zu speichern oder den nächsten Supermarkt in der Nähe
anzuzeigen. Allerdings kann die so entstehende Datenflut auch anderweitig genutzt werden. So können anhand der Orte, an denen
-sich der Nutzer befindet, gezielt Werbung platzieren werden, oder die Positionsdaten können über die Zeit gespeichert werden und
-es werden Bewegungsprofile des Benutzers erstellt.\newline
-Dienste dieser Art können also einen nützlichen Dienst erbringen, allerdings können Daten dieser Art auch Missbraucht werden.
-Es ist also wichtig das die Daten der Benutzer als ein Teil ihrer Privatsphäre angesehen und auch nur so genutzt werden.\newline
-Dies zu ermöglichen ist das Ziel dieser Arbeit. Es soll eine Anwendung entworfen und implementiert werden, welche die
-Positionsdaten der Anwender schützt, dabei aber die volle Funktionalität wahrt. Des weiteren soll sie auf möglichst vielen
-Plattformen von mobilen Geräte lauffähig sein.
+sich der Anwender befindet, gezielt Werbung platzieren werden, oder die Positionsdaten können über die Zeit gespeichert und
+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
diff --git a/ausarbeitung/Einleitung.tex.backup b/ausarbeitung/Einleitung.tex.backup
index 8521b61..06f13ad 100644
--- a/ausarbeitung/Einleitung.tex.backup
+++ b/ausarbeitung/Einleitung.tex.backup
@@ -1,14 +1,20 @@
\section{Einleitung}
-Durch den fortschreitenden Stand der modernen Technik ist es möglich immer leistungsstärkere, mobile Geräte zu bauen. So geht die
-Funktionalität moderner Handys weit über das Telefonieren und Schreiben von SMS hinaus. Aktuelle Modelle, dieser sogennanten
+Durch den fortschreitenden Entwicklung der modernen Technik ist es möglich immer
+leistungsstärkere, mobile Geräte zu bauen. So geht die
+Funktionalität moderner Handys weit über das Telefonieren und Schreiben von SMS hinaus. Aktuellen Modellen, dieser sogennanten
Smartphones, ist es zum Beispiel möglich sich mit einem \textit{WLAN} zu verbinden, die eigene Position mittels \textit{GPS} zu
-ermitteln oder per \textit{3G}-Standart Daten zu übertragen.\newline
+ermitteln oder per \textit{3G}-Standard Daten zu übertragen.\newline
Aus dieser Fülle an Funktionen und den verschiedenen angebotenen Smartphones ergibt sich somit eine immense Menge an möglichen
Anwendungsgebieten. \newline
-Auch positionsabhängige Dienste verbreiten sich, dank \textit{GPS}-Funktionen der Smartphones, immer weiter. So ist es mit
+Auch positionsabhängige Dienste verbreiten sich, dank \textit{GPS}-Funktionen der
+Smartphones, immer weiter. So ist es mit
bestimmten Programmen zum Beispiel möglich eine zurückgelegte Strecke zu speichern oder den nächsten Supermarkt in der Nähe
-anzuzeigen. So können sie anhand der Orte, an denen sich der Nutzer befindet, gezielt Werbung platzieren. Wenn Positionsdaten über
-die Zeit gespeichert werden, kann ein Anbieter in der Lage sein ein Bewegungsprofil des Benutzers zu erstellen.\newline
-Dienste dieser Art können also einen nützlichen Dienst erbringen, allerdings können Daten dieser Art auch Missbraucht werden.
-Wenn die Anwender solcher Software mit ihren Daten zu leichtfertig umgehen oder die Anbieter die
+anzuzeigen. Allerdings kann die so entstehende Datenflut auch anderweitig genutzt werden. So können anhand der Orte, an denen
+sich der Anwender befindet, gezielt Werbung platzieren werden, oder die Positionsdaten können über die Zeit gespeichert und
+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 das Versenden von Positionsdaten, ohne das diese frei zugänglich sind und missbraucht werden können.
+Das heißt mehrere Teilnehmer können sich ihren Standort in einem sicheren Kontext senden.
diff --git a/ausarbeitung/Einleitung.tex~ b/ausarbeitung/Einleitung.tex~
index 15687d1..b9c10df 100644
--- a/ausarbeitung/Einleitung.tex~
+++ b/ausarbeitung/Einleitung.tex~
@@ -1,18 +1,22 @@
\section{Einleitung}
-Durch den fortschreitenden Stand der modernen Technik ist es möglich immer leistungsstärkere, mobile Geräte zu bauen. So geht die
+Durch den fortschreitenden Entwicklung der modernen Technik ist es möglich immer
+leistungsstärkere, mobile Geräte zu bauen. So geht die
Funktionalität moderner Handys weit über das Telefonieren und Schreiben von SMS hinaus. Aktuellen Modellen, dieser sogennanten
Smartphones, ist es zum Beispiel möglich sich mit einem \textit{WLAN} zu verbinden, die eigene Position mittels \textit{GPS} zu
-ermitteln oder per \textit{3G}-Standart Daten zu übertragen.\newline
+ermitteln oder per \textit{3G}-Standard Daten zu übertragen.\newline
Aus dieser Fülle an Funktionen und den verschiedenen angebotenen Smartphones ergibt sich somit eine immense Menge an möglichen
Anwendungsgebieten. \newline
-Auch positionsabhängige Dienste verbreiten sich, dank \textit{GPS}-Funktionen der Smartphones, immer weiter. So ist es mit
+Auch positionsabhängige Dienste verbreiten sich, dank \textit{GPS}-Funktionen der
+Smartphones, immer weiter. So ist es mit
bestimmten Programmen zum Beispiel möglich eine zurückgelegte Strecke zu speichern oder den nächsten Supermarkt in der Nähe
anzuzeigen. Allerdings kann die so entstehende Datenflut auch anderweitig genutzt werden. So können anhand der Orte, an denen
-sich der Nutzer befindet, gezielt Werbung platzieren werden, oder die Positionsdaten können über die Zeit gespeichert werden und
-es werden Bewegungsprofile des Benutzers erstellt.\newline
-Dienste dieser Art können also einen nützlichen Dienst erbringen, allerdings können Daten dieser Art auch Missbraucht werden.
-Es ist also wichtig das die Daten der Benutzer als ein Teil ihrer Privatsphäre angesehen und auch nur so genutzt werden.\newline
-Dies zu ermöglichen ist das Ziel dieser Arbeit. Es soll eine Anwendung entworfen und implementiert werden, welche die
-Positionsdaten der Anwender schützt, dabei aber die volle Funktionalität wahrt. Des weiteren soll sie auf möglichst vielen
-Plattformen der mobilen Geräte lauffähig sein.
+sich der Anwender befindet, gezielt Werbung platzieren werden, oder die Positionsdaten können über die Zeit gespeichert und
+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 trotz allem 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/Erklaerung.aux b/ausarbeitung/Erklaerung.aux
index db9382f..9de6922 100644
--- a/ausarbeitung/Erklaerung.aux
+++ b/ausarbeitung/Erklaerung.aux
@@ -18,9 +18,9 @@
\setcounter{table}{0}
\setcounter{NAT@ctr}{0}
\setcounter{parentequation}{0}
-\setcounter{Item}{0}
\setcounter{lstlisting}{0}
\setcounter{lstnumber}{1}
+\setcounter{Item}{0}
\setcounter{subfigure}{0}
\setcounter{lofdepth}{1}
\setcounter{subtable}{0}
diff --git a/ausarbeitung/Fazit.aux b/ausarbeitung/Fazit.aux
index 3fb63a2..1ba57ac 100644
--- a/ausarbeitung/Fazit.aux
+++ b/ausarbeitung/Fazit.aux
@@ -1,7 +1,7 @@
\relax
-\@writefile{toc}{\contentsline {section}{\numberline {5}Fazit}{22}{section.5}}
+\@writefile{toc}{\contentsline {section}{\numberline {5}Fazit}{20}{section.5}}
\@setckpt{Fazit}{
-\setcounter{page}{23}
+\setcounter{page}{21}
\setcounter{equation}{0}
\setcounter{enumi}{0}
\setcounter{enumii}{0}
@@ -15,13 +15,13 @@
\setcounter{subsubsection}{4}
\setcounter{paragraph}{0}
\setcounter{subparagraph}{0}
-\setcounter{figure}{6}
+\setcounter{figure}{5}
\setcounter{table}{0}
\setcounter{NAT@ctr}{0}
\setcounter{parentequation}{0}
-\setcounter{Item}{0}
\setcounter{lstlisting}{0}
\setcounter{lstnumber}{1}
+\setcounter{Item}{0}
\setcounter{subfigure}{0}
\setcounter{lofdepth}{1}
\setcounter{subtable}{0}
diff --git a/ausarbeitung/Fazit.tex b/ausarbeitung/Fazit.tex
index 629ccfb..60602c2 100644
--- a/ausarbeitung/Fazit.tex
+++ b/ausarbeitung/Fazit.tex
@@ -1,17 +1,2 @@
\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
diff --git a/ausarbeitung/Fazit.tex~ b/ausarbeitung/Fazit.tex~
index 22d6e42..629ccfb 100644
--- a/ausarbeitung/Fazit.tex~
+++ b/ausarbeitung/Fazit.tex~
@@ -13,5 +13,5 @@ somit stark eingeschränkt und diese können nicht mehr ohne weiteres eingesehen
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 benutzen, zum Beispiel den \textit{POSIX-Layer} könnte es in der Zukunft
+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
diff --git a/ausarbeitung/Friend_Finder.aux b/ausarbeitung/Friend_Finder.aux
index c9c6047..f0ab058 100644
--- a/ausarbeitung/Friend_Finder.aux
+++ b/ausarbeitung/Friend_Finder.aux
@@ -1,32 +1,31 @@
\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}}
-\citation{blowfish}
-\citation{OpenSSL}
\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces \textit {Friend Finder} Nachrichtenaustausch}}{14}{figure.3}}
\citation{libircclient}
\citation{OpenSSL}
\@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.3}Versenden der eigenen Position}{16}{subsubsection.4.1.3}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.4}Empfangen der eigenen Position}{16}{subsubsection.4.1.4}}
\@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{toc}{\contentsline {subsection}{\numberline {4.2}Analyse}{17}{subsection.4.2}}
-\citation{xchat}
\@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}{19}{subsubsection.4.2.2}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.3}Versenden und Empfangen von Positionen}{19}{subsubsection.4.2.3}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.4}Fazit der Auswertung}{20}{subsubsection.4.2.4}}
-\@writefile{lof}{\contentsline {figure}{\numberline {6}{\ignorespaces Vergleich von n-Verbindungen und \textit {Friend Finder}}}{21}{figure.6}}
+\@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}}
\@setckpt{Friend_Finder}{
-\setcounter{page}{22}
+\setcounter{page}{20}
\setcounter{equation}{0}
\setcounter{enumi}{0}
\setcounter{enumii}{0}
@@ -40,13 +39,13 @@
\setcounter{subsubsection}{4}
\setcounter{paragraph}{0}
\setcounter{subparagraph}{0}
-\setcounter{figure}{6}
+\setcounter{figure}{5}
\setcounter{table}{0}
\setcounter{NAT@ctr}{0}
\setcounter{parentequation}{0}
-\setcounter{Item}{0}
\setcounter{lstlisting}{0}
\setcounter{lstnumber}{1}
+\setcounter{Item}{0}
\setcounter{subfigure}{0}
\setcounter{lofdepth}{1}
\setcounter{subtable}{0}
diff --git a/ausarbeitung/Friend_Finder.tex b/ausarbeitung/Friend_Finder.tex
index 2bbaa73..ea0d0b1 100644
--- a/ausarbeitung/Friend_Finder.tex
+++ b/ausarbeitung/Friend_Finder.tex
@@ -1,23 +1,21 @@
\section{Friend Finder}
-Die Eingangs beschriebene Software trägt den Namen \textit{Friend Finder} und wurde im Rahmen dieser Arbeit mit fast allen
+Die beschriebene Software trägt den Namen \textit{Friend Finder} und wurde im Rahmen dieser Arbeit mit allen
aufgezählten Funktionen realisiert. Im folgenden wird auf die verwendeten Verfahren sowie Bibliotheken, die zur Realisierung
-notwendig waren, eingegangen.
+notwendig waren, eingegangen und die Programmstruktur aufgezeigt.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Verwendete Verfahren und Bibliotheken}
-\textit{Friend Finder} wurde so konzipiert, dass die Graphische Darstellung ohne großen Aufwand vom den restlichen
-Teilen der Software abgekoppelt und durch eine andere, darstellende Bibliothek ersetzt werden kann. Somit
-könnte man \textit{Enlightenment} durch eine andere Art der Darstellung austauschen, ohne dabei die Funktionalität der
-zugrunde liegenden Komponenten zu zerstören. \newline
-Da das Ver- und Entschlüsseln der Daten möglichst wenig Rechenaufwand erzeugen und der Schlüsselaustausch nicht zu
-kompliziert sein soll, nutzt das Programm ein symmetrisches Verschlüsselungsverfahren. \newline
-\textit{Abbildung 3} zeigt den Kommunikationsaustausch von \textit{Friend Finder}. Der \textit{Message Sender} ist für das
-Versenden und Empfangen der Textnachrichten zuständig, \textit{Sender} sendet die eigene Position, \textit{Receiver} empfängt
-die Positionen der anderen Nutzer und sendet Acknowledgements an die teilnehmenden \textit{Sender}. Alle drei Teile geben ihre
-empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{Enlightenment} ausgibt.
+\textit{Friend Finder} wurde so konzipiert, dass die Graphische Darstellung ohne großen Aufwand von den restlichen
+Teilen der Software abgekoppelt und durch eine andere Art der Darstellung ersetzt werden kann. Würde \textit{Enlightenment}
+austauschen, würde die Funktionsweise der zugrundeliegenden Komponenten zu verändern. \newline
+Neben dem \textit{Graphical User Interface (GUI)} besteht die Software aus drei unterschiedlichen Modulen. Der \textit{Message
+Sender} ist für das Versenden und Empfangen der Textnachrichten zuständig, \textit{Sender} sendet die eigene Position,
+\textit{Receiver} empfängt die Positionen der anderen Nutzer und sendet Acknowledgements an die teilnehmenden \textit{Sender}.
+Alle drei Teile geben ihre empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{Enlightenment} ausgibt.
+\textit{Abbildung 3} zeigt den Kommunikationsaustausch von \textit{Friend Finder}.
\begin{figure}[!ht]
\centering
@@ -29,13 +27,11 @@ empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{E
Zum Erstellen der Oberfläche wurde \textit{Enlightenment} verwendet. Diese Bibliothek stellt alle benötigten Funktionen bereit und
bietet eine Fülle an vordefinierten Bedienelement. Der gesammte Programmcode der Benutzeroberfläche wurde in einer Datei
-zusammengefast (\textit{gui.c}). Diese Tatsache vereinfacht das Erhalten der Modularität, da nur diese Datei
-durch eine andere ersetzt werden muss um einen anderen Typ von Oberfläche zu nutzen. \newline
-In der der Datei \textit{gui.c} sind alle Funktionen enthalten um die Oberflächenelement zu erzeugen und zu platzieren. Um die
-gewünschte Funktionalität der einzelnen Elemente zu realisieren wurden auch die Aufrufe der benötigten Funktionen aus anderen
+zusammengefast (\textit{gui.c}). \newline
+In dieser Datei sind alle Funktionen enthalten um die Oberflächenelement zu platzieren. Um die gewünschte Funktionalität der
+einzelnen Elemente zu realisieren wurden auch die Aufrufe der benötigten Funktionen aus anderen
Modulen in dieser Datei implementiert. \newline
-Wie schon erwähnt, wurde die Graphische Nutzeroberfläche mit Hilfe von Bibliotheken aus dem \textit{Elementary}-Paket
-realisiert. Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap} \citep{OSM} genutzt.
+Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap} \citep{OSM} genutzt.
\subsubsection{Versenden der Nachrichten}
@@ -46,20 +42,21 @@ Stabilität. Ein weiterer Vorteil ist, dass man Daten die an mehrere Benutzer ge
In der Datei \textit{msg\_sender.c} sind alle Funktionen und Aufrufe implementiert, welche nötig sind um die Verbindung zum
\textit{IRC-Server} zu erstellen und die Nachrichten zu verschicken. Um eine Verbindung zu einem gegebenen \textit{IRC-Server} zu
-erstellen muss eine \textit{IRC-Session} initialisiert werden. Diese \textit{Session} beinhaltet Informationen wie zum Beispiel
+etablieren, muss eine \textit{IRC-Session} initialisiert werden. Diese \textit{Session} beinhaltet Informationen wie zum Beispiel
den \textit{Nickname} des Benutzers oder die \textit{IP-Adresse} des Servers. Nachdem diese \textit{Session} gestartet wurde,
-kann man nun durch das Aufrufen der Funktion ``\textit{set\_txt\_msg(char* msg)}'' die Nachricht versenden. Wird eine Nachricht
-empfangen so wird diese an die Funktion ``\textit{show\_message(char* msg)}`` , welche zur Benutzeroberfläche gehört, übergeben.
+können nun Nachrichten versandt werden. Wird eine Nachricht empfangen so wird diese an die Benutzeroberfläche weitergereicht.
Bei der Implementerierung des Nachrichtenversandes ist eine Besonderheit zu erwähnen. Das genutzte Verschlüsselungsverfahren
\textit{Blowfish} \citep{blowfish} wurde seitens der \textit{OpenSSL}\citep{OpenSSL} Bibliothek als \textit{Blockcipher}
-implementiert. \textit{Blowfish} wurde Aufgrund der schnellen verschlüsselungsrate sowie einfachen Implementierung gewählt und
+implementiert. \textit{Blowfish} wurde Aufgrund der schnellen Verschlüsselungsrate sowie einfachen Implementierung gewählt und
ist ein symmetrisches Verschlüsselungsverfahren. Das bedeutet, das immer nur maximal 64 Bit Nachrichten verschlüsselt werden
-können. Da in der Programmiersprache \textit{C} dies genau acht ASCII-Zeichen entspricht, werden alle zu sendenden Nachrichten in
-Blöcke der Größe acht aufgeteilt, versandt und beim Empfänger wieder zusammengesetzt. \newline
+können. Aufgrund dieser Restriktion werden Textnachrichten in Blöcke der Zeichenlänge 6 aufgeteilt und anschliessend
+versandt. Um den die Codierung der Verschlüsselten Nachrichten zu erhalten werden alle versendeten Daten des Programmes in die
+\textit{Base64} \citep{base64} Darstellung umgewandelt. Dies ist notwendig, da die verschiedenen \textit{IRC}-Server
+unterschiedliche Zeichenkodierungen nutzen können.\newline
Ein weiterer wichtiger Unterschied zu den Modulen Senden und Empfangen von \textit{GPS}-Positionen ist die Tatsache, dass bei
diesem Programmteil Sender und Empfänger in der gleichen Datei implementiert wurden. Der Grund hierfür ist, dass man hier nicht
zwischen mehreren Sendern oder Empfängern unterscheiden muss, und diese zwei Teile hier somit nicht komplett getrennt voneinander
-arbeiten müssen. In der folgenden Abbildung ist eine Konversation über \textit{Friend Finder} zu sehen.\newline
+arbeiten müssen. In der folgenden Abbildung ist eine Textkonversation mit \textit{Friend Finder} zu sehen.\newline
\begin{figure}[!ht]
\centering
@@ -71,9 +68,7 @@ Um Nachrichten zu versenden wurde für dieses Projekt die \textit{IRC-Client Bib
Bibliothek bietet verschiedene Funktionen um eine Verbindung mit einem \textit{IRC-Server} zu erstellen und Nachrichten an
diesen zu senden, sowie eingehende Nachrichten zu empfangen.\newline
Zur Ver- und Entschlüsselung der gesendeten Nachrichten, sowie der Positionsdaten, wird die Bibliothek
-des \textit{OpenSSL-Projekts}\citep{OpenSSL}, namens \textit{libcrypto}, verwendet. Hierzu werden die Daten mit dem
-\textit{Blowfish-Algorithmus} verschlüsselt. Bei diesem Algorithmus handelt es sich um ein symmetrisches
-Verfahren, bei welchem alle Teilnehmer den gleichen privaten Schlüssel zum ver- sowie entschlüsseln nutzen.
+des \textit{OpenSSL-Projekts}\citep{OpenSSL}, namens \textit{libcrypto}, verwendet.
\subsubsection{Versenden der eigenen Position}
@@ -84,34 +79,28 @@ Allerdings muss auch hier, wie beim Versenden der Textnachrichten, darauf geacht
Länge 8 Byte verschlüsselt wird. Somit ist es auch hier nötig Längen- und Breitengrad in zwei Teile aufzuteilen und getrennt zu
versenden. Es werden für das Versenden einer Position insgesamt vier Nachrichten an den \textit{IRC}-Server übermittelt.
Wurden diese vier Nachrichten übermittelt, so werden solange keine Daten mehr gesendet, bis der Empfänger eine
-Bestätigung an den \textit{IRC-Kanal} sendet. Diese Bestätigung wird ebenfalls verschlüsselt versandt. Kommt dieses
-\textit{Acknowledgement} beim Sender an, so versendet dieser wieder ein \textit{Latitude/Longtitude} Paar.\newline
+Bestätigung für jedes Fragment an den \textit{IRC-Kanal} sendet. Diese Bestätigungen werden ebenfalls verschlüsselt versandt.
+Kommt dieses \textit{Acknowledgement} beim Sender an, so versendet dieser wieder ein \textit{Latitude/Longtitude} Paar.\newline
Auch hier wird, wie beim Versenden der Nachrichten zum Verschlüsseln der \textit{Blowfish-Algorithmus} aus
\textit{libcrypto}, sowie \textit{libircclient} zum versenden der Daten genutzt.
\subsubsection{Empfangen der eigenen Position}
-Das Verhalten des Empfängers beim Erhalten einer Nachricht ist etwas komplizierter. Im ersten Schritt muss auch hier eine
-\textit{IRC-Session} initialisiert werden. Da mehrere Benutzer Positionsdaten senden können legt der Empfänger für jeden Sender
-einen Datensatz an. Dieser wird nach und nach mit den Positionsdaten gefüllt und die benötigten Daten weitergegeben, sobald alle
-vorhanden sind. Da der Sender seine Daten, aufgrund der Restrektion der Länge der zu verschlüsselnden Zeichenkette, gestückelt
-sendet ist es von Nöten, dass der Empfänger die Daten dem jeweiligen Absender zuordnen kann und diese auch wieder korrekt
-zusammensetzt. Um die einzelnen Fragmente wieder zuzordnen, werden an diese vor dem versenden Terminierungszeichen angefügt,
-welche zum Beispiel eindeutig als ersten Teil einer \textit{Longtitude}-Koordinate identifizieren. Wenn diese wieder zugeordnet
-wurden und sowohl \textit{Latitude} als auch \textit{Longtitude} Informationen vorhanden sind, werden diese Position
-an das Frontend weitergegeben. \newline
+Im ersten Schritt muss auch hier eine \textit{IRC-Session} initialisiert werden. Da mehrere Benutzer Positionsdaten senden können
+legt der Empfänger für jeden Sender einen Datensatz an. Dieser wird nach und nach mit gesendeten Fragmenten der Positionsdaten
+gefüllt. Sind alle Fragmente beim Empfänger angekommen so werden die benötigten Daten zur Visuallisierung weitergegeben. Um die
+einzelnen Positionsfragmente zuzordnen zu können, werden an diese vor dem versenden Terminierungszeichen angefügt. Diese
+Identifizieren zum Beispiel eindeutig einen ersten Teil einer \textit{Longtitude}-Koordinate.
Zur Realisierung des Empfängers werden die gleichen Bibliotheken wie beim Sender genutzt. Auch hier wird zur Entschlüsselung der
\textit{Blowfish-Algorithmus} von \textit{libcrypto} angewandt.
\subsubsection{Erzeugen eines 2D-Barcodes}
-Die Datei \textit{barcode.c} beinhaltet die Funktionen zum Erstellen eines 2D-Barcodes. Hierzu wird die Funktion
-``\textit{generate\_barcode(char* key)}'', mit einer Zeichenkette als Übergabeparameter, aufgerufen. Aus dieser Zeichenkette wird
-im Anschluss ein Barcode erstellt, welcher im darauf folgenden Schritt als \textit{.png} Datei auf das Speichermedium geschrieben
-wird.
-Zum erstellen des Barcodes wurde die offene Bibliothek \textit{qrencode} \citep{qrencode} genutzt. Diese erstellt aus einer
+Die Datei \textit{barcode.c} beinhaltet die Funktionen zum Erstellen eines 2D-Barcodes. Aus einer Zeichenkette wird
+ein Barcode erstellt, welcher im darauf folgenden Schritt als \textit{.png} Datei auf das Speichermedium geschrieben
+wird. Zum erstellen des Barcodes wurde die offene Bibliothek \textit{qrencode} \citep{qrencode} genutzt. Diese erstellt aus einer
Zeichenkette einen 2D-Barcode. Aus den Bilddaten dieses Barcodes wurde mit \textit{libpng} \citep{PNG} eine \textit{.png} Datei
generiert. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er von \textit{Friend Finder} ausgegeben wird.
@@ -128,99 +117,76 @@ generiert. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er v
Das Ziel war es mit \textit{Friend Finder} Daten verschlüsselt zu übertragen. Es soll dabei ein möglichst geringer
Berechnungsaufwand entstehen um die Daten zu verschlüsseln, sowie möglichst wenig Datenoverhead produziert und versendet werden.
-Unter Datenoverhead werden die Hintergrunddaten gesehen, welche versendet werden um zum Beispiel die Verbindung
-zwischen Client und Server aufrecht zu erhalten oder um zu kontrollieren ob Server oder Client noch verfügbar sind. Diese Daten
- sind von Interesse da mit vielen versendeten Daten ein höherer Anspruch des Rechenkerns einhergeht, was wiederrum in einem
+Unter Datenoverhead werden Hintergrunddaten gesehen, welche versendet werden um zum Beispiel die Verbindung zwischen Client und
+Server aufrecht zu erhalten oder um zu kontrollieren ob Server oder Client noch verfügbar sind. Diese Daten
+sind von Interesse da mit vielen versendeten Daten ein höherer Anspruch des Rechenkerns einhergeht, was wiederrum in einem
höheren Stromverbrauch resultiert.\newline
Im folgenden Teil wird der erzeugte Datenverkehr von \textit{Friend Finder} analysiert. Ein Hauptaugenmerkt wird hierbei vor allem
auf die Packetgröße, sowie die Menge der versendeten Datenpakete geworfen. Der \textit{Traffic} wurde mit Hilfe des Programmes
\textit{Wireshark} \citep{Wireshark} untersucht.Wie bereits erwähnt wird zum Versenden der Nachrichten das \textit{IRC-Protokoll}
verwendet. In dieser Testumgebung wurde die Software \textit{IRCD-Hybrid} \citep{IRCD} genutzt. Der Server lief auf dem gleichen
-Computer wie der Client und der Client hat sich über das \textit{localhost} Interface mit dem Server verbunden. \newline
+Computer wie der Client. Der Client hat sich über das \textit{localhost} Interface mit dem Server verbunden. \newline
Die Analyse ist in drei Teile aufgeteilt. Als erstes wird auf den allgemein entstehenden Datenverkehr eingegangen, welcher
bei Verbindungsaufbau, sowie bei Beenden der Verbindung entsteht. Der zweite Teil beschäftigt sich mit dem Versenden sowie
-Empfangen von Nachrichten. Im letzten Teil dieser Analyse wird auch das dritte Feature, dass Versenden und Empfangen von
-Positionen, unter die Lupe genommen.
+Empfangen von Nachrichten. Im letzten Teil dieser Analyse wird das Versenden und Empfangen von Positionen, unter die Lupe
+genommen. Alle Größen innerhalb der Analyse beziehen sich nur auf die Größe des Datenfeldes, exklusiv der Header.
\subsubsection{Allgemeiner Datenverkehr}
-Bei Messung des allgemeinen Datenaufkommens mit eine normalen \textit{IRC-Clients}, hier \textit{X-Chat} \citep{xchat}, ergibt
-sich folgender Datenverkehr. \newline
-Beim Verbindungsaufbau sendet der \textit{IRC}-Server zuerst ein Paket mit Informationen wie Limit der \textit{Channels}
-oder Anzahl der aktiven Benutzer. Dieses Paket hatte in der Versuchsumgebung eine Größe von 1090 Bytes. Hiervon müssen noch 20
-Bytes \textit{IP-} und 32 Byte \textit{TCP-Header} abgezogen werden. Somit sind die hat das Datenfeld eine Größe von 1038 Bytes.
-Bei im folgenden genannten Paketgrößen sind diese 52 Byte schon abgezogen. \newline
-Wenn im nächsten Schritt der Benutzer nun eine \textit{Channel} beitritt, so sendet dieser drei Pakete an den Server. Diese
-beinhalten den Namen des \textit{Channels} dem beigetreten werden soll, eine Anfrage nach einer Liste der aktiven Nutzer in diesem
-\textit{Channel}sowie welche Rechte der beitretende Nutzer in diesem \textit{Channel} inne hat. Diese drei Pakete haben alle die
-Größe von 26 Byte. Ist die Verbindung zwischen Client und Server aufgebaut so sendet der Client alle 30 Sekunden ein \textit{Ping}
-Paket an den Server, welches dieser mit einem \textit{Pong} beantwortet. Diese Pakete haben eine Größe von 40 Byte für die
-\textit{Ping} Nachricht und 58 Byte für die beantwortende \textit{Pong} Nachricht. Alle 60 Sekunden versendet der Client eine
-Anfrage, welche Teilnehmer sich im \textit{Channel} befinden. Diese Nachricht von Client zu Server ist 25 Byte groß. Die Antwort
-hierzu ist abhängig von der Anzahl der Benutzer. Ist nur ein Benutzer im \textit{Channel} so ist sie 151 Bytes groß, bei zwei ist
-sie schon 233 Byte groß. Wird eine Verbindung beendet, so schickt der Client eine \textit{Quit} Nachricht an den Server.
-\newline
-
-Im Gegensatz zu diesem hohen Hintergrundverkehr benötigt \textit{Friend Finder} nur einen \textit{TCP-Handshake} um die
-Verbindung aufzubauen. Ist die Verbindung etabliert fallen keine weiteren Hintergrunddaten an. Der Nachteil hiervon ist, dass der
-Client nur bei einem auftretenden Fehler beim Versenden der Daten bemerkt, dass er nicht mehr verbunden ist. Allerdings wird
-hiermit auch Berechnungszeit und somit Akku gespart, da diese \textit{Keep-Alive} Nachrichten, sowie die zusätzliche
-Informationen über den Server im Rahmen von \textit{Friend Finder} nicht benötigt werden. Da die Positionsdaten mehrmals pro
-Minute übermittelt werden besteht somit immer Datenverkehr zwischen Sender und \textit{IRC}-Server und es kann schnell
-festgestellt werden ob eine Verbindung noch aktiv ist. \newline
+Der Allgemeine Hintergrundverkehr bei \textit{Friend Finder} besteht zum einen aus \textit{Keep-Alive} Nachrichten, sowie der
+Anfrage des Clients nach aktiven Nutzern in den \textit{Channels} in denen er selbst aktiv ist. Die \textit{Keep-Alive}
+Nachrichten werden alle 30 Sekunden zwischen Server und Client ausgetauscht. Die Größe des Datenfeldes einer
+solchen Nachricht beträgt also 24 Byte. Das Datenfeld der Pakete welche von Server an Client gesendet werden hat die Größe von 44
+Byte. \newline
+Die Anfragen nach den anderen Benutzern in einem \textit{Channel} werden alle 60 Sekunden versandt. Die Größe der Pakete welche
+von Client zu Server gesandt werden, betragen hierbei 10 Bytes. Die Größe der Antwort des Servers hängt von der Anzahl der
+aktiven Benutzer innerhalb eines Channels ab. Für zwei Benutzer ergibt sich ein Datenvolumen von 193 Byte, wobei diese
+Größe auch Abhängig von der Länge der Benutzernamen sowie des Namens des\textit{Channels} ist. \newline
\subsubsection{Versenden und Empfangen von Nachrichten}
Um das Versenden von Nachrichten zu evaluieren wurde ``Hello World`` als Testnachricht benutzt. Der \textit{Blockcipher} von
-\textit{Friend Finder} teilt den Satz "Hello World" in zwei Teile auf: ''Hello `` und ''World``. Diese werden dann von
-\textit{TCP} aufgrund der Fenstergröße in ein Paket gepackt. Das gesamte Paket hat die größe von 147 Bytes, wobei \textit{TCP-}
-und \textit{IP-Header} abgezogen werden müssen. Somit haben die Daten eine Größe von insgesamt 81 Bytes.\newline
+\textit{Friend Finder} teilt den Satz ''Hello World`` in zwei Teile auf: ''Hello `` und ''World``. Diese werden dann von
+\textit{TCP} aufgrund der Fenstergröße in ein Paket gepackt. Dieses Paket hat ein Datenfeld der Größe von 99 Byte.\newline
Beachtet man dass ein \textit{char} in \textit{C} die Größe von einem Byte hat und der Beispielsatz aus elf Zeichen besteht, so
-ist dieser unverschlüsselt 11 Byte groß. Nach der Verschlüsselung werden beim Senden noch Informationen wie der
-\textit{Channel} und der Empfänger der Nachricht in das zu versendende \textit{IRC}-Paket geschrieben. Somit vergrößert
-sich eine Textnachricht circa um den Faktor 7,4, wenn sie verschlüsselt ist und alle Zusatzinformationen hineingepakt
-wurden. \newline
+ist dieser unverschlüsselt elf Byte groß. Nach der Verschlüsselung werden beim Senden noch Informationen wie der
+\textit{Channel} und der Empfänger der Nachricht in das zu versendende \textit{IRC}-Paket geschrieben und im Anschluss die
+Konvertierung zur \textit{Base64}-Darstellung vorgenommen. Die \textit{Base64}-Darstellung vergrößert im Allgemeinen, aufgrund
+der Datenkonvertierung, das Datenvolumen um 36\%. Somit vergrößert sich eine Textnachricht circa um den Faktor $9$ sobald sie
+verschlüsselt, \textit{Base64}-kodiert und mit allen Zusatzinformationen erweitert wurde. \newline
Wenn $h$ die Größe des \textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht ist, so ergibt sie die
-ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 7,4)$.
+ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 9)$.
\subsubsection{Versenden und Empfangen von Positionen}
Wie schon erwähnt, werden die Positionsdaten beim Sender aufgeteilt und mit vier unterschiedlichen Nachrichten versandt. Wie
-beim Versenden der Textnachrichten werden diese vier Nachrichten auch hier in ein Paket gepakt. Dieses hat die Gesamtgröße
-von 235 Byte. Abzüglich der \textit{TCP-} und \textit{IP-Header} ergibt sich hier eine Datengröße von 169 Byte. Die Anzahl
-der unverschlüsselten Zeichen, die zu senden sind, beträgt 21 Zeichen. Diese sind jeweils 1 Byte groß, womit sie in der Summe
-also 21 Byte Größe haben. Durch die Verschlüsselung sowie die benötigten Zusatzinformationen, wie \textit{Channel} für
-den die Nachricht bestimmt ist, vergrößert sich das Datenvolumen also um circa den Faktor acht. Wenn $h$ die Größe des
-\textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht. Somit ergibt sich die Größe der versendeten
-Nachricht circa durch $h + (t \cdot 8)$. Hinzu kommt noch, das für jedes empfangene Positions-Fragmeint ein Acknowledgement
-gesendet wird. Somit sind nach Empfangen aller vier Positionsteile vier Acknowledgements der Größe von 124 Bytes insgesamt und 58
-Bytes an Daten ohne Header gesendet worden.\newline
-Somit kann aus Folgende Formel für den Datenverkehr über die Zeit hergeleitet werden: $((h + (t \cdot 8)) + (4 \cdot a)) \cdot n$,
-wobei $a$ die Größe eines Acknowledgement-Paketes ist und $n$ die Anzahl der versandten Pakete repräsentiert.
+beim Versenden der Textnachrichten werden diese vier Nachrichten auch hier in ein Paket gepackt. Bei der Messung wurden vier
+Verschiedene Pakete, mit jeweils unterschiedlichen versandten Positionen untersucht. Dabei betrug sich die Größe des Datenfeldes
+zwischen 431 Byte. Die Anzahl der unverschlüsselten Zeichen, die für ein \textit{Latitude}/\textit{Longtitude}-Paar zu
+senden sind, beträgt 21 Zeichen. Jedes Zeichen ist Byte groß, womit sich in der Summe eine Größe von 21 Byte ergibt.
+Durch die Verschlüsselung, \textit{Base64}-Kodierung sowie Zusatzinformationen vergrößert sich das Datenvolumen also um circa den
+Faktor zwanzig. Wenn $h$ die Größe des \textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht. Somit
+ergibt sich die Größe der versendeten Nachricht circa durch $h + (t \cdot 20)$. Hinzu kommt noch, das für jedes empfangene
+Positions-Fragmeint ein Acknowledgement gesendet wird. Die Größe der eines Acknowledgment Paketes beträgt zwischen 147 und 153
+Byte. In einem solchen Paket werden vier Acknowledgments zusammengefasst.\newline
+Folglich kann aus Folgende Formel für den Datenverkehr über die Zeit hergeleitet werden: $((h + (t \cdot 20)) + (4 \cdot a)) \cdot
+n$, wobei $a$ die Größe eines Acknowledgement-Paketes ist und $n$ die Anzahl der versandten Pakete repräsentiert.
\subsubsection{Fazit der Auswertung}
-Im Bereich des Allgemeinen Datenverkehrs fällt kein Overhead durch \textit{Friend Finder} an. Hier werden nur dann Daten
-versandt, wenn dies auch vom Nutzer so gewollt sind und auch gebraucht werden. Dies hat den Vorteil, dass der Anwender die totale
-Kontrolle über die Daten, die er sendet, hat. Allerdings kann so auch erst beim Versenden von Daten festgestellt werden, ob die
-Verbindung unterbrochen wurde, da im Hintergrund die Verbindung nicht ständig überprüft wird. Aufgrund der Tatsache, dass
-Positionsdaten mehrmals pro Minute versandt werden, ist dies aber auch nicht wirklich nötig da durch das Versenden oder
-nicht Versenden dieser Daten auch ein Verbindungsproblem festgestellt werden könnte\newline
-Ein weiterer Vorteil von \textit{Friend Finder} ist das Verschicken von Daten an mehrere Benutzer. Hier muss der
-Client sein Paket nur einmal versenden und alle teilnehmenden Nutzer in einem Channel können diese Nachricht einsehen, sofern dies
-gewollt ist. Würde man hier eine Verbindung pro Teilnehmer nutzen, so müsste man für $n$ Teilnehmer $n$ Verbindungen öffnen und
-auch $n$ Mal die Daten versenden. Dies würde ein nicht unerheblicher Berechnungsaufwand sowie Datenverkehr darstellen. Im
-Empfangen der Daten ergibt zwischen der Lösung durch \textit{Friend Finder} oder einer Verbindung pro Teilnehmer keinen
-Unterschied, da bei beiden Modellen diese Daten nur einmal empfangen werden.\newline
-In der folgenden Abbildung ist an der X-Achse die Anzahl der Teilnehmer und an der Y-Achse die Anzahl der zu versendenden
-Dateneineheiten abgetragen. Hier ist deutlich zu sehen, dass bei steigender Teilnehmer Anzahl eine Lösung mit einer offenen
-Verbindung pro Benutzer soviel Datenpakete wie Nutzer versenden muss. Bei der Lösung mit einem zentralen \textit{Channel} müssen
-die Daten immer nur einmal versandt werden, unabhängig von der Nutzeranzahl.
+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} \ No newline at end of file
+%\end{figure}
diff --git a/ausarbeitung/Friend_Finder.tex.backup b/ausarbeitung/Friend_Finder.tex.backup
index 1f497e5..3519707 100644
--- a/ausarbeitung/Friend_Finder.tex.backup
+++ b/ausarbeitung/Friend_Finder.tex.backup
@@ -1,28 +1,25 @@
\section{Friend Finder}
-Die eingangs beschriebene Software hat den Namen \textit{Friend Finder} und wurde im Rahmen dieser Arbeit mit fast allen
-aufgezählten Funktionen realisiert. Das fotographieren des Barcodes, der Gruppenchat sowie das Setzen von Marken auf der Kartesind
-in der Implementation nicht enthalten. Im folgenden wird auf die Verwendeten Verfahren sowie Bibliotheken, die zur Realisierung
-notwendig waren, eingegangen.
+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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Verwendete Verfahren und Bibliotheken}
-\textit{Friend Finder} wurde so konzipiert, dass die Graphische Darstellung ohne großen Aufwand vom den restlichen
-Teilen der Software abgekoppelt und durch eine andere, darstellende Bibliothek ersetzt werden kann. Somit
-könnte man \textit{Enlightenment} durch eine andere Art der Darstellung austauschen, ohne dabei die Funktionalität der
-zugrunde liegenden Komponenten zu zerstören. \newline
-Da das Ver- und Entschlüsseln der Daten möglichst wenig Rechenaufwand erzeugen und der Schlüsselaustausch nicht zu
-kompliziert sein soll, nutzt das Programm ein symmetrisches Verschlüsselungsverfahren. \newline
-\textit{Abbildung 3} zeigt den Kommunikationsaustausch von \textit{Friend Finder}. Der \textit{Message Sender} ist für das
-Versenden und Empfangen der Textnachrichten zuständig, \textit{Sender} sendet die eigene Position, \textit{Receiver} empfängt
-die Positionen der anderen Nutzer und sendet Acknowledgements an die teilnehmenden \textit{Sender}. Alle drei Teile geben ihre
-empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{Enlightenment} ausgibt.
-
-\begin{figure}[h]
+\textit{Friend Finder} wurde so konzipiert, dass die Graphische Darstellung ohne großen Aufwand von den restlichen
+Teilen der Software abgekoppelt und durch eine andere Art der Darstellung ersetzt werden kann. Würde \textit{Enlightenment}
+austauschen, würde die Funktionsweise der zugrundeliegenden Komponenten zu verändern. \newline
+Neben dem \textit{Graphical User Interface (GUI)} besteht die Software aus drei unterschiedlichen Modulen. Der \textit{Message
+Sender} ist für das Versenden und Empfangen der Textnachrichten zuständig, \textit{Sender} sendet die eigene Position,
+\textit{Receiver} empfängt die Positionen der anderen Nutzer und sendet Acknowledgements an die teilnehmenden \textit{Sender}.
+Alle drei Teile geben ihre empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{Enlightenment} ausgibt.
+\textit{Abbildung 3} zeigt den Kommunikationsaustausch von \textit{Friend Finder}.
+
+\begin{figure}[!ht]
\centering
- \includegraphics[width=7cm]{Bilder/ablauf}
+ \includegraphics[width=10cm]{Bilder/ablauf}
\caption{\textit{Friend Finder} Nachrichtenaustausch}
\end{figure}
@@ -30,49 +27,48 @@ empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{E
Zum Erstellen der Oberfläche wurde \textit{Enlightenment} verwendet. Diese Bibliothek stellt alle benötigten Funktionen bereit und
bietet eine Fülle an vordefinierten Bedienelement. Der gesammte Programmcode der Benutzeroberfläche wurde in einer Datei
-zusammengefast (\textit{gui.c}). Diese Tatsache vereinfacht das Erhalten der Modularität, da einfach nur diese Datei
-durch eine andere ersetzt werden muss um einen anderen Typ von Oberfläche zu benutzen. \newline
-In der der Datei \textit{gui.c} sind alle Funktionen enthalten um die Oberflächenelement zu erzeugen und zu platzieren. Um die
-gewünschte Funktionalität der einzelnen Elemente zu realisieren wurden auch die Aufrufe der benötigten Funktionen aus anderen
+zusammengefast (\textit{gui.c}). \newline
+In dieser Datei sind alle Funktionen enthalten um die Oberflächenelement zu platzieren. Um die gewünschte Funktionalität der
+einzelnen Elemente zu realisieren wurden auch die Aufrufe der benötigten Funktionen aus anderen
Modulen in dieser Datei implementiert. \newline
-Wie schon erwähnt, wurde die Graphische Nutzeroberfläche mit Hilfe von Bibliotheken aus dem \textit{Elementary}-Paket
-realisiert. Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap} \citep{OSM} genutzt.
+Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap} \citep{OSM} genutzt.
\subsubsection{Versenden der Nachrichten}
Um Daten im Allgemeinen zu versenden wurde das \textit{IRC}-Protokoll verwendet. Die
Vorteile dieses Protokolles liegen in seiner weiten Verbreitung, einer ausgedehnten Serverstruktur, sowie in dessen
-Stabilität.\newline
+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
-erstellen muss eine \textit{IRC-Session} initialisiert werden. Diese \textit{Session} beinhaltet Informationen wie zum Beispiel
+etablieren, muss eine \textit{IRC-Session} initialisiert werden. Diese \textit{Session} beinhaltet Informationen wie zum Beispiel
den \textit{Nickname} des Benutzers oder die \textit{IP-Adresse} des Servers. Nachdem diese \textit{Session} gestartet wurde,
-kann man nun durch das Aufrufen der Funktion ``\textit{set\_txt\_msg(char* msg)}'' die Nachricht versenden. Wird eine Nachricht
-empfangen so wird diese an die Funktion ``\textit{show\_message(char* msg)}`` , welche zur Benutzeroberfläche gehört, übergeben.
+können nun Nachrichten versandt werden. Wird eine Nachricht empfangen so wird diese an die Benutzeroberfläche weitergereicht.
Bei der Implementerierung des Nachrichtenversandes ist eine Besonderheit zu erwähnen. Das genutzte Verschlüsselungsverfahren
-\textit{Blowfish} wurde seitens der \textit{OpenSSL}\citep{OpenSSL} Bibliothek als \textit{Blockcipher} implementiert. Das
-bedeutet, das immer nur maximal 64 Bit Nachrichten verschlüsselt werden können. Da in der Programmiersprache \textit{C} dies genau
-acht ASCII-Zeichen entspricht, werden alle zu sendenden Nachrichten in Blöcke der Größe acht aufgeteilt, versandt und beim
-Empfänger wieder zusammengesetzt. \newline
+\textit{Blowfish} \citep{blowfish} wurde seitens der \textit{OpenSSL}\citep{OpenSSL} Bibliothek als \textit{Blockcipher}
+implementiert. \textit{Blowfish} wurde Aufgrund der schnellen Verschlüsselungsrate sowie einfachen Implementierung gewählt und
+ist ein symmetrisches Verschlüsselungsverfahren. Das bedeutet, das immer nur maximal 64 Bit Nachrichten verschlüsselt werden
+können. Aufgrund dieser Restriktion werden Textnachrichten in Blöcke der Zeichenlänge 6 aufgeteilt und anschliessend
+versandt. Um den die Codierung der Verschlüsselten Nachrichten zu erhalten werden alle versendeten Daten des Programmes in die
+\textit{Base64} \citep{base64} Darstellung umgewandelt. Dies ist notwendig, da die verschiedenen \textit{IRC}-Server
+unterschiedliche Zeichenkodierungen nutzen können.\newline
Ein weiterer wichtiger Unterschied zu den Modulen Senden und Empfangen von \textit{GPS}-Positionen ist die Tatsache, dass bei
diesem Programmteil Sender und Empfänger in der gleichen Datei implementiert wurden. Der Grund hierfür ist, dass man hier nicht
zwischen mehreren Sendern oder Empfängern unterscheiden muss, und diese zwei Teile hier somit nicht komplett getrennt voneinander
-arbeiten müssen. In der folgenden Abbildung ist eine Konversation über \textit{Friend Finder} zu sehen.\newline
+arbeiten müssen. In der folgenden Abbildung ist eine Textkonversation mit \textit{Friend Finder} zu sehen.\newline
-\begin{figure}[h]
+\begin{figure}[!ht]
\centering
- \includegraphics[width=5cm]{Bilder/chat}
+ \includegraphics[width=8cm]{Bilder/chat}
\caption{Versenden von Chatnachrichten}
\end{figure}
Um Nachrichten zu versenden wurde für dieses Projekt die \textit{IRC-Client Bibliothek}\citep{libircclient} verwendet. Diese
-\textit{library} bietet verschiedene Funktionen um eine Verbindung mit einem \textit{IRC-Server} zu erstellen und Nachrichten an
+Bibliothek bietet verschiedene Funktionen um eine Verbindung mit einem \textit{IRC-Server} zu erstellen und Nachrichten an
diesen zu senden, sowie eingehende Nachrichten zu empfangen.\newline
-Zur Ver- und Entschlüsselung der gesendeten Nachrichten, sowie der Positionsdaten wird die Bibliothek
-des \textit{OpenSSL-Projekts}\citep{OpenSSL}, namens \textit{libcrypto}, verwendet. Hierzu werden die Daten mit dem
-\textit{Blowfish-Algorithmus} verschlüsselt. Bei diesem Algorithmus handelt es sich um ein symmetrisches
-Verfahren, bei welchem alle Teilnehmer den gleichen privaten Schlüssel zum ver- sowie entschlüsseln nutzen.
+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}
@@ -81,41 +77,36 @@ eine \textit{IRC-Session} initialisiert werden um danach die Position zu versend
in einer vorgegebenen Reihenfolge. Zuerst wird der verschlüsselte Längengrad, danach der verschlüsselte Breitengrade gesendet.
Allerdings muss auch hier, wie beim Versenden der Textnachrichten, darauf geachtet werden dass maximal eine Zeichenkette der
Länge 8 Byte verschlüsselt wird. Somit ist es auch hier nötig Längen- und Breitengrad in zwei Teile aufzuteilen und getrennt zu
-versenden. Somit werden für das Versenden einer Position insgesamt acht Nachrichten an den \textit{IRC}-Server übermittelt.
+versenden. Es werden für das Versenden einer Position insgesamt vier Nachrichten an den \textit{IRC}-Server übermittelt.
Wurden diese vier Nachrichten übermittelt, so werden solange keine Daten mehr gesendet, bis der Empfänger eine
-Bestätigung an den \textit{IRC-Kanal} sendet. Diese Bestätigung ist wird unverschlüsselt versandt. Kommt dieses
-\textit{Acknowledgement} beim Sender an, so versendet dieser wieder ein \textit{Latitude/Longtitude Paar}.\newline
+Bestätigung für jedes Fragment an den \textit{IRC-Kanal} sendet. Diese Bestätigungen werden ebenfalls verschlüsselt versandt.
+Kommt dieses \textit{Acknowledgement} beim Sender an, so versendet dieser wieder ein \textit{Latitude/Longtitude} Paar.\newline
Auch hier wird, wie beim Versenden der Nachrichten zum Verschlüsseln der \textit{Blowfish-Algorithmus} aus
\textit{libcrypto}, sowie \textit{libircclient} zum versenden der Daten genutzt.
\subsubsection{Empfangen der eigenen Position}
-Das Verhalten des Empfängers beim Erhalten einer Nachricht ist etwas komplizierter. Im ersten Schritt muss auch hier eine
-\textit{IRC-Session} initialisiert werden. Da mehrere Benutzer Positionsdaten senden können legt der Empfänger für jeden Sender
-einen Datensatz an. Dieser wird nach und nach mit den Positionsdaten gefüllt und die benötigten Daten weitergegeben, sobald alle
-vorhanden sind. Da der Sender seine Daten, aufgrund der Restrektion der Länge der zu verschlüsselnden Zeichenkette, gestückelt
-sendet ist es von Nöten das der Empfänger die Daten dem jeweiligen Absender zuordnen kann und diese auch wieder korrekt
-zusammensetzt. Dies geschieht mit Hilfe von Terminierungszeichen am Ende eines jeden Positionsbruchstückes. Dieses Zeichen wurde
-vom Sender angehängt und der Empfänger kann mit dieser Hilfe erkennen wie die gesendeten Daten zugeordnet werden müssen. Wenn dies
-geschehen ist und sowohl \textit{Latitude} als auch \textit{Longtitude} Informationen vorhanden sind, werden diese Position an das
-Frontend weitergegeben. \newline
+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} genutzt.
+\textit{Blowfish-Algorithmus} von \textit{libcrypto} angewandt.
\subsubsection{Erzeugen eines 2D-Barcodes}
-Die Datei \textit{barcode.c} beinhaltet die Funktionen zum Erstellen eines 2D-Barcodes. Hierzu wird die Funktion
-``\textit{generate\_barcode(char* key)}'', mit einer Zeichenkette als Übergabeparameter, aufgerufen. Aus dieser Zeichenkette wird
-dann ein Barcode erstellt, welcher im darauf folgenden Schritt als \textit{.png} Datei auf das Speichermedium geschrieben wird.
-Zum erstellen des Barcodes wurde die offene Bibliothek \textit{qrencode} \citep{qrencode} genutzt. Diese erstellt aus einer
+Die Datei \textit{barcode.c} beinhaltet die Funktionen zum Erstellen eines 2D-Barcodes. Aus einer Zeichenkette wird
+ein Barcode erstellt, welcher im darauf folgenden Schritt als \textit{.png} Datei auf das Speichermedium geschrieben
+wird. Zum erstellen des Barcodes wurde die offene Bibliothek \textit{qrencode} \citep{qrencode} genutzt. Diese erstellt aus einer
Zeichenkette einen 2D-Barcode. Aus den Bilddaten dieses Barcodes wurde mit \textit{libpng} \citep{PNG} eine \textit{.png} Datei
-erstellt. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er von \textit{Friend Finder} ausgegeben wird.
+generiert. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er von \textit{Friend Finder} ausgegeben wird.
-\begin{figure}[h]
+\begin{figure}[!ht]
\centering
- \includegraphics[width=5cm]{Bilder/barcode}
+ \includegraphics[width=8cm]{Bilder/barcode}
\caption{2D-Barcode mit \textit{Friend Finder}}
\end{figure}
@@ -126,93 +117,74 @@ erstellt. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er vo
Das Ziel war es mit \textit{Friend Finder} Daten verschlüsselt zu übertragen. Es soll dabei ein möglichst geringer
Berechnungsaufwand entstehen um die Daten zu verschlüsseln, sowie möglichst wenig Datenoverhead produziert und versendet werden.
-Unter Datenoverhead werden die Hintergrunddaten gesehen, welche versendet werden um zum Beispiel die Verbindung
-zwischen Client und Server aufrecht zu erhalten oder um zu kontrollieren ob Server oder Client noch verfügbar sind. Diese Daten
- sind von Interesse da mit vielen versendeten Daten ein höherer Anspruch des Rechenkerns einhergeht, was wiederrum in einem
+Unter Datenoverhead werden Hintergrunddaten gesehen, welche versendet werden um zum Beispiel die Verbindung zwischen Client und
+Server aufrecht zu erhalten oder um zu kontrollieren ob Server oder Client noch verfügbar sind. Diese Daten
+sind von Interesse da mit vielen versendeten Daten ein höherer Anspruch des Rechenkerns einhergeht, was wiederrum in einem
höheren Stromverbrauch resultiert.\newline
Im folgenden Teil wird der erzeugte Datenverkehr von \textit{Friend Finder} analysiert. Ein Hauptaugenmerkt wird hierbei vor allem
auf die Packetgröße, sowie die Menge der versendeten Datenpakete geworfen. Der \textit{Traffic} wurde mit Hilfe des Programmes
\textit{Wireshark} \citep{Wireshark} untersucht.Wie bereits erwähnt wird zum Versenden der Nachrichten das \textit{IRC-Protokoll}
verwendet. In dieser Testumgebung wurde die Software \textit{IRCD-Hybrid} \citep{IRCD} genutzt. Der Server lief auf dem gleichen
-Computer wie der Client und der Client hat sich über das \textit{localhost} Interface mit dem Server verbunden. \newline
+Computer wie der Client. Der Client hat sich über das \textit{localhost} Interface mit dem Server verbunden. \newline
Die Analyse ist in drei Teile aufgeteilt. Als erstes wird auf den allgemein entstehenden Datenverkehr eingegangen, welcher
bei Verbindungsaufbau, sowie bei Beenden der Verbindung entsteht. Der zweite Teil beschäftigt sich mit dem Versenden sowie
-Empfangen von Nachrichten. Im letzten Teil dieser Analyse wird auch das dritte Feature, dass Versenden und Empfangen von
-Positionen, unter die Lupe genommen.
+Empfangen von Nachrichten. Im letzten Teil dieser Analyse wird das Versenden und Empfangen von Positionen, unter die Lupe
+genommen. Alle Größen innerhalb der Analyse beziehen sich nur auf die Größe des Datenfeldes, exklusiv der Header.
\subsubsection{Allgemeiner Datenverkehr}
-Bei Messung des allgemeinen Datenaufkommens mit eine normalen \textit{IRC-Clients}, hier \textit{X-Chat} \citep{xchat}, ergeben
-sich folgender Datenverkehr. \newline
-Beim Verbindungsaufbau sendet der \textit{IRC}-Server zuerst ein Paket mit Informationen wie Limit der \textit{Channels}
-oder Anzahl der aktiven Benutzer. Dieses Paket hatte in der Versuchsumgebung eine Größe von 1090 Bytes. Hiervon müssen noch 20
-Bytes \textit{IP-} und 32 Byte \textit{TCP-Header} abgezogen werden. Somit sind die hat das Datenfeld eine Größe von 1038 Bytes.
-Bei im folgenden genannten Paketgrößen sind diese 52 Byte schon abgezogen. \newline
-Wenn im nächsten Schritt der Benutzer nun eine \textit{Channel} beitritt so sendet dieser drei Pakete an den Server. Diese
-beinhalten den Namen des \textit{Channels} dem beigetreten werden soll, eine Anfrage der aktiven Nutzer in diesem \textit{Channel}
-sowie welche Rechter der beitretende Nutzer in diesem \textit{Channel} inne hat. Diese drei Pakete haben alle die Größe von 26
-Byte. Ist die Verbindung zwischen Client und Server aufgebaut so sendet der Client alle 30 Sekunden ein \textit{Ping} Paket an den
-Server, welches dieser mit einem \textit{Pong} beantwortet. Diese Pakete haben eine Größe von 40 Byte für die \textit{Ping}
-Nachricht und 58 Byte für die beantwortende \textit{Pong} Nachricht. Alle 60 Sekunden versendet der Client eine Anfrage, welche
-Teilnehmer sich im \textit{Channel} befinden. Diese Nachricht von Client zu Server ist 25 Byte groß. Die Antwort hierzu ist
-abhängig von der Anzahl der Benutzer. Ist nur ein Benutzer im \textit{Channel} so ist sie 151 Bytes groß, bei zwei ist sie schon
-233 Byte groß. Wird eine Verbindung beendet, so schickt der Client noch eine \textit{Quit} Nachricht an den Server. \newline
-
-Im Gegensatz zu diesem hohen Hintergrundverkehr benötigt \textit{Friend Finder} nur einen \textit{TCP-Handshake} um die
-Verbindung aufzubauen. Ist die Verbindung etabliert fallen keine weiteren Hintergrunddaten an. Der Nachteil hiervon ist, dass der
-Client nur bei einem auftretenden Fehler beim versenden der Daten bemerkt das er nicht mehr verbunden ist. Allerdings wird
-hiermit auch Berechnungszeit und somit Akku gespart, da diese \textit{Keep-Alive} Nachrichten, sowie die zusätzliche
-Informationen über den Server im Rahmen von \textit{Friend Finder} nicht benötigt werden, da die Positionsdaten mehrmals pro
-Minute übermittelt werden und somit immer Datenverkehr zwischen Sender und \textit{IRC}-Server vorhanden ist. \newline
+Der Allgemeine Hintergrundverkehr bei \textit{Friend Finder} besteht zum einen aus \textit{Keep-Alive} Nachrichten, sowie der
+Anfrage des Clients nach aktiven Nutzern in den \textit{Channels} in denen er selbst aktiv ist. Die \textit{Keep-Alive}
+Nachrichten werden alle 30 Sekunden zwischen Server und Client ausgetauscht. Die Größe des Datenfeldes einer
+solchen Nachricht beträgt also 24 Byte. Das Datenfeld der Pakete welche von Server an Client gesendet werden hat die Größe von 44
+Byte. \newline
+Die Anfragen nach den anderen Benutzern in einem \textit{Channel} werden alle 60 Sekunden versandt. Die Größe der Pakete welche
+von Client zu Server gesandt werden, betragen hierbei 10 Bytes. Die Größe der Antwort des Servers hängt von der Anzahl der
+aktiven Benutzer innerhalb eines Channels ab. Für zwei Benutzer ergibt sich ein Datenvolumen von 193 Byte, wobei diese
+Größe auch Abhängig von der Länge der Benutzernamen sowie des Namens des\textit{Channels} ist. \newline
\subsubsection{Versenden und Empfangen von Nachrichten}
Um das Versenden von Nachrichten zu evaluieren wurde ``Hello World`` als Testnachricht benutzt. Der \textit{Blockcipher} von
-\textit{Friend Finder} teilt den Satz "Hello World" in zwei Teile auf: ''Hello `` und ''World``. Diese werden dann von
-\textit{TCP} aufgrund der Fenstergröße in ein Paket gepackt. Das gesamte Paket hat die größe von 147 Bytes, wobei \textit{TCP-}
-und \textit{IP-Header} abgezogen werden müssen. Somit haben die Daten eine Größe von insgesamt 81 Bytes.\newline
+\textit{Friend Finder} teilt den Satz ''Hello World`` in zwei Teile auf: ''Hello `` und ''World``. Diese werden dann von
+\textit{TCP} aufgrund der Fenstergröße in ein Paket gepackt. Dieses Paket hat ein Datenfeld der Größe von 99 Byte.\newline
Beachtet man dass ein \textit{char} in \textit{C} die Größe von einem Byte hat und der Beispielsatz aus elf Zeichen besteht, so
-ist dieser unverschlüsselt 11 Byte groß. Nach der Verschlüsselung werden beim Senden noch Informationen wie der
-\textit{Channel} und der Empfänger der Nachricht in das zu versendende \textit{IRC}-Paket geschrieben. Somit vergrößert
-sich eine Textnachricht circa um den Faktor 7,4, wenn sie verschlüsselt ist und alle Zusatzinformationen hineingepakt
-wurden. \newline
+ist dieser unverschlüsselt elf Byte groß. Nach der Verschlüsselung werden beim Senden noch Informationen wie der
+\textit{Channel} und der Empfänger der Nachricht in das zu versendende \textit{IRC}-Paket geschrieben und im Anschluss die
+Konvertierung zur \textit{Base64}-Darstellung vorgenommen. Die \textit{Base64}-Darstellung vergrößert im Allgemeinen, aufgrund
+der Datenkonvertierung, das Datenvolumen um 36\%. Somit vergrößert sich eine Textnachricht circa um den Faktor $9$ sobald sie
+verschlüsselt, \textit{Base64}-kodiert und mit allen Zusatzinformationen erweitert wurde. \newline
Wenn $h$ die Größe des \textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht ist, so ergibt sie die
-ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 7,4)$.
+ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 9)$.
\subsubsection{Versenden und Empfangen von Positionen}
Wie schon erwähnt, werden die Positionsdaten beim Sender aufgeteilt und mit vier unterschiedlichen Nachrichten versandt. Wie
-beim Versenden der Textnachrichten werden diese vier Nachrichten auch hier in ein Paket gepakt. Dieses hat die Gesamtgröße
-von 235 Byte. Abzüglich der \textit{TCP-} und \textit{IP-Header} ergibt sich hier eine Datengröße von 169 Byte. Die Anzahl
-der unverschlüsselten Zeichen, die zu senden sind, beträgt 21 Zeichen. Diese sind jeweils 1 Byte groß, womit sie in der Summe
-also 21 Byte Größe haben. Durch die Verschlüsselung sowie die benötigten Zusatzinformationen, wie \textit{Channel} für
-den die Nachricht bestimmt ist, vergrößert sich das Datenvolumen also um circa den Faktor acht. Wenn $h$ die Größe des
-\textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht. Somit ergibt sich die Größe der versendeten
-Nachricht circa durch $h + (t \cdot 8)$. Hinzu kommt noch, das für jedes empfangene Positions-Fragmeint ein Acknowledgement
-gesendet wird. Somit sind nach Empfangen aller vier Positionsteile vier Acknowledgements der Größe von 124 Bytes insgesamt und 58
-Bytes an Daten ohne Header gesendet worden.\newline
-Somit kann aus Folgende Formel für den Datenverkehr über die Zeit hergeleitet werden: $((h + (t \cdot 8)) + (4 \cdot a)) \cdot n$,
-wobei $a$ die Größe eines Acknowledgement-Paketes ist und $n$ die Anzahl der versandten Pakete repräsentiert.
+beim Versenden der Textnachrichten werden diese vier Nachrichten auch hier in ein Paket gepackt. Bei der Messung wurden vier
+Verschiedene Pakete, mit jeweils unterschiedlichen versandten Positionen untersucht. Dabei betrug sich die Größe des Datenfeldes
+zwischen 431 Byte. Die Anzahl der unverschlüsselten Zeichen, die für ein \textit{Latitude}/\textit{Longtitude}-Paar zu
+senden sind, beträgt 21 Zeichen. Jedes Zeichen ist Byte groß, womit sich in der Summe eine Größe von 21 Byte ergibt.
+Durch die Verschlüsselung, \textit{Base64}-Kodierung sowie Zusatzinformationen vergrößert sich das Datenvolumen also um circa den
+Faktor zwanzig. Wenn $h$ die Größe des \textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht. Somit
+ergibt sich die Größe der versendeten Nachricht circa durch $h + (t \cdot 20)$. Hinzu kommt noch, das für jedes empfangene
+Positions-Fragmeint ein Acknowledgement gesendet wird. Die Größe der eines Acknowledgment Paketes beträgt zwischen 147 und 153
+Byte. In einem solchen Paket werden vier Acknowledgments zusammengefasst.\newline
+Folglich kann aus Folgende Formel für den Datenverkehr über die Zeit hergeleitet werden: $((h + (t \cdot 20)) + (4 \cdot a)) \cdot
+n$, wobei $a$ die Größe eines Acknowledgement-Paketes ist und $n$ die Anzahl der versandten Pakete repräsentiert.
\subsubsection{Fazit der Auswertung}
-Im Bereich des Allgemeinen Datenverkehrs fällt kein Overhead durch \textit{Friend Finder} an. Hier werden nur dann Daten
-versandt, wenn dies auch vom Nutzer so gewollt sind und auch gebraucht werden. Dies hat den Vorteil, dass der Anwender die totale
-Kontrolle über die Daten, die er sendet, hat. Allerdings kann so auch erst beim Versenden von Daten festgestellt werden, ob die
-Verbindung unterbrochen wurde, da im Hintergrund die Verbindung nicht ständig überprüft wird. Aufgrund der Tatsache, dass
-Positionsdaten mehrmals pro Minute versandt werden, ist dies aber auch nicht wirklich nötig da durch das Versenden oder
-nicht Versenden dieser Daten auch ein Verbindungsproblem festgestellt werden könnte\newline
-Ein weiterer Vorteil von \textit{Friend Finder} ist das Verschicken von Daten an mehrere Benutzer. Hier muss der
-Client sein Paket nur einmal versenden und alle teilnehmenden Nutzer in einem Channel können diese Nachricht einsehen, sofern dies
-gewollt ist. Würde man hier eine Verbindung pro Teilnehmer nutzen, so müsste man für $n$ Teilnehmer $n$ Verbindungen öffnen und
-auch $n$ Mal die Daten versenden. Dies würde ein nicht unerheblicher Berechnungsaufwand sowie Datenverkehr darstellen. Im
-Empfangen der Daten ergibt zwischen der Lösung durch \textit{Friend Finder} oder einer Verbindung pro Teilnehmer keinen
-Unterschied, da bei beiden Modellen diese Daten nur einmal empfangen werden.
-
-\begin{figure}[h]
-\centering
- \includegraphics[width=10cm]{Bilder/verbindungen}
- \caption{Vergleich von n-Verbindungen und \textit{Friend Finder}}
-\end{figure} \ No newline at end of file
+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}
diff --git a/ausarbeitung/Friend_Finder.tex~ b/ausarbeitung/Friend_Finder.tex~
index 6f800ac..ea0d0b1 100644
--- a/ausarbeitung/Friend_Finder.tex~
+++ b/ausarbeitung/Friend_Finder.tex~
@@ -1,23 +1,21 @@
\section{Friend Finder}
-Die Eingangs beschriebene Software trägt den Namen \textit{Friend Finder} und wurde im Rahmen dieser Arbeit mit fast allen
+Die beschriebene Software trägt den Namen \textit{Friend Finder} und wurde im Rahmen dieser Arbeit mit allen
aufgezählten Funktionen realisiert. Im folgenden wird auf die verwendeten Verfahren sowie Bibliotheken, die zur Realisierung
-notwendig waren, eingegangen.
+notwendig waren, eingegangen und die Programmstruktur aufgezeigt.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Verwendete Verfahren und Bibliotheken}
-\textit{Friend Finder} wurde so konzipiert, dass die Graphische Darstellung ohne großen Aufwand vom den restlichen
-Teilen der Software abgekoppelt und durch eine andere, darstellende Bibliothek ersetzt werden kann. Somit
-könnte man \textit{Enlightenment} durch eine andere Art der Darstellung austauschen, ohne dabei die Funktionalität der
-zugrunde liegenden Komponenten zu zerstören. \newline
-Da das Ver- und Entschlüsseln der Daten möglichst wenig Rechenaufwand erzeugen und der Schlüsselaustausch nicht zu
-kompliziert sein soll, nutzt das Programm ein symmetrisches Verschlüsselungsverfahren. \newline
-\textit{Abbildung 3} zeigt den Kommunikationsaustausch von \textit{Friend Finder}. Der \textit{Message Sender} ist für das
-Versenden und Empfangen der Textnachrichten zuständig, \textit{Sender} sendet die eigene Position, \textit{Receiver} empfängt
-die Positionen der anderen Nutzer und sendet Acknowledgements an die teilnehmenden \textit{Sender}. Alle drei Teile geben ihre
-empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{Enlightenment} ausgibt.
+\textit{Friend Finder} wurde so konzipiert, dass die Graphische Darstellung ohne großen Aufwand von den restlichen
+Teilen der Software abgekoppelt und durch eine andere Art der Darstellung ersetzt werden kann. Würde \textit{Enlightenment}
+austauschen, würde die Funktionsweise der zugrundeliegenden Komponenten zu verändern. \newline
+Neben dem \textit{Graphical User Interface (GUI)} besteht die Software aus drei unterschiedlichen Modulen. Der \textit{Message
+Sender} ist für das Versenden und Empfangen der Textnachrichten zuständig, \textit{Sender} sendet die eigene Position,
+\textit{Receiver} empfängt die Positionen der anderen Nutzer und sendet Acknowledgements an die teilnehmenden \textit{Sender}.
+Alle drei Teile geben ihre empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{Enlightenment} ausgibt.
+\textit{Abbildung 3} zeigt den Kommunikationsaustausch von \textit{Friend Finder}.
\begin{figure}[!ht]
\centering
@@ -29,13 +27,11 @@ empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{E
Zum Erstellen der Oberfläche wurde \textit{Enlightenment} verwendet. Diese Bibliothek stellt alle benötigten Funktionen bereit und
bietet eine Fülle an vordefinierten Bedienelement. Der gesammte Programmcode der Benutzeroberfläche wurde in einer Datei
-zusammengefast (\textit{gui.c}). Diese Tatsache vereinfacht das Erhalten der Modularität, da nur diese Datei
-durch eine andere ersetzt werden muss um einen anderen Typ von Oberfläche zu nutzen. \newline
-In der der Datei \textit{gui.c} sind alle Funktionen enthalten um die Oberflächenelement zu erzeugen und zu platzieren. Um die
-gewünschte Funktionalität der einzelnen Elemente zu realisieren wurden auch die Aufrufe der benötigten Funktionen aus anderen
+zusammengefast (\textit{gui.c}). \newline
+In dieser Datei sind alle Funktionen enthalten um die Oberflächenelement zu platzieren. Um die gewünschte Funktionalität der
+einzelnen Elemente zu realisieren wurden auch die Aufrufe der benötigten Funktionen aus anderen
Modulen in dieser Datei implementiert. \newline
-Wie schon erwähnt, wurde die Graphische Nutzeroberfläche mit Hilfe von Bibliotheken aus dem \textit{Elementary}-Paket
-realisiert. Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap} \citep{OSM} genutzt.
+Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap} \citep{OSM} genutzt.
\subsubsection{Versenden der Nachrichten}
@@ -46,20 +42,21 @@ Stabilität. Ein weiterer Vorteil ist, dass man Daten die an mehrere Benutzer ge
In der Datei \textit{msg\_sender.c} sind alle Funktionen und Aufrufe implementiert, welche nötig sind um die Verbindung zum
\textit{IRC-Server} zu erstellen und die Nachrichten zu verschicken. Um eine Verbindung zu einem gegebenen \textit{IRC-Server} zu
-erstellen muss eine \textit{IRC-Session} initialisiert werden. Diese \textit{Session} beinhaltet Informationen wie zum Beispiel
+etablieren, muss eine \textit{IRC-Session} initialisiert werden. Diese \textit{Session} beinhaltet Informationen wie zum Beispiel
den \textit{Nickname} des Benutzers oder die \textit{IP-Adresse} des Servers. Nachdem diese \textit{Session} gestartet wurde,
-kann man nun durch das Aufrufen der Funktion ``\textit{set\_txt\_msg(char* msg)}'' die Nachricht versenden. Wird eine Nachricht
-empfangen so wird diese an die Funktion ``\textit{show\_message(char* msg)}`` , welche zur Benutzeroberfläche gehört, übergeben.
+können nun Nachrichten versandt werden. Wird eine Nachricht empfangen so wird diese an die Benutzeroberfläche weitergereicht.
Bei der Implementerierung des Nachrichtenversandes ist eine Besonderheit zu erwähnen. Das genutzte Verschlüsselungsverfahren
\textit{Blowfish} \citep{blowfish} wurde seitens der \textit{OpenSSL}\citep{OpenSSL} Bibliothek als \textit{Blockcipher}
-implementiert. \textit{Blowfish} wurde Aufgrund der schnellen verschlüsselungsrate sowie einfachen Implementierung gewählt und
+implementiert. \textit{Blowfish} wurde Aufgrund der schnellen Verschlüsselungsrate sowie einfachen Implementierung gewählt und
ist ein symmetrisches Verschlüsselungsverfahren. Das bedeutet, das immer nur maximal 64 Bit Nachrichten verschlüsselt werden
-können. Da in der Programmiersprache \textit{C} dies genau acht ASCII-Zeichen entspricht, werden alle zu sendenden Nachrichten in
-Blöcke der Größe acht aufgeteilt, versandt und beim Empfänger wieder zusammengesetzt. \newline
+können. Aufgrund dieser Restriktion werden Textnachrichten in Blöcke der Zeichenlänge 6 aufgeteilt und anschliessend
+versandt. Um den die Codierung der Verschlüsselten Nachrichten zu erhalten werden alle versendeten Daten des Programmes in die
+\textit{Base64} \citep{base64} Darstellung umgewandelt. Dies ist notwendig, da die verschiedenen \textit{IRC}-Server
+unterschiedliche Zeichenkodierungen nutzen können.\newline
Ein weiterer wichtiger Unterschied zu den Modulen Senden und Empfangen von \textit{GPS}-Positionen ist die Tatsache, dass bei
diesem Programmteil Sender und Empfänger in der gleichen Datei implementiert wurden. Der Grund hierfür ist, dass man hier nicht
zwischen mehreren Sendern oder Empfängern unterscheiden muss, und diese zwei Teile hier somit nicht komplett getrennt voneinander
-arbeiten müssen. In der folgenden Abbildung ist eine Konversation über \textit{Friend Finder} zu sehen.\newline
+arbeiten müssen. In der folgenden Abbildung ist eine Textkonversation mit \textit{Friend Finder} zu sehen.\newline
\begin{figure}[!ht]
\centering
@@ -71,9 +68,7 @@ Um Nachrichten zu versenden wurde für dieses Projekt die \textit{IRC-Client Bib
Bibliothek bietet verschiedene Funktionen um eine Verbindung mit einem \textit{IRC-Server} zu erstellen und Nachrichten an
diesen zu senden, sowie eingehende Nachrichten zu empfangen.\newline
Zur Ver- und Entschlüsselung der gesendeten Nachrichten, sowie der Positionsdaten, wird die Bibliothek
-des \textit{OpenSSL-Projekts}\citep{OpenSSL}, namens \textit{libcrypto}, verwendet. Hierzu werden die Daten mit dem
-\textit{Blowfish-Algorithmus} verschlüsselt. Bei diesem Algorithmus handelt es sich um ein symmetrisches
-Verfahren, bei welchem alle Teilnehmer den gleichen privaten Schlüssel zum ver- sowie entschlüsseln nutzen.
+des \textit{OpenSSL-Projekts}\citep{OpenSSL}, namens \textit{libcrypto}, verwendet.
\subsubsection{Versenden der eigenen Position}
@@ -84,34 +79,28 @@ Allerdings muss auch hier, wie beim Versenden der Textnachrichten, darauf geacht
Länge 8 Byte verschlüsselt wird. Somit ist es auch hier nötig Längen- und Breitengrad in zwei Teile aufzuteilen und getrennt zu
versenden. Es werden für das Versenden einer Position insgesamt vier Nachrichten an den \textit{IRC}-Server übermittelt.
Wurden diese vier Nachrichten übermittelt, so werden solange keine Daten mehr gesendet, bis der Empfänger eine
-Bestätigung an den \textit{IRC-Kanal} sendet. Diese Bestätigung wird ebenfalls verschlüsselt versandt. Kommt dieses
-\textit{Acknowledgement} beim Sender an, so versendet dieser wieder ein \textit{Latitude/Longtitude} Paar.\newline
+Bestätigung für jedes Fragment an den \textit{IRC-Kanal} sendet. Diese Bestätigungen werden ebenfalls verschlüsselt versandt.
+Kommt dieses \textit{Acknowledgement} beim Sender an, so versendet dieser wieder ein \textit{Latitude/Longtitude} Paar.\newline
Auch hier wird, wie beim Versenden der Nachrichten zum Verschlüsseln der \textit{Blowfish-Algorithmus} aus
\textit{libcrypto}, sowie \textit{libircclient} zum versenden der Daten genutzt.
\subsubsection{Empfangen der eigenen Position}
-Das Verhalten des Empfängers beim Erhalten einer Nachricht ist etwas komplizierter. Im ersten Schritt muss auch hier eine
-\textit{IRC-Session} initialisiert werden. Da mehrere Benutzer Positionsdaten senden können legt der Empfänger für jeden Sender
-einen Datensatz an. Dieser wird nach und nach mit den Positionsdaten gefüllt und die benötigten Daten weitergegeben, sobald alle
-vorhanden sind. Da der Sender seine Daten, aufgrund der Restrektion der Länge der zu verschlüsselnden Zeichenkette, gestückelt
-sendet ist es von Nöten, dass der Empfänger die Daten dem jeweiligen Absender zuordnen kann und diese auch wieder korrekt
-zusammensetzt. Um die einzelnen Fragmente wieder zuzordnen, werden an diese vor dem versenden Terminierungszeichen angefügt,
-welche zum Beispiel eindeutig als ersten Teil einer \textit{Longtitude}-Koordinate identifizieren. Wenn diese wieder zugeordnet
-wurden und sowohl \textit{Latitude} als auch \textit{Longtitude} Informationen vorhanden sind, werden diese Position
-an das Frontend weitergegeben. \newline
+Im ersten Schritt muss auch hier eine \textit{IRC-Session} initialisiert werden. Da mehrere Benutzer Positionsdaten senden können
+legt der Empfänger für jeden Sender einen Datensatz an. Dieser wird nach und nach mit gesendeten Fragmenten der Positionsdaten
+gefüllt. Sind alle Fragmente beim Empfänger angekommen so werden die benötigten Daten zur Visuallisierung weitergegeben. Um die
+einzelnen Positionsfragmente zuzordnen zu können, werden an diese vor dem versenden Terminierungszeichen angefügt. Diese
+Identifizieren zum Beispiel eindeutig einen ersten Teil einer \textit{Longtitude}-Koordinate.
Zur Realisierung des Empfängers werden die gleichen Bibliotheken wie beim Sender genutzt. Auch hier wird zur Entschlüsselung der
\textit{Blowfish-Algorithmus} von \textit{libcrypto} angewandt.
\subsubsection{Erzeugen eines 2D-Barcodes}
-Die Datei \textit{barcode.c} beinhaltet die Funktionen zum Erstellen eines 2D-Barcodes. Hierzu wird die Funktion
-``\textit{generate\_barcode(char* key)}'', mit einer Zeichenkette als Übergabeparameter, aufgerufen. Aus dieser Zeichenkette wird
-im Anschluss ein Barcode erstellt, welcher im darauf folgenden Schritt als \textit{.png} Datei auf das Speichermedium geschrieben
-wird.
-Zum erstellen des Barcodes wurde die offene Bibliothek \textit{qrencode} \citep{qrencode} genutzt. Diese erstellt aus einer
+Die Datei \textit{barcode.c} beinhaltet die Funktionen zum Erstellen eines 2D-Barcodes. Aus einer Zeichenkette wird
+ein Barcode erstellt, welcher im darauf folgenden Schritt als \textit{.png} Datei auf das Speichermedium geschrieben
+wird. Zum erstellen des Barcodes wurde die offene Bibliothek \textit{qrencode} \citep{qrencode} genutzt. Diese erstellt aus einer
Zeichenkette einen 2D-Barcode. Aus den Bilddaten dieses Barcodes wurde mit \textit{libpng} \citep{PNG} eine \textit{.png} Datei
generiert. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er von \textit{Friend Finder} ausgegeben wird.
@@ -128,99 +117,76 @@ generiert. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er v
Das Ziel war es mit \textit{Friend Finder} Daten verschlüsselt zu übertragen. Es soll dabei ein möglichst geringer
Berechnungsaufwand entstehen um die Daten zu verschlüsseln, sowie möglichst wenig Datenoverhead produziert und versendet werden.
-Unter Datenoverhead werden die Hintergrunddaten gesehen, welche versendet werden um zum Beispiel die Verbindung
-zwischen Client und Server aufrecht zu erhalten oder um zu kontrollieren ob Server oder Client noch verfügbar sind. Diese Daten
- sind von Interesse da mit vielen versendeten Daten ein höherer Anspruch des Rechenkerns einhergeht, was wiederrum in einem
+Unter Datenoverhead werden Hintergrunddaten gesehen, welche versendet werden um zum Beispiel die Verbindung zwischen Client und
+Server aufrecht zu erhalten oder um zu kontrollieren ob Server oder Client noch verfügbar sind. Diese Daten
+sind von Interesse da mit vielen versendeten Daten ein höherer Anspruch des Rechenkerns einhergeht, was wiederrum in einem
höheren Stromverbrauch resultiert.\newline
Im folgenden Teil wird der erzeugte Datenverkehr von \textit{Friend Finder} analysiert. Ein Hauptaugenmerkt wird hierbei vor allem
auf die Packetgröße, sowie die Menge der versendeten Datenpakete geworfen. Der \textit{Traffic} wurde mit Hilfe des Programmes
\textit{Wireshark} \citep{Wireshark} untersucht.Wie bereits erwähnt wird zum Versenden der Nachrichten das \textit{IRC-Protokoll}
verwendet. In dieser Testumgebung wurde die Software \textit{IRCD-Hybrid} \citep{IRCD} genutzt. Der Server lief auf dem gleichen
-Computer wie der Client und der Client hat sich über das \textit{localhost} Interface mit dem Server verbunden. \newline
+Computer wie der Client. Der Client hat sich über das \textit{localhost} Interface mit dem Server verbunden. \newline
Die Analyse ist in drei Teile aufgeteilt. Als erstes wird auf den allgemein entstehenden Datenverkehr eingegangen, welcher
bei Verbindungsaufbau, sowie bei Beenden der Verbindung entsteht. Der zweite Teil beschäftigt sich mit dem Versenden sowie
-Empfangen von Nachrichten. Im letzten Teil dieser Analyse wird auch das dritte Feature, dass Versenden und Empfangen von
-Positionen, unter die Lupe genommen.
+Empfangen von Nachrichten. Im letzten Teil dieser Analyse wird das Versenden und Empfangen von Positionen, unter die Lupe
+genommen. Alle Größen innerhalb der Analyse beziehen sich nur auf die Größe des Datenfeldes, exklusiv der Header.
\subsubsection{Allgemeiner Datenverkehr}
-Bei Messung des allgemeinen Datenaufkommens mit eine normalen \textit{IRC-Clients}, hier \textit{X-Chat} \citep{xchat}, ergibt
-sich folgender Datenverkehr. \newline
-Beim Verbindungsaufbau sendet der \textit{IRC}-Server zuerst ein Paket mit Informationen wie Limit der \textit{Channels}
-oder Anzahl der aktiven Benutzer. Dieses Paket hatte in der Versuchsumgebung eine Größe von 1090 Bytes. Hiervon müssen noch 20
-Bytes \textit{IP-} und 32 Byte \textit{TCP-Header} abgezogen werden. Somit sind die hat das Datenfeld eine Größe von 1038 Bytes.
-Bei im folgenden genannten Paketgrößen sind diese 52 Byte schon abgezogen. \newline
-Wenn im nächsten Schritt der Benutzer nun eine \textit{Channel} beitritt, so sendet dieser drei Pakete an den Server. Diese
-beinhalten den Namen des \textit{Channels} dem beigetreten werden soll, eine Anfrage nach einer Liste der aktiven Nutzer in diesem
-\textit{Channel}sowie welche Rechte der beitretende Nutzer in diesem \textit{Channel} inne hat. Diese drei Pakete haben alle die
-Größe von 26 Byte. Ist die Verbindung zwischen Client und Server aufgebaut so sendet der Client alle 30 Sekunden ein \textit{Ping}
-Paket an den Server, welches dieser mit einem \textit{Pong} beantwortet. Diese Pakete haben eine Größe von 40 Byte für die
-\textit{Ping} Nachricht und 58 Byte für die beantwortende \textit{Pong} Nachricht. Alle 60 Sekunden versendet der Client eine
-Anfrage, welche Teilnehmer sich im \textit{Channel} befinden. Diese Nachricht von Client zu Server ist 25 Byte groß. Die Antwort
-hierzu ist abhängig von der Anzahl der Benutzer. Ist nur ein Benutzer im \textit{Channel} so ist sie 151 Bytes groß, bei zwei ist
-sie schon 233 Byte groß. Wird eine Verbindung beendet, so schickt der Client eine \textit{Quit} Nachricht an den Server.
-\newline
-
-Im Gegensatz zu diesem hohen Hintergrundverkehr benötigt \textit{Friend Finder} nur einen \textit{TCP-Handshake} um die
-Verbindung aufzubauen. Ist die Verbindung etabliert fallen keine weiteren Hintergrunddaten an. Der Nachteil hiervon ist, dass der
-Client nur bei einem auftretenden Fehler beim Versenden der Daten bemerkt, dass er nicht mehr verbunden ist. Allerdings wird
-hiermit auch Berechnungszeit und somit Akku gespart, da diese \textit{Keep-Alive} Nachrichten, sowie die zusätzliche
-Informationen über den Server im Rahmen von \textit{Friend Finder} nicht benötigt werden. Da die Positionsdaten mehrmals pro
-Minute übermittelt werden besteht somit immer Datenverkehr zwischen Sender und \textit{IRC}-Server und es kann schnell
-festgestellt werden ob eine Verbindung noch aktiv ist. \newline
+Der Allgemeine Hintergrundverkehr bei \textit{Friend Finder} besteht zum einen aus \textit{Keep-Alive} Nachrichten, sowie der
+Anfrage des Clients nach aktiven Nutzern in den \textit{Channels} in denen er selbst aktiv ist. Die \textit{Keep-Alive}
+Nachrichten werden alle 30 Sekunden zwischen Server und Client ausgetauscht. Die Größe des Datenfeldes einer
+solchen Nachricht beträgt also 24 Byte. Das Datenfeld der Pakete welche von Server an Client gesendet werden hat die Größe von 44
+Byte. \newline
+Die Anfragen nach den anderen Benutzern in einem \textit{Channel} werden alle 60 Sekunden versandt. Die Größe der Pakete welche
+von Client zu Server gesandt werden, betragen hierbei 10 Bytes. Die Größe der Antwort des Servers hängt von der Anzahl der
+aktiven Benutzer innerhalb eines Channels ab. Für zwei Benutzer ergibt sich ein Datenvolumen von 193 Byte, wobei diese
+Größe auch Abhängig von der Länge der Benutzernamen sowie des Namens des\textit{Channels} ist. \newline
\subsubsection{Versenden und Empfangen von Nachrichten}
Um das Versenden von Nachrichten zu evaluieren wurde ``Hello World`` als Testnachricht benutzt. Der \textit{Blockcipher} von
-\textit{Friend Finder} teilt den Satz "Hello World" in zwei Teile auf: ''Hello `` und ''World``. Diese werden dann von
-\textit{TCP} aufgrund der Fenstergröße in ein Paket gepackt. Das gesamte Paket hat die größe von 147 Bytes, wobei \textit{TCP-}
-und \textit{IP-Header} abgezogen werden müssen. Somit haben die Daten eine Größe von insgesamt 81 Bytes.\newline
+\textit{Friend Finder} teilt den Satz ''Hello World`` in zwei Teile auf: ''Hello `` und ''World``. Diese werden dann von
+\textit{TCP} aufgrund der Fenstergröße in ein Paket gepackt. Dieses Paket hat ein Datenfeld der Größe von 99 Byte.\newline
Beachtet man dass ein \textit{char} in \textit{C} die Größe von einem Byte hat und der Beispielsatz aus elf Zeichen besteht, so
-ist dieser unverschlüsselt 11 Byte groß. Nach der Verschlüsselung werden beim Senden noch Informationen wie der
-\textit{Channel} und der Empfänger der Nachricht in das zu versendende \textit{IRC}-Paket geschrieben. Somit vergrößert
-sich eine Textnachricht circa um den Faktor 7,4, wenn sie verschlüsselt ist und alle Zusatzinformationen hineingepakt
-wurden. \newline
+ist dieser unverschlüsselt elf Byte groß. Nach der Verschlüsselung werden beim Senden noch Informationen wie der
+\textit{Channel} und der Empfänger der Nachricht in das zu versendende \textit{IRC}-Paket geschrieben und im Anschluss die
+Konvertierung zur \textit{Base64}-Darstellung vorgenommen. Die \textit{Base64}-Darstellung vergrößert im Allgemeinen, aufgrund
+der Datenkonvertierung, das Datenvolumen um 36\%. Somit vergrößert sich eine Textnachricht circa um den Faktor $9$ sobald sie
+verschlüsselt, \textit{Base64}-kodiert und mit allen Zusatzinformationen erweitert wurde. \newline
Wenn $h$ die Größe des \textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht ist, so ergibt sie die
-ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 7,4)$.
+ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 9)$.
\subsubsection{Versenden und Empfangen von Positionen}
Wie schon erwähnt, werden die Positionsdaten beim Sender aufgeteilt und mit vier unterschiedlichen Nachrichten versandt. Wie
-beim Versenden der Textnachrichten werden diese vier Nachrichten auch hier in ein Paket gepakt. Dieses hat die Gesamtgröße
-von 235 Byte. Abzüglich der \textit{TCP-} und \textit{IP-Header} ergibt sich hier eine Datengröße von 169 Byte. Die Anzahl
-der unverschlüsselten Zeichen, die zu senden sind, beträgt 21 Zeichen. Diese sind jeweils 1 Byte groß, womit sie in der Summe
-also 21 Byte Größe haben. Durch die Verschlüsselung sowie die benötigten Zusatzinformationen, wie \textit{Channel} für
-den die Nachricht bestimmt ist, vergrößert sich das Datenvolumen also um circa den Faktor acht. Wenn $h$ die Größe des
-\textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht. Somit ergibt sich die Größe der versendeten
-Nachricht circa durch $h + (t \cdot 8)$. Hinzu kommt noch, das für jedes empfangene Positions-Fragmeint ein Acknowledgement
-gesendet wird. Somit sind nach Empfangen aller vier Positionsteile vier Acknowledgements der Größe von 124 Bytes insgesamt und 58
-Bytes an Daten ohne Header gesendet worden.\newline
-Somit kann aus Folgende Formel für den Datenverkehr über die Zeit hergeleitet werden: $((h + (t \cdot 8)) + (4 \cdot a)) \cdot n$,
-wobei $a$ die Größe eines Acknowledgement-Paketes ist und $n$ die Anzahl der versandten Pakete repräsentiert.
+beim Versenden der Textnachrichten werden diese vier Nachrichten auch hier in ein Paket gepackt. Bei der Messung wurden vier
+Verschiedene Pakete, mit jeweils unterschiedlichen versandten Positionen untersucht. Dabei betrug sich die Größe des Datenfeldes
+zwischen 431 Byte. Die Anzahl der unverschlüsselten Zeichen, die für ein \textit{Latitude}/\textit{Longtitude}-Paar zu
+senden sind, beträgt 21 Zeichen. Jedes Zeichen ist Byte groß, womit sich in der Summe eine Größe von 21 Byte ergibt.
+Durch die Verschlüsselung, \textit{Base64}-Kodierung sowie Zusatzinformationen vergrößert sich das Datenvolumen also um circa den
+Faktor zwanzig. Wenn $h$ die Größe des \textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht. Somit
+ergibt sich die Größe der versendeten Nachricht circa durch $h + (t \cdot 20)$. Hinzu kommt noch, das für jedes empfangene
+Positions-Fragmeint ein Acknowledgement gesendet wird. Die Größe der eines Acknowledgment Paketes beträgt zwischen 147 und 153
+Byte. In einem solchen Paket werden vier Acknowledgments zusammengefasst.\newline
+Folglich kann aus Folgende Formel für den Datenverkehr über die Zeit hergeleitet werden: $((h + (t \cdot 20)) + (4 \cdot a)) \cdot
+n$, wobei $a$ die Größe eines Acknowledgement-Paketes ist und $n$ die Anzahl der versandten Pakete repräsentiert.
\subsubsection{Fazit der Auswertung}
-Im Bereich des Allgemeinen Datenverkehrs fällt kein Overhead durch \textit{Friend Finder} an. Hier werden nur dann Daten
-versandt, wenn dies auch vom Nutzer so gewollt sind und auch gebraucht werden. Dies hat den Vorteil, dass der Anwender die totale
-Kontrolle über die Daten, die er sendet, hat. Allerdings kann so auch erst beim Versenden von Daten festgestellt werden, ob die
-Verbindung unterbrochen wurde, da im Hintergrund die Verbindung nicht ständig überprüft wird. Aufgrund der Tatsache, dass
-Positionsdaten mehrmals pro Minute versandt werden, ist dies aber auch nicht wirklich nötig da durch das Versenden oder
-nicht Versenden dieser Daten auch ein Verbindungsproblem festgestellt werden könnte\newline
-Ein weiterer Vorteil von \textit{Friend Finder} ist das Verschicken von Daten an mehrere Benutzer. Hier muss der
-Client sein Paket nur einmal versenden und alle teilnehmenden Nutzer in einem Channel können diese Nachricht einsehen, sofern dies
-gewollt ist. Würde man hier eine Verbindung pro Teilnehmer nutzen, so müsste man für $n$ Teilnehmer $n$ Verbindungen öffnen und
-auch $n$ Mal die Daten versenden. Dies würde ein nicht unerheblicher Berechnungsaufwand sowie Datenverkehr darstellen. Im
-Empfangen der Daten ergibt zwischen der Lösung durch \textit{Friend Finder} oder einer Verbindung pro Teilnehmer keinen
-Unterschied, da bei beiden Modellen diese Daten nur einmal empfangen werden.\newline
-In der folgenden Abbildung ist an der X-Achse die Anzahl der Teilnehmer und an der Y-Achse die Anzahl der zu versendenden
-Dateneineheiten abgetragen. Hier ist deutlich zu sehen, dass bei steigender Teilnehmer Anzahl eine Lösung mit einer offenen
-Verbindung pro Benutzer soviel Datenpakete wie Nutzer versenden muss. Bei der Lösung mit einem zentralen \textit{Channel} müssen
-die Daten immer nur einmal versandt werden, unabhängig von der Nutzeranzahl.
-
-\begin{figure}[!ht]
-\centering
- \includegraphics[width=10cm]{Bilder/verbindungen}
- \caption{Vergleich von n-Verbindungen und \textit{Friend Finder}}
-\end{figure} \ No newline at end of file
+Die Hintergrunddaten welche vom \textit{IRC}-Protokoll versandt werden ergeben einen geringen, in Kauf zu nehmenden Datenoverhead.
+Zu beobachten ist, dass das Datenvolumen der Versendeten Daten, sowohl bei Positionsdaten als auch bei Textnachrichten, durch die
+Verschlüsselung und die anschliessende Konvertierung in die \textit{Base64}-Darstellung zunimmt. Als großen Vorteil kann hier aber
+gesehen werden, dass es mit einmaligem Versenden einer Position möglich ist $n$ Teilnehmer eines \textit{Channels} diese zu
+übermitteln, da alle die Nachrichten innerhalb dieses \textit{Channels} lesen können. Somit ergibt sich hier ein großer Vorteil
+gegenüber dem Aufbauen von $n$ einzelnen Verbindungen. Würde man einen solchen Ansatz wählen, müssten $n$ Verbindungen geöffnet
+werden und die Daten folglich auch $n$ Mal versandt werden. Der dabei entstehnde Datenverkehr steht in keiner Relation zu dem der
+gewählten Lösung. Somit stellt das \textit{IRC}-Protokoll eine hervorragende Lösung für Programme dieser Art dar.
+
+%\begin{figure}[!ht]
+%\centering
+% \includegraphics[width=10cm]{Bilder/verbindungen}
+% \caption{Vergleich von n-Verbindungen und \textit{Friend Finder}}
+%\end{figure}
diff --git a/ausarbeitung/Grundlagen.aux b/ausarbeitung/Grundlagen.aux
index 1187ece..6e62e5a 100644
--- a/ausarbeitung/Grundlagen.aux
+++ b/ausarbeitung/Grundlagen.aux
@@ -1,20 +1,21 @@
\relax
\citation{privacy}
+\citation{geocaching}
\citation{Latitude}
\citation{SPALS}
+\citation{dummy}
\citation{kprivacy}
\citation{kanonymity}
\citation{quadtree}
-\citation{dummy}
\@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.2}Vorraussetzungen}{3}{subsection.2.2}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}Ziele}{4}{subsection.2.3}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.4}Anforderungen an die Software}{5}{subsection.2.4}}
-\citation{qrcode}
+\@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.5}Verfahren}{6}{subsection.2.5}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.4}Verfahren}{6}{subsection.2.4}}
\@setckpt{Grundlagen}{
\setcounter{page}{8}
\setcounter{equation}{0}
@@ -26,7 +27,7 @@
\setcounter{mpfootnote}{0}
\setcounter{part}{0}
\setcounter{section}{2}
-\setcounter{subsection}{5}
+\setcounter{subsection}{4}
\setcounter{subsubsection}{0}
\setcounter{paragraph}{0}
\setcounter{subparagraph}{0}
@@ -34,9 +35,9 @@
\setcounter{table}{0}
\setcounter{NAT@ctr}{0}
\setcounter{parentequation}{0}
-\setcounter{Item}{0}
\setcounter{lstlisting}{0}
\setcounter{lstnumber}{1}
+\setcounter{Item}{0}
\setcounter{subfigure}{0}
\setcounter{lofdepth}{1}
\setcounter{subtable}{0}
diff --git a/ausarbeitung/Grundlagen.tex b/ausarbeitung/Grundlagen.tex
index 3f2ec84..f193e69 100644
--- a/ausarbeitung/Grundlagen.tex
+++ b/ausarbeitung/Grundlagen.tex
@@ -1,137 +1,145 @@
\section{Grundlagen}
-In diesem ersten Teil wird der momentane Stand von \textit{location privacy} Software auf mobilen
-Geräten aufgezeigt. \textit{Location privacy} wird von Beresford und Stanjano durch ``...the ability to prevent other parties from
-learning one's current or past position'' \citep{privacy} definiert.\newline
-Des weiteren werden die Anforderungen, die an ein Programm dieser Art gestellt werden, analysiert.
+\textit{Location privacy} wird von Duckham und Kulik durch ``\textit{... 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
+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
+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}
-Da so gut wie alle aktuellen Smart Phones mit dem \textit{Global Positioning System (GPS)} ausgestattet sind existieren für die
-verschiedenen Betriebssysteme schon 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} zu
-betreiben.\newline
+Da so gut wie alle aktuellen Smartphones mit dem \textit{Global Positioning System (GPS)} ausgestattet sind, existieren 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}
+\citep{geocaching} zu betreiben.\newline
Zum Beispiel bietet \textit{Google} den Dienst \textit{Google Latitude} \citep{Latitude} 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
-Um auch im Rahmen solcher Anwendungen die \textit{location privacy} zu wahren, gibt es unterschiedliche Ansätze. So befasst sich
-eine Arbeit mit dem Titel \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS} mit dem Versenden von verschlüsselten
-Daten. Hierfür wurde ein Dienst für mobile Geräte implementiert welcher Daten verschlüsselt an mehrere Nutzer
-sendet. Es wurde ein möglichst einfaches und verlässliches Protokoll entworfen, mit dem Ziel die Berechnungszeiten niedrig zu
-halten. \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
+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
Einen anderer Ansatz verfolgen Gruteser und Grundwald \citep{kprivacy}. Sie versuchen mit Hilfe von \textit{k-anonymity}
-\citep{kanonymity} \textit{location privacy} zu ermöglichen. Man versteht unter \textit{k-anonymity}, dass in
+\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, welcher dieser $k$ Personen
-eines Bereiches die Daten versandt hat.\newline
-Zum Verschleiern der Position nutzen Kido u.a. \citep{dummy} Datensätze die falsche Positionsangaben beinhalten. Dieser wird
-an einen Dienst gesandt, welcher auf den gesamten Datensatz antwortet. Nur der Client weiß, welche der empfangenen Daten auf der
-eigentlichen Position basieren.\newline
-Wie an den vorangegangenen Arbeiten ersichtlich ist, existieren schon ein Reihe von unterschiedlichen Ansätzten um die Wahrung der
-\textit{location privacy} zu ermöglichen.
-
-%anderer titel der section
+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
+
+
\subsection{Vorraussetzungen}
-Um die Privatsphäre der Nutzer, von Diensten wie \textit{Google Latitude}, zu wahren kann neben den bereits existenten auch
-ein anderer Ansatz verfolgt werden. 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}-Standart
+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
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. Um die \textit{location privacy} zu wahren, dürfen die Positionsdaten also nicht für jederman zugänglich sein. Da
-man aus solchen Daten die aktuelle Position erfahren oder Bewegungsprofile erstellen kann, sollten der Zugang zu ihnen nur dann
-erlaubt sein wenn der Benutzer dies erlaubt. Die Daten müssen also soweit entfremdet oder abgeändert werden damit diese nicht
-mehr rekonstruierbar sind, ausser der Benutzer wünscht dies.\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
+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 besitzt. Um diese Kontrolle zu bewahren, müssen die Informationen mit
-einer möglichst transparenten und doch verlässlichen Methode verteilt werden. Auch die Möglichkeit der Speicherung der Daten über
-die Zeit muss hier berücksichtigt werden. Um diesen Punkt zu umgehen sollte man zum Übertragen der Informationen nicht nur auf
-einen zentralen Knoten angewießen sein, sondern nutzt im optimalen Fall ein ganzes Netzwerk von solchen Knotenpunkten.\newline
-Wenn all diese Punkte beim Versenden der Daten berücksichtigt werden, so kann man einen Dienst erstellen welcher die
-Funktionalität eines \textit{Goolge Latitudes} bietet aber auch die \textit{location privacy} des Benutzers wahrt.
+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
+
\subsection{Ziele}
Zusammenfassend kann also gesagt werden, dass eine Software mit den beschriebenen Eigenschaften die Sicherheit der
-Daten, im Kontext von nicht für jeden zugänglich, und das Vermeiden von Vorratsdatenspeicherung zum Ziel haben sollte. Dem
+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 Fachkentniss alle Features anwenden kann, ohne dass die obigen Punkte ausser
+abstrahiert werden, als dass auch ein Benutzer ohne Fachkenntnis alle Features 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 Verschlüsselungen Schlüssel
-voraussetzt, muss ein Verfahren genutzt werden welches den Austausch von zwei Schlüsseln auf einfache Weiße ermöglicht. Allerdings
-muss garantiert sein dass die Schlüssel während des Austausches nicht von Personen abgefangen werden, für die sie nicht bestimmt
-sind. \newline
-Ist ein solches Verfahren gegeben, so muss nun eine Möglichkeit gefunden werden die Daten möglichst sicher und effizient zu
-Verschlüsseln. Es muss also ein Algorithmus genutzt werden, der sowohl sicher ist und mit möglichst geringem Aufwand die Daten
-ver- und entschlüsselt. \newline
-
-Da vermieden werden soll, dass es möglich ist Daten über die Zeit zu sammeln, sollte die Anwendung nicht nur auf einen zentralen
-Knotenpunkt, über den alle Daten fließen, angewießen sein. Es wird also ein dezentrale Struktur benötigt, innerhalb derer man
-einzelne Knoten, über die die Daten gesendet werden, wählen kann. Diese Struktur sollte über ein Protokoll verfügen welches
-die Daten versenden kann. Dieses Protokoll sollte verlässlich, stabil und auch für langsame Netzwerke optimiert sein um eine
-reibungslose Kommunikation zu garantieren. \newline
-
-Ein weiterer, bisher noch nicht berücksichtigter Punkt ist die Plattformunabhängigkeit. Ein solches Programm sollte 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 somit auch möglichst viele Benutzer erreicht und es kann
-auch Kommunikation unter Besitzern von unterschiedlichen Typen von Mobiltelefonen stattfinden.\newline
-
-\subsection{Anforderungen an die Software}
-
-Aus den vorrangegangenen Zielen lassen sich die Anforderungen ableiten die an eine solche Software, neben der Ver- sowie
-Entschlüsselung der Daten und einem dezentralen System zum Versenden der Daten, gestellt werden. Da Positionsdaten versendet
-werden, sollte die Applikation in der Lage sein die Standorte anderer Nutzer anzuzeigen. Um die Position zu visualisieren muss ein
-Format genutzt werden, welches hierfür geeignet ist. Es bietet sich an hierfür das \textit{Latitude}/\textit{Longtitude} Format zu
-nutzen, da es hiermit möglich ist jeden Punkt auf der Erdoberfläche Geokoordinatensystem darzustellen. Des weiteren nutzt
-\textit{GPS} dieses Koordinatenformat. Da aus Gründen der Nutzbarkeit die Positionen der Teilnehmer auf einer Karte dargestellt
-werden sollten muss ein Format für die Karte genutzt werden, welches auf dem mobilen Gerät darstelbar ist und man einfach auf den
-neusten Stand bringen kann.\newline
-Benutzer die sich in größeren Entfernungen befinden sind für Programme dieser Art nur begrenzt interessant. Deshalb werden nur
-Teilnehmer innerhalb eines bestimmten Radiuses angezeigt.\newline
-Um die Kommunikation zwischen verschiedenen Teilnehmern zu ermöglichen sollte es des weiteren möglich sein Chatnachrichten
-auszutauschen. Somit kann die Interaktion der Anwender und somit der Nutzen des Dienstes noch gesteigert werden.\newline
-Die Struktur des Programmes sollte möglichst modular gehalten werden, damit es auch in späteren Phasen den Entwicklern
-leicht fällt bestimmte Programmteile auszutauschen. Somit soll gewährleistet werden das bestimmte Funktionen auch zu einem
-späteren Zeitpunkt ausgetauscht werden können. So wäre es zum Beispiel denkbar verschiedene Algorithmen zur Verschlüsselung oder
-ein anderes Protokoll zum Versenden der Daten zusätzlich zu implementieren oder die bisher genutzten Algrorithmen auszutauschen.
-\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, offenen 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
+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
+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
\subsection{Verfahren}
-Anhanden der Anforderungen müssen nun geeignete Verfahren und Protokolle sowohl für Kommunikation als auch für Verschlüsselung
-gewählt werden. Wie schon erwähnt muss die Verschlüsselung möglichst einfach zu berechnen sein und dabei trotzdem noch
-bestmögliche Sicherheit der Daten bieten. Aus Gründen der Schlüsselverwaltung ist 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, was einen
+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
-Der Austausch der Schlüssel könnte theoretisch auf mehreren Wegen geschehen. So könnte man sie per \textit{Bluetooth} übertragen
-oder einen 2D-Barcode \citep{qrcode} aus der Zeichenkette erstellen, fotographieren und wieder in eine Zeichenkette umwandeln. Da
-\textit{Bluetooth} ein unsicheres Medium darstellt \citep{bluetooth}, der Sitzungs PIN kann per Daten-Phishing wiederhergestellt
-werden, werden die Schlüssel per Barcode verteilt. Es findet somit keine Datenübertragung durch Kommunikation zwischen den
-Geräten statt, womit der Schlüssel auf diesem Weg nicht abgefangen werden kann. \newline
-
-Für die Kommunikation zwischen den einzelnen Teilnehmern ist ein dezentrales Protokoll von Nöten, welches möglichst wenig
-Daten verschickt, die nichts mit der eigentlichen Kommunikation zu tun haben, das stabil läuft und welches beim Ausfallen eines
-Knotenpunktes diesen mit einem anderen ersetzen kann.\newline
-Ein Vorhandenes Protokoll, welches ein aktives Netzwerk bereitstellt das auch rege genutzt wird, ist das \textit{IRC}-Protokoll
-\citep{IRC}. Es stehen bereits mehrere Server zur Verfügung und jeder Nutzer kann einen eigenen Server bereitstellen.
-Jeder Server verwaltet mehrere \textit {Channels}. Würde nun ein Server ausfallen, so könnten die Nutzer auf einen anderen
-\textit{IRC}-Server ausweichen. Des weiteren sind \textit{IRC}-Netzwerke nicht mit einem zentralen Knotenpunkt organisiert,
-sondern bestehen aus mehreren Servern. Somit ist auch die Anforderung der Dezentralität gegeben, da Nutzer beliebig zwischen den
-Servern wechseln können. Das Versenden von Hintergrunddaten, wie zum Beispiel Sitzungsinformationen, ist von der Anwendung
-auf Clientseite frei auswählbar und skalierbar.\newline
-Auf dieses Verfahren soll nun das Protokoll zum Versenden von Textnachrichten sowie Positionsdaten aufsetzten. Die Daten werden
-in beiden Fällen verschlüsselt über einen \textit{IRC}-Channel gesendet und dort ausgegeben. Beim Versenden der Positionen muss
-zwischen Sender und Empfänger unterschieden werden. Dies geschieht, indem dem User ein entsprechender Suffix angehängt wird. Somit
-kann zwischen diesen beiden Diensten unterschieden werden. Beim Kommunizieren mit Textnachrichten muss der Benutzer im Vorfeld
-festlegen mit welchem anderen Teilnehmer er Nachrichten austauschen möchte. Daraufhin werden den zwei Anwendern nur die jeweiligen
-Textnachrichten des anderen aus dem \textit{Channel} angezeigt. \newline
-
-Durch die Wahl dieser Lösung ist sowohl die Berechnungszeiten durch ein symmetrisches Verfahren niedrig gehalten, der
-Verwaltungsaufwand für die Schlüssel gering und die Verteilung der Schlüssel kann durch die angesprochenen Barcodes erfolgen. Bei
-der Kommunikation gibt es keinen einzelnen zentralen Server der den gesamten Datenverkehr einsehen kann. Der Verkehr erfolgt über
-die \textit{IRC}-Server nur in verschlüsselter Form. Des weiteren kann jeder beliebige \textit{IRC}-Server gewählt werden \ No newline at end of file
+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.
+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
+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
+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
diff --git a/ausarbeitung/Grundlagen.tex.backup b/ausarbeitung/Grundlagen.tex.backup
index 3448d21..365bf6e 100644
--- a/ausarbeitung/Grundlagen.tex.backup
+++ b/ausarbeitung/Grundlagen.tex.backup
@@ -1,155 +1,146 @@
\section{Grundlagen}
-In diesem ersten Teil wird der momentane Stand von \textit{location privacy} Software auf mobilen
-Geräten aufgezeigt. \textit{Location privacy} wird von Beresford und Stanjano durch ``...the ability to prevent other parties from
-learning one's current or past position'' \citep{privacy} definiert.\newline
-Des weiteren werden die Anforderungen, die an ein Programm dieser Art gestellt werden, analysiert.
+\textit{Location privacy} wird von Duckham und Kulik durch ``\textit{... 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
+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
+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}
-Da so gut wie alle aktuellen Smart Phones mit dem \textit{Global Positioning System (GPS)} ausgestattet sind existieren für die
-verschiedenen Betriebssysteme schon 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} zu
-betreiben.\newline
+Da so gut wie alle aktuellen Smartphones mit dem \textit{Global Positioning System (GPS)} ausgestattet sind, existieren 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}
+\citep{geocaching} zu betreiben.\newline
Zum Beispiel bietet \textit{Google} den Dienst \textit{Google Latitude} \citep{Latitude} 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
-Um auch im Rahmen solcher Anwendungen die \textit{location privacy} zu wahren, gibt es unterschiedliche Ansätze. So befasst sich
-eine Arbeit mit dem Titel \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS} mit dem Versenden von verschlüsselten
-Daten. Hierfür wurde ein Dienst für mobile Geräte implementiert welcher Daten verschlüsselt an mehrere Nutzer
-sendet. Es wurde ein möglichst einfaches und verlässliches Protokoll entworfen, mit dem Ziel die Berechnungszeiten niedrig zu
-halten. \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
+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
Einen anderer Ansatz verfolgen Gruteser und Grundwald \citep{kprivacy}. Sie versuchen mit Hilfe von \textit{k-anonymity}
-\citep{kanonymity} \textit{location privacy} zu ermöglichen. Man versteht unter \textit{k-anonymity}, dass in
+\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, welcher dieser $k$ Personen
-eines Bereiches die Daten versandt hat.\newline
-Zum Verschleiern der Position nutzen Kido u.a. \citep{dummy} Datensätze die falsche Positionsangaben beinhalten. Dieser wird
-an einen Dienst gesandt, welcher auf den gesamten Datensatz antwortet. Nur der Client weiß, welche der empfangenen Daten auf der
-eigentlichen Position basieren.\newline
-Wie an den vorangegangenen Arbeiten ersichtlich ist, existieren schon ein Reihe von unterschiedlichen Ansätzten um die Wahrung der
-\textit{location privacy} zu ermöglichen.
+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
+
%anderer titel der section
\subsection{Vorraussetzungen}
-Um die Privatsphäre der Nutzer, von Diensten wie \textit{Google Latitude}, zu wahren können neben den bereits existenten auch
-ein anderer Ansatz verfolgt werden. Da die Verbreitung von mobilen Geräten hat 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}-Standart
+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
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. Um die \textit{location privacy} zu wahren, dürfen die Positionsdaten also nicht für jederman zugänglich sein. Da
-man aus solchen Daten die aktuelle Position erfahren oder Bewegungsprofile erstellen kann, sollten der Zugang zu ihnen nur dann
-erlaubt sein wenn der Benutzer dies erlaubt. Die Daten müssen also soweit entfremdet oder abgeändert werden damit diese nicht
-mehr zu rekonstruieren sind, ausser der Benutzer wünscht dies.\newline
-Ist dies gegeben, sollen die Daten im nächsten Schritt versendet werden. Auch hier sollte ein Weg gefunden werden, damit der
-Nutzer auch hierüber möglichst viel Kontrolle über seine Datensätze besitzt. Um auch diese Kontrolle zu bewahren müssen die
-Informationen mit einer möglichst transparenten und doch verlässlichen Methode verteilt werden. Auch die Möglichkeit der
-Speicherung der Daten über die Zeit muss hier berücksichtigt werden. Um diesen Punkt zu umgehen sollte man also zum
-übertragen nicht nur auf einen zentralen Knoten angewießen sein, sondern nutzt im optimalen Fall ein ganzes Netzwerk von solchen
-Knotenpunkten.\newline
-Wenn all diese Punkte beim übertragen der Daten berücksichtigt werden, so kann man einen Dienst erstellen welcher die
-Funktionalität eines \textit{Goolge Latitudes} bietet aber auch die \textit{location privacy} des Benutzers wahrt.
+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
+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
+
\subsection{Ziele}
Zusammenfassend kann also gesagt werden, dass eine Software mit den beschriebenen Eigenschaften die Sicherheit der
-Daten, im Kontext von nicht für jeden zugänglich, und auf das Vermeiden von Vorratsdatenspeicherung zum Ziel haben sollte. Dem
+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 das auch ein Benutzer ohne Fachkentniss alle Features anwenden kann, ohne dass die obigen Punkte ausser
+abstrahiert werden, als dass auch ein Benutzer ohne Fachkenntnis alle Features nutzen kann, ohne dass die obigen Punkte ausser
Kraft treten. \newline
-Um die Positionsdaten nicht für jederman zugänglich zu machen sollen diese verschlüsselt werden. Da Verschlüsselungen Schlüssel
-benötigen muss ein Verfahren genutzt werden welches den Austausch von zwei Schlüsseln auf einfache Weiße ermöglicht. Allerdings
-darf darunter nicht die Tatsache leiden, dass die Schlüssel während des Austausches nicht von Personen abgefangen werden dürfen,
-für die sie nicht bestimmt sind. \newline
-Ist ein solches Verfahren gegeben, so muss nun eine Möglichkeit gefunden werden die Daten möglichst sicher und effizient zu
-Verschlüsseln. Es muss also ein Algorithmus genutzt werden, der sowohl sicher ist und mit möglichst geringem Aufwand die Daten
-ver- und entschlüsselt. \newline
-
-Um zu vermeiden, dass es möglich ist Daten über die Zeit zu sammeln sollte die Anwendung nicht nur auf einen zentralen
-Knotenpunkt, über den alle Daten fließen, angewießen sein. Es wird also ein dezentrale Struktur benötigt innerhalb derer man
-einzelne Knoten, über die die Daten gesendet werden, wählen kann. Diese Struktur sollte über ein Protokoll verfügen, welches
-die Daten versenden kann. Dieses Protokoll sollte verlässlich, stabil und auch für langsame Netzwerke optimiert sein um eine
-reibungslose Kommunikation zu garantieren. \newline
-
-Ein weiterer, bisher noch nicht berücksichtigter Punkt ist die Plattformunabhängigkeit. Ein solches Programm sollte 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 somit auch möglichst viele Benutzer erreicht und es kann
-auch Kommunikation zwischen Besitzern von unterschiedlichen Typen von Mobiltelefonen stattfinden.\newline
-
-\subsection{Anforderungen an die Software}
-
-Aus den vorrangegangenen Zielen lassen sich die Anforderungen ableiten die an eine solche Software, neben der Ver- sowie
-Entschlüsselung der Daten und einem dezentralen System zum Versenden der Daten, gestellt werden. Da Positionsdaten versendet
-werden, sollte die Applikation in der Lage sein die Standorte anderer Nutzer anzuzeigen. Um die Position zu visualisieren muss ein
-Format genutzt werden, welches hierfür geeignet ist. Es bietet sich an hierfür das \textit{Latitude}/\textit{Longtitude} Format zu
-nutzen, da es hiermit möglich ist jeden Punkt auf der Erdoberfläche Geokoordinatensystem darzustellen. Des weiteren nutzt
-\textit{GPS} dieses Koordinatenformat. Um zu verhindern dass die Daten von jedem gelesen werden können müssen diese
-Positionsdaten in verschlüsselter Form versendet werden. \newline
-
-Um die Position anderer Teilnehmer zu visualisieren sollte das Programm in der Lage sein, die eigehenden Positionsdaten sowohl zu
-entschlüsseln, als auch diese auf einer Karte darzustellen. Des weiteren muss ein Format für die Karte genutzt werden, welches auf
-dem mobilen Gerät darstelbar ist und man einfach auf den neusten Stand bringen kann. Es werden nur Benutzer innerhalb
-eines Radiuses angezeigt, da die Positionen von Teilnehmern, die sich in größerer Entfernung befinden, schwerer zu erreichen
-sind.\newline
-
-Um die Kommunikation zwischen verschiedenen Teilnehmern zu ermöglichen sollte es möglich sein Chatnachrichten auszutauschen. Auch
-hier muss gewährleistet sein, dass der Datenverkehr verschlüsselt abläuft und somit das mitlesen der Konversation nicht möglich
-ist. \newline
-
-Um einen Schlüssel an eine Person weiterzugeben, deren Positon man sehen oder mit ihr kommunizieren möchte, muss es eine
-Möglichkeit geben diesen Schlüssel auf einfach Weise weiterzugeben. Es ist allerdings darauf zu achten, dass dieser
-Schlüssel nicht während der übertragung abgefangen werden kann, da die Kommunikation ansonsten nichtmehr sicher wäre.\newline
-
-Auf dem Markt sind aktuell viele unterschiedliche Betriebsysteme für Smartphones vertreten. Um möglichst viele Benutzer zu
-erreichen sollte das Programm der Lage sein auf möglichst vielen dieser Plattformen zu arbeiten. Im Zuge dieser
-Plattformunabhängigkeit sollte die Software in einer Sprache implementiert werden, die von möglichst vielen
-Betriebssystemen der mobilen Geräte unterstützt wird. \newline
-
-Die Struktur des Programmes sollte möglichst modular gehalten werden, damit es auch in späteren Phasen den Entwicklern
-leicht fällt bestimmte Programmteile auszutauschen. Somit soll gewährleistet werden das bestimmte Funktionen auch zu einem
-späteren Zeitpunkt ausgetauscht werden können. So wäre es zum Beispiel denkbar verschiedene Algorithmen zur Verschlüsselung oder
-ein anderes Protokoll zum Versenden der Daten zusätzlich zu implementieren oder die bisher genutzten Algrorithmen auszutauschen.
-\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
+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
+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
+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
\subsection{Verfahren}
-Anhanden der Anforderungen müssen nun geeignete Verfahren und Protokolle sowohl für Kommunikation als auch für Verschlüsselung
-gewählt werden. Wie schon erwähnt muss die Verschlüsselung möglichst einfach zu berechnen sein und dabei trotzdem noch
-bestmögliche Verschlüsselung bieten. Aus Gründen des Berechnungsaufwand als auch von Schlüsselverwaltung ist 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, was einen wichtigen Punkt auf mobilen Geräten darstellt. \newline
-
-Der Austausch der Schlüssel könnte theoretisch auf mehreren Wegen geschehen. So könnte man sie per \textit{Bluetooth} übertragen
-oder einen 2D-Barcode \citep{qrcode} aus der Zeichenkette erstellen, fotographieren und wieder in eine Zeichenkette umwandeln. Da
-\textit{Bluetooth} ein unsicheres Medium darstellt \citep{bluetooth}, der Sitzungs PIN kann per Daten-Phishing wiederhergestellt
-werden, werden die Schlüssel per Barcode verteilt. Es findet somit keine Datenübertragung durch Kommunikation zwischen den
-Geräten statt, womit der Schlüssel auf diesem Weg nicht abgefangen werden kann. \newline
-
-Für die Kommunikation zwischen den einzelnen Teilnehmern ist ein dezentrales Protokoll von Nöten, welches möglichst wenig
-Daten verschickt, die nichts mit der eigentlichen Kommunikation zu tun haben, das stabil läuft und welches beim Ausfallen eines
-Knotenpunktes diesen mit einem anderen ersetzen kann.\newline
-Ein Vorhandenes Protokoll, welches ein aktives Netzwerk bereitstellt das auch rege genutzt wird, ist das \textit{IRC}-Protokoll
-\citep{IRC}. Es stehen bereits mehrere Server zur Verfügung und jeder Nutzer kann einen eigenen Server bereitstellen.
-Jeder Server verwaltet mehrere \textit {Channels}. Würde nun ein Server ausfallen, so könnten die Nutzer auf einen anderen
-\textit{IRC}-Server ausweichen. Des weiteren sind \textit{IRC}-Netzwerke nicht mit einem zentralen Knotenpunkt organisiert,
-sondern bestehen aus mehreren Servern. Somit ist auch die Anforderung der Dezentralität gegeben, da Nutzer beliebig zwischen den
-Servern wechseln können. Das Versenden von Hintergrunddaten, wie zum Beispiel Sitzungsinformationen, ist von der Anwendung
-auf Clientseite frei auswählbar und skalierbar.\newline
-Auf dieses Verfahren soll nun das Protokoll zum Versenden von Textnachrichten sowie Positionsdaten aufsetzten. Die Daten werden
-in beiden Fällen verschlüsselt über einen \textit{IRC}-Channel gesendet und dort ausgegeben. Beim Versenden der Positionen muss
-zwischen Sender und Empfänger unterschieden werden. Dies geschieht, indem dem User ein entsprechender Suffix angehängt wird. Somit
-kann zwischen diesen beiden Diensten unterschieden werden. Beim Kommunizieren mit Textnachrichten muss der Benutzer im Vorfeld
-festlegen mit welchem anderen Teilnehmer er Nachrichten austauschen möchte. Daraufhin werden den zwei Anwendern nur die jeweiligen
-Textnachrichten des anderen aus dem \textit{Channel} angezeigt. \newline
-
-Durch die Wahl dieser Lösung ist sowohl die Berechnungszeiten durch ein symmetrisches Verfahren niedrig gehalten, der
-Verwaltungsaufwand für die Schlüssel gering und die Verteilung der Schlüssel kann durch die angesprochenen Barcodes erfolgen. Bei
-der Kommunikation gibt es keinen einzelnen zentralen Server der den gesamten Datenverkehr einsehen kann. Der Verkehr erfolgt über
-die \textit{IRC}-Server nur in verschlüsselter Form. Des weiteren kann jeder beliebige \textit{IRC}-Server gewählt werden. Somit
-sind die Eingangs erwähnten Punkte, Verschlüsselung und dezentralles Protokoll, hiermit abgedeckt und die Privatsphäre ist für den
-Anwender, im Unterschied zu den meisten anderen Anwendungen dieser Art, gesichert. \ No newline at end of file
+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
+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
+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
+
+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
+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 sowohl 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
diff --git a/ausarbeitung/Grundlagen.tex~ b/ausarbeitung/Grundlagen.tex~
index e013ef1..c5f6a4e 100644
--- a/ausarbeitung/Grundlagen.tex~
+++ b/ausarbeitung/Grundlagen.tex~
@@ -1,137 +1,148 @@
\section{Grundlagen}
-In diesem ersten Teil wird der momentane Stand von \textit{location privacy} Software auf mobilen
-Geräten aufgezeigt. \textit{Location privacy} wird von Beresford und Stanjano durch ``...the ability to prevent other parties from
-learning one's current or past position'' \citep{privacy} definiert.\newline
-Des weiteren werden die Anforderungen, die an ein Programm dieser Art gestellt werden, analysiert.
+\textit{Location privacy} wird von Duckham und Kulik durch ``\textit{... 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
+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
+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}
-Da so gut wie alle aktuellen Smart Phones mit dem \textit{Global Positioning System (GPS)} ausgestattet sind existieren für die
-verschiedenen Betriebssysteme schon 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} zu
-betreiben.\newline
+Da so gut wie alle aktuellen Smartphones mit dem \textit{Global Positioning System (GPS)} ausgestattet sind, existieren 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}
+\citep{geocaching} zu betreiben.\newline
Zum Beispiel bietet \textit{Google} den Dienst \textit{Google Latitude} \citep{Latitude} 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
-Um auch im Rahmen solcher Anwendungen die \textit{location privacy} zu wahren, gibt es unterschiedliche Ansätze. So befasst sich
-eine Arbeit mit dem Titel \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS} mit dem Versenden von verschlüsselten
-Daten. Hierfür wurde ein Dienst für mobile Geräte implementiert welcher Daten verschlüsselt an mehrere Nutzer
-sendet. Es wurde ein möglichst einfaches und verlässliches Protokoll entworfen, mit dem Ziel die Berechnungszeiten niedrig zu
-halten. \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
+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
Einen anderer Ansatz verfolgen Gruteser und Grundwald \citep{kprivacy}. Sie versuchen mit Hilfe von \textit{k-anonymity}
-\citep{kanonymity} \textit{location privacy} zu ermöglichen. Man versteht unter \textit{k-anonymity}, dass in
+\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, welcher dieser $k$ Personen
-eines Bereiches die Daten versandt hat.\newline
-Zum Verschleiern der Position nutzen Kido u.a. \citep{dummy} Datensätze die falsche Positionsangaben beinhalten. Dieser wird
-an einen Dienst gesandt, welcher auf den gesamten Datensatz antwortet. Nur der Client weiß, welche der empfangenen Daten auf der
-eigentlichen Position basieren.\newline
-Wie an den vorangegangenen Arbeiten ersichtlich ist, existieren schon ein Reihe von unterschiedlichen Ansätzten um die Wahrung der
-\textit{location privacy} zu ermöglichen.
+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
+
%anderer titel der section
\subsection{Vorraussetzungen}
-Um die Privatsphäre der Nutzer, von Diensten wie \textit{Google Latitude}, zu wahren kann neben den bereits existenten auch
-ein anderer Ansatz verfolgt werden. 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}-Standart
+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
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. Um die \textit{location privacy} zu wahren, dürfen die Positionsdaten also nicht für jederman zugänglich sein. Da
-man aus solchen Daten die aktuelle Position erfahren oder Bewegungsprofile erstellen kann, sollten der Zugang zu ihnen nur dann
-erlaubt sein wenn der Benutzer dies erlaubt. Die Daten müssen also soweit entfremdet oder abgeändert werden damit diese nicht
-mehr rekonstruierbar sind, ausser der Benutzer wünscht dies.\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
+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 besitzt. Um diese Kontrolle zu bewahren, müssen die Informationen mit
-einer möglichst transparenten und doch verlässlichen Methode verteilt werden. Auch die Möglichkeit der Speicherung der Daten über
-die Zeit muss hier berücksichtigt werden. Um diesen Punkt zu umgehen sollte man zum Übertragen der Informationen nicht nur auf
-einen zentralen Knoten angewießen sein, sondern nutzt im optimalen Fall ein ganzes Netzwerk von solchen Knotenpunkten.\newline
-Wenn all diese Punkte beim Versenden der Daten berücksichtigt werden, so kann man einen Dienst erstellen welcher die
-Funktionalität eines \textit{Goolge Latitudes} bietet aber auch die \textit{location privacy} des Benutzers wahrt.
+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
+
\subsection{Ziele}
Zusammenfassend kann also gesagt werden, dass eine Software mit den beschriebenen Eigenschaften die Sicherheit der
-Daten, im Kontext von nicht für jeden zugänglich, und das Vermeiden von Vorratsdatenspeicherung zum Ziel haben sollte. Dem
+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 Fachkentniss alle Features anwenden kann, ohne dass die obigen Punkte ausser
+abstrahiert werden, als dass auch ein Benutzer ohne Fachkenntnis alle Features 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 Verschlüsselungen Schlüssel
-voraussetzt, muss ein Verfahren genutzt werden welches den Austausch von zwei Schlüsseln auf einfache Weiße ermöglicht. Allerdings
-muss garantiert sein dass die Schlüssel während des Austausches nicht von Personen abgefangen werden, für die sie nicht bestimmt
-sind. \newline
-Ist ein solches Verfahren gegeben, so muss nun eine Möglichkeit gefunden werden die Daten möglichst sicher und effizient zu
-Verschlüsseln. Es muss also ein Algorithmus genutzt werden, der sowohl sicher ist und mit möglichst geringem Aufwand die Daten
-ver- und entschlüsselt. \newline
-
-Da vermieden werden soll, dass es möglich ist Daten über die Zeit zu sammeln, sollte die Anwendung nicht nur auf einen zentralen
-Knotenpunkt, über den alle Daten fließen, angewießen sein. Es wird also ein dezentrale Struktur benötigt, innerhalb derer man
-einzelne Knoten, über die die Daten gesendet werden, wählen kann. Diese Struktur sollte über ein Protokoll verfügen, welches
-die Daten versenden kann. Dieses Protokoll sollte verlässlich, stabil und auch für langsame Netzwerke optimiert sein um eine
-reibungslose Kommunikation zu garantieren. \newline
-
-Ein weiterer, bisher noch nicht berücksichtigter Punkt ist die Plattformunabhängigkeit. Ein solches Programm sollte 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 somit auch möglichst viele Benutzer erreicht und es kann
-auch Kommunikation zwischen Besitzern von unterschiedlichen Typen von Mobiltelefonen stattfinden.\newline
-
-\subsection{Anforderungen an die Software}
-
-Aus den vorrangegangenen Zielen lassen sich die Anforderungen ableiten die an eine solche Software, neben der Ver- sowie
-Entschlüsselung der Daten und einem dezentralen System zum Versenden der Daten, gestellt werden. Da Positionsdaten versendet
-werden, sollte die Applikation in der Lage sein die Standorte anderer Nutzer anzuzeigen. Um die Position zu visualisieren muss ein
-Format genutzt werden, welches hierfür geeignet ist. Es bietet sich an hierfür das \textit{Latitude}/\textit{Longtitude} Format zu
-nutzen, da es hiermit möglich ist jeden Punkt auf der Erdoberfläche Geokoordinatensystem darzustellen. Des weiteren nutzt
-\textit{GPS} dieses Koordinatenformat. Da aus Gründen der Nutzbarkeit die Positionen der Teilnehmer auf einer Karte dargestellt
-werden sollten muss ein Format für die Karte genutzt werden, welches auf dem mobilen Gerät darstelbar ist und man einfach auf den
-neusten Stand bringen kann.\newline
-Benutzer die sich in größeren Entfernungen befinden sind für Programme dieser Art nur begrenzt interessant. Deshalb werden nur
-Teilnehmer innerhalb eines bestimmten Radiuses angezeigt.\newline
-Um die Kommunikation zwischen verschiedenen Teilnehmern zu ermöglichen sollte es des weiteren möglich sein Chatnachrichten
-auszutauschen. Somit kann die Interaktion der Anwender und somit der Nutzen des Dienstes noch gesteigert werden.\newline
-Die Struktur des Programmes sollte möglichst modular gehalten werden, damit es auch in späteren Phasen den Entwicklern
-leicht fällt bestimmte Programmteile auszutauschen. Somit soll gewährleistet werden das bestimmte Funktionen auch zu einem
-späteren Zeitpunkt ausgetauscht werden können. So wäre es zum Beispiel denkbar verschiedene Algorithmen zur Verschlüsselung oder
-ein anderes Protokoll zum Versenden der Daten zusätzlich zu implementieren oder die bisher genutzten Algrorithmen auszutauschen.
-\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, offenen 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
+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
+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
\subsection{Verfahren}
-Anhanden der Anforderungen müssen nun geeignete Verfahren und Protokolle sowohl für Kommunikation als auch für Verschlüsselung
-gewählt werden. Wie schon erwähnt muss die Verschlüsselung möglichst einfach zu berechnen sein und dabei trotzdem noch
-bestmögliche Sicherheit der Daten bieten. Aus Gründen der Schlüsselverwaltung ist 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, was einen
+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
-Der Austausch der Schlüssel könnte theoretisch auf mehreren Wegen geschehen. So könnte man sie per \textit{Bluetooth} übertragen
-oder einen 2D-Barcode \citep{qrcode} aus der Zeichenkette erstellen, fotographieren und wieder in eine Zeichenkette umwandeln. Da
-\textit{Bluetooth} ein unsicheres Medium darstellt \citep{bluetooth}, der Sitzungs PIN kann per Daten-Phishing wiederhergestellt
-werden, werden die Schlüssel per Barcode verteilt. Es findet somit keine Datenübertragung durch Kommunikation zwischen den
-Geräten statt, womit der Schlüssel auf diesem Weg nicht abgefangen werden kann. \newline
-
-Für die Kommunikation zwischen den einzelnen Teilnehmern ist ein dezentrales Protokoll von Nöten, welches möglichst wenig
-Daten verschickt, die nichts mit der eigentlichen Kommunikation zu tun haben, das stabil läuft und welches beim Ausfallen eines
-Knotenpunktes diesen mit einem anderen ersetzen kann.\newline
-Ein Vorhandenes Protokoll, welches ein aktives Netzwerk bereitstellt das auch rege genutzt wird, ist das \textit{IRC}-Protokoll
-\citep{IRC}. Es stehen bereits mehrere Server zur Verfügung und jeder Nutzer kann einen eigenen Server bereitstellen.
-Jeder Server verwaltet mehrere \textit {Channels}. Würde nun ein Server ausfallen, so könnten die Nutzer auf einen anderen
-\textit{IRC}-Server ausweichen. Des weiteren sind \textit{IRC}-Netzwerke nicht mit einem zentralen Knotenpunkt organisiert,
-sondern bestehen aus mehreren Servern. Somit ist auch die Anforderung der Dezentralität gegeben, da Nutzer beliebig zwischen den
-Servern wechseln können. Das Versenden von Hintergrunddaten, wie zum Beispiel Sitzungsinformationen, ist von der Anwendung
-auf Clientseite frei auswählbar und skalierbar.\newline
-Auf dieses Verfahren soll nun das Protokoll zum Versenden von Textnachrichten sowie Positionsdaten aufsetzten. Die Daten werden
-in beiden Fällen verschlüsselt über einen \textit{IRC}-Channel gesendet und dort ausgegeben. Beim Versenden der Positionen muss
-zwischen Sender und Empfänger unterschieden werden. Dies geschieht, indem dem User ein entsprechender Suffix angehängt wird. Somit
-kann zwischen diesen beiden Diensten unterschieden werden. Beim Kommunizieren mit Textnachrichten muss der Benutzer im Vorfeld
-festlegen mit welchem anderen Teilnehmer er Nachrichten austauschen möchte. Daraufhin werden den zwei Anwendern nur die jeweiligen
-Textnachrichten des anderen aus dem \textit{Channel} angezeigt. \newline
-
-Durch die Wahl dieser Lösung ist sowohl die Berechnungszeiten durch ein symmetrisches Verfahren niedrig gehalten, der
-Verwaltungsaufwand für die Schlüssel gering und die Verteilung der Schlüssel kann durch die angesprochenen Barcodes erfolgen. Bei
-der Kommunikation gibt es keinen einzelnen zentralen Server der den gesamten Datenverkehr einsehen kann. Der Verkehr erfolgt über
-die \textit{IRC}-Server nur in verschlüsselter Form. Des weiteren kann jeder beliebige \textit{IRC}-Server gewählt werden \ No newline at end of file
+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.
+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
+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
+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
diff --git a/ausarbeitung/Title.aux b/ausarbeitung/Title.aux
index d8d1b2d..0dc42de 100644
--- a/ausarbeitung/Title.aux
+++ b/ausarbeitung/Title.aux
@@ -18,9 +18,9 @@
\setcounter{table}{0}
\setcounter{NAT@ctr}{0}
\setcounter{parentequation}{0}
-\setcounter{Item}{0}
\setcounter{lstlisting}{0}
\setcounter{lstnumber}{1}
+\setcounter{Item}{0}
\setcounter{subfigure}{0}
\setcounter{lofdepth}{1}
\setcounter{subtable}{0}
diff --git a/ausarbeitung/Tutorial.aux b/ausarbeitung/Tutorial.aux
index 597a60d..aa134cd 100644
--- a/ausarbeitung/Tutorial.aux
+++ b/ausarbeitung/Tutorial.aux
@@ -38,9 +38,9 @@
\setcounter{table}{0}
\setcounter{NAT@ctr}{0}
\setcounter{parentequation}{0}
-\setcounter{Item}{0}
\setcounter{lstlisting}{0}
\setcounter{lstnumber}{1}
+\setcounter{Item}{0}
\setcounter{subfigure}{0}
\setcounter{lofdepth}{1}
\setcounter{subtable}{0}
diff --git a/ausarbeitung/Tutorial.tex b/ausarbeitung/Tutorial.tex
index b824145..f366c88 100644
--- a/ausarbeitung/Tutorial.tex
+++ b/ausarbeitung/Tutorial.tex
@@ -5,49 +5,39 @@ benötigte Hardware, wie zum Beispiel \textit{GPS} oder eine Kamera besitzen, zu
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 GPS oder Lagesensoren sind in den meisten, aktuellen Geräten vorhanden oder werden in der
-nächsten Generation, des jeweiligen Herstellers, vorhanden sein.\newline
-
-Die Wahl der Plattform aufgrund des Betriebssystemes gestalltet sich schon schwerer. 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
+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} interessant, welchen man mit den immer gleichen Programmbibliotheken nutzen kann, unabhängig was
-diesem \textit{Layer} für ein System zu Grunde liegt. Dieser \textit{Layer} soll also eine Schnittstelle zwischen Anwendungen und
-Betriebssytem repräsentieren. Ein \textit{Layer} welcher genau diese Anforderungen erfüllt ist der \textit{Portable Operating
-System Interface for Unix Layer (POSIX Layer)} \citep{POSIX}. 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
+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
+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
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.\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
+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
+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} 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
\subsubsection{Android}
@@ -56,21 +46,21 @@ Kernel kümmert sich um die Prozess- und Speicherverwaltung, Kommunikation sowie
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} 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
\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
+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
\subsubsection{iPhone OS}
@@ -90,12 +80,14 @@ ermöglicht Programme direkt zu portieren. Des weitern besitzt \textit{Symian OS
\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
+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 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.
@@ -112,7 +104,7 @@ Da \textit{Windows Mobile} und die Programmiersprache \textit{C} genutzt wird, w
\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
-Es wird zwischen zwei verschiedenen Arten des \textit{CeGCC's} unterschieden. Zum Einen \textit{CeGCC}, zum Anderen
+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}
@@ -124,8 +116,8 @@ kompiliert werden.
\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
+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.
@@ -153,4 +145,5 @@ ist und gezeichnet werden soll. Die Bibliothek \textit{Evas} ist eine \textit{ca
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.backup b/ausarbeitung/Tutorial.tex.backup
index f33eb1f..c4ee8cb 100644
--- a/ausarbeitung/Tutorial.tex.backup
+++ b/ausarbeitung/Tutorial.tex.backup
@@ -1,34 +1,41 @@
\section{Technische Grundlagen}
-Ein wichtiger Punkt ist auch die Wahl der passenden Plattform. Bei geeigneter Wahl dieser ist es möglich die Software auf mehrere
-Betriebssysteme für Smart Phones zu portieren und somit eine mehrfache Implementation zu vermeiden. Es wäre somit auch möglich
-viele Nutzer zu erreichen und auch die Kommunikation zwischen einem Besitzer eines \textit{iPhones} sowie dem Besitzer eines
-\textit{Palm Pre} sicherzustellen.\newline
+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.
-Grundlegend sind Betriebsysteme interessant, die über einen \textit{Layer} verfügen mit welchem man eine große Anzahl an
-Bibliotheken und Schnittstellen ansprechen kann. Dieser Layer soll also eine Schnittstelle zwischen Anwendungen und Betriebssytem
-sein. Ein solcher ist der \textit{Portable Operating System Interface for UniX} Layer (\textit{POSIX Layer}). Mit diesem
-LayerDurch stehen eine große Menge an aktuellen Bibliotheken, aus der \textit{Open-Source} Gemeinde, zur Verfügung welche auch
-aktiv weiterentwickelt werden. Anwendungen die auf einem \textit{Linux}-System entwickelt wurden können somit auch ohne weiteres
-auf ein anderes, \textit{POSIX} kompatibles System, portiert werden.\newline
-Auch die Frage der unterstützten Programmiersprachen stellt sich, da das Programm nicht ständig neu implementiert werden soll,
+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
+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
+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
-Die Problematik der Plattformwahl aufgrund von vorhandener oder nicht vorhandener Hardware ist im Vergleich nicht allzu
-groß. So haben mittlerweile die meisten der aktuellen Geräte eine ähnliche Ausstattung was Speicher und Prozessorleistung angeht.
-Auch erweiterte Features wie GPS oder Lagesensoren sind in den meisten aktuellen Geräten vorhanden oder werden in der nächsten
-Generation, des jeweiligen Herstellers, vorhanden sein.\newline
-
\subsection{Betriebsysteme für mobile Geräte}
-Wie schon erwähnt ist die wahl einer geeigneten Plattform nicht unerheblich. Im folgenden werden fünf Betriebssysteme für mobile
+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.
\subsubsection{Windows Mobile}
Der wohl bekannteste Vertreter ist \textit{Windows Mobile}. Die aktuelle Version 6.5 wurde von Microsoft
-auch \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
+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
@@ -47,14 +54,14 @@ Programme die in \textit{C}/\textit{C++} geschrieben wurden für diese Plattform
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 ein virtuelle Java-Maschine auf, in welcher \textit{Android} läuft.\newline
+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{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} gelieferten stabil auf den Geräten stabil
-sind. Allerdings ergeben sich hier für die Zukunft, sobald mehr Bibliotheken stabil unterstützt werden, sicher
+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
\subsubsection{WebOS}
@@ -62,18 +69,18 @@ interessante Möglichkeiten für Anwendungsentwicklung und Portierung.\newline
\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 existiert
-eine Erweiterung des \textit{POSIX Layers} names \textit{PIPS}. Es werden somit mehrere Programmiersprachen unterstützt
-und es besteht die Möglichkeit den \textit{POSIX Layer} zu nutzen.\newline
+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
\subsubsection{iPhone OS}
-Bei \textit{iPhoneOS} \citep{iPhoneOS} handelt es sich um eine portierte 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}. Der größte Kritikpunkt an diesem System dürfte
-allerdings das fehlen von \textit{Multitasking}-Unterstützung sein. 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
+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
+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
\subsubsection{Symbian OS}
@@ -85,31 +92,32 @@ ermöglicht Programme direkt zu portieren. Des weitern besitzt \textit{Symian OS
\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 auf nach \textit{Windows Mobile} zu portieren. \newline
+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
+wäre. \textit{Android} hat zwar eine \textit{C} Unterstützung, allerdings gibt der Hersteller an das nicht alle Bibliotheken
stabil sind.\newline
Aufgrund der Implementierung in \textit{C} ist es auch möglich das Programm für \textit{WebOS} und \textit{SymbianOS} zu
kompilieren.
\subsection{Softwaregrundlagen}
-Aufgrund der gewählten Zielplattform und Programmiersprache muss nun eine Möglichkeit gefunden werden das Programm sowohl für die
+Anhand der gewählten Zielplattform und Programmiersprache muss nun eine Möglichkeit gefunden werden das Programm sowohl für die
jeweiligen Plattformen zu kompilieren, sowie die graphischen Elemente auf den Plattformen darzustellen.
\subsubsection{CeGCC}
-Da \textit{Windows Mobile} und die Programmiersprache \textit{C} genutzt wird, wird der \textit{CeGCC} \citep{CeGCC} als
-\textit{Cross-Compiler} verwendet. Mit ihm ist es möglich Programmcode, der unter \textit{Linux} entwickelt wurde nach
+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
\textit{Windows Mobile} zu portieren. Bei \textit{CeGCC} handelt es sich um ein \textit{Open-Source} Projekt, bassierend auf dem
-GCC. Mit diesem Tool können in einer \textit{Linux} Umgebung die für \textit{Windows Mobile} benötigten Bibliotheken und
+\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
-Es wird zwischen zwei verschiedenen Arten des CeGCC's unterschieden. Zum Einen \textit{CeGCC}, zum Anderen \textit{mingw32ce}.
+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 nutzt. Der \textit{mingw32ce}-Kompiler wird dann gebraucht, wenn man auch \textit{Windows Mobile}
-Bibliotheken einbinden möchte.\newline
+Bibliotheken einbinden möchte. Der \textit{mingw32ce}-Kompiler wird dann gebraucht, wenn auch \textit{Windows Mobile}
+Bibliotheken zum Einstatz kommen.\newline
Soll das Programm nun für \textit{WebOS} oder \textit{SymbianOS} portiert werden, kann dies auf unter \textit{Linux} normal
kompiliert werden.
@@ -117,8 +125,8 @@ kompiliert werden.
\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
+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.
@@ -139,11 +147,11 @@ 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 \textit{library} welche das serialisieren von mehreren Programmteilen ermöglicht und
+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,
welche mit einer internen \textit{state machine} und einem Zustandsgraphen speichert was wo, in welcher Farbe und wie sichtbar
-ist und gezeichnet wird. Die Bibliothek \textit{Evas} ist eine \textit{canvas}-Bibliothek, welche sich um Effekte wie
+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 ist eine genaue Anweisung zu finden, um \textit{Enlightenment} für \textit{Windows Mobile} zu erstellen. \ No newline at end of file
+Im Anhang 1 sind genaue Anweisungen zu finden, um \textit{Enlightenment} für \textit{Windows Mobile} zu portieren. \ No newline at end of file
diff --git a/ausarbeitung/Tutorial.tex~ b/ausarbeitung/Tutorial.tex~
index 9c24222..5560397 100644
--- a/ausarbeitung/Tutorial.tex~
+++ b/ausarbeitung/Tutorial.tex~
@@ -5,49 +5,39 @@ benötigte Hardware, wie zum Beispiel \textit{GPS} oder eine Kamera besitzen, zu
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 GPS oder Lagesensoren sind in den meisten, aktuellen Geräten vorhanden oder werden in der
-nächsten Generation, des jeweiligen Herstellers, vorhanden sein.\newline
-
-Die Wahl der Plattform aufgrund des Betriebssystemes gestalltet sich schon schwerer. 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
+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} interessant, welchen man mit den immer gleichen Programmbibliotheken nutzen kann, unabhängig was
-diesem \textit{Layer} für ein System zu Grunde liegt. Dieser \textit{Layer} soll also eine Schnittstelle zwischen Anwendungen und
-Betriebssytem repräsentieren. Ein \textit{Layer} welcher genau diese Anforderungen erfüllt ist der \textit{Portable Operating
-System Interface for Unix Layer (POSIX Layer)} \citep{POSIX}. 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
+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
+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
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.\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
+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
+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} 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
\subsubsection{Android}
@@ -56,21 +46,21 @@ Kernel kümmert sich um die Prozess- und Speicherverwaltung, Kommunikation sowie
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} 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
\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
+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
\subsubsection{iPhone OS}
@@ -90,12 +80,14 @@ ermöglicht Programme direkt zu portieren. Des weitern besitzt \textit{Symian OS
\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
+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 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.
@@ -112,7 +104,7 @@ Da \textit{Windows Mobile} und die Programmiersprache \textit{C} genutzt wird, w
\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
-Es wird zwischen zwei verschiedenen Arten des \textit{CeGCC's} unterschieden. Zum Einen \textit{CeGCC}, zum Anderen
+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}
@@ -124,8 +116,8 @@ kompiliert werden.
\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
+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.
@@ -146,7 +138,7 @@ 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
+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,
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
diff --git a/ausarbeitung/literature.bib b/ausarbeitung/literature.bib
index 437c79d..d92eff0 100644
--- a/ausarbeitung/literature.bib
+++ b/ausarbeitung/literature.bib
@@ -129,11 +129,11 @@ year = {2009},
}
@article{privacy,
-title = {Location privacy in pervasive computing},
-author = {Alastair R. Beresford and Frank Stajano},
-journal = {IEEE Pervasive Computing Magazine},
-year = {2003},
-pages = {46-55},
+title = {Location privacy and locationaware computing},
+author = {Matt Duckham and Lars Kulik},
+journal = {Dynamic and mobile GIS: investigating change in space and time},
+year = {2006},
+pages = {34-51},
}
@misc{OSM,
@@ -201,3 +201,24 @@ year = {2005},
journal = {ICPS '05. Proceedings. International Conference on Pervasive Services},
pages = {88-97},
}
+
+@article{geocaching,
+title = {Geocaching: hike and seek with your GPS.},
+author = {Erik Sherman},
+year = {2005},
+journal = {Computing Reviews},
+volume = {Volume 46},
+number = {2},
+}
+
+@misc{base64,
+titel = {RFC 4648},
+year = {2006},
+}
+
+@misc{symm,
+author = {Günter Müller},
+howpublished = {Vorlesung IT-Sicherheit},
+year = {2009},
+page = {17-18},
+}
diff --git a/ausarbeitung/literature.bib.backup b/ausarbeitung/literature.bib.backup
index 1faeb30..0e2b720 100644
--- a/ausarbeitung/literature.bib.backup
+++ b/ausarbeitung/literature.bib.backup
@@ -129,8 +129,8 @@ year = {2009},
}
@article{privacy,
-title = {Location privacy in pervasive computing},
-author = {Alastair R. Beresford and Frank Stajano},
+title = {Location privacy and locationaware computing},
+author = {Matt Duckham and Lars Kulik},
journal = {IEEE Pervasive Computing Magazine},
year = {2003},
pages = {46-55},
@@ -157,4 +157,68 @@ author = {Eija Kaasinen},
year = {2003},
journal = {Personal and Ubiquitous Computing},
pages = {70-79},
-} \ No newline at end of file
+volume = {Volume 7},
+number = {1},
+}
+
+@article{blowfish,
+title = {Description of a New Variable-Length Key, 64-Bit Block Cipher (Blowfish)},
+author = {Bruce Schneier},
+year = {1994},
+journal = {Fast Software Encryption, Cambridge Security Workshop Proceedings},
+pages = {191-204},
+}
+
+@article{kprivacy,
+title = {Anonymous usage of location based services through spatial and temporal cloacking},
+author = {Marco Gruteser and Dirk Grunwald},
+year = {2003},
+journal = {Proceedings of the 1st international conference on Mobile systems, applications and services},
+pages = {31-42},
+}
+
+@article{kanonymity,
+title = {k-Anonymity},
+author = {Valentina Ciriani and Sabrina De Capitani di Vimercati and Sara Foresti and Pierangela Samarati},
+year = {2007},
+journal = {Secure Data Management in Decentralized Systems},
+pages = {323-353},
+}
+
+@article{quadtree,
+title = {The Quadtree and Related Hierarchical Data Structures},
+author = {Hanan Samet},
+year = {1984},
+journal = {ACM Computing Surveys (CSUR)},
+pages = {187-260},
+volume = {Volume 16},
+}
+
+@article{dummy,
+title = {An anonymous communication technique using dummies for location-based services},
+author = {Hidetoshi Kido and Yutaka Yanagisawa and Tetsuji Satoh},
+year = {2005},
+journal = {ICPS '05. Proceedings. International Conference on Pervasive Services},
+pages = {88-97},
+}
+
+@article{geocaching,
+title = {Geocaching: hike and seek with your GPS.},
+author = {Erik Sherman},
+year = {2005},
+journal = {Computing Reviews},
+volume = {Volume 46},
+number = {2},
+}
+
+@misc{base64,
+titel = {RFC 4648},
+year = {2006},
+}
+
+@misc{symm,
+author = {Günter Müller},
+howpublished = {Vorlesung IT-Sicherheit},
+year = {2009},
+page = {17-18},
+}
diff --git a/ausarbeitung/literature.bib~ b/ausarbeitung/literature.bib~
index 0ca0d81..51c4364 100644
--- a/ausarbeitung/literature.bib~
+++ b/ausarbeitung/literature.bib~
@@ -129,11 +129,11 @@ year = {2009},
}
@article{privacy,
-title = {Location privacy in pervasive computing},
-author = {Alastair R. Beresford and Frank Stajano},
-journal = {IEEE Pervasive Computing Magazine},
-year = {2003},
-pages = {46-55},
+title = {Location privacy and locationaware computing},
+author = {Matt Duckham and Lars Kulik},
+journal = {Dynamic and &mobile GIS: investigating change in space and time},
+year = {2006},
+pages = {34-51},
}
@misc{OSM,
@@ -193,3 +193,32 @@ journal = {ACM Computing Surveys (CSUR)},
pages = {187-260},
volume = {Volume 16},
}
+
+@article{dummy,
+title = {An anonymous communication technique using dummies for location-based services},
+author = {Hidetoshi Kido and Yutaka Yanagisawa and Tetsuji Satoh},
+year = {2005},
+journal = {ICPS '05. Proceedings. International Conference on Pervasive Services},
+pages = {88-97},
+}
+
+@article{geocaching,
+title = {Geocaching: hike and seek with your GPS.},
+author = {Erik Sherman},
+year = {2005},
+journal = {Computing Reviews},
+volume = {Volume 46},
+number = {2},
+}
+
+@misc{base64,
+titel = {RFC 4648},
+year = {2006},
+}
+
+@misc{symm,
+author = {Günter Müller},
+howpublished = {Vorlesung IT-Sicherheit},
+year = {2009},
+page = {17-18},
+}
diff --git a/ausarbeitung/maindoc.aux b/ausarbeitung/maindoc.aux
index aa29ee1..79c5dab 100644
--- a/ausarbeitung/maindoc.aux
+++ b/ausarbeitung/maindoc.aux
@@ -44,17 +44,20 @@
\bibcite{WebOS}{{17}{}{{}}{{}}}
\bibcite{Windows}{{18}{}{{}}{{}}}
\bibcite{Wireshark}{{19}{}{{}}{{}}}
-\bibcite{xchat}{{20}{}{{}}{{}}}
-\bibcite{privacy}{{21}{}{{}}{{}}}
+\bibcite{XChat}{{20}{}{{}}{{}}}
+\bibcite{base64}{{21}{}{{}}{{}}}
\bibcite{kanonymity}{{22}{}{{}}{{}}}
-\bibcite{kprivacy}{{23}{}{{}}{{}}}
-\bibcite{location}{{24}{}{{}}{{}}}
-\bibcite{dummy}{{25}{}{{}}{{}}}
-\bibcite{FriendSensing}{{26}{}{{}}{{}}}
-\bibcite{quadtree}{{27}{}{{}}{{}}}
-\bibcite{blowfish}{{28}{}{{}}{{}}}
-\bibcite{bluetooth}{{29}{}{{}}{{}}}
-\bibcite{SPALS}{{30}{}{{}}{{}}}
+\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}{}{{}}{{}}}
\bibstyle{plain}
\citation{*}
\global\NAT@numberstrue
diff --git a/ausarbeitung/maindoc.bbl b/ausarbeitung/maindoc.bbl
index e55e0a9..4eb15bf 100644
--- a/ausarbeitung/maindoc.bbl
+++ b/ausarbeitung/maindoc.bbl
@@ -76,14 +76,12 @@ Windows mobile.
Wireshark.
\newblock [Online; letzter Aufruf 27.01.2010].
-\bibitem{xchat}
+\bibitem{XChat}
X-chat.
\newblock [Online; letzter Aufruf 11.02.2010].
-\bibitem{privacy}
-Alastair~R. Beresford and Frank Stajano.
-\newblock Location privacy in pervasive computing.
-\newblock {\em IEEE Pervasive Computing Magazine}, pages 46--55, 2003.
+\bibitem{base64}
+2006.
\bibitem{kanonymity}
Valentina Ciriani, Sabrina De~Capitani di~Vimercati, Sara Foresti, and
@@ -92,6 +90,12 @@ Valentina Ciriani, Sabrina De~Capitani di~Vimercati, Sara Foresti, and
\newblock {\em Secure Data Management in Decentralized Systems}, pages
323--353, 2007.
+\bibitem{privacy}
+Matt Duckham and Lars Kulik.
+\newblock Location privacy and locationaware computing.
+\newblock {\em Dynamic and mobile GIS: investigating change in space and time},
+ pages 34--51, 2006.
+
\bibitem{kprivacy}
Marco Gruteser and Dirk Grunwald.
\newblock Anonymous usage of location based services through spatial and
@@ -111,6 +115,10 @@ Hidetoshi Kido, Yutaka Yanagisawa, and Tetsuji Satoh.
\newblock {\em ICPS '05. Proceedings. International Conference on Pervasive
Services}, pages 88--97, 2005.
+\bibitem{symm}
+Günter Müller.
+\newblock Vorlesung IT-Sicherheit, 2009.
+
\bibitem{FriendSensing}
Daniele Quercia and Licia Capra.
\newblock Friendsensing: Recommending friends using mobile phones, 2009.
@@ -134,6 +142,11 @@ Yaniv Shaked and Avishai Wool.
\newblock {\em Proceedings of the 3rd international conference on Mobile
systems, applications, and services}, pages 39--50, 2005.
+\bibitem{geocaching}
+Erik Sherman.
+\newblock Geocaching: hike and seek with your gps.
+\newblock {\em Computing Reviews}, Volume 46(2), 2005.
+
\bibitem{SPALS}
Konstantin Welke and Klaus Rechert.
\newblock Spontaneous privacy-aware location sharing, 2009.
diff --git a/ausarbeitung/maindoc.blg b/ausarbeitung/maindoc.blg
index b0091b2..d07038d 100644
--- a/ausarbeitung/maindoc.blg
+++ b/ausarbeitung/maindoc.blg
@@ -22,53 +22,54 @@ 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 xchat
Warning--to sort, need author or key in Windows
Warning--to sort, need author or key in PalmOS
-You've used 30 entries,
+Warning--to sort, need author or key in XChat
+You've used 33 entries,
2118 wiz_defined-function locations,
- 619 strings with 6443 characters,
-and the built_in function-call counts, 6581 in all, are:
-= -- 625
-> -- 147
+ 630 strings with 6610 characters,
+and the built_in function-call counts, 7137 in all, are:
+= -- 675
+> -- 162
< -- 6
-+ -- 72
-- -- 40
-* -- 293
-:= -- 863
-add.period$ -- 69
-call.type$ -- 30
-change.case$ -- 110
++ -- 79
+- -- 44
+* -- 316
+:= -- 950
+add.period$ -- 75
+call.type$ -- 33
+change.case$ -- 119
chr.to.int$ -- 0
-cite$ -- 50
-duplicate$ -- 288
-empty$ -- 736
-format.name$ -- 40
-if$ -- 1550
+cite$ -- 54
+duplicate$ -- 312
+empty$ -- 799
+format.name$ -- 44
+if$ -- 1673
int.to.chr$ -- 0
-int.to.str$ -- 30
-missing$ -- 8
-newline$ -- 132
-num.names$ -- 20
-pop$ -- 276
+int.to.str$ -- 33
+missing$ -- 9
+newline$ -- 144
+num.names$ -- 24
+pop$ -- 297
preamble$ -- 1
-purify$ -- 80
+purify$ -- 88
quote$ -- 0
-skip$ -- 255
+skip$ -- 278
stack$ -- 0
-substring$ -- 324
-swap$ -- 76
+substring$ -- 339
+swap$ -- 79
text.length$ -- 6
text.prefix$ -- 0
top$ -- 0
-type$ -- 120
-warning$ -- 20
-while$ -- 34
-width$ -- 32
-write$ -- 248
-(There were 20 warnings)
+type$ -- 132
+warning$ -- 21
+while$ -- 38
+width$ -- 35
+write$ -- 272
+(There were 21 warnings)
diff --git a/ausarbeitung/maindoc.log b/ausarbeitung/maindoc.log
index 23950a2..49b2fce 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) 22 FEB 2010 19:45
+This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) (format=pdflatex 2009.12.22) 23 FEB 2010 22:12
entering extended mode
%&-line parsing enabled.
**maindoc
@@ -333,6 +333,35 @@ LaTeX Font Info: Overwriting math alphabet `\mathit' in version `bold'
(Font) OT1/cmr/bx/it --> OT1/ptm/m/it on input line 35.
LaTeX Info: Redefining \hbar on input line 50.
)
+(/usr/share/texmf-texlive/tex/latex/listings/listings.sty
+\lst@mode=\count113
+\lst@gtempboxa=\box31
+\lst@token=\toks30
+\lst@length=\count114
+\lst@currlwidth=\dimen134
+\lst@column=\count115
+\lst@pos=\count116
+\lst@lostspace=\dimen135
+\lst@width=\dimen136
+\lst@newlines=\count117
+\lst@lineno=\count118
+\c@lstlisting=\count119
+\lst@maxwidth=\dimen137
+
+(/usr/share/texmf-texlive/tex/latex/listings/lstpatch.sty
+File: lstpatch.sty 2004/10/17 1.3b (Carsten Heinz)
+)
+(/usr/share/texmf-texlive/tex/latex/listings/lstmisc.sty
+File: lstmisc.sty 2004/09/07 1.3 (Carsten Heinz)
+\c@lstnumber=\count120
+\lst@skipnumbers=\count121
+\lst@framebox=\box32
+)
+(/usr/share/texmf-texlive/tex/latex/listings/listings.cfg
+File: listings.cfg 2004/09/05 1.3 listings configuration
+))
+Package: listings 2004/10/17 1.3b (Carsten Heinz)
+
(/usr/share/texmf-texlive/tex/latex/eqlist/eqlist.sty
eqlist.sty by M. Vaeth: Revision 2.1
Package: eqlist 2002/08/15 v2.1
@@ -341,13 +370,13 @@ Package: eqparbox 2004/08/02 v2.1 Create equal-widthed parboxes
\eqp@tempdima=\skip59
\eqp@tempdimb=\skip60
)
-\eql@cnt=\count113
+\eql@cnt=\count122
)
(/usr/share/texmf-texlive/tex/latex/hyperref/hyperref.sty
Package: hyperref 2007/02/07 v6.75r Hypertext links for LaTeX
-\@linkdim=\dimen134
-\Hy@linkcounter=\count114
-\Hy@pagecounter=\count115
+\@linkdim=\dimen138
+\Hy@linkcounter=\count123
+\Hy@pagecounter=\count124
(/usr/share/texmf-texlive/tex/latex/hyperref/pd1enc.def
File: pd1enc.def 2007/02/07 v6.75r Hyperref: PDFDocEncoding definition (HO)
@@ -371,53 +400,24 @@ Package hyperref Info: Backreferencing OFF on input line 2308.
Implicit mode ON; LaTeX internals redefined
Package hyperref Info: Bookmarks ON on input line 2444.
LaTeX Info: Redefining \url on input line 2599.
-\Fld@menulength=\count116
-\Field@Width=\dimen135
-\Fld@charsize=\dimen136
-\Choice@toks=\toks30
-\Field@toks=\toks31
+\Fld@menulength=\count125
+\Field@Width=\dimen139
+\Fld@charsize=\dimen140
+\Choice@toks=\toks31
+\Field@toks=\toks32
Package hyperref Info: Hyper figures OFF on input line 3102.
Package hyperref Info: Link nesting OFF on input line 3107.
Package hyperref Info: Hyper index ON on input line 3110.
Package hyperref Info: backreferencing OFF on input line 3117.
Package hyperref Info: Link coloring ON on input line 3120.
-\Hy@abspage=\count117
-\c@Item=\count118
+\Hy@abspage=\count126
+\c@Item=\count127
)
*hyperref using driver hpdftex*
(/usr/share/texmf-texlive/tex/latex/hyperref/hpdftex.def
File: hpdftex.def 2007/02/07 v6.75r Hyperref driver for pdfTeX
-\Fld@listcount=\count119
+\Fld@listcount=\count128
)
-(/usr/share/texmf-texlive/tex/latex/listings/listings.sty
-\lst@mode=\count120
-\lst@gtempboxa=\box31
-\lst@token=\toks32
-\lst@length=\count121
-\lst@currlwidth=\dimen137
-\lst@column=\count122
-\lst@pos=\count123
-\lst@lostspace=\dimen138
-\lst@width=\dimen139
-\lst@newlines=\count124
-\lst@lineno=\count125
-\c@lstlisting=\count126
-\lst@maxwidth=\dimen140
-
-(/usr/share/texmf-texlive/tex/latex/listings/lstpatch.sty
-File: lstpatch.sty 2004/10/17 1.3b (Carsten Heinz)
-)
-(/usr/share/texmf-texlive/tex/latex/listings/lstmisc.sty
-File: lstmisc.sty 2004/09/07 1.3 (Carsten Heinz)
-\c@lstnumber=\count127
-\lst@skipnumbers=\count128
-\lst@framebox=\box32
-)
-(/usr/share/texmf-texlive/tex/latex/listings/listings.cfg
-File: listings.cfg 2004/09/05 1.3 listings configuration
-))
-Package: listings 2004/10/17 1.3b (Carsten Heinz)
-
(/usr/share/texmf-texlive/tex/latex/base/makeidx.sty
Package: makeidx 2000/03/29 v1.0m Standard LaTeX package
)
@@ -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 106.
-LaTeX Font Info: ... okay on input line 106.
-LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 106.
-LaTeX Font Info: ... okay on input line 106.
-LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 106.
-LaTeX Font Info: ... okay on input line 106.
-LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 106.
-LaTeX Font Info: ... okay on input line 106.
-LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 106.
-LaTeX Font Info: ... okay on input line 106.
-LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 106.
-LaTeX Font Info: ... okay on input line 106.
-LaTeX Font Info: Checking defaults for PD1/pdf/m/n on input line 106.
-LaTeX Font Info: ... okay on input line 106.
-LaTeX Font Info: Try loading font information for OT1+ptm on input line 106.
+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.
(/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 106.
+Package hyperref Info: Link coloring ON on input line 107.
(/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 106.
-LaTeX Info: Redefining \pageref on input line 106.
+LaTeX Info: Redefining \ref on input line 107.
+LaTeX Info: Redefining \pageref on input line 107.
(./maindoc.out)
(./maindoc.out)
\@outlinefile=\write3
@@ -531,7 +531,7 @@ LaTeX Info: Redefining \pageref on input line 106.
\openout2 = `Title.aux'.
(./Title.tex
-<Bilder/siegel.png, id=131, 568.2831pt x 568.2831pt>
+<Bilder/siegel.png, id=127, 568.2831pt x 568.2831pt>
File: Bilder/siegel.png Graphic file (type png)
<use Bilder/siegel.png>
[1
@@ -589,99 +589,80 @@ 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.117 \include{Erklaerung}
+l.118 \include{Erklaerung}
[1
]
\openout2 = `Einleitung.aux'.
- (./Einleitung.tex) [2
+ (./Einleitung.tex)
+Overfull \hbox (28.31004pt too wide) in paragraph at lines 3--119
+\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,
+ []
+
+[2
]
\openout2 = `Grundlagen.aux'.
(./Grundlagen.tex
-Overfull \hbox (13.7917pt too wide) in paragraph at lines 3--7
-\OT1/ptm/m/n/12 Des weit-eren wer-den die An-forderun-gen, die an ein Pro-gramm
- dieser Art gestellt wer-den, analysiert.
- []
+Underfull \hbox (badness 10000) in paragraph at lines 16--48
-
-Overfull \hbox (0.42947pt too wide) in paragraph at lines 37--55
-\OT1/ptm/m/n/12 ware, auch an-dere Rah-menbe-din-gun-gen gegeben sein. Um die \
-OT1/ptm/m/it/12 lo-ca-tion pri-va-cy \OT1/ptm/m/n/12 zu wahren, d[]urfen
[]
[3
]
-Underfull \hbox (badness 10000) in paragraph at lines 58--63
+Underfull \hbox (badness 10000) in paragraph at lines 52--72
[]
-
-Underfull \hbox (badness 10000) in paragraph at lines 64--71
+[4]
+Underfull \hbox (badness 10000) in paragraph at lines 76--81
[]
-Underfull \hbox (badness 10000) in paragraph at lines 72--77
+Underfull \hbox (badness 10000) in paragraph at lines 82--88
[]
-[4]
-Underfull \hbox (badness 10000) in paragraph at lines 78--82
-
- []
+Underfull \hbox (badness 10000) in paragraph at lines 89--100
-Overfull \hbox (3.8546pt too wide) in paragraph at lines 85--102
-\OT1/ptm/m/n/12 Die Struk-tur des Pro-grammes sollte m[]oglichst mod-u-lar geha
-l-ten wer-den, damit es auch in sp[]ateren
[]
-Overfull \hbox (21.40086pt too wide) in paragraph at lines 85--102
-\OT1/ptm/m/n/12 Phasen den En-twick-lern le-icht f[]allt bes-timmte Pro-grammte
-ile auszu-tauschen. Somit soll gew[]ahrleistet
- []
-
+Underfull \hbox (badness 10000) in paragraph at lines 101--109
-Overfull \hbox (5.27069pt too wide) in paragraph at lines 85--102
-\OT1/ptm/m/n/12 wer-den das bes-timmte Funk-tio-nen auch zu einem sp[]ateren Ze
-it-punkt aus-ge-tauscht wer-den k[]onnen.
[]
-
-Underfull \hbox (badness 10000) in paragraph at lines 85--102
+[5]
+Underfull \hbox (badness 10000) in paragraph at lines 112--119
[]
-Underfull \hbox (badness 10000) in paragraph at lines 105--111
-
+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
[]
-[5]
-Underfull \hbox (badness 10000) in paragraph at lines 112--117
-
- []
+Underfull \hbox (badness 10000) in paragraph at lines 120--128
-Overfull \hbox (20.70735pt too wide) in paragraph at lines 118--134
-\OT1/ptm/m/n/12 gesendet und dort aus-gegeben. Beim Versenden der Po-si-tio-nen
- muss zwis-chen Sender und Empf[]anger
[]
-Underfull \hbox (badness 10000) in paragraph at lines 118--134
+Underfull \hbox (badness 10000) in paragraph at lines 129--140
[]
-) [6] [7]
+[6]) [7]
\openout2 = `Tutorial.aux'.
(./Tutorial.tex
@@ -695,18 +676,7 @@ Underfull \hbox (badness 10000) in paragraph at lines 7--11
[]
-Overfull \hbox (0.23062pt too wide) in paragraph at lines 12--26
-\OT1/ptm/m/n/12 Auch die Frage der un-ter-st[]utzten Pro-gram-mier-sprachen ste
-llt sich, da das Pro-gramm nicht st[]andig
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 12--26
-
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 35--40
+Underfull \hbox (badness 10000) in paragraph at lines 37--41
[]
@@ -714,67 +684,61 @@ Underfull \hbox (badness 10000) in paragraph at lines 35--40
]
-Underfull \hbox (badness 10000) in paragraph at lines 54--57
+Underfull \hbox (badness 10000) in paragraph at lines 44--47
[]
-Underfull \hbox (badness 10000) in paragraph at lines 58--65
+Underfull \hbox (badness 10000) in paragraph at lines 48--55
[]
-Underfull \hbox (badness 10000) in paragraph at lines 68--74
+Underfull \hbox (badness 10000) in paragraph at lines 58--64
[]
-Underfull \hbox (badness 10000) in paragraph at lines 77--83
+Underfull \hbox (badness 10000) in paragraph at lines 67--73
[]
[9]
-Overfull \hbox (0.91805pt too wide) in paragraph at lines 93--101
+Overfull \hbox (0.91805pt too wide) in paragraph at lines 83--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 109--114
+Underfull \hbox (badness 10000) in paragraph at lines 101--106
[]
[10]
-Underfull \hbox (badness 10000) in paragraph at lines 115--120
+Underfull \hbox (badness 10000) in paragraph at lines 107--112
[]
-
-Overfull \hbox (3.26653pt too wide) in paragraph at lines 126--132
-\OT1/ptm/m/n/12 auch f[]ur den Be-nutzer ansprechend darzustellen sowie eine ei
-n-fache Be-di-en-barkeit zu garantieren.
- []
-
-<Bilder/elm-app-01_2.png, id=252, 133.35536pt x 185.83714pt>
+<Bilder/elm-app-01_2.png, id=251, 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=253, 206.48572pt x 405.22821pt>
+<Bilder/elm-app-02_2.png, id=252, 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=254, 48.18pt x 72.27pt>
+<Bilder/efl.png, id=253, 48.18pt x 72.27pt>
File: Bilder/efl.png Graphic file (type png)
<use Bilder/efl.png>
LaTeX Warning: `h' float specifier changed to `ht'.
-Underfull \hbox (badness 10000) in paragraph at lines 149--155
+Underfull \hbox (badness 10000) in paragraph at lines 141--147
[]
@@ -783,91 +747,94 @@ l.png>]
\openout2 = `Friend_Finder.aux'.
(./Friend_Finder.tex
-<Bilder/ablauf.png, id=270, 546.54187pt x 597.73312pt>
+Overfull \hbox (12.09158pt too wide) in paragraph at lines 11--19
+\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>
File: Bilder/ablauf.png Graphic file (type png)
<use Bilder/ablauf.png>
-Overfull \hbox (19.98601pt too wide) in paragraph at lines 30--39
+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
[]
-Underfull \hbox (badness 10000) in paragraph at lines 42--46
-
+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.
[]
-[13
+Underfull \hbox (badness 10000) in paragraph at lines 38--42
+
+ []
-]
-Underfull \hbox (badness 10000) in paragraph at lines 47--63
+
+Underfull \hbox (badness 10000) in paragraph at lines 43--60
[]
-[14 <./Bilder/ablauf.png>]
-<Bilder/chat.png, id=287, 338.76563pt x 450.18187pt>
+[13
+
+
+] [14 <./Bilder/ablauf.png>]
+<Bilder/chat.png, id=288, 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 80--89
+Underfull \hbox (badness 10000) in paragraph at lines 75--84
[]
[15 <./Bilder/chat.png>]
-Overfull \hbox (17.9312pt too wide) in paragraph at lines 90--92
+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
[]
-
-Underfull \hbox (badness 10000) in paragraph at lines 95--104
-
- []
-
-[16] <Bilder/barcode.png, id=303, 337.26pt x 450.9347pt>
+<Bilder/barcode.png, id=300, 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 129--135
+ <use Bilder/barcode.png>
+Underfull \hbox (badness 10000) in paragraph at lines 118--124
[]
-
-Underfull \hbox (badness 10000) in paragraph at lines 136--141
+[16]
+Underfull \hbox (badness 10000) in paragraph at lines 125--130
[]
[17 <./Bilder/barcode.png>]
-Underfull \hbox (badness 10000) in paragraph at lines 149--165
-
+Overfull \hbox (13.04648pt too wide) in paragraph at lines 138--147
+\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
+\OT1/ptm/m/n/12 Nachricht-
[]
-Underfull \hbox (badness 10000) in paragraph at lines 166--173
+Underfull \hbox (badness 10000) in paragraph at lines 138--147
[]
-[18]
-Overfull \hbox (4.52718pt too wide) in paragraph at lines 176--187
+
+Overfull \hbox (4.52718pt too wide) in paragraph at lines 150--161
\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 190--202
+Overfull \hbox (15.74675pt too wide) in paragraph at lines 164--176
\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
[]
-[19] <Bilder/verbindungen.png, id=329, 408.77719pt x 360.59718pt>
-File: Bilder/verbindungen.png Graphic file (type png)
-
-<use Bilder/verbindungen.png>) [20] [21 <./Bilder/verbindungen.png>]
+[18]) [19]
\openout2 = `Fazit.aux'.
-
-(./Fazit.tex) [22
+ (./Fazit.tex) [20
]
@@ -878,124 +845,123 @@ Underfull \hbox (badness 10000) in paragraph at lines 9--13
[]
-[23
+[21
-] [24] [25] [26]
-Overfull \hbox (13.83946pt too wide) in paragraph at lines 201--204
+] [22] [23] [24]
+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``
[]
-Overfull \hbox (15.93102pt too wide) in paragraph at lines 232--235
+Overfull \hbox (15.93102pt too wide) in paragraph at lines 233--236
[]\OT1/ptm/m/n/12 Allerdings wird sie im Ord-ner ''freetype2`` nicht ge-fun-den
. Um dies zu umge-hen muss ''ft2build.h``
[]
-Overfull \hbox (169.12907pt too wide) in paragraph at lines 238--238
+Overfull \hbox (169.12907pt too wide) in paragraph at lines 239--239
[] \OT1/cmtt/m/n/12 cp $WINCE_PATH/freetype-2.3.7-dev/include/freetype2/ft2buil
d.h $WINCE_PATH/freetype-2.3.7-dev/include[]
[]
-[27] [28]
-Overfull \hbox (40.46509pt too wide) in paragraph at lines 322--325
+[25] [26]
+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''
[]
-[29]
-LaTeX Font Info: Try loading font information for OMS+ptm on input line 361.
+[27]
+LaTeX Font Info: Try loading font information for OMS+ptm on input line 362.
(/usr/share/texmf-texlive/tex/latex/psnfss/omsptm.fd
File: omsptm.fd
)
LaTeX Font Info: Font shape `OMS/ptm/m/n' in size <12> not available
-(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 361.
+(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 362.
-Overfull \hbox (7.57867pt too wide) in paragraph at lines 361--363
+Overfull \hbox (7.57867pt too wide) in paragraph at lines 362--364
[][]$\OT1/cmtt/m/n/12 http : / / sourceforge . net / projects / cegcc / files /
ported % 20packages / zlib-[]1 . 2 .
[]
-Overfull \hbox (7.57867pt too wide) in paragraph at lines 363--365
+Overfull \hbox (7.57867pt too wide) in paragraph at lines 364--366
[][]$\OT1/cmtt/m/n/12 http : / / sourceforge . net / projects / cegcc / files /
ported % 20packages / zlib-[]1 . 2 .
[]
-Overfull \hbox (19.92868pt too wide) in paragraph at lines 365--367
+Overfull \hbox (19.92868pt too wide) in paragraph at lines 366--368
[][]$\OT1/cmtt/m/n/12 http : / / sourceforge . net / projects / cegcc / files /
ported % 20packages / libjpeg-[]6b /
[]
-Overfull \hbox (19.92868pt too wide) in paragraph at lines 367--369
+Overfull \hbox (19.92868pt too wide) in paragraph at lines 368--370
[][]$\OT1/cmtt/m/n/12 http : / / sourceforge . net / projects / cegcc / files /
ported % 20packages / libjpeg-[]6b /
[]
-Overfull \hbox (19.92868pt too wide) in paragraph at lines 375--377
+Overfull \hbox (19.92868pt too wide) in paragraph at lines 376--378
[][]$\OT1/cmtt/m/n/12 http : / / sourceforge . net / projects / cegcc / files /
ported % 20packages / freetype-[]2 .
[]
-Overfull \hbox (19.92868pt too wide) in paragraph at lines 377--379
+Overfull \hbox (19.92868pt too wide) in paragraph at lines 378--380
[][]$\OT1/cmtt/m/n/12 http : / / sourceforge . net / projects / cegcc / files /
ported % 20packages / freetype-[]2 .
[]
-[30]
-Overfull \hbox (7.57867pt too wide) in paragraph at lines 379--381
+[28]
+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 .
[]
-Overfull \hbox (7.57867pt too wide) in paragraph at lines 381--383
+Overfull \hbox (7.57867pt too wide) in paragraph at lines 382--384
[][]$\OT1/cmtt/m/n/12 http : / / sourceforge . net / projects / cegcc / files /
ported % 20packages / libpng-[]1 .
[]
-[31] [32] [33]
-Overfull \hbox (2.40399pt too wide) in paragraph at lines 512--512
+[29] [30] [31]
+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[]
[]
-Overfull \hbox (2.40399pt too wide) in paragraph at lines 512--512
+Overfull \hbox (2.40399pt too wide) in paragraph at lines 513--513
[]\OT1/cmtt/m/n/12 arm-mingw32ce-strip efl/evas/modules/savers/png/mingw32ce-ar
m/saver_png.dll[]
[]
-) [34] (./maindoc.bbl [35
+) [32] (./maindoc.bbl [33
-]) [36] (./maindoc.aux (./Title.aux) (./Erklaerung.aux) (./Einleitung.aux) (./G
+]) [34] (./maindoc.aux (./Title.aux) (./Erklaerung.aux) (./Einleitung.aux) (./G
rundlagen.aux) (./Tutorial.aux) (./Friend_Finder.aux)
(./Fazit.aux) (./Anhang.aux)) )
Here is how much of TeX's memory you used:
- 8746 strings out of 95086
- 119971 string characters out of 1183254
- 199554 words of memory out of 1500000
- 11549 multiletter control sequences out of 10000+50000
+ 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
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/cmmi10.pfb></usr/share/t
-exmf-texlive/fonts/type1/bluesky/cm/cmr10.pfb></usr/share/texmf-texlive/fonts/t
-ype1/bluesky/cm/cmssbx10.pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/c
-msy10.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 (38 pages, 1496046 bytes).
+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).
PDF statistics:
- 493 PDF objects out of 1000 (max. 8388607)
- 122 named destinations out of 1000 (max. 131072)
- 305 words of extra memory for PDF output out of 10000 (max. 10000000)
+ 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)
diff --git a/ausarbeitung/maindoc.out b/ausarbeitung/maindoc.out
index d25cb89..fe8e152 100644
--- a/ausarbeitung/maindoc.out
+++ b/ausarbeitung/maindoc.out
@@ -3,8 +3,7 @@
\BOOKMARK [2][-]{subsection.2.1}{Aktueller Stand}{section.2}
\BOOKMARK [2][-]{subsection.2.2}{Vorraussetzungen}{section.2}
\BOOKMARK [2][-]{subsection.2.3}{Ziele}{section.2}
-\BOOKMARK [2][-]{subsection.2.4}{Anforderungen an die Software}{section.2}
-\BOOKMARK [2][-]{subsection.2.5}{Verfahren}{section.2}
+\BOOKMARK [2][-]{subsection.2.4}{Verfahren}{section.2}
\BOOKMARK [1][-]{section.3}{Technische Grundlagen}{}
\BOOKMARK [2][-]{subsection.3.1}{Betriebsysteme f\374r mobile Ger\344te}{section.3}
\BOOKMARK [3][-]{subsubsection.3.1.1}{Windows Mobile}{subsection.3.1}
diff --git a/ausarbeitung/maindoc.pdf b/ausarbeitung/maindoc.pdf
index a7f0029..c4f6366 100644
--- a/ausarbeitung/maindoc.pdf
+++ b/ausarbeitung/maindoc.pdf
Binary files differ
diff --git a/ausarbeitung/maindoc.tex b/ausarbeitung/maindoc.tex
index 5a52706..fbaac79 100644
--- a/ausarbeitung/maindoc.tex
+++ b/ausarbeitung/maindoc.tex
@@ -38,6 +38,7 @@
\usepackage{theorem}
%\usepackage{mathpazo}
\usepackage{mathptmx}
+\usepackage{listings}
%Listen
\usepackage{eqlist}
diff --git a/ausarbeitung/maindoc.tex~ b/ausarbeitung/maindoc.tex~
index a406aad..fbaac79 100644
--- a/ausarbeitung/maindoc.tex~
+++ b/ausarbeitung/maindoc.tex~
@@ -38,6 +38,7 @@
\usepackage{theorem}
%\usepackage{mathpazo}
\usepackage{mathptmx}
+\usepackage{listings}
%Listen
\usepackage{eqlist}
@@ -125,7 +126,7 @@
%\bibliography{literature}
\bibliography{literature}
%\bibliographystyle{plain}
-\bibliographystyle{plainnat}
+\bibliographystyle{plain}
\nocite{*}
\end{document}
diff --git a/ausarbeitung/maindoc.toc b/ausarbeitung/maindoc.toc
index 84d0c09..5d941cb 100644
--- a/ausarbeitung/maindoc.toc
+++ b/ausarbeitung/maindoc.toc
@@ -2,10 +2,9 @@
\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.2}Vorraussetzungen}{3}{subsection.2.2}
-\contentsline {subsection}{\numberline {2.3}Ziele}{4}{subsection.2.3}
-\contentsline {subsection}{\numberline {2.4}Anforderungen an die Software}{5}{subsection.2.4}
-\contentsline {subsection}{\numberline {2.5}Verfahren}{6}{subsection.2.5}
+\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}
\contentsline {section}{\numberline {3}Technische Grundlagen}{8}{section.3}
\contentsline {subsection}{\numberline {3.1}Betriebsysteme f\IeC {\"u}r mobile Ger\IeC {\"a}te}{8}{subsection.3.1}
\contentsline {subsubsection}{\numberline {3.1.1}Windows Mobile}{9}{subsubsection.3.1.1}
@@ -21,12 +20,12 @@
\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}{16}{subsubsection.4.1.3}
+\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.5}Erzeugen eines 2D-Barcodes}{16}{subsubsection.4.1.5}
-\contentsline {subsection}{\numberline {4.2}Analyse}{17}{subsection.4.2}
+\contentsline {subsection}{\numberline {4.2}Analyse}{16}{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}{19}{subsubsection.4.2.2}
-\contentsline {subsubsection}{\numberline {4.2.3}Versenden und Empfangen von Positionen}{19}{subsubsection.4.2.3}
-\contentsline {subsubsection}{\numberline {4.2.4}Fazit der Auswertung}{20}{subsubsection.4.2.4}
-\contentsline {section}{\numberline {5}Fazit}{22}{section.5}
+\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}