summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--ausarbeitung/Anhang.aux4
-rw-r--r--ausarbeitung/Bilder/verbindungen.pngbin0 -> 17916 bytes
-rw-r--r--ausarbeitung/Einleitung.tex24
-rw-r--r--ausarbeitung/Einleitung.tex.backup32
-rw-r--r--ausarbeitung/Einleitung.tex~26
-rw-r--r--ausarbeitung/Fazit.aux6
-rw-r--r--ausarbeitung/Friend_Finder.aux25
-rw-r--r--ausarbeitung/Friend_Finder.tex30
-rw-r--r--ausarbeitung/Friend_Finder.tex.backup24
-rw-r--r--ausarbeitung/Friend_Finder.tex~36
-rw-r--r--ausarbeitung/Grundlagen.aux13
-rw-r--r--ausarbeitung/Grundlagen.tex246
-rw-r--r--ausarbeitung/Grundlagen.tex.backup256
-rw-r--r--ausarbeitung/Grundlagen.tex~246
-rw-r--r--ausarbeitung/Title.tex2
-rw-r--r--ausarbeitung/Tutorial.aux6
-rw-r--r--ausarbeitung/Tutorial.tex45
-rw-r--r--ausarbeitung/Tutorial.tex~47
-rw-r--r--ausarbeitung/literature.bib35
-rw-r--r--ausarbeitung/literature.bib.backup47
-rw-r--r--ausarbeitung/literature.bib~40
-rw-r--r--ausarbeitung/maindoc.aux18
-rw-r--r--ausarbeitung/maindoc.bbl34
-rw-r--r--ausarbeitung/maindoc.blg67
-rw-r--r--ausarbeitung/maindoc.log274
-rw-r--r--ausarbeitung/maindoc.out4
-rw-r--r--ausarbeitung/maindoc.pdfbin1447389 -> 1467630 bytes
-rw-r--r--ausarbeitung/maindoc.tex2
-rw-r--r--ausarbeitung/maindoc.tex~3
-rw-r--r--ausarbeitung/maindoc.toc28
-rw-r--r--friendfinder/draw_user.c1
-rwxr-xr-xfriendfinder/guibin203594 -> 208527 bytes
-rw-r--r--friendfinder/gui.c24
-rw-r--r--friendfinder/receiver.c139
-rw-r--r--friendfinder/receiver.h4
-rw-r--r--friendfinder/sender.c29
36 files changed, 1086 insertions, 731 deletions
diff --git a/ausarbeitung/Anhang.aux b/ausarbeitung/Anhang.aux
index df5ee3a..c7ea42a 100644
--- a/ausarbeitung/Anhang.aux
+++ b/ausarbeitung/Anhang.aux
@@ -1,6 +1,6 @@
\relax
\@setckpt{Anhang}{
-\setcounter{page}{33}
+\setcounter{page}{35}
\setcounter{equation}{0}
\setcounter{enumi}{0}
\setcounter{enumii}{0}
@@ -14,7 +14,7 @@
\setcounter{subsubsection}{4}
\setcounter{paragraph}{0}
\setcounter{subparagraph}{0}
-\setcounter{figure}{5}
+\setcounter{figure}{6}
\setcounter{table}{0}
\setcounter{NAT@ctr}{0}
\setcounter{parentequation}{0}
diff --git a/ausarbeitung/Bilder/verbindungen.png b/ausarbeitung/Bilder/verbindungen.png
new file mode 100644
index 0000000..5df5eda
--- /dev/null
+++ b/ausarbeitung/Bilder/verbindungen.png
Binary files differ
diff --git a/ausarbeitung/Einleitung.tex b/ausarbeitung/Einleitung.tex
index 54b8443..9bfcffd 100644
--- a/ausarbeitung/Einleitung.tex
+++ b/ausarbeitung/Einleitung.tex
@@ -2,22 +2,26 @@
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
-Smart Phones, ist es zum Beispiel möglich sich mit einem \textit{WLAN} zu verbinden, die eigene Position mittels \textit{GPS} zu
+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{UMTS} Daten zu übertragen.\newline
-Aus dieser Fülle an Funktionen und den verschiedenen angebotenen Smart Phones ergibt sich somit eine immense Menge an möglichen
+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 Smart Phones, 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. Dienste dieser Art sind bei Benutzern sehr beliebt und werden auch rege genutzt. Was allerdings von vielen
-Anwendern übersehen wird, ist die Tatsache, dass es möglich ist durch übermittelte Positionsdaten ein Bewegungsprofil zu
-erstellen, oder aber dritte Personen könnten die Daten abfangen und anderweitig missbrauchen. \newline
+anzuzeigen. Für die Anbieter solcher Dienste stellen diese ein rentables Geschäftsmodell dar. So können sie anhand der Orte,
+an denen sich der Nutzer befindet, gezielt Werbung platzieren. Wenn Positionsdaten über die Zeit gespeichert werden, so
+kann ein Anbieter in der Lage sein ein Bewegungsprofil des Benutzers zu erstellen.\newline
-Somit ist es besonders im Bereich von Positionsdaten ein wichtiger Aspekt, Daten zu verschlüsseln. Hierzu müssen Algorithmen
+Somit ist es besonders im Bereich von Positionsdaten ein wichtiger Aspekt, Daten zu verschlüsseln. Hierzu sollten Algorithmen
genutzt werden, welche das Verschlüsseln von Daten ohne zuviel Berechnungsaufwand durchführen, um den Akku des Gerätes zu
-schonen. Eine weitere Frage,die sich in diesem Kontext stellt, ist wie man auf sichere Art und Weise die Schlüssel, welche zum
-verschlüsseln der Daten genutzt werden, sicher und einfach verteilen kann. Hierbei sollte sichergestellt sein dass es für den
-Benutzer ohne großen Aufwand möglich ist den Schlüssel weiterzugeben und dritte Personen diese nicht abfangen können\newline
+schonen. Um Daten zu ver- und entschlüsseln werden Schlüssel benötigt, die verteilt werden müssen. Beim Verteilen dieser
+Schlüssel muss allerdings darauf geachtet werden, dass diese nur Teilnehmer erhalten für welche sie auch bestimmt sind, da der
+Datenaustausch ansonsten abgehört werden kann.\newline
+Auch im Hinblick auf das Speichern und Sammeln von Daten der Nutzer kann ein anderer Ansatz erdacht werden. So würde durch eine
+dezentrale Infrastruktur kein zentraler Knotenpunkt existieren über den der gesamte Datenverkehr läuft. Somit wäre man von einem
+Betreiber oder einer Institution unabhängiger und es wäre nicht mehr so leicht Informationen über einen Benutzer
+zusammenzutragen. \newline
Eine solche Software, welche Positionsdaten in einem sicheren Kontext versendet, wurde im Rahmen dieser Bachelor-Arbeit
konzipiert und implementiert. Hierbei ging es vor allem um eine sichere sowie dezentrale Datenübertragung.
diff --git a/ausarbeitung/Einleitung.tex.backup b/ausarbeitung/Einleitung.tex.backup
index f8f6376..e84fd37 100644
--- a/ausarbeitung/Einleitung.tex.backup
+++ b/ausarbeitung/Einleitung.tex.backup
@@ -1,17 +1,25 @@
\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. Aktuellen Modelle dieser sogennanten Smart
-Phones ist es zum Beispiel möglich sich mit einem \textit{WLAN} zu verbinden, die eigene Position mittels \textit{GPS} zu
+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
+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{UMTS} Daten zu übertragen.\newline
-Aus dieser Fülle an Funktionen und den verschiedenen angebotenen Modellen ergeben sich somit eine Menge an möglichen
-Anwendungsgebieten dieser mobilen Geräte. \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 Smart Phones, immer weiter. So ist es mit
-bestimmen Programmen zum Beispiel möglich eine zurückgelegte Strecke zu speichern oder sich den nächsten Supermarkt in der Nähe
-anzeigen zu lassen. Dienste dieser Art sind bei Benutzern sehr beliebt und werden auch rege genutzt. Was allerdings von vielen
-Anwendern übersehen wird ist die Tatsache das es möglich ist durch übermittelte Positionsdaten ein Bewegungsprofil zu erstellen.
-Oder aber dritte Personen könnten die Daten abfangen und missbrauchen. \newline
+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. Für die Anbieter solcher Dienste stellen diese ein rentables Geschäftsmodell dar. So können sie anhand der Orte,
+an denen sich der Nutzer befindet, gezielt Werbung platzieren. Was auch von vielen Anwendern übersehen wird, ist die
+Tatsache, dass es möglich ist durch übermittelte Positionsdaten ein Bewegungsprofil zu erstellen, oder aber dritte Personen
+könnten die Daten abfangen und anderweitig missbrauchen. \newline
-Somit ist es besonders im Bereich von Positionsdaten ein wichtiger Aspekt Daten zu verschlüsseln. Hierzu müssen Algorithmen
-genutzt werden welche das Verschlüsseln von Daten ohne zuviel Berechnungsaufwand durchführen. \ No newline at end of file
+Somit ist es besonders im Bereich von Positionsdaten ein wichtiger Aspekt, Daten zu verschlüsseln. Hierzu sollten Algorithmen
+genutzt werden, welche das Verschlüsseln von Daten ohne zuviel Berechnungsaufwand durchführen, um den Akku des Gerätes zu
+schonen. Um Daten zu ver- und entschlüsseln werden Schlüssel benötigt, die verteilt werden müssen. Beim Verteilen dieser
+Schlüssel muss allerdings darauf geachtet werden, dass diese nur Teilnehmer erhalten, für welche sie auch bestimmt sind, da der
+Datenaustausch ansonsten abgehört werden kann.
+
+Eine solche Software, welche Positionsdaten in einem sicheren Kontext versendet, wurde im Rahmen dieser Bachelor-Arbeit
+konzipiert und implementiert. Hierbei ging es vor allem um eine sichere sowie dezentrale Datenübertragung.
+Ein weiterer Teil bildet das Kompilieren eines Programmes für Windows Mobile unter Linux. \ No newline at end of file
diff --git a/ausarbeitung/Einleitung.tex~ b/ausarbeitung/Einleitung.tex~
index 78f5ea8..9bfcffd 100644
--- a/ausarbeitung/Einleitung.tex~
+++ b/ausarbeitung/Einleitung.tex~
@@ -2,23 +2,27 @@
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
-Smart Phones, ist es zum Beispiel möglich sich mit einem \textit{WLAN} zu verbinden, die eigene Position mittels \textit{GPS} zu
+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{UMTS} Daten zu übertragen.\newline
-Aus dieser Fülle an Funktionen und den verschiedenen angebotenen Smart Phones ergibt sich somit eine immense Menge an möglichen
+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 Smart Phones, 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. Dienste dieser Art sind bei Benutzern sehr beliebt und werden auch rege genutzt. Was allerdings von vielen
-Anwendern übersehen wird, ist die Tatsache, dass es möglich ist durch übermittelte Positionsdaten ein Bewegungsprofil zu
-erstellen, oder aber dritte Personen könnten die Daten abfangen und anderweitig missbrauchen. \newline
+anzuzeigen. Für die Anbieter solcher Dienste stellen diese ein rentables Geschäftsmodell dar. So können sie anhand der Orte,
+an denen sich der Nutzer befindet, gezielt Werbung platzieren. Wenn Positionsdaten über die Zeit gespeichert werden, so
+kann ein Anbieter in der Lage sein ein Bewegungsprofil des Benutzers zu erstellen.\newline
-Somit ist es besonders im Bereich von Positionsdaten ein wichtiger Aspekt, Daten zu verschlüsseln. Hierzu müssen Algorithmen
+Somit ist es besonders im Bereich von Positionsdaten ein wichtiger Aspekt, Daten zu verschlüsseln. Hierzu sollten Algorithmen
genutzt werden, welche das Verschlüsseln von Daten ohne zuviel Berechnungsaufwand durchführen, um den Akku des Gerätes zu
-schonen. Eine weitere Frage,die sich in diesem Kontext stellt, ist wie man auf sichere Art und Weise die Schlüssel, welche zum
-verschlüsseln der Daten genutzt werden, sicher und einfach verteilen kann. Hierbei sollte sichergestellt sein dass es für den
-Benutzer ohne großen Aufwand möglich ist den Schlüssel weiterzugeben und dritte Personen diese nicht abfangen können\newline
+schonen. Um Daten zu ver- und entschlüsseln werden Schlüssel benötigt, die verteilt werden müssen. Beim Verteilen dieser
+Schlüssel muss allerdings darauf geachtet werden, dass diese nur Teilnehmer erhalten für welche sie auch bestimmt sind, da der
+Datenaustausch ansonsten abgehört werden kann.\newline
+Auch im Hinblick auf das Speichern und Sammeln von Daten der Nutzer kann ein anderer Ansatz erdacht werden. So würde durch eine
+dezentrale Infrastruktur kein zentraler Knotenpunkt existieren über den der gesamte Datenverkehr läuft. Somit wäre man von einem
+Betreiber oder einer Institution unabhängiger und es wäre nicht mehr so leicht Informationen über einen Benutzer
+zusammenzutragen. \newline
Eine solche Software, welche Positionsdaten in einem sicheren Kontext versendet, wurde im Rahmen dieser Bachelor-Arbeit
-konzipiert und implementiert. Hierbei ging es vor allem um eine sichere Datenübertragung sowie eine dezentrale Datenübertragung.
+konzipiert und implementiert. Hierbei ging es vor allem um eine sichere sowie dezentrale Datenübertragung.
Ein weiterer Teil bildet das Kompilieren eines Programmes für Windows Mobile unter Linux. \ No newline at end of file
diff --git a/ausarbeitung/Fazit.aux b/ausarbeitung/Fazit.aux
index e749e2e..3fb63a2 100644
--- a/ausarbeitung/Fazit.aux
+++ b/ausarbeitung/Fazit.aux
@@ -1,7 +1,7 @@
\relax
-\@writefile{toc}{\contentsline {section}{\numberline {5}Fazit}{20}{section.5}}
+\@writefile{toc}{\contentsline {section}{\numberline {5}Fazit}{22}{section.5}}
\@setckpt{Fazit}{
-\setcounter{page}{21}
+\setcounter{page}{23}
\setcounter{equation}{0}
\setcounter{enumi}{0}
\setcounter{enumii}{0}
@@ -15,7 +15,7 @@
\setcounter{subsubsection}{4}
\setcounter{paragraph}{0}
\setcounter{subparagraph}{0}
-\setcounter{figure}{5}
+\setcounter{figure}{6}
\setcounter{table}{0}
\setcounter{NAT@ctr}{0}
\setcounter{parentequation}{0}
diff --git a/ausarbeitung/Friend_Finder.aux b/ausarbeitung/Friend_Finder.aux
index f7a6777..b41a077 100644
--- a/ausarbeitung/Friend_Finder.aux
+++ b/ausarbeitung/Friend_Finder.aux
@@ -2,29 +2,30 @@
\citation{OSM}
\@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{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces \textit {Friend Finder} Nachrichtenaustausch}}{13}{figure.3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.1}Grafisches Benutzeroberfl\IeC {\"a}che}{13}{subsubsection.4.1.1}}
\citation{OpenSSL}
+\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces \textit {Friend Finder} Nachrichtenaustausch}}{14}{figure.3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.2}Versenden der Nachrichten}{14}{subsubsection.4.1.2}}
\citation{libircclient}
\citation{OpenSSL}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.1}Grafisches Benutzeroberfl\IeC {\"a}che}{14}{subsubsection.4.1.1}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.2}Versenden der Nachrichten}{14}{subsubsection.4.1.2}}
\@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}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.5}Erzeugen eines 2D-Barcodes}{17}{subsubsection.4.1.5}}
+\@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{Wireshark}
\citation{IRCD}
\citation{xchat}
-\@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces 2D-Barcode mit \textit {Friend Finder}}}{17}{figure.5}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.1}Allgemeiner Datenverkehr}{17}{subsubsection.4.2.1}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.2}Versenden und Empfangen von Nachrichten}{18}{subsubsection.4.2.2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.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}{19}{subsubsection.4.2.4}}
+\@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}}
\@setckpt{Friend_Finder}{
-\setcounter{page}{20}
+\setcounter{page}{22}
\setcounter{equation}{0}
\setcounter{enumi}{0}
\setcounter{enumii}{0}
@@ -38,7 +39,7 @@
\setcounter{subsubsection}{4}
\setcounter{paragraph}{0}
\setcounter{subparagraph}{0}
-\setcounter{figure}{5}
+\setcounter{figure}{6}
\setcounter{table}{0}
\setcounter{NAT@ctr}{0}
\setcounter{parentequation}{0}
diff --git a/ausarbeitung/Friend_Finder.tex b/ausarbeitung/Friend_Finder.tex
index c90efe1..88fc5c9 100644
--- a/ausarbeitung/Friend_Finder.tex
+++ b/ausarbeitung/Friend_Finder.tex
@@ -20,9 +20,9 @@ Versenden und Empfangen der Textnachrichten zuständig, \textit{Sender} sendet d
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]
+\begin{figure}[!ht]
\centering
- \includegraphics[width=7cm]{Bilder/ablauf}
+ \includegraphics[width=10cm]{Bilder/ablauf}
\caption{\textit{Friend Finder} Nachrichtenaustausch}
\end{figure}
@@ -42,7 +42,8 @@ realisiert. Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \t
Um Daten im Allgemeinen zu versenden wurde das \textit{IRC}-Protokoll verwendet. Die
Vorteile dieses Protokolles liegen in seiner weiten Verbreitung, einer ausgedehnten Serverstruktur, sowie in dessen
-Stabilität.\newline
+Stabilität. Ein weiterer Vorteil ist, dass man Daten die an mehrere Benutzer gesendet werden 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
@@ -60,9 +61,9 @@ diesem Programmteil Sender und Empfänger in der gleichen Datei implementiert wu
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
-\begin{figure}[h]
+\begin{figure}[!ht]
\centering
- \includegraphics[width=5cm]{Bilder/chat}
+ \includegraphics[width=8cm]{Bilder/chat}
\caption{Versenden von Chatnachrichten}
\end{figure}
@@ -84,7 +85,7 @@ Länge 8 Byte verschlüsselt wird. Somit ist es auch hier nötig Längen- und Br
versenden. Somit werden für das Versenden einer Position insgesamt acht Nachrichten an den \textit{IRC}-Server übermittelt.
Wurden diese vier Nachrichten übermittelt, so werden solange keine Daten mehr gesendet, bis der Empfänger eine
Bestätigung an den \textit{IRC-Kanal} sendet. Diese Bestätigung ist wird unverschlüsselt versandt. Kommt dieses
-\textit{Acknowledgement} beim Sender an, so versendet dieser wieder ein \textit{Latitude/Longtitude Paar}.\newline
+\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.
@@ -113,9 +114,9 @@ Zum erstellen des Barcodes wurde die offene Bibliothek \textit{qrencode} \citep{
Zeichenkette einen 2D-Barcode. Aus den Bilddaten dieses Barcodes wurde mit \textit{libpng} \citep{PNG} eine \textit{.png} Datei
erstellt. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er von \textit{Friend Finder} ausgegeben wird.
-\begin{figure}[h]
+\begin{figure}[!ht]
\centering
- \includegraphics[width=5cm]{Bilder/barcode}
+ \includegraphics[width=8cm]{Bilder/barcode}
\caption{2D-Barcode mit \textit{Friend Finder}}
\end{figure}
@@ -209,5 +210,14 @@ Client sein Paket nur einmal versenden und alle teilnehmenden Nutzer in einem Ch
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.
-%Grafik erstellen
+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
diff --git a/ausarbeitung/Friend_Finder.tex.backup b/ausarbeitung/Friend_Finder.tex.backup
index 7fb56c7..1f497e5 100644
--- a/ausarbeitung/Friend_Finder.tex.backup
+++ b/ausarbeitung/Friend_Finder.tex.backup
@@ -179,7 +179,7 @@ ist dieser unverschlüsselt 11 Byte groß. Nach der Verschlüsselung werden beim
sich eine Textnachricht circa um den Faktor 7,4, wenn sie verschlüsselt ist und alle Zusatzinformationen hineingepakt
wurden. \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 * 7,4)$.
+ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 7,4)$.
\subsubsection{Versenden und Empfangen von Positionen}
@@ -190,13 +190,11 @@ der unverschlüsselten Zeichen, die zu senden sind, beträgt 21 Zeichen. Diese s
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 * 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 * 8)) + (4 * a)) * n$, wobei $a$
-die Größe eines Acknowledgement-Paketes ist und $n$ die Anzahl der versandten Pakete repräsentiert.
-%formel für entsthenden verkehr aufstellen -> grafik erstellen.
-
+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.
\subsubsection{Fazit der Auswertung}
@@ -208,5 +206,13 @@ Positionsdaten mehrmals pro Minute versandt werden, ist dies aber auch nicht wir
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.
+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
diff --git a/ausarbeitung/Friend_Finder.tex~ b/ausarbeitung/Friend_Finder.tex~
index 0639d18..88fc5c9 100644
--- a/ausarbeitung/Friend_Finder.tex~
+++ b/ausarbeitung/Friend_Finder.tex~
@@ -20,9 +20,9 @@ Versenden und Empfangen der Textnachrichten zuständig, \textit{Sender} sendet d
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]
+\begin{figure}[!ht]
\centering
- \includegraphics[width=7cm]{Bilder/ablauf}
+ \includegraphics[width=10cm]{Bilder/ablauf}
\caption{\textit{Friend Finder} Nachrichtenaustausch}
\end{figure}
@@ -42,7 +42,8 @@ realisiert. Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \t
Um Daten im Allgemeinen zu versenden wurde das \textit{IRC}-Protokoll verwendet. Die
Vorteile dieses Protokolles liegen in seiner weiten Verbreitung, einer ausgedehnten Serverstruktur, sowie in dessen
-Stabilität.\newline
+Stabilität. Ein weiterer Vorteil ist, dass man Daten die an mehrere Benutzer gesendet werden 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
@@ -60,9 +61,9 @@ diesem Programmteil Sender und Empfänger in der gleichen Datei implementiert wu
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
-\begin{figure}[h]
+\begin{figure}[!ht]
\centering
- \includegraphics[width=5cm]{Bilder/chat}
+ \includegraphics[width=8cm]{Bilder/chat}
\caption{Versenden von Chatnachrichten}
\end{figure}
@@ -84,7 +85,7 @@ Länge 8 Byte verschlüsselt wird. Somit ist es auch hier nötig Längen- und Br
versenden. Somit werden für das Versenden einer Position insgesamt acht Nachrichten an den \textit{IRC}-Server übermittelt.
Wurden diese vier Nachrichten übermittelt, so werden solange keine Daten mehr gesendet, bis der Empfänger eine
Bestätigung an den \textit{IRC-Kanal} sendet. Diese Bestätigung ist wird unverschlüsselt versandt. Kommt dieses
-\textit{Acknowledgement} beim Sender an, so versendet dieser wieder ein \textit{Latitude/Longtitude Paar}.\newline
+\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.
@@ -113,9 +114,9 @@ Zum erstellen des Barcodes wurde die offene Bibliothek \textit{qrencode} \citep{
Zeichenkette einen 2D-Barcode. Aus den Bilddaten dieses Barcodes wurde mit \textit{libpng} \citep{PNG} eine \textit{.png} Datei
erstellt. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er von \textit{Friend Finder} ausgegeben wird.
-\begin{figure}[h]
+\begin{figure}[!ht]
\centering
- \includegraphics[width=5cm]{Bilder/barcode}
+ \includegraphics[width=8cm]{Bilder/barcode}
\caption{2D-Barcode mit \textit{Friend Finder}}
\end{figure}
@@ -179,7 +180,7 @@ ist dieser unverschlüsselt 11 Byte groß. Nach der Verschlüsselung werden beim
sich eine Textnachricht circa um den Faktor 7,4, wenn sie verschlüsselt ist und alle Zusatzinformationen hineingepakt
wurden. \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 \dot 7,4)$.
+ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 7,4)$.
\subsubsection{Versenden und Empfangen von Positionen}
@@ -190,10 +191,10 @@ der unverschlüsselten Zeichen, die zu senden sind, beträgt 21 Zeichen. Diese s
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 \dot 8)$. Hinzu kommt noch, das für jedes empfangene Positions-Fragmeint ein Acknowledgement
+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 \dot a)) \dot n$,
+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.
\subsubsection{Fazit der Auswertung}
@@ -209,5 +210,14 @@ Client sein Paket nur einmal versenden und alle teilnehmenden Nutzer in einem Ch
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.
-%Grafik erstellen
+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
diff --git a/ausarbeitung/Grundlagen.aux b/ausarbeitung/Grundlagen.aux
index 74d60b1..5a2f5b5 100644
--- a/ausarbeitung/Grundlagen.aux
+++ b/ausarbeitung/Grundlagen.aux
@@ -1,14 +1,17 @@
\relax
+\citation{privacy}
\citation{Latitude}
+\citation{location}
\citation{SPALS}
-\citation{FriendSensing}
\@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}Ziele}{4}{subsection.2.2}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}Anwendungsm\IeC {\"o}glichkeiten}{4}{subsection.2.3}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.4}Anforderungen}{6}{subsection.2.4}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.5}Verfahren}{6}{subsection.2.5}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Anwendungsm\IeC {\"o}glichkeiten}{4}{subsection.2.2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}Ziele}{4}{subsection.2.3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.4}Anforderungen}{5}{subsection.2.4}}
+\citation{qrcode}
+\citation{bluetooth}
\citation{IRC}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.5}Verfahren}{6}{subsection.2.5}}
\@setckpt{Grundlagen}{
\setcounter{page}{8}
\setcounter{equation}{0}
diff --git a/ausarbeitung/Grundlagen.tex b/ausarbeitung/Grundlagen.tex
index f66bf6b..f9634e2 100644
--- a/ausarbeitung/Grundlagen.tex
+++ b/ausarbeitung/Grundlagen.tex
@@ -1,54 +1,99 @@
\section{Grundlagen}
-In diesem ersten Teil dieser Bachelor-Arbeit wird der momentane Stand von \textit{location awareness} Software auf mobilen
-Geräten aufgezeigt. Es wird auch analysiert, was für Anforderungen an ein Programm dieser Art gestellt werden um einen sicheren
-Datenverkehr zu garantieren.
+In diesem ersten Teil dieser Bachelor-Arbeit 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.
\subsection{Aktueller Stand}
+
Da so gut wie alle aktuellen Smart Phones mit einem \textit{GPS} ausgestattet sind existieren für die verschiedenen
-Betriebssysteme schon eine Reihe von Anwendungen die Funktionalitäten für \textit{location awareness} bieten. So existieren
+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. Es
-existieren auch eine Menge an Anwendungen die die eigene Position für Freunde sichtbar macht.\newline
-So bietet \textit{Google} den Dienst \textit{Google Latitude} \citep{Latitude} an. Bei diesem Programm ist es möglich die Position
-von Freunden, die diesen auch Dienst 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. Es existiert auch eine Paper mit dem
-Titel \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS}. Hierfür wurde ein Dienst für mobile Geräte implementiert,
-welcher Daten verschlüsselt an mehrere Nutzer sendet. Für diesen Dienst wurde auch mit ein möglichst einfaches und verlässliches
-Protokoll entworfen, mit dem Ziel die Berechnungszeiten niedrig zu halten. Des weiteren hat man in dem Paper
-\textit{FriendSensing: Recommending Friends Using Mobile Phones} \citep{FriendSensing} Möglichkeiten erörtert um die Position
-anderer Benutzer mit Hilfe von \textit{Bluetooth} zu bestimmen. Hierbei registrierte eine Software wie oft welcher Nutzer mit
-einem anderen in Kontakt stand und wie oft sie in \textit{Bluetooth} Reichweite waren. Diese Aufzählung, über Software die
-sich mit der Thematik von \textit{location awareness} auseinandersetzt könnte an dieser Stelle noch weiter fortgeführt werden da
-es hierfür Unmengen an Programmen gibt. \newline
-
-Allerdings nutzen diese Programme, die oft auf \textit{Google Maps} basieren, meistens das Prinzip eines zentralen Knotenpunktes,
-an welchen die Positionsdaten gesendet werden und dieser diese dann weiterleitet. Somit existiert immer eine zentrale
-Kontrollinstanz, welche Einsicht in die Daten der Nutzer hat, während die Nutzer selbst immer nur Zugang zu den für sie bestimmten
- Daten besitzen. Somit können die Nutzer auch nicht die Nutzung ihrer Daten durch den Anbieter einsehen. Die Folgen hiervon
-könnten sein, dass zum Beispiel der Anbieter gezielt Werbung für die Position der Nutzer einspielt, da er ihren Aufenthaltsort
-immer kennt. \newline
-
-Bestehende Software dieser Art verschlüsselt auch in den seltensten Fällen die versendeten Daten. Da es sich bei Positionsdaten
-um sehr sensible Daten handelt stellt dies ein großes Manko dar. So könnten Dritte den Datenverkehr abhören und auch
-Positionsdaten von Nutzern erhalten, die diese nur einer bestimmten Gruppe zur Verfügung stellen wollten. Sind diese
-Positionsdaten erst einmal gesammelt können ohne weiteres Bewegungsprofile erstellt und missbraucht werden. Der Benutzer begibt
-sich also mit der Nutzung von solchen Programmen in die Gefahr das regelmäßige Aufenthaltsorte erkannt werden und der ständig
-aufspürbar ist. Somit stellen solche Dienste, die sensible Daten dieser Art ohne Verschlüsselung versenden, eine starke
-Einschränkung für die Privatsphäre dar.\newline
+existieren auch eine Menge von Anwendungen, die die eigene Position für Freunde sichtbar macht.\newline
+So bietet \textit{Google} beispielsweise 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
+Es wurde in einer Befragung von Versuchspersonen herausgefunden, dass diese keine Bedenken im Bezug auf Positionsdaten und
+Privatsphäre haben \citep{location}. Da es aber immer mehr solcher Dienste gibt, sollte man gerade zum Schutz dieser Benutzer,
+Anwendungen entwickeln welche Wert auf die Wahrung \textit{location privacy } legen.\newline
+Um die Positionsdaten auf optimale Art und Weiße zu schützen, sollten diese nur in einem verschlüsselten Format
+versendet werden. Positionsdaten stellen für den Nutzer sensible Daten dar, da sie viel über seine Gewohnheiten und täglichen
+Ablauf verraten können. Wenn man diese Daten unverschlüsselt versendet so begibt man sich in die Gefahr das regelmäßige
+Aufenthaltsorte erkannt werden oder man sogar ständig aufspürbar ist, was eine erhebliche Verletzung der \textit{location
+privacy} darstellen würde.\newline
+Mit der Thematik von verschlüsselter Datenübertragung auf mobilen Geräten befasst sich eine Arbeit mit dem Titel
+\textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS}. 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
+
+Ein anderes Problem stellt die Nutzung von zentral organisierten Netzen dar. Hier ist es möglich, ohne das der Benutzer davon
+Kentniss hat, auf alle über diesen Knoten versandten Daten zuzugreifen. Dies könnte durch die Nutzung eines dezentralen,
+verteilten Systems eingeschränkt werden. Somit würde nicht nur keine Kontrollinstanz existieren, welche Einsicht in die Daten der
+Nutzer hat während die Nutzer selbst immer nur Zugang zu den für sie bestimmten Daten besitzen, sondern man könnte die Daten auf
+mehrere Knoten verteilen. Diese Tatsache würde das gezielte Sammeln von Daten erschweren und somit der oben genannten Defintion
+von \textit{location privacy} entgegenkommen.\newline
+
+\subsection{Anwendungsmöglichkeiten}
+
+Die Verbreitung von solchen mobilen Geräten hat in den letzten Jahren beständig zugenommen und alle neueren Modelle besitzen ein
+\textit{GPS}-Modul. Des weiteren sind alle modernen Geräte in der Lage, Daten sowohl über den \textit{3G}-Standart
+sowie per \textit{WLAN} zu übertragen. Wenn nun eine Gruppe, welche mit entsprechenden mobilen Geräten ausgestattet ist,
+die Positionen austauschen möchte, so wird zuallerst ein Protokoll benötigt welches die Daten versenden kann. Dieses Protokoll
+sollte sowohl verlässlich als auch für langsame Netze konzipiert sein. Im nächsten Schritt soll diese Verbindung nun nur
+verschlüsselte Daten übertragen. Hierzu wird also ein geeigneter Algorithmus benötigt, welcher die Daten verschlüsselt. Dieser
+sollte dabei bei möglichst wenig Berechnungsaufwand eine möglichst gute Verschlüsselung bieten.\newline
+Will man nun Daten verschlüsseln so benötigen sowohl Sender als auch Empfänger die gleichen Schlüssel. Es wird also auch eine
+Möglichkeit gesucht, mit deren Hilfe man Schlüssel auf eine sichere Art und Weiße übertragen kann. Sind diese Anforderungen
+erfüllt, so können die Mitglieder dieser Gruppe nun ihre Positionsdaten austauschen, ohne diese Möglichweiße Personen mitzuteilen
+für die diese nicht bestimmt sind.\newline
+Mit diesem gegebenen Protokoll und den Verschlüsselungsverfahren ist es nun ohne weiteres möglich auch Textnachrichten zwischen
+zwei Mitgliedern einer Gruppe auszutauschen. \newline
+%Wenn nun eine Benutzergruppe dieses Programm nutzen möchte, so sollte dies für sie mit einfachen Mitteln möglich sein. Hierzu
+%betrachten wir den Fall, dass eine Gruppe von Touristen in einer ihnen fremden Stadt
+%unterwegs ist. Die Reiseteilnehmer möchten nun auf eigene Faust die Stadt erkunden. Da die Gruppeteilnehmer ihre Daten nicht
+%öffentlich preisgeben wollen, möchten sie ein verschlüsselte Verbindung untereinander aufbauen. Dazu wird im ersten Schritt ein
+%oder mehrere Schlüssel benötigt. Beim Verteilen der Schlüssel stellt sich nun die Frage wie dies ohne großen Aufwand aber mit
+%maximaler Sicherheit möglich ist. Hier könnte nun ein Gruppenmitglied einen oder mehrere Schlüssel erstellen und diese an die
+%jeweiligen Teilnehmer senden. Nach dem Austausch der Schlüssel kann nun über eine beliebige Infrastruktur eine Verbindung mit den
+%anderen Teilnehmern der Gruppe aufgebaut werden. \newline
+%Nun stellt sich allerdings auch die Frage nach der Anzahl der zu verteilenden Schlüssel. Je nach Art der Verschlüsselung reicht
+%ein Schlüssel aus, oder es sind mehrere nötig. Würde die Software eine asymmetrische Verschlüsselung benutzen, so müsste jeder
+%Nutzer einen privaten Schlüssel erstellen und sich, mittels scannen eines Barcodes, den zugehörigen öffentlichen Schlüssel
+%besorgen. Dies hätte zur Folge das man, je nach Gruppe mit der kommuniziert werden soll, immer mehrere Schlüssel besitzen und
+%verwalten müsste. Je nach gewähltem Verfahren kann auch zusätzlich noch ein Zertifikat für diese Schlüssel hinzukommen. Ein
+%symmetrischen Kryptographieverfahren hätte hier den Vorteil, dass man nur einen Schlüssel an alle Benutzer der Gruppe verteilen
+%müsste. Des weitern fällt der Verwaltungsaufwand hier wesentlich geringer aus, da nur ein Schlüssel pro Gruppe von nöten ist.
+%Zusätzlich würde auch noch für ein symmetrisches Verfahren sprechen,dass diese einen wesentlich geringeren Berechnungsaufwand
+%haben und somit der Akku länger halten würde.\newline
+%Wenn diese Gruppe sich nun aufteilt, um getrennt die Stadt zu erkunden, so kann nun über die bestehnde Verbindung kommuniziert
+%werden. Die Gruppenteilnehmer möchten hierbei sehen wo die anderen Mitreisenden sich gerade befinden. Allerdings ist es für die
+%Teilnehmer hier nicht von Interesse, die Position weit entfernter Teilnehmer zu sehen, da der Fussweg zu deren Standort zu weit
+%wäre. Es wäre also nützlich, für den Benutzer, wenn er ab einem bestimmten Abstand die anderen Teilnehmer ausblenden könnte.
+%Endeckt nun ein Mitglied dieser Reisegruppe eine besondere Sehenswürdigkeit, möchte er dies vielleicht einem Freund aus der
+%Reisegruppe mitteilen. Zu diesem Zweck bräuchte er eine Chatfunktion, mit welcher er andere Gruppenmitglieder kontaktieren und
+%mit
+%ihnen Nachrichten austauschen kann. Allerdings sollte auch diese Funktion, aus Gründen der Privatsphäre, Daten nur in einem
+%%verschlüsselten Format übertragen. Des weiteren sollte es möglich sein nur mit dieser einen Person gezielt zu chatten, ohne das
+%die gesamte Gruppe mithören kann. Natürlich wäre hier noch eine Zusatzfunktion möglich, die einen Chat mit der gesamten Gruppe
+%%verfügbar macht. Wenn dieser Tourist nun seinen Freund per Chat kontaktiert hat, können sich diese nun einen Treffpunkt
+%verabreden
+%und diesen auf der Karte dem anderen Teilnehmer senden und im Anschluss sich den Weg dorthin errechnen lassen. \newline
\subsection{Ziele}
-Die obigen zwei Punkte wurden bisher in den meisten noch nicht berücksichtigt. Somit besteht seitens der Nutzer
-mit Sicherheit eine Nachfrage nach einer Software, welche ihre Persönlichen Daten auf sicherem Wege schützt und trotzdem noch die
-gewohnte Funktionalität bietet. Hierfür muss sichergestellt sein, dass es den Nutzern ohne Fachkentniss möglich ist, Schlüssel
-zur Verschlüsselung untereinander auszutauschen und somit festzulegen wer alles diese Positionsdaten erhalten darf. Des
-weiteren muss beim Schlüsselaustausch gewährleistet sein, dass der Schlüssel auf eine sichere Art und Weiße übertragen
-wird, ohne das andere diesen abfangen können. Hierbei muss allerdings beachtet werden, dass diese Software auf mobilen Geräten
-lauffähig sein soll. Es sollte also gewährleistet werden dass die genutzten Algorithmen nicht zu berechnungsintensiv sind, die
-Datensicherheit aber trotz allem gegeben ist. \newline
+Die Anwendung eines solchen Programmes soll dem Nutzer möglichst einfach gemacht werden und trotzdem die gesetzten Ziele, wie die
+Verschlüsselung der Daten und Nutzung einer dezentralen Infrastruktur, erfüllen. \newline
+
+Es soll also sicher gestellt sein, dass es auch Benutzern ohne Fachkentniss möglich ist, die benötigten Schlüssel untereinander
+auszutauschen und somit festzulegen wer alles diese Positionsdaten einsehen darf. Des weiteren muss beim Schlüsselaustausch
+gewährleistet sein, dass der Schlüssel auf eine sichere Art und Weiße übertragen wird, ohne das andere diesen mitlesen können.
+Hierbei muss allerdings beachtet werden, dass diese Software auf mobilen Geräten lauffähig sein soll. Es sollte also gewährleistet
+werden dass die genutzten Algorithmen nicht zu berechnungsintensiv sind, die Datensicherheit aber trotz allem gegeben ist.
+\newline
Da auch ein zentraler Knoten, über den der gesamte Datenverkehr aller Benutzer läuft, unerwünscht ist, muss hier ein
-Kommunikationsdienst genutzt werden, welcher nach ein dezentrales Prinzip verfolgt. Auch hier muss, wie bei der
+Kommunikationsdienst genutzt werden, welcher ein dezentrales Prinzip verfolgt. Auch hier muss, wie bei der
Datenverschlüsselung, gewährleistet sein dass die Bedienung für den Anwender möglichst einfach gehalten wird und er somit ohne
Aufwand und Fachwissen die Kommunikationsparameter einstellen und abändern kann. \newline
@@ -56,96 +101,75 @@ Da mittlerweile eine große Anzahl an unterschiedlichen Plattformen für mobile
die Software auf möglichst vielen dieser Betriebssystemen lauffähig ist. So ist sichergestellt, dass möglichst viele Benutzer
erreicht werden. \newline
-\subsection{Anwendungsmöglichkeiten}
-
-Wenn nun eine Benutzergruppe dieses Programm nutzen möchte, so sollte sie in der Lage sein mit einfachen Mitteln die nötigen
-Parameter zu verteilen. Hierzu betrachten wir den möglichen Fall, dass eine Gruppe von Touristen in einer ihnen fremden Stadt
-unterwegs sind. Diese möchten nun auf eigene Faust diese Stadt erkunden. Hierzu müssen zuerst geignete Kartendaten vorhanden
-sein. Hier sollten, wenn möglich, freie Kartendaten verwendet werden um Nebenkosten zu verringern. Es muss allerdings darauf
-geachtet werden das diese möglichst immer auf einem aktuellen Stand sind. Wenn so eine Karte vorhanden ist, so kann im
-nächstenwird Schritt ein Schlüssel erstellt und an alle Teilnehmer dieser Gruppe verteilt werden. Beim Verteilen stellt
-sich nun die Frage wie dies ohne großen Aufwand aber mit maximaler Sicherheit möglich ist. Hier könnte nun ein Gruppenmitglied
-einen oder mehrere Schlüssel erstellen und diese sich in Form eines \textit{2D-Barcodes} ausgeben lasen. Dieser Barcode kann nun
-von den anderen Nutzern, mit deren Smart Phones, gescannt und wieder in einen Schlüssel, bestehend aus Zeichenketten, umgewandelt
-werden. Da dies keine Kommunikation zwischen den Geräten erfordert kann kein dritter diese Schlüssel während der Datenübertragung
-abfangen.\newline
-Nun stellt sich allerdings auch die Frage nach der Anzahl der zu verteilenden Schlüssel. Je nach Art der Verschlüsselung reicht
-ein Schlüssel aus, oder es sind mehrere nötig. Würde die Software eine asymmetrische Verschlüsselung benutzen, so müsste jeder
-Nutzer einen privaten Schlüssel erstellen und sich, mittels scannen eines Barcodes, den zugehörigen öffentlichen Schlüssel
-besorgen. Dies hätte zur Folge das man, je nach Gruppe mit der kommuniziert werden soll, immer mehrere Schlüssel besitzen und
-verwalten müsste. Je nach gewähltem Verfahren kann auch zusätzlich noch ein Zertifikat für diese Schlüssel hinzukommen. Ein
-symmetrischen Kryptographieverfahren hätte hier den Vorteil, dass man nur einen Schlüssel an alle Benutzer der Gruppe verteilen
-müsste. Des weitern fällt der Verwaltungsaufwand hier wesentlich geringer aus, da nur ein Schlüssel pro Gruppe von nöten ist.
-Zusätzlich würde auch noch für ein symmetrisches Verfahren sprechen,dass diese einen wesentlich geringeren Berechnungsaufwand
-haben und somit der Akku länger halten würde.\newline
-Nachdem diese Gruppe von Touristen nun ihre Schlüssel ausgetauscht haben erkunden sie unabhängig voneinander die Stadt. Dabei
-möchten sie sehen wo die anderen Mitreisenden sich gerade befinden. Allerdings ist es für die Teilnehmer hier nicht von
-Interesse, die anderen Teilnehmer auserhalb eines bestimmten Radiuses zu sehen, da der Fussweg zu deren Standort zu weit wäre. Es
-wäre also nützlich für den Benutzer wenn er ab einem bestimmten Abstand die anderen Teilnehmer ausblenden könnte. Endeckt nun ein
-Mitglied dieser Reisegruppe eine besondere Sehenswürdigkeit, möchte er dies vielleicht einem Freund aus der Reisegruppe
-mitteilen. Zu diesem Zweck bräuchte er eine Chatfunktion, mit welcher er andere Gruppenmitglieder kontaktieren und mit ihnen
-Nachrichten austauschen kann. Allerdings sollte auch diese Funktion aus Gründen der Privatsphäre, Daten nur in einem
-verschlüsselten Format übertragen. Des weiteren sollte es möglich sein nur mit dieser einen Person gezielt zu chatten, ohne das
-die gesamte Gruppe mithören kann. Natürlich wäre hier noch eine Zusatzfunktion möglich, die einen Chat mit der gesamten Gruppe
-verfügbar macht. Wenn dieser Tourist nun seinen Freund per Chat kontaktiert hat, können sich diese nun einen
-Treffpunkt verabreden und diesen auf der Karte dem anderen Teilnehmer senden und im Anschluss den Weg dorthin sich
-errechnen lassen. \newline
-
-Ein weiterer möglicher Fall wäre dass man mit Freunden kommunzieren möchte, aber keine \textit{UMTS} Datenflatrate
-besitzt und kein öffentliches WLAN in Reichweite ist. Es sollte also auch sichergestellt sein dass die Datenpakete, welche
-versandt werden, nicht allzu groß sind. Auch die Anzahl der Hintergrunddaten, die vom verwendeten Protokoll versandt werden,
-sollten nicht zu groß ist. So ist zum einen gesichert das nicht zu hohe Verbindungskosten entsehen und zum anderen auch der
-Berechnungsaufwand für das erstellen und versenden dieser Pakete nicht zu groß ist. \newline
-
\subsection{Anforderungen}
-Anhand der zwei vorrangegangenen Beispielen ist gut erkennbar was an Funktionalität benötigt wird. So sollte es möglich sein die
-Standorte anderer Nutzer zu auf einer Karte zu anzuzeigen. Damit für andere Nutzer die eigene Position sichtbar ist, muss diese in
-einem gängigen Format versendet werden. Hierfür ist das Format \textit{Latitude}/\textit{Longtitude} bestens geignet. Um
-die Datensicherheit zu garantieren müssen diese Positionsdaten in verschlüsselter Form versendet werden. \newline
+Anhanden der Anwendungsmöglichkeiten lassen sich die Anforderungen, die an die Software gestellt werden, ableiten. So sollte
+es möglich sein die Standorte anderer Nutzer anzuzeigen. Damit für andere Anwender die eigene Position sichtbar
+ist, muss diese in einem gängigen Format versendet werden. Hierfür ist das Format \textit{Latitude}/\textit{Longtitude} bestens
+geignet, da es sich um das am meisten verbreitetste Format handelt und es möglich ist jeden Punkt auf der Erdeerfläche ob in
+diesem Geokoordinatensystem darzustellen. 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 muss das Programm in der Lage sein, die eigehenden Positionsdaten sowohl zu
+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 sollte auch möglich sein, nur
-Benutzer innerhalb einer bestimmten Entfernung anzuzeigen, da eine Person die sich in 6 Kilometer Entfernung aufhält für Dienste
-dieser Art nur begrenzt sinnvoll sind. \newline
+Benutzer innerhalb einer bestimmten Entfernung anzuzeigen, da eine Person die sich in sechs Kilometer Entfernung aufhält für
+Dienste dieser Art nur begrenzt sinnvoll sind. \newline
Um die Kommunikation zwischen verschiedenen Teilnehmern zu ermöglichen sollte es möglich sein Chatnachrichten auszutauschen. Auch
-hier muss gewährleistet sein das der Datenverkehr verschlüsselt ablaufen muss und somit Dritte nicht die Konversation mitlesen
-können. \newline
+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. Hierzu kann aus einer vorher festgelegten Zeichenkette einen
-2D-Barcode erstellt und angezeigt werden. Zur Weitergabe des Schlüssels muss nun der andere Anwender diesen vom Display
-fotographieren. \newline
+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
\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 von Berechnungsaufwand als auch von Schlüsselverwaltung ist ein symmetrisches
+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. Die Daten werden also durch Client A ver- und von Client B
-entschlüssel. \newline
-Die Schlüssel können, wie schon beschrieben, durch das Erstellen eines \textit{2D-Barcodes} und das fotographieren von diesem
-zwischen den Anwendern Ausgetauscht werden.
+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
+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
-Eine Möglichkeit wäre hier eine \textit{Peer-to-Peer} Lösung. Allerdings verbietet ein Großteil der \textit{GSM}-Provider
-\textit{Peer-to-Peer} Datenverkehr innerhalb ihrer Netze, womit diese Lösung praktisch nicht anwendbar wäre. Ein Vorhandenes
-Protokoll, welches ein aktives Netzwerk bereitstellt und dieses und auch rege genutzt wird, ist das \textit{IRC}-Protokoll
-\citep{IRC}. Dieses stellt mehrere Server zur Verfügung, wobei jeder Nutzer auch einen eigenen Server bereitstellen
-kann. Jeder Server verwaltet mehrere \textit {Channels}. Würde nun ein Server ausfallen, so könnten die Nutzer auf einen anderen
+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
-
-Durch die Wahl dieser Lösung ist also garantiert, dass sowohl die Berechnungszeiten durch ein symmetrisches Verfahren niedrig
-gehalten werden, der Verwaltungsaufwand für die Schlüssel gering ist 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 diesen 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
+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
diff --git a/ausarbeitung/Grundlagen.tex.backup b/ausarbeitung/Grundlagen.tex.backup
index 3eb2624..712a9a1 100644
--- a/ausarbeitung/Grundlagen.tex.backup
+++ b/ausarbeitung/Grundlagen.tex.backup
@@ -1,54 +1,95 @@
\section{Grundlagen}
-In diesem ersten Teil dieser Bachelor-Arbeit wird der momentane Stand von \textit{location awareness} Software auf mobilen
-Geräten aufgezeigt. Es wird auch analysiert, was für Anforderungen an ein Programm dieser Art gestellt werden um einen sicheren
-Datenverkehr zu garantieren.
+In diesem ersten Teil dieser Bachelor-Arbeit 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. Allerdings wurde nach Befragungen von Versuchspersonen
+herausgefunden dass die Anwender mit dem Thema Privatsphäre, in Verbindung mit Diensten die die Position angeben, keinerlei
+Bedenken haben \citep{location}.\newline
+Des weiteren werden die Anforderungen, die an ein Programm dieser Art gestellt werden, analysiert.
\subsection{Aktueller Stand}
Da so gut wie alle aktuellen Smart Phones mit einem \textit{GPS} ausgestattet sind existieren für die verschiedenen
-Betriebssysteme schon eine Reihe von Anwendungen die Funktionalitäten für \textit{location awareness} bieten. So existieren
+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. Es
-existieren auch eine Menge an Anwendungen die die eigene Position für Freunde sichtbar macht.\newline
-So bietet \textit{Google} den Dienst \textit{Google Latitude} \citep{Latitude} an. Bei diesem Programm ist es möglich die Position
-von Freunden, die diesen auch Dienst 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. Es existiert auch eine Paper mit dem
-Titel \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS}. Hierfür wurde ein Dienst für mobile Geräte implementiert,
-welcher Daten verschlüsselt an mehrere Nutzer sendet. Für diesen Dienst wurde auch mit ein möglichst einfaches und verlässliches
-Protokoll entworfen, mit dem Ziel die Berechnungszeiten niedrig zu halten. Des weiteren hat man in dem Paper
-\textit{FriendSensing: Recommending Friends Using Mobile Phones} \citep{FriendSensing} Möglichkeiten erörtert um die Position
-anderer Benutzer mit Hilfe von \textit{Bluetooth} zu bestimmen. Hierbei registrierte eine Software wie oft welcher Nutzer mit
-einem anderen in Kontakt stand und wie oft sie in \textit{Bluetooth} Reichweite waren. Diese Aufzählung, über Software die
-sich mit der Thematik von \textit{location awareness} auseinandersetzt könnte an dieser Stelle noch weiter fortgeführt werden da
-es hierfür Unmengen an Programmen gibt. \newline
-
-Allerdings nutzen diese Programme, die oft auf \textit{Google Maps} basieren, meistens das Prinzip eines zentralen Knotenpunktes,
-an welchen die Positionsdaten gesendet werden und dieser diese dann weiterleitet. Somit existiert immer eine zentrale
-Kontrollinstanz, welche Einsicht in die Daten der Nutzer hat, während die Nutzer selbst immer nur Zugang zu den für sie bestimmten
- Daten besitzen. Somit können die Nutzer auch nicht die Nutzung ihrer Daten durch den Anbieter einsehen. Die Folgen hiervon
-könnten sein, dass zum Beispiel der Anbieter gezielt Werbung für die Position der Nutzer einspielt, da er ihren Aufenthaltsort
-immer kennt. \newline
-
-Bestehende Software dieser Art verschlüsselt auch in den seltensten Fällen die versendeten Daten. Da es sich bei Positionsdaten
-um sehr sensible Daten handelt stellt dies ein großes Manko dar. So könnten Dritte den Datenverkehr abhören und auch
-Positionsdaten von Nutzern erhalten, die diese nur einer bestimmten Gruppe zur Verfügung stellen wollten. Sind diese
-Positionsdaten erst einmal gesammelt können ohne weiteres Bewegungsprofile erstellt und missbraucht werden. Der Benutzer begibt
-sich also mit der Nutzung von solchen Programmen in die Gefahr das regelmäßige Aufenthaltsorte erkannt werden und der ständig
-aufspürbar ist. Somit stellen solche Dienste, die sensible Daten dieser Art ohne Verschlüsselung versenden, eine starke
-Einschränkung für die Privatsphäre dar.\newline
+existieren auch eine Menge von Anwendungen, die die eigene Position für Freunde sichtbar macht.\newline
+So bietet \textit{Google} beispielsweise 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 die Positionsdaten auf optimale Art und Weiße zu schützen, sollten diese nur in einem verschlüsselten Format
+versendet werden. Positionsdaten stellen für den Nutzer sensible Daten dar, da sie viel über seine Gewohnheiten und täglichen
+Ablauf verraten können. Wenn man diese Daten unverschlüsselt versendet so begibt man sich in die Gefahr das regelmäßige
+Aufenthaltsorte erkannt werden oder man sogar ständig aufspürbar ist, was eine erhebliche Verletzung der \textit{location
+privacy} darstellen würde.\newline
+Mit der Thematik von verschlüsselter Datenübertragung auf mobilen Geräten befasst sich eine Arbeit mit dem Titel
+\textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS}. 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
+
+Ein anderes Problem stellt die Nutzung von zentral organisierten Netzen dar. Hier ist es möglich, ohne das der Benutzer davon
+Kentniss hat, auf alle über diesen Knoten versandten Daten zuzugreifen. Dies könnte durch die Nutzung eines dezentralen,
+verteilten Systems eingeschränkt werden. Somit würde nicht nur keine Kontrollinstanz existieren, welche Einsicht in die Daten der
+Nutzer hat während die Nutzer selbst immer nur Zugang zu den für sie bestimmten Daten besitzen, sondern man könnte die Daten auf
+mehrere Knoten verteilen. Diese Tatsache würde das gezielte Sammeln von Daten erschweren und somit der oben genannten Defintion
+von \textit{location privacy} entgegenkommen.\newline
+
+\subsection{Anwendungsmöglichkeiten}
+
+Die Verbreitung von solchen mobilen Geräten hat in den letzten Jahren beständig zugenommen und alle neueren Modelle besitzen ein
+\textit{GPS}-Modul. Des weiteren sind alle modernen Geräte in der Lage, Daten sowohl über den \textit{3G}-Standart
+sowie per \textit{WLAN} zu übertragen. Wenn nun eine Gruppe, welche mit entsprechenden mobilen Geräten ausgestattet ist,
+die Positionen austauschen möchte, so wird zuallerst ein Protokoll benötigt welches die Daten versenden kann. Dieses Protokoll
+sollte sowohl verlässlich als auch für langsame Netze konzipiert sein. Im nächsten Schritt soll diese Verbindung nun nur
+verschlüsselte Daten übertragen. Hierzu wird also ein geeigneter Algorithmus benötigt, welcher die Daten verschlüsselt. Dieser
+sollte dabei bei möglichst wenig Berechnungsaufwand eine möglichst gute Verschlüsselung bieten.\newline
+Will man nun Daten verschlüsseln so benötigen sowohl Sender als auch Empfänger die gleichen Schlüssel. Es wird also auch eine
+Möglichkeit gesucht, mit deren Hilfe man Schlüssel auf eine sichere Art und Weiße übertragen kann. Sind diese Anforderungen
+erfüllt, so können die Mitglieder dieser Gruppe nun ihre Positionsdaten austauschen, ohne diese Möglichweiße Personen mitzuteilen
+für die diese nicht bestimmt sind.\newline
+Mit diesem gegebenen Protokoll und den Verschlüsselungsverfahren ist es nun ohne weiteres möglich auch Textnachrichten zwischen
+zwei Mitgliedern einer Gruppe auszutauschen. \newline
+%Wenn nun eine Benutzergruppe dieses Programm nutzen möchte, so sollte dies für sie mit einfachen Mitteln möglich sein. Hierzu
+%betrachten wir den Fall, dass eine Gruppe von Touristen in einer ihnen fremden Stadt
+%unterwegs ist. Die Reiseteilnehmer möchten nun auf eigene Faust die Stadt erkunden. Da die Gruppeteilnehmer ihre Daten nicht
+%öffentlich preisgeben wollen, möchten sie ein verschlüsselte Verbindung untereinander aufbauen. Dazu wird im ersten Schritt ein
+%oder mehrere Schlüssel benötigt. Beim Verteilen der Schlüssel stellt sich nun die Frage wie dies ohne großen Aufwand aber mit
+%maximaler Sicherheit möglich ist. Hier könnte nun ein Gruppenmitglied einen oder mehrere Schlüssel erstellen und diese an die
+%jeweiligen Teilnehmer senden. Nach dem Austausch der Schlüssel kann nun über eine beliebige Infrastruktur eine Verbindung mit den
+%anderen Teilnehmern der Gruppe aufgebaut werden. \newline
+%Nun stellt sich allerdings auch die Frage nach der Anzahl der zu verteilenden Schlüssel. Je nach Art der Verschlüsselung reicht
+%ein Schlüssel aus, oder es sind mehrere nötig. Würde die Software eine asymmetrische Verschlüsselung benutzen, so müsste jeder
+%Nutzer einen privaten Schlüssel erstellen und sich, mittels scannen eines Barcodes, den zugehörigen öffentlichen Schlüssel
+%besorgen. Dies hätte zur Folge das man, je nach Gruppe mit der kommuniziert werden soll, immer mehrere Schlüssel besitzen und
+%verwalten müsste. Je nach gewähltem Verfahren kann auch zusätzlich noch ein Zertifikat für diese Schlüssel hinzukommen. Ein
+%symmetrischen Kryptographieverfahren hätte hier den Vorteil, dass man nur einen Schlüssel an alle Benutzer der Gruppe verteilen
+%müsste. Des weitern fällt der Verwaltungsaufwand hier wesentlich geringer aus, da nur ein Schlüssel pro Gruppe von nöten ist.
+%Zusätzlich würde auch noch für ein symmetrisches Verfahren sprechen,dass diese einen wesentlich geringeren Berechnungsaufwand
+%haben und somit der Akku länger halten würde.\newline
+%Wenn diese Gruppe sich nun aufteilt, um getrennt die Stadt zu erkunden, so kann nun über die bestehnde Verbindung kommuniziert
+%werden. Die Gruppenteilnehmer möchten hierbei sehen wo die anderen Mitreisenden sich gerade befinden. Allerdings ist es für die
+%Teilnehmer hier nicht von Interesse, die Position weit entfernter Teilnehmer zu sehen, da der Fussweg zu deren Standort zu weit
+%wäre. Es wäre also nützlich, für den Benutzer, wenn er ab einem bestimmten Abstand die anderen Teilnehmer ausblenden könnte.
+%Endeckt nun ein Mitglied dieser Reisegruppe eine besondere Sehenswürdigkeit, möchte er dies vielleicht einem Freund aus der
+%Reisegruppe mitteilen. Zu diesem Zweck bräuchte er eine Chatfunktion, mit welcher er andere Gruppenmitglieder kontaktieren und
+%mit
+%ihnen Nachrichten austauschen kann. Allerdings sollte auch diese Funktion, aus Gründen der Privatsphäre, Daten nur in einem
+%%verschlüsselten Format übertragen. Des weiteren sollte es möglich sein nur mit dieser einen Person gezielt zu chatten, ohne das
+%die gesamte Gruppe mithören kann. Natürlich wäre hier noch eine Zusatzfunktion möglich, die einen Chat mit der gesamten Gruppe
+%%verfügbar macht. Wenn dieser Tourist nun seinen Freund per Chat kontaktiert hat, können sich diese nun einen Treffpunkt
+%verabreden
+%und diesen auf der Karte dem anderen Teilnehmer senden und im Anschluss sich den Weg dorthin errechnen lassen. \newline
\subsection{Ziele}
-Die obigen zwei Punkte wurden bisher in den meisten noch nicht berücksichtigt. Somit besteht seitens der Nutzer
-mit Sicherheit eine Nachfrage nach einer Software, welche ihre Persönlichen Daten auf sicherem Wege schützt und trotzdem noch die
-gewohnte Funktionalität bietet. Hierfür muss sichergestellt sein, dass es den Nutzern ohne Fachkentniss möglich ist, Schlüssel
-zur Verschlüsselung untereinander auszutauschen und somit festzulegen wer alles diese Positionsdaten erhalten darf. Des
-weiteren muss beim Schlüsselaustausch gewährleistet sein, dass der Schlüssel auf eine sichere Art und Weiße übertragen
-wird, ohne das andere diesen abfangen können. Hierbei muss allerdings beachtet werden, dass diese Software auf mobilen Geräten
-lauffähig sein soll. Es sollte also gewährleistet werden dass die genutzten Algorithmen nicht zu berechnungsintensiv sind, die
-Datensicherheit aber trotz allem gegeben ist. \newline
+Die Anwendung eines solchen Programmes soll dem Nutzer möglichst einfach gemacht werden. Es soll also sicher gestellt sein, dass
+es auch Benutzern ohne Fachkentniss möglich ist, die benötigten Schlüssel untereinander auszutauschen und somit festzulegen wer
+alles diese Positionsdaten einsehen darf. Dies ist notwendig um auch Personen, die mit der Thematik von \textit{location privacy}
+noch nicht so vertraut sind, die Nutzung des Programmes zu ermöglichen. Des weiteren muss beim Schlüsselaustausch gewährleistet
+sein, dass der Schlüssel auf eine sichere Art und Weiße übertragen wird, ohne das andere diesen mitlesen können. Hierbei muss
+allerdings beachtet werden, dass diese Software auf mobilen Geräten lauffähig sein soll. Es sollte also gewährleistet werden dass
+die genutzten Algorithmen nicht zu berechnungsintensiv sind, die Datensicherheit aber trotz allem gegeben ist. \newline
Da auch ein zentraler Knoten, über den der gesamte Datenverkehr aller Benutzer läuft, unerwünscht ist, muss hier ein
-Kommunikationsdienst genutzt werden, welcher nach ein dezentrales Prinzip verfolgt. Auch hier muss, wie bei der
+Kommunikationsdienst genutzt werden, welcher ein dezentrales Prinzip verfolgt. Auch hier muss, wie bei der
Datenverschlüsselung, gewährleistet sein dass die Bedienung für den Anwender möglichst einfach gehalten wird und er somit ohne
Aufwand und Fachwissen die Kommunikationsparameter einstellen und abändern kann. \newline
@@ -56,96 +97,75 @@ Da mittlerweile eine große Anzahl an unterschiedlichen Plattformen für mobile
die Software auf möglichst vielen dieser Betriebssystemen lauffähig ist. So ist sichergestellt, dass möglichst viele Benutzer
erreicht werden. \newline
-\subsection{Anwendungsmöglichkeiten}
-
-Wenn nun eine Benutzergruppe dieses Programm nutzen möchte, so sollte sie in der Lage sein mit einfachen Mitteln die nötigen
-Parameter zu verteilen. Hierzu betrachten wir den möglichen Fall, dass eine Gruppe von Touristen in einer ihnen fremden Stadt
-unterwegs sind. Diese möchten nun auf eigene Faust diese Stadt erkunden. Hierzu müssen zuerst geignete Kartendaten vorhanden
-sein. Hier sollten, wenn möglich, freie Kartendaten verwendet werden um Nebenkosten zu verringern. Es muss allerdings darauf
-geachtet werden das diese möglichst immer auf einem aktuellen Stand sind. Wenn so eine Karte vorhanden ist, so kann im
-nächstenwird Schritt ein Schlüssel erstellt und an alle Teilnehmer dieser Gruppe verteilt werden. Beim Verteilen stellt
-sich nun die Frage wie dies ohne großen Aufwand aber mit maximaler Sicherheit möglich ist. Hier könnte nun ein Gruppenmitglied
-einen oder mehrere Schlüssel erstellen und diese sich in Form eines \textit{2D-Barcodes} ausgeben lasen. Dieser Barcode kann nun
-von den anderen Nutzern, mit deren Smart Phones, gescannt und wieder in einen Schlüssel, bestehend aus Zeichenketten, umgewandelt
-werden. Da dies keine Kommunikation zwischen den Geräten erfordert kann kein dritter diese Schlüssel während der Datenübertragung
-abfangen.\newline
-Nun stellt sich allerdings auch die Frage nach der Anzahl der zu verteilenden Schlüssel. Je nach Art der Verschlüsselung reicht
-ein Schlüssel aus, oder es sind mehrere nötig. Würde die Software eine asymmetrische Verschlüsselung benutzen, so müsste jeder
-Nutzer einen privaten Schlüssel erstellen und sich, mittels scannen eines Barcodes, den öffentlichen Schlüssel besorgen. Dies
-hätte zur folge das man, je nach Gruppe mit der kommuniziert werden soll, immer mehrere Schlüssel besitzen und verwalten müsste.
-Je nach gewähltem Verfahren kann auch zusätzlich noch ein Zertifikat für diese Schlüssel hinzukommen. Der normale Benutzer müsste
-hier also schon seine Schlüssel richtig verwalten. Ein symmetrischen Kryptographieverfahren hätte hier den Vorteil, dass man nur
-einen Schlüssel an alle Benutzer der Gruppe verteilen müsste. Des weitern fällt der Verwaltungsaufwand hier wesentlich geringer
-aus, da nur ein Schlüssel pro Gruppe von nöten ist. Was des weiteren auch noch für ein symmetrisches Verfahren sprechen würde,
-ist die Tatsache dass diese einen wesentlich geringeren Berechnungsaufwand haben und somit der Akku länger halten würde.\newline
-Nachdem diese Gruppe von Touristen nun ihre Schlüssel ausgetauscht haben erkunden sie unabhängig voneinander die Stadt. Dabei
-möchten sie sehen wo die anderen Mitreisenden sich gerade befinden. Allerdings ist es für die Teilnehmer hier nicht von
-Interesse, die anderen Teilnehmer auserhalb eines bestimmten Radiuses zu sehen, da der Fussweg zu deren Standort zu weit wäre. Es
-wäre also nützlich für den Benutzer wenn er ab einem bestimmten Radius die anderen Teilnehmer ausblenden könnte. Endeckt nun ein
-Mitglied dieser Reisegruppe eine besondere Sehenswürdigkeit, möchte er dies vielleicht einem Freund aus der Reisegruppe
-mitteilen. Zu diesem Zweck bräuchte er eine Chatfunktion, mit welcher er andere Gruppenmitglieder kontaktieren und mit ihnen
-Nachrichten austauschen kann. Allerdings sollte auch diese Funktion aus Gründen der Privatsphäre Daten nur in einem
-verschlüsselten Format übertragen. Des weiteren sollte es möglich sein nur mit dieser einen Person gezielt zu chatten, ohne das
-die gesamte Gruppe mithören kann. Natürlich könnte man sich auch hier noch eine Zusatzfunktion überlegen, die einen Chat mit
-der gesamten Gruppe ermöglicht. Wenn dieser Tourist nun seinen Freund per Chat kontaktiert hat, können sich diese nun einen
-Treffpunkt verabreden und diesen entweder auf der Karte dem anderen Teilnehmer senden und im Anschluss den Weg dorthin sich
-errechnen lassen. \newline
-
-Ein weiterer möglicher Fall wäre dass man mit Freunden kommunzieren möchte, aber keine \textit{UMTS} Datenflatrate
-besitzt. Es sollte also auch sichergestellt sein dass die Datenpakete, welche versandt werden, nicht allzu groß sind und auch die
-Anzahl der Hintergrunddaten, die vom verwendeten Protokoll versandt werden, nicht zu groß ist. So ist zum einen gesichert das
-nicht zu hohe Verbindungskosten entsehen und zum anderen auch der Berechnungsaufwand für das erstellen und versenden dieser
-Pakete nicht zu groß ist. \newline
-
\subsection{Anforderungen}
-Anhand der zwei vorrangegangenen Beispielen ist gut erkennbar was an Funktionalität benötigt wird. So sollte es möglich sein die
-Standorte anderer Nutzer zu auf einer Karte zu anzuzeigen. Damit für andere Nutzer die eigene Position sichtbar ist, muss diese in
-einem gängigen Format versendet werden. Hierfür ist das Format \textit{Latitude}/\textit{Longtitude} bestens geignet. Um
-die Datensicherheit zu garantieren müssen diese Positionsdaten in verschlüsselter Form versendet werden. \newline
+Anhanden der Anwendungsmöglichkeiten lassen sich die Anforderungen, die an die Software gestellt werden, ableiten. So sollte
+es möglich sein die Standorte anderer Nutzer anzuzeigen. Damit für andere Anwender die eigene Position sichtbar
+ist, muss diese in einem gängigen Format versendet werden. Hierfür ist das Format \textit{Latitude}/\textit{Longtitude} bestens
+geignet, da es sich um das am meisten verbreitetste Format handelt und es möglich ist jeden Punkt auf der Erdeerfläche ob in
+diesem Geokoordinatensystem darzustellen. 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 muss das Programm in der Lage sein, die eigehenden Positionsdaten sowohl zu
+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 sollte auch möglich sein, nur
-Benutzer innerhalb einer bestimmten Entfernung anzuzeigen, da eine Person die sich in 6 Kilometer Entfernung aufhält für Dienste
-dieser Art nur begrenzt sinnvoll sind. \newline
+Benutzer innerhalb einer bestimmten Entfernung anzuzeigen, da eine Person die sich in sechs Kilometer Entfernung aufhält für
+Dienste dieser Art nur begrenzt sinnvoll sind. \newline
Um die Kommunikation zwischen verschiedenen Teilnehmern zu ermöglichen sollte es möglich sein Chatnachrichten auszutauschen. Auch
-hier muss gewährleistet sein das der Datenverkehr verschlüsselt ablaufen muss und somit dritte nicht die Konversation mitlesen
-können. \newline
+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. Hierzu kann aus einer vorher festgelegten Zeichenkette einen
-2D-Barcode erstellt und angezeigt werden. Zur Weitergabe des Schlüssels muss nun der andere Anwender diesen vom Display
-fotographieren. \newline
+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
\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. Wie schon erwähnt ist aufgrund von sowohl Berechnungsaufwand als auch von
-Schlüsselverwaltung 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. Die Daten werden also
-durch Client A ver- und von Client B entschlüssel. \newline
-Die Schlüssel können, wie schon beschrieben, durch das Erstellen eines \textit{2D-Barcodes} und das fotographieren von diesem
-ausgetauscht werden.
-
-Für die Kommunikation zwischen den einzelnen Teilnehmern ist ein dezentrales Protokoll von nöten, welches möglichst wenig
-Daten verschickt welche nichts mit der eigentlichen Kommunikation zu tun haben, das stabil läuft und welches beim Ausfallen eines
+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
-Eine Möglichkeit wäre hier eine \textit{Peer-to-Peer} Lösung. Allerdings verbietet ein Großteil der \textit{GSM}-Provider
-\textit{Peer-to-Peer} Datenverkehr innerhalb ihrer Netze, womit diese Lösung praktisch nicht anwendbar wäre. Ein Vorhandenes
-Protokoll, welches ein aktives Netzwerk bereitstellt und dieses und auch rege genutzt wird, ist das \textit{IRC}-Protokoll
-\citep{IRC}. Dieses stellt mehrere Server zur Verfügung, wobei jeder Nutzer auch einen eigenen Server bereitstellen kann, die
-mehrere \textit{Channels} haben können. \textit{IRC} ist ein Chatprotokoll welches auch Dateien versenden kann. Würde nun ein
-Server ausfallen, so könnten die Nutzer auf einen anderen \textit{IRC}-Server wechseln. 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.\newline
-
-Durch die Wahl dieser Lösung ist also garantiert, dass sowohl die Berechnungszeiten durch ein symmetrisches Verfahren niedrig
-gehalten werden, der Verwaltungsaufwand für die Schlüssel ist gering da nur ein Schlüssel pro Gruppe gespeichert werden muss 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 diesen 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, anderst als bei anderen Anwendungen
-dieser Art, gesichert. \ No newline at end of file
+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
diff --git a/ausarbeitung/Grundlagen.tex~ b/ausarbeitung/Grundlagen.tex~
index d83d1c6..68519a1 100644
--- a/ausarbeitung/Grundlagen.tex~
+++ b/ausarbeitung/Grundlagen.tex~
@@ -1,54 +1,99 @@
\section{Grundlagen}
-In diesem ersten Teil dieser Bachelor-Arbeit wird der momentane Stand von \textit{location awareness} Software auf mobilen
-Geräten aufgezeigt. Es wird auch analysiert, was für Anforderungen an ein Programm dieser Art gestellt werden um einen sicheren
-Datenverkehr zu garantieren.
+In diesem ersten Teil dieser Bachelor-Arbeit 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.
\subsection{Aktueller Stand}
+
Da so gut wie alle aktuellen Smart Phones mit einem \textit{GPS} ausgestattet sind existieren für die verschiedenen
-Betriebssysteme schon eine Reihe von Anwendungen die Funktionalitäten für \textit{location awareness} bieten. So existieren
+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. Es
-existieren auch eine Menge an Anwendungen die die eigene Position für Freunde sichtbar macht.\newline
-So bietet \textit{Google} den Dienst \textit{Google Latitude} \citep{Latitude} an. Bei diesem Programm ist es möglich die Position
-von Freunden, die diesen auch Dienst 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. Es existiert auch eine Paper mit dem
-Titel \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS}. Hierfür wurde ein Dienst für mobile Geräte implementiert,
-welcher Daten verschlüsselt an mehrere Nutzer sendet. Für diesen Dienst wurde auch mit ein möglichst einfaches und verlässliches
-Protokoll entworfen, mit dem Ziel die Berechnungszeiten niedrig zu halten. Des weiteren hat man in dem Paper
-\textit{FriendSensing: Recommending Friends Using Mobile Phones} \citep{FriendSensing} Möglichkeiten erörtert um die Position
-anderer Benutzer mit Hilfe von \textit{Bluetooth} zu bestimmen. Hierbei registrierte eine Software wie oft welcher Nutzer mit
-einem anderen in Kontakt stand und wie oft sie in \textit{Bluetooth} Reichweite waren. Diese Aufzählung, über Software die
-sich mit der Thematik von \textit{location awareness} auseinandersetzt könnte an dieser Stelle noch weiter fortgeführt werden da
-es hierfür Unmengen an Programmen gibt. \newline
-
-Allerdings nutzen diese Programme, die oft auf \textit{Google Maps} basieren, meistens das Prinzip eines zentralen Knotenpunktes,
-an welchen die Positionsdaten gesendet werden und dieser diese dann weiterleitet. Somit existiert immer eine zentrale
-Kontrollinstanz, welche Einsicht in die Daten der Nutzer hat, während die Nutzer selbst immer nur Zugang zu den für sie bestimmten
- Daten besitzen. Somit können die Nutzer auch nicht die Nutzung ihrer Daten durch den Anbieter einsehen. Die Folgen hiervon
-könnten sein, dass zum Beispiel der Anbieter gezielt Werbung für die Position der Nutzer einspielt, da er ihren Aufenthaltsort
-immer kennt. \newline
-
-Bestehende Software dieser Art verschlüsselt auch in den seltensten Fällen die versendeten Daten. Da es sich bei Positionsdaten
-um sehr sensible Daten handelt stellt dies ein großes Manko dar. So könnten Dritte den Datenverkehr abhören und auch
-Positionsdaten von Nutzern erhalten, die diese nur einer bestimmten Gruppe zur Verfügung stellen wollten. Sind diese
-Positionsdaten erst einmal gesammelt können ohne weiteres Bewegungsprofile erstellt und missbraucht werden. Der Benutzer begibt
-sich also mit der Nutzung von solchen Programmen in die Gefahr das regelmäßige Aufenthaltsorte erkannt werden und der ständig
-aufspürbar ist. Somit stellen solche Dienste, die sensible Daten dieser Art ohne Verschlüsselung versenden, eine starke
-Einschränkung für die Privatsphäre dar.\newline
+existieren auch eine Menge von Anwendungen, die die eigene Position für Freunde sichtbar macht.\newline
+So bietet \textit{Google} beispielsweise 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
+Es wurde in einer Befragung von Versuchspersonen herausgefunden, dass diese keine Bedenken im Bezug auf Positionsdaten und
+Privatsphäre haben \citep{location}. Da es aber immer mehr solcher Dienste gibt, sollte man gerade zum Schutz diese Benutzer,
+Anwendungen entwickeln welche Wert auf die Wahrung \textit{location privacy } legen.\newline
+Um die Positionsdaten auf optimale Art und Weiße zu schützen, sollten diese nur in einem verschlüsselten Format
+versendet werden. Positionsdaten stellen für den Nutzer sensible Daten dar, da sie viel über seine Gewohnheiten und täglichen
+Ablauf verraten können. Wenn man diese Daten unverschlüsselt versendet so begibt man sich in die Gefahr das regelmäßige
+Aufenthaltsorte erkannt werden oder man sogar ständig aufspürbar ist, was eine erhebliche Verletzung der \textit{location
+privacy} darstellen würde.\newline
+Mit der Thematik von verschlüsselter Datenübertragung auf mobilen Geräten befasst sich eine Arbeit mit dem Titel
+\textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS}. 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
+
+Ein anderes Problem stellt die Nutzung von zentral organisierten Netzen dar. Hier ist es möglich, ohne das der Benutzer davon
+Kentniss hat, auf alle über diesen Knoten versandten Daten zuzugreifen. Dies könnte durch die Nutzung eines dezentralen,
+verteilten Systems eingeschränkt werden. Somit würde nicht nur keine Kontrollinstanz existieren, welche Einsicht in die Daten der
+Nutzer hat während die Nutzer selbst immer nur Zugang zu den für sie bestimmten Daten besitzen, sondern man könnte die Daten auf
+mehrere Knoten verteilen. Diese Tatsache würde das gezielte Sammeln von Daten erschweren und somit der oben genannten Defintion
+von \textit{location privacy} entgegenkommen.\newline
+
+\subsection{Anwendungsmöglichkeiten}
+
+Die Verbreitung von solchen mobilen Geräten hat in den letzten Jahren beständig zugenommen und alle neueren Modelle besitzen ein
+\textit{GPS}-Modul. Des weiteren sind alle modernen Geräte in der Lage, Daten sowohl über den \textit{3G}-Standart
+sowie per \textit{WLAN} zu übertragen. Wenn nun eine Gruppe, welche mit entsprechenden mobilen Geräten ausgestattet ist,
+die Positionen austauschen möchte, so wird zuallerst ein Protokoll benötigt welches die Daten versenden kann. Dieses Protokoll
+sollte sowohl verlässlich als auch für langsame Netze konzipiert sein. Im nächsten Schritt soll diese Verbindung nun nur
+verschlüsselte Daten übertragen. Hierzu wird also ein geeigneter Algorithmus benötigt, welcher die Daten verschlüsselt. Dieser
+sollte dabei bei möglichst wenig Berechnungsaufwand eine möglichst gute Verschlüsselung bieten.\newline
+Will man nun Daten verschlüsseln so benötigen sowohl Sender als auch Empfänger die gleichen Schlüssel. Es wird also auch eine
+Möglichkeit gesucht, mit deren Hilfe man Schlüssel auf eine sichere Art und Weiße übertragen kann. Sind diese Anforderungen
+erfüllt, so können die Mitglieder dieser Gruppe nun ihre Positionsdaten austauschen, ohne diese Möglichweiße Personen mitzuteilen
+für die diese nicht bestimmt sind.\newline
+Mit diesem gegebenen Protokoll und den Verschlüsselungsverfahren ist es nun ohne weiteres möglich auch Textnachrichten zwischen
+zwei Mitgliedern einer Gruppe auszutauschen. \newline
+%Wenn nun eine Benutzergruppe dieses Programm nutzen möchte, so sollte dies für sie mit einfachen Mitteln möglich sein. Hierzu
+%betrachten wir den Fall, dass eine Gruppe von Touristen in einer ihnen fremden Stadt
+%unterwegs ist. Die Reiseteilnehmer möchten nun auf eigene Faust die Stadt erkunden. Da die Gruppeteilnehmer ihre Daten nicht
+%öffentlich preisgeben wollen, möchten sie ein verschlüsselte Verbindung untereinander aufbauen. Dazu wird im ersten Schritt ein
+%oder mehrere Schlüssel benötigt. Beim Verteilen der Schlüssel stellt sich nun die Frage wie dies ohne großen Aufwand aber mit
+%maximaler Sicherheit möglich ist. Hier könnte nun ein Gruppenmitglied einen oder mehrere Schlüssel erstellen und diese an die
+%jeweiligen Teilnehmer senden. Nach dem Austausch der Schlüssel kann nun über eine beliebige Infrastruktur eine Verbindung mit den
+%anderen Teilnehmern der Gruppe aufgebaut werden. \newline
+%Nun stellt sich allerdings auch die Frage nach der Anzahl der zu verteilenden Schlüssel. Je nach Art der Verschlüsselung reicht
+%ein Schlüssel aus, oder es sind mehrere nötig. Würde die Software eine asymmetrische Verschlüsselung benutzen, so müsste jeder
+%Nutzer einen privaten Schlüssel erstellen und sich, mittels scannen eines Barcodes, den zugehörigen öffentlichen Schlüssel
+%besorgen. Dies hätte zur Folge das man, je nach Gruppe mit der kommuniziert werden soll, immer mehrere Schlüssel besitzen und
+%verwalten müsste. Je nach gewähltem Verfahren kann auch zusätzlich noch ein Zertifikat für diese Schlüssel hinzukommen. Ein
+%symmetrischen Kryptographieverfahren hätte hier den Vorteil, dass man nur einen Schlüssel an alle Benutzer der Gruppe verteilen
+%müsste. Des weitern fällt der Verwaltungsaufwand hier wesentlich geringer aus, da nur ein Schlüssel pro Gruppe von nöten ist.
+%Zusätzlich würde auch noch für ein symmetrisches Verfahren sprechen,dass diese einen wesentlich geringeren Berechnungsaufwand
+%haben und somit der Akku länger halten würde.\newline
+%Wenn diese Gruppe sich nun aufteilt, um getrennt die Stadt zu erkunden, so kann nun über die bestehnde Verbindung kommuniziert
+%werden. Die Gruppenteilnehmer möchten hierbei sehen wo die anderen Mitreisenden sich gerade befinden. Allerdings ist es für die
+%Teilnehmer hier nicht von Interesse, die Position weit entfernter Teilnehmer zu sehen, da der Fussweg zu deren Standort zu weit
+%wäre. Es wäre also nützlich, für den Benutzer, wenn er ab einem bestimmten Abstand die anderen Teilnehmer ausblenden könnte.
+%Endeckt nun ein Mitglied dieser Reisegruppe eine besondere Sehenswürdigkeit, möchte er dies vielleicht einem Freund aus der
+%Reisegruppe mitteilen. Zu diesem Zweck bräuchte er eine Chatfunktion, mit welcher er andere Gruppenmitglieder kontaktieren und
+%mit
+%ihnen Nachrichten austauschen kann. Allerdings sollte auch diese Funktion, aus Gründen der Privatsphäre, Daten nur in einem
+%%verschlüsselten Format übertragen. Des weiteren sollte es möglich sein nur mit dieser einen Person gezielt zu chatten, ohne das
+%die gesamte Gruppe mithören kann. Natürlich wäre hier noch eine Zusatzfunktion möglich, die einen Chat mit der gesamten Gruppe
+%%verfügbar macht. Wenn dieser Tourist nun seinen Freund per Chat kontaktiert hat, können sich diese nun einen Treffpunkt
+%verabreden
+%und diesen auf der Karte dem anderen Teilnehmer senden und im Anschluss sich den Weg dorthin errechnen lassen. \newline
\subsection{Ziele}
-Die obigen zwei Punkte wurden bisher in den meisten noch nicht berücksichtigt. Somit besteht seitens der Nutzer
-mit Sicherheit eine Nachfrage nach einer Software, welche ihre Persönlichen Daten auf sicherem Wege schützt und trotzdem noch die
-gewohnte Funktionalität bietet. Hierfür muss sichergestellt sein, dass es den Nutzern ohne Fachkentniss möglich ist, Schlüssel
-zur Verschlüsselung untereinander auszutauschen und somit festzulegen wer alles diese Positionsdaten erhalten darf. Des
-weiteren muss beim Schlüsselaustausch gewährleistet sein, dass der Schlüssel auf eine sichere Art und Weiße übertragen
-wird, ohne das andere diesen abfangen können. Hierbei muss allerdings beachtet werden, dass diese Software auf mobilen Geräten
-lauffähig sein soll. Es sollte also gewährleistet werden dass die genutzten Algorithmen nicht zu berechnungsintensiv sind, die
-Datensicherheit aber trotz allem gegeben ist. \newline
+Die Anwendung eines solchen Programmes soll dem Nutzer möglichst einfach gemacht werden und trotzdem die gesetzten Ziele, wie die
+Verschlüsselung der Daten und Nutzung einer dezentralen Infrastruktur, erfüllen. \newline
+
+Es soll also sicher gestellt sein, dass es auch Benutzern ohne Fachkentniss möglich ist, die benötigten Schlüssel untereinander
+auszutauschen und somit festzulegen wer alles diese Positionsdaten einsehen darf. Des weiteren muss beim Schlüsselaustausch
+gewährleistet sein, dass der Schlüssel auf eine sichere Art und Weiße übertragen wird, ohne das andere diesen mitlesen können.
+Hierbei muss allerdings beachtet werden, dass diese Software auf mobilen Geräten lauffähig sein soll. Es sollte also gewährleistet
+werden dass die genutzten Algorithmen nicht zu berechnungsintensiv sind, die Datensicherheit aber trotz allem gegeben ist.
+\newline
Da auch ein zentraler Knoten, über den der gesamte Datenverkehr aller Benutzer läuft, unerwünscht ist, muss hier ein
-Kommunikationsdienst genutzt werden, welcher nach ein dezentrales Prinzip verfolgt. Auch hier muss, wie bei der
+Kommunikationsdienst genutzt werden, welcher ein dezentrales Prinzip verfolgt. Auch hier muss, wie bei der
Datenverschlüsselung, gewährleistet sein dass die Bedienung für den Anwender möglichst einfach gehalten wird und er somit ohne
Aufwand und Fachwissen die Kommunikationsparameter einstellen und abändern kann. \newline
@@ -56,96 +101,75 @@ Da mittlerweile eine große Anzahl an unterschiedlichen Plattformen für mobile
die Software auf möglichst vielen dieser Betriebssystemen lauffähig ist. So ist sichergestellt, dass möglichst viele Benutzer
erreicht werden. \newline
-\subsection{Anwendungsmöglichkeiten}
-
-Wenn nun eine Benutzergruppe dieses Programm nutzen möchte, so sollte sie in der Lage sein mit einfachen Mitteln die nötigen
-Parameter zu verteilen. Hierzu betrachten wir den möglichen Fall, dass eine Gruppe von Touristen in einer ihnen fremden Stadt
-unterwegs sind. Diese möchten nun auf eigene Faust diese Stadt erkunden. Hierzu müssen zuerst geignete Kartendaten vorhanden
-sein. Hier sollten, wenn möglich, freie Kartendaten verwendet werden um Nebenkosten zu verringern. Es muss allerdings darauf
-geachtet werden das diese möglichst immer auf einem aktuellen Stand sind. Wenn so eine Karte vorhanden ist, so kann im
-nächstenwird Schritt ein Schlüssel erstellt und an alle Teilnehmer dieser Gruppe verteilt werden. Beim Verteilen stellt
-sich nun die Frage wie dies ohne großen Aufwand aber mit maximaler Sicherheit möglich ist. Hier könnte nun ein Gruppenmitglied
-einen oder mehrere Schlüssel erstellen und diese sich in Form eines \textit{2D-Barcodes} ausgeben lasen. Dieser Barcode kann nun
-von den anderen Nutzern, mit deren Smart Phones, gescannt und wieder in einen Schlüssel, bestehend aus Zeichenketten, umgewandelt
-werden. Da dies keine Kommunikation zwischen den Geräten erfordert kann kein dritter diese Schlüssel während der Datenübertragung
-abfangen.\newline
-Nun stellt sich allerdings auch die Frage nach der Anzahl der zu verteilenden Schlüssel. Je nach Art der Verschlüsselung reicht
-ein Schlüssel aus, oder es sind mehrere nötig. Würde die Software eine asymmetrische Verschlüsselung benutzen, so müsste jeder
-Nutzer einen privaten Schlüssel erstellen und sich, mittels scannen eines Barcodes, den zugehörigen öffentlichen Schlüssel
-besorgen. Dies hätte zur Folge das man, je nach Gruppe mit der kommuniziert werden soll, immer mehrere Schlüssel besitzen und
-verwalten müsste. Je nach gewähltem Verfahren kann auch zusätzlich noch ein Zertifikat für diese Schlüssel hinzukommen. Ein
-symmetrischen Kryptographieverfahren hätte hier den Vorteil, dass man nur einen Schlüssel an alle Benutzer der Gruppe verteilen
-müsste. Des weitern fällt der Verwaltungsaufwand hier wesentlich geringer aus, da nur ein Schlüssel pro Gruppe von nöten ist.
-Zusätzlich würde auch noch für ein symmetrisches Verfahren sprechen,dass diese einen wesentlich geringeren Berechnungsaufwand
-haben und somit der Akku länger halten würde.\newline
-Nachdem diese Gruppe von Touristen nun ihre Schlüssel ausgetauscht haben erkunden sie unabhängig voneinander die Stadt. Dabei
-möchten sie sehen wo die anderen Mitreisenden sich gerade befinden. Allerdings ist es für die Teilnehmer hier nicht von
-Interesse, die anderen Teilnehmer auserhalb eines bestimmten Radiuses zu sehen, da der Fussweg zu deren Standort zu weit wäre. Es
-wäre also nützlich für den Benutzer wenn er ab einem bestimmten Abstand die anderen Teilnehmer ausblenden könnte. Endeckt nun ein
-Mitglied dieser Reisegruppe eine besondere Sehenswürdigkeit, möchte er dies vielleicht einem Freund aus der Reisegruppe
-mitteilen. Zu diesem Zweck bräuchte er eine Chatfunktion, mit welcher er andere Gruppenmitglieder kontaktieren und mit ihnen
-Nachrichten austauschen kann. Allerdings sollte auch diese Funktion aus Gründen der Privatsphäre, Daten nur in einem
-verschlüsselten Format übertragen. Des weiteren sollte es möglich sein nur mit dieser einen Person gezielt zu chatten, ohne das
-die gesamte Gruppe mithören kann. Natürlich wäre hier noch eine Zusatzfunktion möglich, die einen Chat mit der gesamten Gruppe
-verfügbar macht. Wenn dieser Tourist nun seinen Freund per Chat kontaktiert hat, können sich diese nun einen
-Treffpunkt verabreden und diesen auf der Karte dem anderen Teilnehmer senden und im Anschluss den Weg dorthin sich
-errechnen lassen. \newline
-
-Ein weiterer möglicher Fall wäre dass man mit Freunden kommunzieren möchte, aber keine \textit{UMTS} Datenflatrate
-besitzt und kein öffentliches WLAN in Reichweite ist. Es sollte also auch sichergestellt sein dass die Datenpakete, welche
-versandt werden, nicht allzu groß sind. Auch die Anzahl der Hintergrunddaten, die vom verwendeten Protokoll versandt werden,
-sollten nicht zu groß ist. So ist zum einen gesichert das nicht zu hohe Verbindungskosten entsehen und zum anderen auch der
-Berechnungsaufwand für das erstellen und versenden dieser Pakete nicht zu groß ist. \newline
-
\subsection{Anforderungen}
-Anhand der zwei vorrangegangenen Beispielen ist gut erkennbar was an Funktionalität benötigt wird. So sollte es möglich sein die
-Standorte anderer Nutzer zu auf einer Karte zu anzuzeigen. Damit für andere Nutzer die eigene Position sichtbar ist, muss diese in
-einem gängigen Format versendet werden. Hierfür ist das Format \textit{Latitude}/\textit{Longtitude} bestens geignet. Um
-die Datensicherheit zu garantieren müssen diese Positionsdaten in verschlüsselter Form versendet werden. \newline
+Anhanden der Anwendungsmöglichkeiten lassen sich die Anforderungen, die an die Software gestellt werden, ableiten. So sollte
+es möglich sein die Standorte anderer Nutzer anzuzeigen. Damit für andere Anwender die eigene Position sichtbar
+ist, muss diese in einem gängigen Format versendet werden. Hierfür ist das Format \textit{Latitude}/\textit{Longtitude} bestens
+geignet, da es sich um das am meisten verbreitetste Format handelt und es möglich ist jeden Punkt auf der Erdeerfläche ob in
+diesem Geokoordinatensystem darzustellen. 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 muss das Programm in der Lage sein, die eigehenden Positionsdaten sowohl zu
+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 sollte auch möglich sein, nur
-Benutzer innerhalb einer bestimmten Entfernung anzuzeigen, da eine Person die sich in 6 Kilometer Entfernung aufhält für Dienste
-dieser Art nur begrenzt sinnvoll sind. \newline
+Benutzer innerhalb einer bestimmten Entfernung anzuzeigen, da eine Person die sich in sechs Kilometer Entfernung aufhält für
+Dienste dieser Art nur begrenzt sinnvoll sind. \newline
Um die Kommunikation zwischen verschiedenen Teilnehmern zu ermöglichen sollte es möglich sein Chatnachrichten auszutauschen. Auch
-hier muss gewährleistet sein das der Datenverkehr verschlüsselt ablaufen muss und somit Dritte nicht die Konversation mitlesen
-können. \newline
+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. Hierzu kann aus einer vorher festgelegten Zeichenkette einen
-2D-Barcode erstellt und angezeigt werden. Zur Weitergabe des Schlüssels muss nun der andere Anwender diesen vom Display
-fotographieren. \newline
+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
\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 von Berechnungsaufwand als auch von Schlüsselverwaltung ist ein symmetrisches
+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. Die Daten werden also durch Client A ver- und von Client B
-entschlüssel. \newline
-Die Schlüssel können, wie schon beschrieben, durch das Erstellen eines \textit{2D-Barcodes} und das fotographieren von diesem
-zwischen den Anwendern Ausgetauscht werden.
+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
+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
-Eine Möglichkeit wäre hier eine \textit{Peer-to-Peer} Lösung. Allerdings verbietet ein Großteil der \textit{GSM}-Provider
-\textit{Peer-to-Peer} Datenverkehr innerhalb ihrer Netze, womit diese Lösung praktisch nicht anwendbar wäre. Ein Vorhandenes
-Protokoll, welches ein aktives Netzwerk bereitstellt und dieses und auch rege genutzt wird, ist das \textit{IRC}-Protokoll
-\citep{IRC}. Dieses stellt mehrere Server zur Verfügung, wobei jeder Nutzer auch einen eigenen Server bereitstellen
-kann. Jeder Server verwaltet mehrere \textit {Channels}. Würde nun ein Server ausfallen, so könnten die Nutzer auf einen anderen
+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
-
-Durch die Wahl dieser Lösung ist also garantiert, dass sowohl die Berechnungszeiten durch ein symmetrisches Verfahren niedrig
-gehalten werden, der Verwaltungsaufwand für die Schlüssel gering ist 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 diesen 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 anderen Anwendungen dieser Art, gesichert. \ No newline at end of file
+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
diff --git a/ausarbeitung/Title.tex b/ausarbeitung/Title.tex
index 2692e0b..68221e9 100644
--- a/ausarbeitung/Title.tex
+++ b/ausarbeitung/Title.tex
@@ -7,7 +7,7 @@
{\large B A C H E L O R A R B E I T}
\vspace{1.3cm}
-{\Huge Mobiler, persönlicher Assistent}
+{\Huge Mobiler Friend Finder }
\vspace{1.7cm}
{\Huge Patrick Hornecker}
diff --git a/ausarbeitung/Tutorial.aux b/ausarbeitung/Tutorial.aux
index 49ea512..7e5ac42 100644
--- a/ausarbeitung/Tutorial.aux
+++ b/ausarbeitung/Tutorial.aux
@@ -3,19 +3,19 @@
\citation{CeGCC}
\@writefile{toc}{\contentsline {section}{\numberline {3}Technische Grundlagen}{8}{section.3}}
\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Betriebsysteme f\IeC {\"u}r mobile Ger\IeC {\"a}te}{8}{subsection.3.1}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.1}Windows Mobile}{8}{subsubsection.3.1.1}}
\citation{Android}
\citation{WebOS}
\citation{iPhoneOS}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.1}Windows Mobile}{9}{subsubsection.3.1.1}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.2}Android}{9}{subsubsection.3.1.2}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.3}WebOS}{9}{subsubsection.3.1.3}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.4}iPhone OS}{9}{subsubsection.3.1.4}}
\citation{SymbianOS}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.4}iPhone OS}{10}{subsubsection.3.1.4}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.5}Symbian OS}{10}{subsubsection.3.1.5}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.6}Zielplattform}{10}{subsubsection.3.1.6}}
\@writefile{toc}{\contentsline {subsection}{\numberline {3.2}Softwaregrundlagen}{10}{subsection.3.2}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.2.1}CeGCC}{10}{subsubsection.3.2.1}}
\citation{efl}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.2.1}CeGCC}{11}{subsubsection.3.2.1}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.2.2}Enlightenment}{11}{subsubsection.3.2.2}}
\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Beispiele verschiedener \textit {Elementary} Icons}}{11}{figure.1}}
\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Aufbau von \textit {Enlightenment}}}{12}{figure.2}}
diff --git a/ausarbeitung/Tutorial.tex b/ausarbeitung/Tutorial.tex
index b32d7b9..990cb38 100644
--- a/ausarbeitung/Tutorial.tex
+++ b/ausarbeitung/Tutorial.tex
@@ -1,27 +1,32 @@
\section{Technische Grundlagen}
-Ein wichtiger Punkt ist auch die Wahl der passenden Plattform. Bei geeigneter Auswahl 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 die Kommunikation zwischen einem Besitzer eines \textit{iPhones} sowie dem Besitzer
-eines \textit{Palm Pre's} 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 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
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 \textit{Layer} soll also eine Schnittstelle zwischen Anwendungen und
-Betriebssytem sein. Ein solcher 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
-welche auch aktiv weiterentwickelt werden. Anwendungen die auf einem \textit{Linux}-System entwickelt wurden können somit
-ohne weiteres auf ein anderes, \textit{POSIX} kompatibles System, portiert werden.\newline
+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 sein. 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
+weiterentwickelt werden und auch ständig neue Bibliotheken erscheinen. 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
-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 nicht unerheblich. Im Folgenden werden fünf Betriebssysteme für mobile
Plattformen vorgestellt und auf deren Portierungsmöglichkeiten eingegangen.
\subsubsection{Windows Mobile}
@@ -62,9 +67,9 @@ 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 beinhaltet
-eine Erweiterung des \textit{POSIX Layers} names \textit{PIPS}. Somit werden 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}
@@ -147,4 +152,4 @@ 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 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 7ae5447..990cb38 100644
--- a/ausarbeitung/Tutorial.tex~
+++ b/ausarbeitung/Tutorial.tex~
@@ -1,27 +1,32 @@
\section{Technische Grundlagen}
-Ein wichtiger Punkt ist auch die Wahl der passenden Plattform. Bei geeigneter Auswahl 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 die Kommunikation zwischen einem Besitzer eines \textit{iPhones} sowie dem Besitzer
-eines \textit{Palm Pre's} 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 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
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 \textit{Layer} soll also eine Schnittstelle zwischen Anwendungen und
-Betriebssytem sein. Ein solcher 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
-welche auch aktiv weiterentwickelt werden. Anwendungen die auf einem \textit{Linux}-System entwickelt wurden können somit
-ohne weiteres auf ein anderes, \textit{POSIX} kompatibles System, portiert werden.\newline
+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 sein. 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
+weiterentwickelt werden und auch ständig neue Bibliotheken erscheinen. 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
-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 nicht unerheblich. Im Folgenden werden fünf Betriebssysteme für mobile
Plattformen vorgestellt und auf deren Portierungsmöglichkeiten eingegangen.
\subsubsection{Windows Mobile}
@@ -62,9 +67,9 @@ 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 beinhaltet
-eine Erweiterung des \textit{POSIX Layers} names \textit{PIPS}. Somit werden 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}
@@ -118,7 +123,7 @@ 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
+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}.
@@ -147,4 +152,4 @@ 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 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/literature.bib b/ausarbeitung/literature.bib
index 7d4f12f..6c2ee0d 100644
--- a/ausarbeitung/literature.bib
+++ b/ausarbeitung/literature.bib
@@ -85,6 +85,12 @@ url = {http://megaui.net/fukuchi/works/qrencode/index.en.html},
Note = {[Online; letzter Aufruf 11.02.2010]},
}
+@misc{qrcode,
+title = {QR Code},
+url = {http://www.denso-wave.com/qrcode/qrstandard-e.html},
+Note = {[Online; letzter Aufruf 11.02.2010]},
+}
+
@misc{PNG,
title = {libpng},
url = {http://www.libpng.org/},
@@ -117,13 +123,40 @@ Note = {[Online; letzter Aufruf 03.02.2010]},
@misc{SPALS,
title = {Spontaneous Privacy-Aware Location Sharing},
-author = {Klaus Rechert and Konstantin Welke},
+author = {Konstantin Welke and Klaus Rechert},
organization= {Lehrstuhl für Kommunikationssysteme, Albert-Ludwigs Universität Freiburg},
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},
+}
+
@misc{OSM,
Title = {OpenStreetMap},
url = {http://www.openstreetmap.de/},
Note = {[Online; letzter Aufruf 13.02.2010]},
+}
+
+@article{bluetooth,
+title = {Cracking the Bluetooth PIN},
+author = {Yaniv Shaked and Avishai Wool},
+journal = {Proceedings of the 3rd international conference on Mobile systems, applications, and services},
+organization= {School of Electrical Engineering Systems Tel Aviv University},
+year = {2005},
+pages = {39-50},
+}
+
+@article{location,
+title = {User needs for location-aware mobile services},
+author = {Eija Kaasinen},
+year = {2003},
+journal = {Personal and Ubiquitous Computing},
+pages = {70-79},
+volume = {Volume 7},
+number = {1},
} \ No newline at end of file
diff --git a/ausarbeitung/literature.bib.backup b/ausarbeitung/literature.bib.backup
index 40f1632..1faeb30 100644
--- a/ausarbeitung/literature.bib.backup
+++ b/ausarbeitung/literature.bib.backup
@@ -73,12 +73,6 @@ url = {http://www.google.com/intl/en_us/latitude/intro.html},
Note = {[Online; letzter Aufruf 11.02.2010]},
}
-@misc{Locale,
-title = {Locale},
-url = {http://www.twofortyfouram.com/},
-Note = {[Online; letzter Aufruf 11.02.2010]},
-}
-
@misc{POSIX,
title = {Portable Operating System Interface for Unix Layer},
url = {http://standards.ieee.org/regauth/posix/},
@@ -91,6 +85,12 @@ url = {http://megaui.net/fukuchi/works/qrencode/index.en.html},
Note = {[Online; letzter Aufruf 11.02.2010]},
}
+@misc{qrcode,
+title = {QR Code},
+url = {http://www.denso-wave.com/qrcode/qrstandard-e.html},
+Note = {[Online; letzter Aufruf 11.02.2010]},
+}
+
@misc{PNG,
title = {libpng},
url = {http://www.libpng.org/},
@@ -123,7 +123,38 @@ Note = {[Online; letzter Aufruf 03.02.2010]},
@misc{SPALS,
title = {Spontaneous Privacy-Aware Location Sharing},
-author = {Klaus Rechert and Konstantin Welke},
-OPTorganization = {Lehrstuhl für Kommunikationssysteme, Albert-Ludwigs Universität Freiburg},
+author = {Konstantin Welke and Klaus Rechert},
+organization= {Lehrstuhl für Kommunikationssysteme, Albert-Ludwigs Universität Freiburg},
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},
+}
+
+@misc{OSM,
+Title = {OpenStreetMap},
+url = {http://www.openstreetmap.de/},
+Note = {[Online; letzter Aufruf 13.02.2010]},
+}
+
+@article{bluetooth,
+title = {Cracking the Bluetooth PIN},
+author = {Yaniv Shaked and Avishai Wool},
+journal = {Proceedings of the 3rd international conference on Mobile systems, applications, and services},
+organization= {School of Electrical Engineering Systems Tel Aviv University},
+year = {2005},
+pages = {39-50},
+}
+
+@article{location,
+title = {User needs for location-aware mobile services},
+author = {Eija Kaasinen},
+year = {2003},
+journal = {Personal and Ubiquitous Computing},
+pages = {70-79},
} \ No newline at end of file
diff --git a/ausarbeitung/literature.bib~ b/ausarbeitung/literature.bib~
index 6880fff..caf72d1 100644
--- a/ausarbeitung/literature.bib~
+++ b/ausarbeitung/literature.bib~
@@ -85,6 +85,12 @@ url = {http://megaui.net/fukuchi/works/qrencode/index.en.html},
Note = {[Online; letzter Aufruf 11.02.2010]},
}
+@misc{qrcode,
+title = {QR Code},
+url = {http://www.denso-wave.com/qrcode/qrstandard-e.html},
+Note = {[Online; letzter Aufruf 11.02.2010]},
+}
+
@misc{PNG,
title = {libpng},
url = {http://www.libpng.org/},
@@ -117,8 +123,40 @@ Note = {[Online; letzter Aufruf 03.02.2010]},
@misc{SPALS,
title = {Spontaneous Privacy-Aware Location Sharing},
-author = {Klaus Rechert and Konstantin Welke},
+author = {Konstantin Welke and Klaus Rechert},
organization= {Lehrstuhl für Kommunikationssysteme, Albert-Ludwigs Universität Freiburg},
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},
+}
+
+@misc{OSM,
+Title = {OpenStreetMap},
+url = {http://www.openstreetmap.de/},
+Note = {[Online; letzter Aufruf 13.02.2010]},
+}
+
+@article{bluetooth,
+title = {Cracking the Bluetooth PIN},
+author = {Yaniv Shaked and Avishai Wool},
+journal = {Proceedings of the 3rd international conference on Mobile systems, applications, and services},
+organization= {School of Electrical Engineering Systems Tel Aviv University},
+year = {2005},
+pages = {39-50},
+}
+
+@article{location,
+title = {User needs for location-aware mobile services},
+author = {Eija Kaasinen},
+year = {2003},
+journal = {Personal and Ubiquitous Computing},
+pages = {70-79},
+volume = {Volume 7},
+number = {No. 1},
+} \ No newline at end of file
diff --git a/ausarbeitung/maindoc.aux b/ausarbeitung/maindoc.aux
index 3d9f771..8af28ed 100644
--- a/ausarbeitung/maindoc.aux
+++ b/ausarbeitung/maindoc.aux
@@ -39,12 +39,16 @@
\bibcite{OSM}{{12}{}{{OSM}}{{}}}
\bibcite{PalmOS}{{13}{}{{PalmOS}}{{}}}
\bibcite{POSIX}{{14}{}{{POSIX}}{{}}}
-\bibcite{SymbianOS}{{15}{}{{SymbianOS}}{{}}}
-\bibcite{WebOS}{{16}{}{{WebOS}}{{}}}
-\bibcite{Windows}{{17}{}{{Windows}}{{}}}
-\bibcite{Wireshark}{{18}{}{{Wireshark}}{{}}}
-\bibcite{xchat}{{19}{}{{xchat}}{{}}}
-\bibcite{FriendSensing}{{20}{2009}{{Quercia und Capra}}{{}}}
-\bibcite{SPALS}{{21}{2009}{{Rechert und Welke}}{{}}}
+\bibcite{qrcode}{{15}{}{{qrcode}}{{}}}
+\bibcite{SymbianOS}{{16}{}{{SymbianOS}}{{}}}
+\bibcite{WebOS}{{17}{}{{WebOS}}{{}}}
+\bibcite{Windows}{{18}{}{{Windows}}{{}}}
+\bibcite{Wireshark}{{19}{}{{Wireshark}}{{}}}
+\bibcite{xchat}{{20}{}{{xchat}}{{}}}
+\bibcite{privacy}{{21}{2003}{{Beresford und Stajano}}{{}}}
+\bibcite{location}{{22}{2003}{{Kaasinen}}{{}}}
+\bibcite{FriendSensing}{{23}{2009}{{Quercia und Capra}}{{}}}
+\bibcite{bluetooth}{{24}{2005}{{Shaked und Wool}}{{}}}
+\bibcite{SPALS}{{25}{2009}{{Welke und Rechert}}{{}}}
\bibstyle{dinat}
\citation{*}
diff --git a/ausarbeitung/maindoc.bbl b/ausarbeitung/maindoc.bbl
index e7ce7e6..477a5f4 100644
--- a/ausarbeitung/maindoc.bbl
+++ b/ausarbeitung/maindoc.bbl
@@ -1,4 +1,4 @@
-\begin{thebibliography}{21}
+\begin{thebibliography}{25}
% this bibliography was produced with the style dinat.bst v2.5
\makeatletter
\newcommand{\dinatlabel}[1]%
@@ -78,6 +78,11 @@
\newblock URL \url{http://standards.ieee.org/regauth/posix/}. --
\newblock [Online; letzter Aufruf 11.02.2010]
+\bibitem[qrcode()]{qrcode}
+\dinatlabel{qrcode } \emph{QR Code}. --
+\newblock URL \url{http://www.denso-wave.com/qrcode/qrstandard-e.html}. --
+\newblock [Online; letzter Aufruf 11.02.2010]
+
\bibitem[SymbianOS()]{SymbianOS}
\dinatlabel{SymbianOS } \emph{Symbian OS}. --
\newblock [Online; letzter Aufruf 03.02.2010]
@@ -103,6 +108,19 @@
\newblock URL \url{http://xchat.org/}. --
\newblock [Online; letzter Aufruf 11.02.2010]
+\bibitem[Beresford und Stajano(2003)]{privacy}
+\dinatlabel{Beresford und Stajano 2003} \textsc{Beresford}, Alastair~R.~;
+ \textsc{Stajano}, Frank:
+\newblock Location privacy in pervasive computing.
+\newblock In: \emph{IEEE Pervasive Computing Magazine}
+\newblock (2003), S.~46--55
+
+\bibitem[Kaasinen(2003)]{location}
+\dinatlabel{Kaasinen 2003} \textsc{Kaasinen}, Eija:
+\newblock User needs for location-aware mobile services.
+\newblock In: \emph{Personal and Ubiquitous Computing}
+\newblock Volume 7 (2003), Nr.~1, S.~70--79
+
\bibitem[Quercia und Capra(2009)]{FriendSensing}
\dinatlabel{Quercia und Capra 2009} \textsc{Quercia}, Daniele~; \textsc{Capra},
Licia:
@@ -112,9 +130,17 @@
\url{web.mit.edu/quercia/www/publications/friendSensing_short.pdf}. --
\newblock [Online; letzter Aufruf 27.01.2010]
-\bibitem[Rechert und Welke(2009)]{SPALS}
-\dinatlabel{Rechert und Welke 2009} \textsc{Rechert}, Klaus~; \textsc{Welke},
- Konstantin:
+\bibitem[Shaked und Wool(2005)]{bluetooth}
+\dinatlabel{Shaked und Wool 2005} \textsc{Shaked}, Yaniv~; \textsc{Wool},
+ Avishai:
+\newblock Cracking the Bluetooth PIN.
+\newblock In: \emph{Proceedings of the 3rd international conference on Mobile
+ systems, applications, and services}
+\newblock (2005), S.~39--50
+
+\bibitem[Welke und Rechert(2009)]{SPALS}
+\dinatlabel{Welke und Rechert 2009} \textsc{Welke}, Konstantin~;
+ \textsc{Rechert}, Klaus:
\newblock \emph{Spontaneous Privacy-Aware Location Sharing}.
\newblock 2009
diff --git a/ausarbeitung/maindoc.blg b/ausarbeitung/maindoc.blg
index 23d8e40..709ca1b 100644
--- a/ausarbeitung/maindoc.blg
+++ b/ausarbeitung/maindoc.blg
@@ -12,6 +12,7 @@ The style file: dinat.bst
Reallocated wiz_functions (elt_size=4) to 6000 items from 3000.
Database file #1: literature.bib
Warning--to sort, need author or key in Latitude
+Warning--to sort, need author or key in qrcode
Warning--to sort, need author or key in IRC
Warning--to sort, need author or key in POSIX
Warning--to sort, need author or key in CeGCC
@@ -30,45 +31,45 @@ 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 21 entries,
+You've used 25 entries,
3552 wiz_defined-function locations,
- 886 strings with 7666 characters,
-and the built_in function-call counts, 6925 in all, are:
-= -- 848
-> -- 20
-< -- 37
-+ -- 64
-- -- 12
-* -- 636
-:= -- 1067
-add.period$ -- 2
-call.type$ -- 21
-change.case$ -- 87
-chr.to.int$ -- 21
-cite$ -- 78
-duplicate$ -- 281
-empty$ -- 733
-format.name$ -- 26
-if$ -- 1585
+ 908 strings with 8194 characters,
+and the built_in function-call counts, 9371 in all, are:
+= -- 1147
+> -- 47
+< -- 82
++ -- 120
+- -- 28
+* -- 867
+:= -- 1447
+add.period$ -- 5
+call.type$ -- 25
+change.case$ -- 105
+chr.to.int$ -- 25
+cite$ -- 85
+duplicate$ -- 352
+empty$ -- 927
+format.name$ -- 58
+if$ -- 2096
int.to.chr$ -- 0
int.to.str$ -- 1
-missing$ -- 0
-newline$ -- 116
-num.names$ -- 8
-pop$ -- 165
+missing$ -- 12
+newline$ -- 139
+num.names$ -- 20
+pop$ -- 197
preamble$ -- 1
-purify$ -- 67
+purify$ -- 84
quote$ -- 0
-skip$ -- 189
+skip$ -- 278
stack$ -- 0
-substring$ -- 346
-swap$ -- 29
-text.length$ -- 4
+substring$ -- 583
+swap$ -- 42
+text.length$ -- 9
text.prefix$ -- 0
top$ -- 0
-type$ -- 231
-warning$ -- 19
-while$ -- 52
+type$ -- 275
+warning$ -- 20
+while$ -- 77
width$ -- 0
-write$ -- 179
-(There were 19 warnings)
+write$ -- 217
+(There were 20 warnings)
diff --git a/ausarbeitung/maindoc.log b/ausarbeitung/maindoc.log
index d4b5569..d8a3ab7 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) 15 FEB 2010 12:54
+This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) (format=pdflatex 2009.12.22) 18 FEB 2010 18:50
entering extended mode
%&-line parsing enabled.
**maindoc
@@ -534,17 +534,14 @@ LaTeX Info: Redefining \pageref on input line 105.
<Bilder/siegel.png, id=131, 568.2831pt x 568.2831pt>
File: Bilder/siegel.png Graphic file (type png)
<use Bilder/siegel.png>
-(/usr/share/texmf-texlive/tex/latex/ucs/data/uni-0.def
-File: uni-0.def 2004/10/17 UCS: Unicode data U+0000..U+00FF
-) [1
+[1
-{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map} <./Bilder/siegel.png>]) (./
-maindoc.toc
+{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map} <./Bilder/siegel.png>])
+(./maindoc.toc
LaTeX Font Info: Try loading font information for OT1+ztmcm on input line 4.
-
-(/usr/share/texmf-texlive/tex/latex/psnfss/ot1ztmcm.fd
+ (/usr/share/texmf-texlive/tex/latex/psnfss/ot1ztmcm.fd
File: ot1ztmcm.fd 2000/01/03 Fontinst v1.801 font definitions for OT1/ztmcm.
)
LaTeX Font Info: Try loading font information for OML+ztmcm on input line 4.
@@ -585,8 +582,11 @@ LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <7> not available
]
\openout2 = `Erklaerung.aux'.
- (./Erklaerung.tex)pdfTeX warning (ext4): destination with the same identifier
-(name{page.1}) has been already used, duplicate ignored
+ (./Erklaerung.tex
+(/usr/share/texmf-texlive/tex/latex/ucs/data/uni-0.def
+File: uni-0.def 2004/10/17 UCS: Unicode data U+0000..U+00FF
+))pdfTeX warning (ext4): destination with the same identifier (name{page.1}) ha
+s been already used, duplicate ignored
<to be read again>
\relax
l.116 \include{Erklaerung}
@@ -607,7 +607,7 @@ Underfull \hbox (badness 10000) in paragraph at lines 10--15
[]
-Underfull \hbox (badness 10000) in paragraph at lines 16--21
+Underfull \hbox (badness 10000) in paragraph at lines 16--25
[]
@@ -618,17 +618,30 @@ Underfull \hbox (badness 10000) in paragraph at lines 16--21
\openout2 = `Grundlagen.aux'.
(./Grundlagen.tex
-Underfull \hbox (badness 10000) in paragraph at lines 8--23
+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.
+ []
+
+Overfull \hbox (3.66167pt too wide) in paragraph at lines 10--29
+\OT1/ptm/m/n/12 Hi-erf[]ur wurde ein Di-enst f[]ur mo-bile Ger[]ate im-ple-men-
+tiert welch-er Dat-en ver-schl[]usselt an mehrere
[]
-Underfull \hbox (badness 10000) in paragraph at lines 24--30
+Underfull \hbox (badness 10000) in paragraph at lines 10--29
[]
-Underfull \hbox (badness 10000) in paragraph at lines 31--38
+Overfull \hbox (8.07138pt too wide) in paragraph at lines 30--36
+\OT1/ptm/m/n/12 en zuzu-greifen. Dies k[]onnte durch die Nutzung eines dezen-tr
+alen, verteil-ten Sys-tems eingeschr[]ankt
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 30--36
[]
@@ -636,94 +649,137 @@ Underfull \hbox (badness 10000) in paragraph at lines 31--38
]
-Underfull \hbox (badness 10000) in paragraph at lines 41--49
+Underfull \hbox (badness 10000) in paragraph at lines 39--82
[]
-Overfull \hbox (21.31631pt too wide) in paragraph at lines 50--54
-[]\OT1/ptm/m/n/12 Da auch ein zen-traler Knoten, []uber den der gesamte Daten-v
-erkehr aller Be-nutzer l[]auft, unerw[]unscht
+Underfull \hbox (badness 10000) in paragraph at lines 85--87
+
[]
-Underfull \hbox (badness 10000) in paragraph at lines 50--54
+Underfull \hbox (badness 10000) in paragraph at lines 88--94
[]
-Underfull \hbox (badness 10000) in paragraph at lines 55--58
-
+Overfull \hbox (21.31631pt too wide) in paragraph at lines 95--99
+[]\OT1/ptm/m/n/12 Da auch ein zen-traler Knoten, []uber den der gesamte Daten-v
+erkehr aller Be-nutzer l[]auft, unerw[]unscht
[]
-Underfull \hbox (badness 10000) in paragraph at lines 61--93
+Underfull \hbox (badness 10000) in paragraph at lines 95--99
[]
[4]
-Underfull \hbox (badness 10000) in paragraph at lines 94--99
+Underfull \hbox (badness 10000) in paragraph at lines 100--103
[]
-[5]
-Underfull \hbox (badness 10000) in paragraph at lines 102--106
+
+Underfull \hbox (badness 10000) in paragraph at lines 106--112
[]
-Underfull \hbox (badness 10000) in paragraph at lines 107--112
+Underfull \hbox (badness 10000) in paragraph at lines 113--118
[]
-Overfull \hbox (5.2344pt too wide) in paragraph at lines 113--116
+Overfull \hbox (5.2344pt too wide) in paragraph at lines 119--122
[]\OT1/ptm/m/n/12 Um die Kom-mu-nika-tion zwis-chen ver-schiede-nen Teil-nehmer
n zu erm[]oglichen sollte es m[]oglich
[]
-Underfull \hbox (badness 10000) in paragraph at lines 113--116
+Underfull \hbox (badness 10000) in paragraph at lines 119--122
+
+ []
+
+Overfull \hbox (1.4715pt too wide) in paragraph at lines 123--126
+\OT1/ptm/m/n/12 erzugeben. Es ist allerd-ings da-rauf zu acht-en, dass dieser S
+chl[]ussel nicht w[]ahrend der []ubertragung
[]
-Underfull \hbox (badness 10000) in paragraph at lines 117--121
+Underfull \hbox (badness 10000) in paragraph at lines 123--126
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 127--131
+
+ []
+
+[5]
+Underfull \hbox (badness 10000) in paragraph at lines 132--137
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 140--146
+
+ []
+
+
+Overfull \hbox (20.69508pt too wide) in paragraph at lines 147--152
+\OT1/ptm/m/n/12 hergestellt wer-den, wer-den die Schl[]ussel per Bar-code verte
+ilt. Es find-et somit keine Dat-en[]ubertragung
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 147--152
+
+ []
+
+Overfull \hbox (20.70735pt too wide) in paragraph at lines 153--169
+\OT1/ptm/m/n/12 gesendet und dort aus-gegeben. Beim Versenden der Po-si-tio-nen
+ muss zwis-chen Sender und Empf[]anger
[]
-[6]
-Underfull \hbox (badness 10000) in paragraph at lines 133--145
+
+Underfull \hbox (badness 10000) in paragraph at lines 153--169
[]
-) [7]
+[6]) [7]
\openout2 = `Tutorial.aux'.
(./Tutorial.tex
-Overfull \hbox (0.23062pt too wide) in paragraph at lines 3--16
-\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 3--6
+
[]
-Underfull \hbox (badness 10000) in paragraph at lines 3--16
+Underfull \hbox (badness 10000) in paragraph at lines 7--11
[]
-Underfull \hbox (badness 10000) in paragraph at lines 17--21
+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
[]
-Overfull \hbox (16.10585pt too wide) in paragraph at lines 24--26
+Overfull \hbox (16.10585pt too wide) in paragraph at lines 29--31
\OT1/ptm/m/n/12 den f[]unf Be-trieb-ssys-teme f[]ur mo-bile Plat-tfor-men vorge
stellt und auf deren Portierungsm[]oglichkeiten
[]
-Underfull \hbox (badness 10000) in paragraph at lines 29--34
+Underfull \hbox (badness 10000) in paragraph at lines 34--39
[]
@@ -731,80 +787,75 @@ Underfull \hbox (badness 10000) in paragraph at lines 29--34
]
-Underfull \hbox (badness 10000) in paragraph at lines 48--51
+Underfull \hbox (badness 10000) in paragraph at lines 53--56
[]
-Underfull \hbox (badness 10000) in paragraph at lines 52--59
+Underfull \hbox (badness 10000) in paragraph at lines 57--64
[]
-Underfull \hbox (badness 10000) in paragraph at lines 62--68
+Underfull \hbox (badness 10000) in paragraph at lines 67--73
[]
-Underfull \hbox (badness 10000) in paragraph at lines 71--77
+Underfull \hbox (badness 10000) in paragraph at lines 76--82
[]
[9]
-Overfull \hbox (0.91805pt too wide) in paragraph at lines 87--95
+Overfull \hbox (0.91805pt too wide) in paragraph at lines 92--100
\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 103--108
+Underfull \hbox (badness 10000) in paragraph at lines 108--113
[]
-
-Underfull \hbox (badness 10000) in paragraph at lines 109--114
+[10]
+Underfull \hbox (badness 10000) in paragraph at lines 114--119
[]
-[10]
-Overfull \hbox (3.26653pt too wide) in paragraph at lines 120--126
+
+Overfull \hbox (3.26653pt too wide) in paragraph at lines 125--131
\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=241, 133.35536pt x 185.83714pt>
+<Bilder/elm-app-01_2.png, id=250, 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=242, 206.48572pt x 405.22821pt>
+<Bilder/elm-app-02_2.png, id=251, 206.48572pt x 405.22821pt>
File: Bilder/elm-app-02_2.png Graphic file (type png)
-<use Bilder/elm-app-02_2.png> <Bilder/efl.png, id=243, 48.18pt x 72.27pt>
+<use Bilder/elm-app-02_2.png> [11 <./Bilder/elm-app-01_2.png> <./Bilder/elm-app
+-02_2.png>] <Bilder/efl.png, id=261, 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'.
-
-
-Overfull \hbox (7.29773pt too wide) in paragraph at lines 143--149
+ <use Bilder/efl.png>
+Overfull \hbox (7.29773pt too wide) in paragraph at lines 148--154
[]\OT1/ptm/m/n/12 Bei \OT1/ptm/m/it/12 Ecore \OT1/ptm/m/n/12 han-delt es sich u
m eine \OT1/ptm/m/it/12 li-brary \OT1/ptm/m/n/12 welche das se-ri-al-isieren vo
n mehreren Pro-grammteilen
[]
-Underfull \hbox (badness 10000) in paragraph at lines 143--149
+Underfull \hbox (badness 10000) in paragraph at lines 148--154
[]
-[11 <./Bilder/elm-app-01_2.png> <./Bilder/elm-app-02_2.png>]) [12 <./Bilder/efl
-.png>]
+) [12 <./Bilder/efl.png>]
\openout2 = `Friend_Finder.aux'.
(./Friend_Finder.tex
-<Bilder/ablauf.png, id=259, 546.54187pt x 597.73312pt>
+<Bilder/ablauf.png, id=268, 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 31--40
@@ -813,90 +864,89 @@ t-en-ment \OT1/ptm/m/n/12 ver-wen-det. Diese Bib-lio-thek stellt alle ben[]otig
ten
[]
-[13
-
- <./Bilder/ablauf.png>]
-Underfull \hbox (badness 10000) in paragraph at lines 43--46
+Underfull \hbox (badness 10000) in paragraph at lines 43--47
[]
+[13
+
-Underfull \hbox (badness 10000) in paragraph at lines 47--62
+]
+Underfull \hbox (badness 10000) in paragraph at lines 48--63
[]
-<Bilder/chat.png, id=268, 338.76563pt x 450.18187pt>
+[14 <./Bilder/ablauf.png>]
+<Bilder/chat.png, id=282, 338.76563pt x 450.18187pt>
File: Bilder/chat.png Graphic file (type png)
<use Bilder/chat.png>
-
-LaTeX Warning: `h' float specifier changed to `ht'.
-
-[14]
-Underfull \hbox (badness 10000) in paragraph at lines 79--88
+[15 <./Bilder/chat.png>]
+Underfull \hbox (badness 10000) in paragraph at lines 80--89
[]
-Overfull \hbox (17.9312pt too wide) in paragraph at lines 89--91
+Overfull \hbox (17.9312pt too wide) in paragraph at lines 90--92
[]\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
[]
-[15 <./Bilder/chat.png>]
-Underfull \hbox (badness 10000) in paragraph at lines 94--103
+
+Underfull \hbox (badness 10000) in paragraph at lines 95--104
[]
-<Bilder/barcode.png, id=286, 337.26pt x 450.9347pt>
+[16] <Bilder/barcode.png, id=299, 337.26pt x 450.9347pt>
File: Bilder/barcode.png Graphic file (type png)
- <use Bilder/barcode.png>
-
-LaTeX Warning: `h' float specifier changed to `ht'.
-
-Underfull \hbox (badness 10000) in paragraph at lines 127--133
+<use Bilder/barcode.png>
+Underfull \hbox (badness 10000) in paragraph at lines 128--134
[]
-[16]
-Underfull \hbox (badness 10000) in paragraph at lines 134--139
+[17 <./Bilder/barcode.png>]
+Underfull \hbox (badness 10000) in paragraph at lines 135--140
[]
-Underfull \hbox (badness 10000) in paragraph at lines 147--162
+Underfull \hbox (badness 10000) in paragraph at lines 148--163
[]
-[17 <./Bilder/barcode.png>]
-Underfull \hbox (badness 10000) in paragraph at lines 163--169
- []
+Underfull \hbox (badness 10000) in paragraph at lines 164--170
+ []
-Overfull \hbox (4.52718pt too wide) in paragraph at lines 172--183
+[18]
+Overfull \hbox (4.52718pt too wide) in paragraph at lines 173--184
\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 186--198
+Overfull \hbox (15.74675pt too wide) in paragraph at lines 187--199
\OT1/ptm/m/n/12 Wie schon erw[]ahnt, wer-den die Po-si-tions-dat-en beim Sender
aufgeteilt und mit vi-er un-ter-schiedlichen
[]
-[18]) [19]
+[19] <Bilder/verbindungen.png, id=326, 408.77719pt x 360.59718pt>
+File: Bilder/verbindungen.png Graphic file (type png)
+
+<use Bilder/verbindungen.png>) [20] [21 <./Bilder/verbindungen.png>]
\openout2 = `Fazit.aux'.
- (./Fazit.tex)
+
+(./Fazit.tex)
Overfull \hbox (1.00261pt too wide) in paragraph at lines 3--121
\OT1/ptm/m/n/12 nungszeit der Ver-schl[]usselung kann bei richtiger Im-ple-men-
tierung ger-ing gehal-ten wer-den. Somit
[]
-[20
+[22
]
@@ -913,7 +963,7 @@ Overfull \hbox (2.40399pt too wide) in paragraph at lines 56--56
2.3-dev/include[]
[]
-[21
+[23
]
@@ -922,7 +972,7 @@ Overfull \hbox (14.754pt too wide) in paragraph at lines 56--56
ngw32ce/include/"[]
[]
-[22] [23] [24]
+[24] [25] [26]
Overfull \hbox (13.83946pt too wide) in paragraph at lines 198--201
\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``
@@ -946,13 +996,13 @@ Overfull \hbox (169.12907pt too wide) in paragraph at lines 234--234
d.h $WINCE_PATH/freetype-2.3.7-dev/include[]
[]
-[25]
+[27]
Overfull \hbox (33.279pt too wide) in paragraph at lines 269--269
[] \OT1/cmtt/m/n/12 #define PROCESS_ALL_ACCESS (STANDARD_RIGHTS_REQUIRE
D|SYNCHRONIZE|0xfff)[]
[]
-[26]
+[28]
Overfull \hbox (119.72905pt too wide) in paragraph at lines 314--314
[] \OT1/cmtt/m/n/12 ./autogen.sh --prefix=$WINCE_PATH --host=arm-mingw32ce --wi
th-edje-cc=$WINCE_PATH/bin/edje_cc[]
@@ -964,7 +1014,7 @@ Overfull \hbox (40.46509pt too wide) in paragraph at lines 316--319
/'' alle Vorkomm-nisse von ``test[]fileselector.c''
[]
-[27]
+[29]
LaTeX Font Info: Try loading font information for OMS+ptm on input line 355.
(/usr/share/texmf-texlive/tex/latex/psnfss/omsptm.fd
@@ -1008,7 +1058,7 @@ Overfull \hbox (19.92868pt too wide) in paragraph at lines 371--373
ported % 20packages / freetype-[]2 .
[]
-[28]
+[30]
Overfull \hbox (7.57867pt too wide) in paragraph at lines 373--375
[][]$\OT1/cmtt/m/n/12 http : / / sourceforge . net / projects / cegcc / files /
ported % 20packages / libpng-[]1 .
@@ -1020,7 +1070,7 @@ Overfull \hbox (7.57867pt too wide) in paragraph at lines 375--377
ported % 20packages / libpng-[]1 .
[]
-[29] [30]
+[31] [32]
Overfull \hbox (14.754pt too wide) in paragraph at lines 501--501
[]\OT1/cmtt/m/n/12 arm-mingw32ce-strip efl/evas/modules/loaders/eet/mingw32ce-a
rm/loader_eet.dll[]
@@ -1062,19 +1112,19 @@ Overfull \hbox (2.40399pt too wide) in paragraph at lines 501--501
m/saver_png.dll[]
[]
-[31]) [32] (./maindoc.bbl [33
+[33]) [34] (./maindoc.bbl [35
-]) [34] (./maindoc.aux (./Title.aux)
+]) [36] (./maindoc.aux (./Title.aux)
(./Erklaerung.aux) (./Einleitung.aux) (./Grundlagen.aux) (./Tutorial.aux)
(./Friend_Finder.aux) (./Fazit.aux) (./Anhang.aux)) )
Here is how much of TeX's memory you used:
- 8724 strings out of 95086
- 119659 string characters out of 1183254
- 200611 words of memory out of 1500000
- 11538 multiletter control sequences out of 10000+50000
+ 8740 strings out of 95086
+ 119896 string characters out of 1183254
+ 200715 words of memory out of 1500000
+ 11546 multiletter control sequences out of 10000+50000
24736 words of font info for 62 fonts, out of 1200000 for 2000
28 hyphenation exceptions out of 8191
- 35i,12n,46p,303b,591s stack positions out of 5000i,500n,6000p,200000b,5000s
+ 35i,11n,46p,303b,538s stack positions out of 5000i,500n,6000p,200000b,5000s
{/usr/share/texmf-texlive/
fonts/enc/dvips/base/8r.enc}</usr/share/texmf-texlive/fonts/type1/bluesky/cm/cm
mi10.pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmr10.pfb></usr/share
@@ -1082,9 +1132,9 @@ mi10.pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmr10.pfb></usr/share
nts/type1/bluesky/cm/cmsy10.pfb></usr/share/texmf-texlive/fonts/type1/bluesky/c
m/cmtt12.pfb></usr/share/texmf-texlive/fonts/type1/urw/times/utmr8a.pfb></usr/s
hare/texmf-texlive/fonts/type1/urw/times/utmri8a.pfb>
-Output written on maindoc.pdf (36 pages, 1447389 bytes).
+Output written on maindoc.pdf (38 pages, 1467630 bytes).
PDF statistics:
- 487 PDF objects out of 1000 (max. 8388607)
- 110 named destinations out of 1000 (max. 131072)
- 300 words of extra memory for PDF output out of 10000 (max. 10000000)
+ 513 PDF objects out of 1000 (max. 8388607)
+ 117 named destinations out of 1000 (max. 131072)
+ 305 words of extra memory for PDF output out of 10000 (max. 10000000)
diff --git a/ausarbeitung/maindoc.out b/ausarbeitung/maindoc.out
index 770b6fd..0c7bb60 100644
--- a/ausarbeitung/maindoc.out
+++ b/ausarbeitung/maindoc.out
@@ -1,8 +1,8 @@
\BOOKMARK [1][-]{section.1}{Einleitung}{}
\BOOKMARK [1][-]{section.2}{Grundlagen}{}
\BOOKMARK [2][-]{subsection.2.1}{Aktueller Stand}{section.2}
-\BOOKMARK [2][-]{subsection.2.2}{Ziele}{section.2}
-\BOOKMARK [2][-]{subsection.2.3}{Anwendungsm\366glichkeiten}{section.2}
+\BOOKMARK [2][-]{subsection.2.2}{Anwendungsm\366glichkeiten}{section.2}
+\BOOKMARK [2][-]{subsection.2.3}{Ziele}{section.2}
\BOOKMARK [2][-]{subsection.2.4}{Anforderungen}{section.2}
\BOOKMARK [2][-]{subsection.2.5}{Verfahren}{section.2}
\BOOKMARK [1][-]{section.3}{Technische Grundlagen}{}
diff --git a/ausarbeitung/maindoc.pdf b/ausarbeitung/maindoc.pdf
index 9ee2548..0bab1b0 100644
--- a/ausarbeitung/maindoc.pdf
+++ b/ausarbeitung/maindoc.pdf
Binary files differ
diff --git a/ausarbeitung/maindoc.tex b/ausarbeitung/maindoc.tex
index 59d9cdb..cb18bca 100644
--- a/ausarbeitung/maindoc.tex
+++ b/ausarbeitung/maindoc.tex
@@ -84,7 +84,7 @@
%l�scht vordefinierte Einstellungen
\fancyhf{}
-\fancyhead[L]{Mobiler, persönlicher Assistent}
+\fancyhead[L]{Mobiler Friend Finder}
\fancyhead[R]{Patrick Hornecker}
\fancyfoot[C]{\thepage}
diff --git a/ausarbeitung/maindoc.tex~ b/ausarbeitung/maindoc.tex~
index a25f999..cb18bca 100644
--- a/ausarbeitung/maindoc.tex~
+++ b/ausarbeitung/maindoc.tex~
@@ -84,7 +84,7 @@
%l�scht vordefinierte Einstellungen
\fancyhf{}
-\fancyhead[L]{Mobiler, persönlicher Assistent}
+\fancyhead[L]{Mobiler Friend Finder}
\fancyhead[R]{Patrick Hornecker}
\fancyfoot[C]{\thepage}
@@ -118,6 +118,7 @@
\include{Grundlagen}
\include{Tutorial}
\include{Friend_Finder}
+\include{Fazit}
\include{Anhang}
%\bibliographystyle{dinat}
%\bibliography{literature}
diff --git a/ausarbeitung/maindoc.toc b/ausarbeitung/maindoc.toc
index 21715af..e3addd2 100644
--- a/ausarbeitung/maindoc.toc
+++ b/ausarbeitung/maindoc.toc
@@ -2,31 +2,31 @@
\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}Ziele}{4}{subsection.2.2}
-\contentsline {subsection}{\numberline {2.3}Anwendungsm\IeC {\"o}glichkeiten}{4}{subsection.2.3}
-\contentsline {subsection}{\numberline {2.4}Anforderungen}{6}{subsection.2.4}
+\contentsline {subsection}{\numberline {2.2}Anwendungsm\IeC {\"o}glichkeiten}{4}{subsection.2.2}
+\contentsline {subsection}{\numberline {2.3}Ziele}{4}{subsection.2.3}
+\contentsline {subsection}{\numberline {2.4}Anforderungen}{5}{subsection.2.4}
\contentsline {subsection}{\numberline {2.5}Verfahren}{6}{subsection.2.5}
\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}{8}{subsubsection.3.1.1}
+\contentsline {subsubsection}{\numberline {3.1.1}Windows Mobile}{9}{subsubsection.3.1.1}
\contentsline {subsubsection}{\numberline {3.1.2}Android}{9}{subsubsection.3.1.2}
\contentsline {subsubsection}{\numberline {3.1.3}WebOS}{9}{subsubsection.3.1.3}
-\contentsline {subsubsection}{\numberline {3.1.4}iPhone OS}{9}{subsubsection.3.1.4}
+\contentsline {subsubsection}{\numberline {3.1.4}iPhone OS}{10}{subsubsection.3.1.4}
\contentsline {subsubsection}{\numberline {3.1.5}Symbian OS}{10}{subsubsection.3.1.5}
\contentsline {subsubsection}{\numberline {3.1.6}Zielplattform}{10}{subsubsection.3.1.6}
\contentsline {subsection}{\numberline {3.2}Softwaregrundlagen}{10}{subsection.3.2}
-\contentsline {subsubsection}{\numberline {3.2.1}CeGCC}{10}{subsubsection.3.2.1}
+\contentsline {subsubsection}{\numberline {3.2.1}CeGCC}{11}{subsubsection.3.2.1}
\contentsline {subsubsection}{\numberline {3.2.2}Enlightenment}{11}{subsubsection.3.2.2}
\contentsline {section}{\numberline {4}Friend Finder}{13}{section.4}
\contentsline {subsection}{\numberline {4.1}Verwendete Verfahren und Bibliotheken}{13}{subsection.4.1}
-\contentsline {subsubsection}{\numberline {4.1.1}Grafisches Benutzeroberfl\IeC {\"a}che}{14}{subsubsection.4.1.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}{14}{subsubsection.4.1.2}
-\contentsline {subsubsection}{\numberline {4.1.3}Versenden der eigenen Position}{15}{subsubsection.4.1.3}
+\contentsline {subsubsection}{\numberline {4.1.3}Versenden der eigenen Position}{16}{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}{16}{subsection.4.2}
-\contentsline {subsubsection}{\numberline {4.2.1}Allgemeiner Datenverkehr}{17}{subsubsection.4.2.1}
-\contentsline {subsubsection}{\numberline {4.2.2}Versenden und Empfangen von Nachrichten}{18}{subsubsection.4.2.2}
+\contentsline {subsubsection}{\numberline {4.1.5}Erzeugen eines 2D-Barcodes}{17}{subsubsection.4.1.5}
+\contentsline {subsection}{\numberline {4.2}Analyse}{17}{subsection.4.2}
+\contentsline {subsubsection}{\numberline {4.2.1}Allgemeiner Datenverkehr}{18}{subsubsection.4.2.1}
+\contentsline {subsubsection}{\numberline {4.2.2}Versenden und Empfangen von Nachrichten}{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}{19}{subsubsection.4.2.4}
-\contentsline {section}{\numberline {5}Fazit}{20}{section.5}
+\contentsline {subsubsection}{\numberline {4.2.4}Fazit der Auswertung}{20}{subsubsection.4.2.4}
+\contentsline {section}{\numberline {5}Fazit}{22}{section.5}
diff --git a/friendfinder/draw_user.c b/friendfinder/draw_user.c
index 9b517aa..5e877c1 100644
--- a/friendfinder/draw_user.c
+++ b/friendfinder/draw_user.c
@@ -58,6 +58,7 @@ void draw_user(struct position *pos)
if (active_map == 1 && test_distance(sender_lat, sender_lon, e, n, own_lat, own_lon, own_e, own_n) == 1)
{
+ printf("PRINTING nick: %s lat: %f lon: %f \n", pos->nick, sender_lat, sender_lon, pos->lon);
e_smart_map_overlay_set_bubble(map, "routing", pos->nick, pos->nick, sender_lat, sender_lon, 0xffffffff);
}
}
diff --git a/friendfinder/gui b/friendfinder/gui
index 5b02679..cce80ee 100755
--- a/friendfinder/gui
+++ b/friendfinder/gui
Binary files differ
diff --git a/friendfinder/gui.c b/friendfinder/gui.c
index 499b0c1..c34739a 100644
--- a/friendfinder/gui.c
+++ b/friendfinder/gui.c
@@ -26,7 +26,9 @@ double current_lat = 47.996578;
double current_lon = 7.840171;
const char *msg_text, *key, *ip = NULL, *nickname = NULL, *partner_nickname = NULL;
-char *from = NULL, *to = NULL, *number = NULL, *current_msg, *last_msg;
+char *from = NULL, *to = NULL, *count = "3", *current_msg, *last_msg;
+int sender_count = 3;
+
static Evas_Object *win, *bbx, *map, *img, *bcb;
@@ -78,6 +80,17 @@ static void set_nickname(void *data, Evas_Object *obj, void *event_info)
}
}
+static void on_partner_number(void *data, Evas_Object *obj, void *event_info)
+{
+ sender_count = elm_entry_entry_get(obj);
+ elm_entry_context_menu_clear(obj);
+}
+
+static void set_partner_number(void *data, Evas_Object *obj, void *event_info)
+{
+ set_sender_count(sender_count);
+}
+
static void on_show_users(void *data, Evas_Object *obj, void *event_info)
{
if (nickname != NULL && strlen(nickname) > 0)
@@ -680,13 +693,10 @@ void init_options()
evas_object_size_hint_weight_set(en4, 1.0, 1.0);
evas_object_size_hint_align_set(en4, 0.0, 0.0);
elm_scroller_content_set(sc4, en4);
- evas_object_smart_callback_add(en4, "changed", NULL, NULL);
+ evas_object_smart_callback_add(en4, "changed", on_partner_number, NULL);
evas_object_show(en4);
- if (number != NULL)
- {
- elm_entry_entry_set(en4, to);
- }
+ elm_entry_entry_set(en4, count);
lb4 = elm_label_add(win);
elm_label_label_set(lb4, "Visible sender");
@@ -700,7 +710,7 @@ void init_options()
evas_object_size_hint_weight_set(bt7, 1.0, 1.0);
evas_object_size_hint_align_set(bt7, -1.0, -1.0);
elm_box_pack_end(bx5, bt7);
- evas_object_smart_callback_add(bt7, "clicked", NULL, NULL);
+ evas_object_smart_callback_add(bt7, "clicked", set_partner_number, NULL);
evas_object_show(bt7);
}
diff --git a/friendfinder/receiver.c b/friendfinder/receiver.c
index 28018b0..1295983 100644
--- a/friendfinder/receiver.c
+++ b/friendfinder/receiver.c
@@ -12,13 +12,13 @@
static irc_session_t *session;
irc_callbacks_t callbacks;
-int _exit = 0;
-
char sender_name[100];
char own_nickname[100];
char *receiver_server_ip;
int username_length;
+int _sender_count = 3;
+int _exit = 0;
struct sender **s_sender;
int s_sender_size;
@@ -35,6 +35,11 @@ void set_receiver_exit()
_exit = 1;
}
+void set_sender_count(int number)
+{
+ _sender_count = number;
+}
+
int init_connection_receiver(char* server_ip, char* user)
{
printf("RECEIVER: initialising connection...\n");
@@ -105,7 +110,7 @@ int get_sender_array_pos(char* nick)
{
for (int i = 0; i < s_sender_size; i++)
{
- if (s_sender[i]->is_init == 1 && strcmp(s_sender[i]->nick, nick) == 0)
+ if (s_sender[i]->is_init == 1 && strlen(s_sender[i]->nick) == 0)//strcmp(s_sender[i]->nick, nick) == 0)
{
return i;
}
@@ -113,7 +118,7 @@ int get_sender_array_pos(char* nick)
if (s_sender[i]->is_init == 0 && strcmp(s_sender[i]->nick, nick) != 0)
{
s_sender[i]->is_init = 1;
- s_sender[i]->nick = nick;
+ memcpy(s_sender[i]->nick, nick, strlen(nick));
return i;
}
@@ -124,41 +129,37 @@ void repair_position(struct sender *_sender, unsigned char *decrypted)
{
if (decrypted[5] == 'a')
{
- memcpy(_sender->lat_first, decrypted, sizeof(decrypted));
+ memcpy(_sender->lat_first, decrypted, strlen(decrypted));
_sender->lat_first[5] = '\0';
_sender->lat_first_set = 1;
- // return;
}
else if (decrypted[4] == 'b')
{
- memcpy(_sender->lat_second, decrypted, sizeof(decrypted));
+ memcpy(_sender->lat_second, decrypted, strlen(decrypted));
_sender->lat_second[4] = '\0';
_sender->lat_second_set = 1;
- // return;
}
else if (decrypted[5] == 'c')
{
- memcpy(_sender->lon_first, decrypted, sizeof(decrypted));
+ memcpy(_sender->lon_first, decrypted, strlen(decrypted));
_sender->lon_first[5] = '\0';
_sender->lon_first_set = 1;
- // return;
}
else if (decrypted[3] == 'd')
{
- memcpy(_sender->lon_second, decrypted, sizeof(decrypted));
+ memcpy(_sender->lon_second, decrypted, strlen(decrypted));
_sender->lon_second[3] = '\0';
_sender->lon_second_set = 1;
- // return;
}
if (_sender->lat_first_set == 1 && _sender->lat_second_set == 1)
{
- memcpy(_sender->lat, _sender->lat_first, sizeof(_sender->lat_first)); //FIXME IM A ANGRY SEGFAULT
+ memcpy(_sender->lat, _sender->lat_first, strlen(_sender->lat_first));
- strcat(_sender->lat, _sender->lat_second);//FIXME TOO
+ strcat(_sender->lat, _sender->lat_second);
_sender->lat_set = 1;
_sender->lat_first_set = 0;
@@ -166,29 +167,36 @@ void repair_position(struct sender *_sender, unsigned char *decrypted)
_sender->lat_first[0] = '\0';
_sender->lat_second[0] = '\0';
-
- // printf("lat: %s \n", _sender->lat);
-
- // _sender->lat[0] = '\0';
}
if (_sender->lon_first_set == 1 && _sender->lon_second_set == 1)
{
- memcpy(_sender->lon, _sender->lon_first, sizeof(_sender->lon_first));//FIXME ALSO PLEASE
-
- strcat(_sender->lon, _sender->lon_second);//FIXME IS THE WORD OF THE HOUR
-
+ memcpy(_sender->lon, _sender->lon_first, strlen(_sender->lon_first));
+ strcat(_sender->lon, _sender->lon_second);
_sender->lon_set = 1;
_sender->lon_first_set = 0;
_sender->lon_second_set = 0;
_sender->lon_first[0] = '\0';
_sender->lon_second[0] = '\0';
-
- // printf("lon: %s \n", _sender->lon);
-
- // _sender->lat[0] = '\0';
}
+
+ printf("lon_set: %i \n", _sender->lon_set);
+ printf("lon: %s \n", _sender->lon);
+ printf("lat_set: %i \n", _sender->lat_set);
+ printf("lat: %s \n", _sender->lat);
+ printf("nick: %s \n", _sender->nick);
+ printf("<<<<<<<<<<<>>>>>>>>>>> \n");
+ printf("first_lon_set: %i \n", _sender->lon_first_set);
+ printf("first_lon: %s \n", _sender->lon_first);
+ printf("second_lon_set: %i \n", _sender->lon_second_set);
+ printf("second_lon: %s \n", _sender->lon_second);
+ printf("<<<<<<<<<<<>>>>>>>>>>> \n");
+ printf("first_lat_set: %i \n", _sender->lat_first_set);
+ printf("first_lat: %s \n", _sender->lat_first);
+ printf("second_lat_set: %i \n", _sender->lat_second_set);
+ printf("second_lat: %s \n", _sender->lat_second);
+ printf("====================== \n");
}
@@ -204,12 +212,12 @@ void dump_data(char* lat, char* lon, char* nick)
void get_position(irc_session_t * session, const char * event, const char * origin, const unsigned char ** params, unsigned int count)
{
+ if (_exit == 1)
+ disconnect_receiver(session, event, origin, params, count);
+
unsigned char *decrypted;
char *sender_org = (char*) malloc(username_length + 1);
-
-// if (_exit == 1)
-// disconnect_receiver();
irc_target_get_nick(origin, sender_name, sizeof(sender_name));
strncpy(sender_org, sender_name, username_length);
@@ -222,13 +230,11 @@ void get_position(irc_session_t * session, const char * event, const char * orig
if (s_sender[pos]->lat_set == 0)
{
- decrypted = (char*) malloc(sizeof(char) * 5);
+ decrypted = (char*) malloc(sizeof(char) * 7);
BF_ecb_encrypt(params[1], decrypted, &key, BF_DECRYPT);
decrypted[strlen(decrypted)] = '\0';
- // printf("decrypted %s \n", decrypted);
-
repair_position(s_sender[pos], decrypted);
free(decrypted);
@@ -236,26 +242,27 @@ void get_position(irc_session_t * session, const char * event, const char * orig
else if (s_sender[pos]->lon_set == 0)
{
- decrypted = (char*) malloc(sizeof(char) * 5);
+ decrypted = (char*) malloc(sizeof(char) * 7);
+
BF_ecb_encrypt(params[1], decrypted, &key, BF_DECRYPT);
decrypted[strlen(decrypted)] = '\0';
- // printf("decrypted %s \n", decrypted);
-
repair_position(s_sender[pos], decrypted);
free(decrypted);
}
- if(s_sender[pos]->lon_set == 1 && s_sender[pos]->lat_set == 1)// && lon != NULL && lat != NULL)
+ if(s_sender[pos]->lon_set == 1 && s_sender[pos]->lat_set == 1)
{
double _lat, _lon;
_lat = atof(s_sender[pos]->lat);
_lon = atof(s_sender[pos]->lon);
- printf("%f %f \n", _lat, _lon);
-
- printf("char lat: %s char lon: %s \n", s_sender[pos]->lat, s_sender[pos]->lon);
+ printf(" DUMPING DATA \n");
+ printf("position in struct is %i \n", pos);
+ printf("lat: %s lon: %s \n", s_sender[pos]->lat, s_sender[pos]->lon);
+ printf("nick: %s \n", s_sender[pos]->nick);
+ printf("=========================================\n");
if (_lat > _lon && _lat == _lat && _lon == _lon)
{
@@ -269,47 +276,65 @@ void get_position(irc_session_t * session, const char * event, const char * orig
s_sender[pos]->lon_set = 0;
s_sender[pos]->lat_set = 0;
- // s_sender[pos]->lat = '\0';
- // s_sender[pos]->lon = '\0';
- }
+
+ s_sender[pos]->lat[0] = '\0';
+ s_sender[pos]->lon[0] = '\0';
+ }
+
free(sender_org);
+ pos = NULL;
+
irc_cmd_msg(session, "#test", "ack");
}
}
void init_sender_struct(int number)
{
- s_sender = (struct sender(*)[number]) malloc(sizeof(struct sender*) * number);
+// s_sender = (struct sender(*)[number]) malloc(sizeof(struct sender*) * number);
+ s_sender = (struct sender(*)[number]) malloc(sizeof(struct sender) * number);
+
s_sender_size = number;
- for (int i = 0; i < number; i++)
+ for (int i = 0; i <= number; i++)
{
s_sender[i] = (struct sender*) malloc(sizeof(struct sender));
s_sender[i]->nick = (char*) malloc(sizeof(char) * 20);
- s_sender[i]->lat = (char*) malloc(sizeof(char) * 9);
- s_sender[i]->lon = (char*) malloc(sizeof(char) * 9);
+ s_sender[i]->nick[0] = '\0';
+
+ s_sender[i]->lat = (char*) malloc(sizeof(char) * 10);
+ s_sender[i]->lat[0] = '\0';
+
+ s_sender[i]->lon = (char*) malloc(sizeof(char) * 10);
+ s_sender[i]->lon[0] = '\0';
- s_sender[i]->is_init = (int) malloc(sizeof(int));
+ // s_sender[i]->is_init = (int) malloc(sizeof(int));
s_sender[i]->is_init = 0;
- //s_sender[i]->lat_set = (int) malloc(sizeof(int));
+ // s_sender[i]->lat_set = (int) malloc(sizeof(int));
s_sender[i]->lat_set = 0;
- //s_sender[i]->lon_set = (int) malloc(sizeof(int));
+ // s_sender[i]->lon_set = (int) malloc(sizeof(int));
s_sender[i]->lon_set = 0;
+ s_sender[i]->lat_first = (char*) malloc(sizeof(char) * 9);
+ s_sender[i]->lat_first[0] = '\0';
- s_sender[i]->lat_first = (char*) malloc(sizeof(char) * 6);
- s_sender[i]->lat_second = (char*) malloc(sizeof(char) * 6);
+ s_sender[i]->lat_second = (char*) malloc(sizeof(char) * 9);
+ s_sender[i]->lat_second[0] = '\0';
- s_sender[i]->lon_first = (char*) malloc(sizeof(char) * 6);
- s_sender[i]->lon_second = (char*) malloc(sizeof(char) * 6);
+ s_sender[i]->lon_first = (char*) malloc(sizeof(char) * 9);
+ s_sender[i]->lon_first[0] = '\0';
-// s_sender[i]->lat[0] = '\0';
-// s_sender[i]->lon[0] = '\0';
+ s_sender[i]->lon_second = (char*) malloc(sizeof(char) * 9);
+ s_sender[i]->lon_second[0] = '\0';
+ s_sender[i]->lon_first_set = 0;
+ s_sender[i]->lon_second_set = 0;
+
+ s_sender[i]->lat_first_set = 0;
+ s_sender[i]->lat_second_set = 0;
}
}
@@ -322,8 +347,8 @@ void on_connect_receiver(irc_session_t * session, const char * event, const char
keyd = read_key();
BF_set_key(&key, keyd->key_length, keyd->key);
-
- init_sender_struct(3);
+
+ init_sender_struct(_sender_count);
irc_cmd_join(session, "#test", NULL);
irc_cmd_msg(session, "#test", "connected");
diff --git a/friendfinder/receiver.h b/friendfinder/receiver.h
index 95b5238..b0c978f 100644
--- a/friendfinder/receiver.h
+++ b/friendfinder/receiver.h
@@ -36,4 +36,8 @@ void receiver_main(void *user);
void receiver_set_ip(char *_ip);
void set_receiver_exit();
+
+void set_sender_count(int number);
+
+
#endif
diff --git a/friendfinder/sender.c b/friendfinder/sender.c
index b9557e8..1d157cb 100644
--- a/friendfinder/sender.c
+++ b/friendfinder/sender.c
@@ -84,11 +84,11 @@ struct sender_data* prepare_position(const unsigned char* lat, const unsigned ch
{
struct sender_data *pos = (struct sender_data*) malloc(sizeof(struct sender_data));
- pos->lat_first = (char*) malloc(sizeof(char) * 5);
- pos->lat_second = (char*) malloc(sizeof(char) * 5);
+ pos->lat_first = (char*) malloc(sizeof(char) * 8);
+ pos->lat_second = (char*) malloc(sizeof(char) * 8);
- pos->lon_first = (char*) malloc(sizeof(char) * 5);
- pos->lon_second = (char*) malloc(sizeof(char) * 5);
+ pos->lon_first = (char*) malloc(sizeof(char) * 8);
+ pos->lon_second = (char*) malloc(sizeof(char) * 8);
for (int i = 0; i < 9; i++)
{
@@ -131,11 +131,18 @@ struct sender_data* prepare_position(const unsigned char* lat, const unsigned ch
void send_position(irc_session_t * session, const char * event, const char * origin, const char ** params, unsigned int count)
{
- unsigned char *crypted_lat_first = (char*) malloc(sizeof(char) * 8);
- unsigned char *crypted_lat_second = (char*) malloc(sizeof(char) * 8);
+ unsigned char *crypted_lat_first = (char*) malloc(sizeof(char) * 9);
+ crypted_lat_first[0] = '\0';
+
+ unsigned char *crypted_lat_second = (char*) malloc(sizeof(char) * 9);
+ crypted_lat_second[0] = '\0';
+
+ unsigned char *crypted_lon_first = (char*) malloc(sizeof(char) * 9);
+ crypted_lon_first[0] = '\0';
+
+ unsigned char *crypted_lon_second = (char*) malloc(sizeof(char) * 9);
+ crypted_lon_second[0] = '\0';
- unsigned char *crypted_lon_first = (char*) malloc(sizeof(char) * 8);
- unsigned char *crypted_lon_second = (char*) malloc(sizeof(char) * 8);
if (first_send == 0)
{
@@ -157,10 +164,10 @@ void send_position(irc_session_t * session, const char * event, const char * ori
if (exit_ == 1)
disconnect_sender();
- const unsigned char *lat_char = (char*) malloc(sizeof(char) * 9);
+ const unsigned char *lat_char = (char*) malloc(sizeof(char) * 10);
sprintf(lat_char, "%f", own_lat);
- const unsigned char *lon_char = (char*) malloc(sizeof(char) * 9);
+ const unsigned char *lon_char = (char*) malloc(sizeof(char) * 10);
sprintf(lon_char, "%f", own_lon);
struct sender_data *pos = (struct sender_data*) malloc(sizeof(struct sender_data));
@@ -223,7 +230,7 @@ void get_aknowledge(irc_session_t * session, const char * event, const char * or
{
resend = 1;
- sleep(5);
+ //sleep(3);
send_position(session, event, origin, params, count);
}