summaryrefslogtreecommitdiffstats
path: root/ausarbeitung/Friend_Finder.tex~
diff options
context:
space:
mode:
authorPatrick Hornecker2010-02-18 19:11:15 +0100
committerPatrick Hornecker2010-02-18 19:11:15 +0100
commit88bb54e30a038269e33fd3b14f3bf321f0cb96c8 (patch)
tree7bf54973611ac14d974f9a07a6cff87093dae706 /ausarbeitung/Friend_Finder.tex~
parenttex source (diff)
downloadfriendfinder-88bb54e30a038269e33fd3b14f3bf321f0cb96c8.tar.gz
friendfinder-88bb54e30a038269e33fd3b14f3bf321f0cb96c8.tar.xz
friendfinder-88bb54e30a038269e33fd3b14f3bf321f0cb96c8.zip
tex source
Diffstat (limited to 'ausarbeitung/Friend_Finder.tex~')
-rw-r--r--ausarbeitung/Friend_Finder.tex~36
1 files changed, 23 insertions, 13 deletions
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