summaryrefslogtreecommitdiffstats
path: root/ausarbeitung/Friend_Finder.tex
diff options
context:
space:
mode:
Diffstat (limited to 'ausarbeitung/Friend_Finder.tex')
-rw-r--r--ausarbeitung/Friend_Finder.tex118
1 files changed, 61 insertions, 57 deletions
diff --git a/ausarbeitung/Friend_Finder.tex b/ausarbeitung/Friend_Finder.tex
index 4c69769..5423194 100644
--- a/ausarbeitung/Friend_Finder.tex
+++ b/ausarbeitung/Friend_Finder.tex
@@ -11,7 +11,7 @@ aufgezeigt.
Der \textit{Friend Finder} wurde so konzipiert, dass die graphische Darstellung ohne großen Aufwand von den restlichen
Teilen der Software abgekoppelt und durch eine andere Art der Darstellung ersetzt werden kann.\newline
Neben dem \textit{Graphical User Interface (GUI)} besteht die Software aus drei unterschiedlichen Modulen. Der \textit{Message
-Sender} ist für das Versenden und Empfangen der Textnachrichten zuständig, \textit{Sender} sendet die eigene Position,
+Sender} ist für das Versenden und Empfangen der Textnachrichten zu\-stän\-dig, \textit{Sender} sendet die eigene Position,
\textit{Receiver} empfängt die Positionen der anderen Nutzer und sendet Acknowledgements an die teilnehmenden \textit{Sender}.
Alle drei Teile geben ihre empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{Enlightenment} ausgibt.
Abbildung \ref{ablauf} zeigt den Kommunikationsaustausch von \textit{Friend Finder}. In dieser Graphik sind die Module zweier
@@ -29,9 +29,9 @@ weiter.
\subsubsection{Graphische Benutzeroberfläche}
-Um die Modularität zu wahren wird der gesammte Programmcode der Benutzeroberfläche in einer Datei zusammengefast. In dieser Datei
-sind alle Funktionen enthalten um die Oberflächenelement zu platzieren. Um die gewünschte Funktionalität der einzelnen Elemente zu
-realisieren wurden auch die Aufrufe der benötigten Funktionen aus anderen Modulen in dieser Datei implementiert. \newline
+Um die Modularität zu wahren, wird der gesammte Programmcode der Benutzeroberfläche in einer Datei zusammengefast. In dieser Datei
+sind alle Funktionen enthalten um die Oberflächen\-ele\-men\-te zu platzieren. Um die gewünschte Funktionalität der einzelnen
+Elemente zu realisieren, wurden die Aufrufe der benötigten Funktionen aus anderen Modulen in dieser Datei implementiert. \newline
Zur Darstellung der Karte wurden Daten des offenen Kartenprojekts \textit{OpenStreetMap}\footnote{OpenStreetMap
http://www.openstreetmap.de/ [Online; letzter Aufruf 13.02.2010]} genutzt.
@@ -41,18 +41,21 @@ Der \textit{Message Sender} kümmert sich um das Versenden von Nachrichten. Um d
implementieren wurde \textit{libircclient}\footnote{libircclient http://libircclient.sourceforge.net/ [Online; letzter Aufruf
25.01.2010]} genutzt. Im ersten
Schritt baut dieser eine Verbindung zum \textit{IRC}-Server auf. Um eine Verbindung mit einem \textit{IRC-Server} zu etablieren,
-muss eine \textit{IRC-Session} initialisiert werden. Diese \textit{Session} beinhaltet Informationen wie zum Beispiel
+muss eine \textit{IRC-Session} initialisiert werden. Diese \textit{Session} beinhaltet Informationen, wie zum Beispiel
den \textit{Nickname} des Benutzers oder die \textit{IP-Adresse} des Servers. Nachdem diese \textit{Session} gestartet wurde,
-können nun Nachrichten versandt werden. Textnachrichten müssen vor dem Versenden in Blöcke aufgeteilt werden, da das genutze
-Verschlüsselungsverfahren \textit{Blowfish} \citep{blowfish} maximal 64 Bit lange Zeichenkette verschlüsselt. Das verwendete
+können Nachrichten versandt werden. Textnachrichten müssen vor dem Versenden in Blöcke aufgeteilt werden, da das genutzte
+Verschlüsselungsverfahren \textit{Blowfish} \citep{blowfish} maximal 64 Bit lange Zeichenketten verschlüsselt. Das verwendete
Verfahren stammt aus der \textit{OpenSSL}\footnote{OpenSSL http://www.openssl.org/ [Online; letzter Aufruf 25.01.2010]}
-Bibliothek. Diese Implementierung wurde aufgrund der schnellen Verschlüsselungsrate sowie einfachen
-Implementierungsmöglichkeiten gewählt. Da das \textit{IRC}-Protokoll nicht alle Zeichen darstellen kann oder bestimmte Zeichen als
+Bibliothek. Diese Implementierung wurde aufgrund der schnellen Verschlüs\-se\-lungs\-ra\-te sowie einfachen
+Implementierungsmöglichkeiten gewählt. Da das \textit{IRC}-Protokoll nicht alle Zei\-chen darstellen kann oder bestimmte Zeichen
+als
Präfixe vor einem Kommando genutzt werden, werden alle versendeten Daten des Programmes in die \textit{Base64}\citep{Base64}
Darstellung umgewandelt.\newline
-Wird nun von einer anderen Instanz des \textit{Message Senders} eine Nachricht empfangen, so setzt er die Teilstücke zusammen.
-Dies geschieht solange, bis ein vom Nachrichtentext getrennt gesendetes Terminierungszeichen empfangen wird. Wurde dieses Zeichen
-empfangen, so gilt die Textnachricht als wiederhergestellt und wird an die Benutzeroberfläche weitergereicht. \newline
+Wird nun von einer anderen Instanz des \textit{Message Senders} eine Nachricht empfangen, so \mbox{setzt} er die Teilstücke
+zusammen.
+Dies geschieht solange, bis ein vom Nachrichtentext getrennt ges\-en\-de\-tes Terminierungszeichen empfangen wird. Wurde dieses
+Zeichen
+empfangen, so gilt die Textnachricht als wiederhergestellt und wird an die Benutzeroberfläche weitergereicht.
In Abbildung \ref{chat} ist die graphische Darstellung eines Nachrichtenaustausches abgebildet.
\begin{figure}[!ht]
@@ -64,23 +67,23 @@ In Abbildung \ref{chat} ist die graphische Darstellung eines Nachrichtenaustausc
\subsubsection{Versenden der eigenen Position}
-Der \textit{Sender} ist zuständig für das Versenden der Positionsdaten. Auch hier muss vor dem Versenden von Daten eine
+Der \textit{Sender} ist zuständig für das Versenden der Positionsdaten. Auch hier muss vor dem Ver\-sen\-den von Daten eine
\textit{IRC-Session} initialisiert werden. Der Ablauf beim Senden der Positionen erfolgt in einer vorgegebenen Reihenfolge. Zuerst
wird der verschlüsselte Längengrad, danach der verschlüsselte Breitengrade gesendet.
Allerdings muss auch hier, wie beim Versenden der Textnachrichten, darauf geachtet werden, dass maximal eine Zeichenkette der
-Länge 64 Bit verschlüsselt wird. Somit ist es auch hier nötig Längen- und Breitengrad in zwei Teile aufzuteilen und getrennt
-zu versenden. An jedes Ende, dieser insgesamt vier Fragmente, wird ein zusätzlicher, jeweils unterschiedlicher Suffix angehängt.
+Länge 64 Bit verschlüsselt wird. Somit ist es auch hier nötig, Längen- und Breitengrad in zwei Teile aufzuteilen und getrennt
+zu versenden. An jedes Ende dieser insgesamt vier Fragmente wird ein zusätzlicher, jeweils unterschiedlicher Suffix angehängt.
Durch diese Suffixe, können die Positionsfragmente später eindeutig zugeordnet werden. Somit werden für das
Versenden von einer Position insgesamt vier Nachrichten an den \textit{IRC}-Server übermittelt.
Wurden diese vier Nachrichten übermittelt, so werden solange keine Daten mehr gesendet, bis der \textit{Empfänger} eine
Bestätigung für jedes Fragment an den \textit{IRC-Channel} sendet. Kommt diese Bestätigung beim \textit{Sender} an, so versendet
dieser wieder ein \textit{Latitude/Longtitude} Paar. Sollten diese \textit{Acknowledgements} ausbleiben, so wartet der Sender eine
-längere Zeit und versendet die Daten erneut. Somit werden Daten in längeren Abständen vesandt, wenn kein \textit{Empfänger} aktiv
+längere Zeit und versendet die Daten erneut. Somit werden Daten in längeren Abständen versandt, wenn kein \textit{Empfänger} aktiv
sein sollte. Tritt nun wieder ein \textit{Empfänger} dem \textit{Channel} bei und sendet \textit{Acknowledgements}, so erhöht der
-Sender daraufhin wieder die Senderate. Diese Vorgehensweise tritt auch in Kraft, falls eine Bestätigung, aufgrund von
-Übertragungsfehlern nur unvollständig ankommt. Sollte die Verbindung zum \textit{IRC}-Server
+Sender daraufhin wieder die Senderate. Diese Vorgehensweise tritt auch in Kraft, falls eine Bestätigung aufgrund von
+Übertragungsfeh\-lern nur unvollständig ankommt. Sollte die Verbindung zum \textit{IRC}-Server
unterbrochen werden, so versucht sich der \textit{Sender} in regelmäßigen Zeitabständen neu zu verbinden. Abbildung \ref{protocol}
-zeigt, das Versenden von Positionsdaten des \textit{Senders} über einen \textit{IRC-Channel} an den \textit{Empfänger}. Dieser
+zeigt das Versenden von Positionsdaten des \textit{Senders} über einen \textit{IRC-Channel} an den \textit{Empfänger}. Dieser
schickt im Anschluss auf gleichem Weg \textit{Acknowledgements} an den \textit{Sender}.
\begin{figure}[!ht]
@@ -93,14 +96,14 @@ schickt im Anschluss auf gleichem Weg \textit{Acknowledgements} an den \textit{S
\subsubsection{Empfangen von Positionen}
Auch beim \textit{Empfänger} muss im ersten Schritt eine \textit{IRC-Session} initialisiert werden. Da mehrere
-Benutzer Positionsdaten senden können legt der \textit{Empfänger} für jeden \textit{Sender} einen Datensatz an. Wird nun ein
-Fragment der Positionsdaten empfangen, so kann der \textit{Empfänger }dies anhanden des Buchstabensuffix zuordnen. Sind alle
-Fragmente einer Position empfangen worden, so werden die benötigten Daten zur Visuallisierung weitergereicht und ein
+Benutzer Positionsdaten senden können, legt der \textit{Empfänger} für jeden \textit{Sender} einen Datensatz an. Wird nun ein
+Fragment der Positionsdaten empfangen, so kann der \textit{Empfänger} dies anhanden des Buchstabensuffix zuordnen. Wurden alle
+Fragmente einer Position empfangen, so werden die benötigten Daten zur Visualisierung weitergereicht und ein
\textit{Acknowledgement} gesendet. Dieses \textit{Acknowledgement} beinhaltet, in verschlüsselter Form, den Namen des
\textit{Senders} der Nachricht. Somit kann der \textit{Sender} die für ihn bestimmten \textit{Acknowledgements} zuordnen. Sollte
der \textit{Sender} das Senden von Nachrichten einstellen, so wartet der \textit{Empfänger} bis ein neuer \textit{Sender}
verfügbar ist. Sollte der Fall eintreten, dass die Positionsfragmente nicht in der vorgesehenen Reihenfolge ankommen, so stellt
-dies für den \textit{Empfänger} kein Problem dar. Auffgrund des Suffixes, wird das Fragment gespeichert und zu einem Längen- oder
+dies für den \textit{Empfänger} kein Problem dar. Aufgrund des Suffixes, wird das Fragment gespeichert und zu einem Längen- oder
Breitengrad vervollständigt, sobald der fehlende Teil vorhanden ist. Sollte ein Fragment nicht ankommen, so werden alle alten,
bis dahin vorhandenen Fragmente verworfen. Dies geschieht, sobald der \textit{Empfänger} registriert, dass ein Positionsfragment
der gleichen Art schon vorhanden ist. Sollte ein Positionsfragment unvollständig ankommen, so wird es verworfen. Wird die
@@ -118,17 +121,17 @@ Darstellung einer Position eines anderen Benutzers.
Um einen 2D-Barcode zu erstellen wird eine Zeichenkette benötigt. Aus dieser werden durch die Nutzung von \textit{qrencode}
\footnote{libqrencode http://megaui.net/fukuchi/works/qrencode/index.en.html\newline[Online; letzter Aufruf 11.02.2010]}
-Bilddaten generiert. Diese werden im nächsten Schritt durch \textit{libpng}\footnote{libpng http://www.libpng.org/ [Online;
-letzter Aufruf 11.02.210]} gerendert und auf das Speichermedium geschrieben. Dieses Bild wird dann durch die \textit{GUI}
+Bilddaten generiert. Diese werden im nächsten Schritt durch \mbox{\textit{libpng}\footnote{libpng http://www.libpng.org/ [Online;
+letzter Aufruf 11.02.210]}} gerendert und auf das Speichermedium geschrieben. Dieses Bild wird dann durch die \textit{GUI}
geladen und ausgegeben. Die Abbildung \ref{barcode} zeigt einen solchen erstellten Barcode, wie er von \textit{Friend Finder}
ausgegeben wird. \newline
Möchten Benutzer Schlüssel austauschen, so kann ein Barcode aus einer Zeichenkette erstellt werden. Die
zugrunde liegende Zeichenkette kann zum Beispiel ein zuvor erstellter und auf dem Medium gespeicherter 1024 Bit Schlüssel, eine in
-\textit{Friend Finder} eingegebene Zeichenkette oder ein Schlüssel der mit der für eine Sitzung erstellt wurde,
+\textit{Friend Finder} eingegebene Zeichenkette oder ein Schlüssel speziell für eine Sitzung erstellt wurde,
sein. Aus dieser kann nun ein Barcode erstellt werden und andere Teilnehmer können diesen ihrerseits fotographieren, in die
-ursprüngliche Zeichenkette umwandeln und als Schlüssel nutzen. Der Vorteil der durch die Wahl dieser Methode ensteht, ist dass
+ursprüngliche Zeichenkette umwandeln und als Schlüssel nutzen. Der Vorteil, der durch die Wahl dieser Methode ensteht, ist dass
Schlüssel ausgetauscht werden können, wenn Nutzer sich durch Zufall treffen oder den Dienst spontan nutzen wollen, ohne dabei
-schon im Vorraus Schlüssel erstellen zu müssen.
+schon im Voraus Schlüssel erstellen zu müssen.
\begin{figure}[!ht]
\centering
@@ -146,7 +149,7 @@ Beim Versenden der Daten durch \textit{Friend Finder} soll möglichst wenig \tex
versendet werden. Unter \textit{Datenoverhead} versteht man Hintergrunddaten, welche versendet werden um die Verbindung
aufrecht zu erhalten oder um die Anzahl der verfügbaren Teilnehmer zu überprüfen. Diese Daten besitzen allerdings keinen
Informationsgehalt für den Anwender.\newline
-Im folgenden Teil wird der erzeugte Datenverkehr von \textit{Friend Finder} analysiert. Der Hauptaugenmerk wird hierbei
+Im folgenden Teil wird der erzeugte Datenverkehr von \textit{Friend Finder} analysiert. Das Hauptaugenmerk wird hierbei
auf die Paketgröße, sowie die Menge der versendeten Datenpakete geworfen. Ein interessanter Punkt stellt die Frage dar, wie sich
das versendete Datenaufkommen im Vergleich zu einer Lösung verhält, welche die Daten an jeden Teilnehmer einzeln verschickt.
Hier ist besonders von Interesse, ob der \textit{Datenoverhead} den Vorteil eines \textit{Broadcast}-Mediums wie ein
@@ -157,19 +160,19 @@ Der \textit{Traffic} wurde mit Hilfe des Programmes \textit{Wireshark}\footnote
http://www.ircd-hybrid.org/ [Online; letzter Aufruf 27.01.2010]} genutzt, welche auf dem gleichen Computer wie der
Client lief. Der Client hat sich in diesem Szenario über das \textit{localhost} Interface mit dem Server verbunden. \newline
Die Analyse ist in drei Teile aufgeteilt. Als erstes wird auf den allgemein entstehenden Datenverkehr eingegangen, welcher
-bei Verbindungsaufbau, sowie bei Beenden der Verbindung entsteht. Der zweite Teil beschäftigt sich mit dem Versenden und
+bei Verbindungsaufbau, sowie bei Beenden der Verbindung ent\-steht. Der zweite Teil beschäftigt sich mit dem Versenden und
Empfangen von Nachrichten. Im letzten Teil dieser Analyse wird der Datenverkehr beim Versenden und Empfangen von Positionen
genauer betrachtet. Alle folgenden Größen beziehen sich nur auf die Größe des Datenfeldes, exklusive der Header.
\subsubsection{Allgemeiner Datenverkehr}
-Der Allgemeine Hintergrundverkehr bei \textit{Friend Finder} besteht zum Einen aus \textit{Keep-Alive} Nachrichten, sowie der
-Anfrage des Clients nach aktiven Nutzern in den \textit{Channels} in denen er selbst aktiv ist. Die \textit{Keep-Alive}
+Der allgemeine Hintergrundverkehr bei \textit{Friend Finder} besteht zum Einen aus \textit{Keep-Alive} Nach\-richt\-en sowie der
+Anfrage des Clients nach aktiven Nutzern in den \textit{Channels}, in denen er selbst aktiv ist. Die \textit{Keep-Alive}
Nachrichten werden alle 30 Sekunden zwischen Server und Client ausgetauscht. Die Größe einer solchen Nachricht von Client zu
Server beträgt 24 Byte. Das Antwortpaket, welches vom Server an den Client gesendet wird, hat eine Größe von 44
Byte. \newline
Anfragen nach den anderen Benutzern innerhalb eines \textit{Channel} werden alle 60 Sekunden versandt. Die Größe der Pakete welche
-von Client zu Server versandt werden, betragen hierbei 10 Bytes. Die Größe der Antwort des Servers hängt von der Anzahl der
+von Client zu Server versandt werden, betragen hierbei zehn Bytes. Die Größe der Antwort des Servers hängt von der Anzahl der
aktiven Benutzer innerhalb eines Channels ab. Für zwei Benutzer ergibt sich ein Datenvolumen von 193 Byte, wobei diese
Größe auch abhängig von der Länge der Benutzernamen sowie des Namens des \textit{Channels} und Servers ist.
@@ -180,8 +183,8 @@ Finder} genutzte \textit{Blockcipher} teilt den Satz "`Hello World"' in zwei Tei
resultierende Paket hat eine Größe von 99 Byte.\newline
Die versendete Textnachricht plus Terminierungszeichen hat im unverschlüsselten Format die Größe von 24 Byte. Nach der
Verschlüsselung werden beim Senden
-noch Informationen bezüglich \textit{Channel} und der Empfänger der Nachricht in das zu versendende \textit{IRC}-Paket
-geschrieben. Nach der verschlüsselung, \textit{Base64}-Kodierung sowie hinzufügen von Zusatzinformationen hat die Größe der
+noch Informationen bezüg\-lich \textit{Channel} und der Empfänger der Nachricht in das zu versendende \textit{IRC}-Paket
+geschrieben. Nach der Verschlüsselung, \textit{Base64}-Kodierung, sowie hinzufügen von Zusatzinformationen hat die Grö\-ße der
Nachricht circa um den Faktor vier zugenommen.\newline
Wenn $h$ die Größe des \textit{TCP-Headers} und $t$ die Anzahl der Zeichen einer unverschlüsselten Nachricht repräsentiert, so
ergibt sich die ungefähre Größe der zu versendenden Nachricht aus: $h + (t \cdot 4)$.
@@ -194,44 +197,45 @@ Größe des Datenfeldes im Mittel 140 Byte. Die Gesamtgröße der unverschlüsse
\textit{Latitude}/\textit{Longtitude}-Paar zu versenden beträgt 32 Byte. Durch die Verschlüsselung,
\textit{Base64}-Kodierung sowie Zusatzinformationen vergrößert sich das Datenvolumen also um circa den Faktor vier. Wenn $h$ die
Größe des \textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht darstellt, ergibt sich die Größe der
-versendeten Nachricht circa durch $h + (t \cdot 4)$. Hinzu kommt, dass für jedes empfangene Positions-Fragment ein
-\textit{Acknowledgement} gesendet wird. Die Größe eines \textit{Acknowledgment}-Paketes beträgt zwischen 110 und 120 Byte. In
-einem solchen Paket werden vier \textit{Acknowledgments} zusammengefasst.\newline
-Daraus kann Folgende Formel für den Datenverkehr pro versendeter Position, bei $n$ Teilnehmern hergeleitet werden:
+versendeten Nachricht circa durch $h + (t \cdot 4)$. Hinzu kommt, dass für jedes em\-pfang\-ene Positions-Fragment ein
+\textit{Acknowledgement} gesendet wird. Die Größe eines \textit{Acknowledgement}-Paketes beträgt zwischen 110 und 120 Byte. In
+einem solchen Paket werden vier \textit{Acknowledgements} zusammengefasst.\newline
+Daraus kann folgende Formel für den Datenverkehr pro versendeter Position bei $n$ Teilnehmern hergeleitet werden:
$((h + (t \cdot 4)) + (4 \cdot a))\cdot n$, wobei $a$ die Größe eines \textit{Acknowledgements} ist und $n$ die Anzahl der
versandten Pakete repräsentiert.
\subsubsection{Fazit der Auswertung}
-Die Hintergrunddaten welche vom \textit{IRC}-Protokoll versandt werden ergeben einen geringen, in Kauf zu nehmenden
+Die Hintergrunddaten welche vom \textit{IRC}-Protokoll versandt werden, ergeben einen geringen, in Kauf zu nehmenden
\textit{Datenoverhead}. Der große Vorteil von \textit{IRC} ist, dass die \textit{Channels} als \textit{Broadcast}-Medium genutzt
werden können. Diese Tatsache macht es möglich, Daten $n$ Teilnehmer zugänglich zu machen und dabei diese nur einmal, über eine
-aktive Verbindung, zu senden. Berücksichtigt man dies, so fällt, der ohnehin geringe \textit{Datenoverhead}, nicht mehr ins
+aktive Verbindung, zu senden. Berücksichtigt man dies, so fällt der ohnehin geringe \textit{Datenoverhead} nicht mehr ins
Gewicht. Würde man diese Daten über $n$ getrennte Verbindungen an die Teilnehmer versenden, so müssten ebensoviele Verbindungen
geöffnet werden und die Daten anstelle von einmal, $n$ Mal versandt werden.\newline
In der folgenden Abbildung \ref{graph} wird das Versenden der Daten über $n$ getrennte Verbindungen, sowie die in \textit{Friend
-Finder} implementierte Methode, zu einem beliebigen Zeitpunkt $t$ verglichen. Es wird angenommen das die versandten Positionsdaten
-eine Größe von 140 Byte und vier \textit{Acknowledgements} von 120 Byte haben. Des Weiteren wird angenommen dass alle Nutzer die
-Daten empfangen auch Positionsdaten senden und somit auch $4 \cdot n$ \textit{Acknowledgements} versandt werden müssen. Daraus
-ergibt sich die Formel $(n \cdot 140) + (n \cdot 120)$, welche als Grundlage für die Abbildung \ref{graph} dient.\newline
+Finder} implementierte Methode, zu einem beliebigen Zeitpunkt $t$ verglichen. Es wird angenommen, dass die versandten
+Positionsdaten eine Größe von 140 Byte und vier \textit{Acknowledgements} von 120 Byte haben. Des Weiteren wird angenommen, dass
+alle Nutzer die Daten empfangen auch Positionsdaten senden und somit auch $4 \cdot n$ \textit{Acknowledgements} versandt werden
+müssen. Daraus ergibt sich die Formel $(n \cdot 140) + (n \cdot 120)$, welche als Grundlage für die Abbildung \ref{graph}
+dient.\newline
In Abbildung \ref{graph2} ist der Hintergrund Traffic von \textit{Friend Finder}, zu einem beliebigen Zeitpunkt $t$, abgetragen.
-Die Größe wird anhand der aktiven Teilnehmer ausgegeben. Es wird angenommen, das eine Nachricht, mit Benutzerinformationen eines
+Die Größe wird anhand der aktiven Teilnehmer ausgegeben. Es wird angenommen, dass eine Nachricht mit Benutzerinformationen eines
\textit{Channels}, für $n$ Benutzer die Größe von $70 + (60 \cdot n)$ hat. Die Größe von 70 Byte stellt hierbei den Server plus
-den \textit{Channel}-Namen dar. Zudem wird angenommen das in diesem Fall die Information zu jedem Benutzer eine Größe von 60 Byte
-hat. Eine \textit{Keep-Alive} Nachricht hat die Größe von 136 Byte, da diese Nachrichten in dem Zeitraum in dem einmal die
+den \textit{Channel}-Namen dar. Zudem wird angenommen, dass in diesem Fall die Information zu jedem Benutzer eine Größe von 60
+Byte hat. Eine \textit{Keep-Alive} Nachricht hat die Größe von 136 Byte, da diese Nachrichten in dem Zeitraum in dem einmal die
Benutzerinformationen ausgetauscht werden, zweimal versandt werden. Dieses Datenvolumen setzt sich aus der Nachricht von Client zu
-Server, sowie der Antwortnachricht des Servers an den Client, zusammen. Die Gesamtgröße der \textit{Keep-Alive} Nachrichten für
-$n$ Teilnehmer wird durch $136 \cdot n$ errechnet. Die eingezeichnete Summe repräsentiert die Formel $(136 \cdot n) + (70 +(60
-\cdot n)$, also die Summe aus \textit{Keep-Alive} Nachrichten sowie versendeten Benutzerinformationen.\newline
+Server, sowie der Antwortnachricht des Servers an den Client zusammen. Die Gesamtgröße der \textit{Keep-Alive} Nachrichten für
+$n$ Teilnehmer wird durch $136 \cdot n$ errechnet. Die eingezeichnete Summe re\-prä\-sen\-tiert die Formel $(136 \cdot n) + (70
++(60 \cdot n)$, also die Summe aus \textit{Keep-Alive} Nachrichten sowie versendeten Benutzerinformationen.\newline
Es fällt also auf, dass beim \textit{IRC}-Protokoll trotz Hintergrunddaten, bei steigender Teilnehmerzahl weniger Datenvolumen
-benötigt wird. Würde eine Lösung mit $n$ Verbindungen gewählt werden, so muss noch bedacht werden dass auf die versendeten Daten
- Hintergrunddaten, multipliziert mit der Anzahl der Teilnehmer, addiert werden müssten. Im gegensatz hierzu müssen diese
-Werte beim nur \textit{IRC}-Protokoll nur einmalig addiert werden.
+benötigt wird. Würde eine Lösung mit $n$ Verbindungen gewählt werden, so muss noch bedacht werden, dass auf die versendeten Daten
+ Hintergrunddaten, multipliziert mit der Anzahl der Teilnehmer, addiert werden müssten. Im Gegensatz hierzu müssen diese
+Werte beim \textit{IRC}-Protokoll nur einmalig addiert werden.
\begin{figure}[!ht]
\centering
\includegraphics[width=12cm]{Bilder/graph}
- \caption{Vergleich des versandten Datenvolumen anhand von unterschiedlichen Teilnehmerzahlen, von $n$-Verbindungen und
+ \caption{Vergleich des versandten Datenvolumen, anhand von unterschiedlichen Teilnehmerzahlen, von $n$-Verbindungen und
\textit{Friend Finder} zu einem beliebigen Zeitpunkt $t$.}
\label{graph}
\end{figure}
@@ -239,7 +243,7 @@ Werte beim nur \textit{IRC}-Protokoll nur einmalig addiert werden.
\begin{figure}[!ht]
\centering
\includegraphics[width=12cm]{Bilder/graph2}
- \caption{Versandte Hintergrunddaten von \textit{Friend Finder} anhand von unterschiedlichen Teilnehmerzahlen, zu einem beliebigen
-Zeitpunkt $t$.}
+ \caption{Versandte Hintergrunddaten von \textit{Friend Finder}, anhand von unterschiedlichen Teilnehmerzahlen, zu einem
+beliebigen Zeitpunkt $t$.}
\label{graph2}
\end{figure} \ No newline at end of file