QoS Ausarbeitung Has..

Netzwerktechnologien Quality of Services
Mobile Messaging und QoS
Dustin Haß
[email protected]
707747
Swen Kummer
[email protected]
716720
Institut für Informatik
1
Inhaltsverzeichnis
1. Einleitung .......................................................................................................................................... 3
2. Jimm ................................................................................................................................................. 3
2.1 Das Oscar Protokolls.................................................................................................................... 3
2.2 Quellcode Änderungen ................................................................................................................ 5
2.3 JAVA SIP....................................................................................................................................... 6
2.4 Messdaten ................................................................................................................................... 7
2.5 QoS-Parameter ............................................................................................................................ 8
3. Mopiphant......................................................................................................................................... 9
3.1 Netzwerkstrukturen: Client-Server, Peer-to-Peer, Mobile-Peer-to-Peer ..................................... 10
3.2 Mopiphant – Aufbau................................................................................................................... 10
3.2.1 Architektur.......................................................................................................................... 10
3.2.2 Cache-Peer ......................................................................................................................... 11
3.3 QoS-Parameter .......................................................................................................................... 12
5. Quellcode ........................................................................................................................................ 14
5.1 Contactlist.java I ........................................................................................................................ 14
5.2 Contactlist.java II ....................................................................................................................... 14
5.3 Contactlist.java III ...................................................................................................................... 14
5.4 Traffic.java I............................................................................................................................... 14
5.5 Traffic.java II.............................................................................................................................. 14
5.6 Traffic.java III............................................................................................................................. 15
5.7 Traffic.java IV............................................................................................................................. 15
5.8 Traffic.java V ............................................................................................................................. 16
5.9 Traffic.java VI............................................................................................................................. 16
6. Glossar............................................................................................................................................ 17
2
1. Einleitung
Durch die wachsende Anzahl an javafähigen Mobiltelefonen hat die Menge der Java-Applikationen stark
zugenommen. Eine dieser Applikationen ist der ICQ-Clone Jimm, ehemals bekannt als MobICQ. Derzeit
hat ICQ 200 Millionen registrierte Nutzer, so dass mit Jimm eine hohe Personenzahl erreicht werden
kann. Auf Grund der hohen SMS- und Telefonkosten sind viele Menschen ständig auf der Suche nach
günstigen Alternativen. Durch Jimm bietet sich die Möglichkeit unterwegs kostengünstig Nachrichten zu
versenden, da lediglich Gebühren für die GPRS Nutzung entstehen.
Unsere Motivation war die Frage, wie sehr wir mit Jimm das GSM-/GPRS-Netz belasten und unter welchen Umständen welche Menge an Datenverkehr verschickt wird. Da Jimm der GPL unterliegt, wäre es
möglich den Quelltext zu analysieren und zu modifizieren.
Die Verlegung typischer PC-Anwendungen wie Instant Messaging (IM) auf ein Mobiltelefon ließ uns nach
weiteren portierten Anwendung Ausschau halten. Dabei fiel uns der Mopiphant auf, welcher ein Peer-to-
Peer Client für Smartphones ist. Das Hauptaugenmerk soll jedoch auf Jimm liegen, daher wird der Mopiphant weniger intensiv von uns behandelt.
2. Jimm
Jimm unterliegt der GPL und ist somit kostenlos. Die Vorraussetzungen sind weiterhin ein J2ME – fähiges
Mobiltelefon mit Raw Socket Support. Da Jimm in Java geschrieben ist und benötigt er J2ME und durch
die Verbindung über mehrere Kanäle parallel, muss Raw Socket Support vorhanden sein. Dieser funktionieren ähnlich wie Ports am PC und man kann auf den entsprechenden Sockets Nachrichten empfangen
und daher passend zuordnen.
2.1 Das Oscar Protokolls
ICQ Clienten kommunizieren mit verschiedenen Oscar Protokollversionen, wobei Oscar 8 in Jimm imp-
lementiert ist. Das Oscar Protokoll ist eine AOL Entwicklung und propertiär. Daher sind nur begrenzt
Informationen verfügbar, jedoch sind diese für die ICQ Nutzung ausreichend. Die Protokolle sind bis zur
Version 10 entwickelt und untereinander kompatibel, denn die Versionsnummer gibt lediglich den Funktionsumfang des Clienten wieder. Während in der Version 8 nur Dateitransfer und Chat möglich ist, so
kann man in den neueren Versionen bereits Push-to-Talk, Videoconferencing und Flashgames nutzen.
Aktuell wird Oscar 8 bis 10 eingesetzt, doch weitere Entwicklungen sind nicht absehbar durch die Ge-
heimhaltung von seitens AOL. Viele ICQ Clones kämpfen mit dem propertiären Oscar Protokoll, wie seit
Anfang Februar 2006 sichtbar bei Miranda. Die DLL mit dem Oscarprotokoll war unvollständig, so dass
durch eine Änderung bei ICQ keine Nachrichten mehr die Miranda-Nutzer erreichten. Ein Log Auszug:
[10:13:41 ICQ] Message (format 2) through server - UIN: 293327524, FirstTLV: 19
[10:13:41 ICQ] Unsupported TLV (19) in message (format 2)
Als UIN wurde in diesem Log 293327524 gezeigt, da sie eine von uns genutzte UIN ist und als Fehlermeldung beim jeweiligen Nutzer steht. Das erste TLV war bisher TLV(11), doch selbst diese Funktionali-
tät ist nicht hinreichend bekannt. Ein Bugfix behob den Fehler, wobei das bisher implementierte Protokoll nur erweitert werden musste. Das Message Format 2 ist wie folgt bekannt:
3
Bildquelle: http://www.micq.org/ICQ-OSCAR-Protocol-v7-v8-v9/Packets/Fam4/Com0/Sub2.html
Das Protokoll besteht aus den drei Grundformaten FLAP, SNAC und TLV, wobei eine Nachricht im SNAC
Format im FLAP enthalten sein kann. Das TLV kann wie das SNAC im FLAP enthalten sein, oder im data
Teil des SNAC eingefügt werden. Die folgende Grafik veranschaulicht die Verbindung der Formate untereinander und deren Bestandteile:
Zu erkennen ist, dass FLAP die Basis der verschickten
Nachrichten an den ICQ Server ist. Die Nachrichten
werden über fünf Channel geschickt, welche mit Hilfe
von Sockets implementiert wurden. Sämtliche Nach-
richten im SNAC Format werden auf dem Channel 2
übertragen. Auf den restlichen Channel’s wird FLAP
oder FLAP mit TLV gesendet. Das Oscar-Protokoll
wird jedoch nicht nur von ICQ, sondern auch von AIM
genutzt, denn beide gehören zu AOL. Durch kleine
Unterschiede sind sie nicht immer 100%ig kompatibel.
4
Die Details der Inhalte für Service ID, Family und Subfamily sind auf der Seite von A. V. Shutko nachzule-
sen. Auf eine nähere Beschreibung jeder einzelnen Funktion wurde verzichtet, da dieses Detailwissen für
das Projekt nicht unbedingt nötig ist.
2.2 Quellcode Änderungen
Der Client Jimm ist komplett in Java geschrieben und nutzt die Klassen von J2ME. Da der vollständige
Quellcode verfügbar ist, konnte so die Funktionsweise nachvollzogen werden. Das Ziel war es, die Höhe
des Datenverkehrs festzuhalten. Daher waren Änderungen in der Traffic.java und Contactlist.java notwendig. Die Modifikationen wurden mit einem „// QoS Mod“ Kommentar versehen, sowie wichtige Vari-
ablen mit den Anfangsbuchstaben qos_ gekennzeichnet. Daher sind die Codemodifikationen leicht zu
finden.
Die oberste Zeile der Buddy-Liste wurde ersetzt durch eine Anzeige des Sessiontraffic in Byte sowie der Größe des letzten Paketes. Eine ursprüngliche
Planung der Anzeige in kB/s wurde auf Grund zu geringer Datenübertragung
verworfen. Die Daten über GPRS sind nur einzelne Pakete und ergeben einen
nicht immer im Sekundentakt messbaren Datenfluss. In der Contactlist.java
wurde unter I der Kontruktor angepasst, im Teil II wurde die Rückgabe des
Sessiontraffic von kb in byte geändert und im III. Teil die Bildschirmausgabe
angepasst. Der Befehl „ResourceBundle.getString“ wandelt den Text in einen
String um, so dass er im Ausgabestring abgelegt werden konnte. AusgegeBildquelle: jimm.org
ben wird immer ein String, in dem z.B. die Variablenwerte abgelegt werden.
Für die Änderung der Anzeige des Traffic wurde die Bezeichnung in der
Sprachdatei auf QoS-Traffic geändert. Der Ausgabestring wurde dahingehend
geändert, dass die Bytes der Session, das Anfangsdatum sowie die Gesamtbytezahl ausgegeben werden. Weiterhin wird vom Paket 48 bis 57 die Größe
und der Zeitpunkt, seit dem Jimm Start, in Millisekunden ausgegeben. Da im
Durchschnitt 39 Pakete für einen Verbindungsaufbau bzw. 47 Pakete beim
erstmaligen Verbindungsaufbau, inklusive des Ladens der Buddyliste vom
Server verschickt werden, haben wir uns für eine Protokollierung ab dem 48.
Paket entschieden. Ursprünglich wollten wir die Ergebnisse in einem Array der
Form Daten[Paketgröße,Zeitpunkt] festhalten, doch der Prozessor des S65 war
damit überfordert und wir bekamen Verbindungsabbrüche. Als Möglichkeit
sahen wir daher die Speicherung in den Variablen z1 bis z10. Da wir beim
Bildquelle: jimm.org
Start von Jimm den Zeitpunkt in qos_starttimer auf Grund der großen Zahl
vom Typ Long festlegen mussten, brauchten wir durch die Speicherung der
Differenz von qos_starttimer zum aktuellen Zeitpunkt nur noch Integer Werte.
Sparsame Ressourcenverwaltung ist wegen der Speicherlimitierung sehr bedeutsam. Während des Versendens der Pakete ließen wir einen Zähler (qos_i)
mitlaufen, so konnten wir feststellen, wann das 48. bis 57. Pakete verschickt
wurde.
Mit einer IF-Abfrage wird dies überprüft und gegebenenfalls die Differenz des
aktuellen
Zeitpunktes
und
des
Jimm
Starts
ermittelt.
Da
mit
Sys-
tem.currentTimeMillis() eine Rückgabe vom Typ long erfolgt ist, war ein Cast
des Ergebnisses auf Integer erforderlich.
Bildquelle: Screenshot
5
Zu Beginn der Messungen haben wir 100 Pakete gespeichert, um einen Überblick zu erhalten, doch aus
den 100 Paketen (48. bis 157.) reichte die Erfassung der ersten 10 aus. Die Schlussfolgerung von 10
Paketen war identisch mit der von 100 Paketen und nur zeigte eine ständige Wiederholung (Buddy
kommen online, Dateiversand, Idletime,…) der Ereignisse. Für die Ausgabe auf der Buddyliste und die
Speicherung des letzten Paketes der Messungen wurde die Methode QoS_getlastPacket eingefügt. Passend dazu wurde die Methode addTraffic erweitert. Um den modifizierten Jimm Client zu testen, muss
lediglich Java SDK, Java WTK, Siemens WTK und der Siemens S65 Emulator installiert werden. Die Grund-
funktionalität ohne Dateiversand sollte auf jeden MIDP2 Mobiltelefon lauffähig sein. Ein Zugriff auf das
Dateisystem ist nur bei Siemens Telefonen möglich, da hier die fileaccess.jar zur Verfügung stand. Diese
Datei war bereits im Sourcebundle von Jimm enthalten.
2.3 JAVA SIP
Die Implementierung von
SIP in Java ist im JSR 180
sowie im White Paper „SIP
and the Java Platforms“
von
Phelim
detailiert
Dabei
O'Doherty
beschrieben.
entspricht
dies
einer Umsetzung des SIP
RFC’s 3261 inklusive den
zusätzlichen Umsetzungen der RFC 2976, 3262,
3265, 3311, 3326, 3428
und 3515.
Das
Session
Initiation
Protocol wurde in Java
für Computer (JAIN), sowie für Mobiltelefone (SIP
for J2ME) integriert.
Bildquelle: http://java.sun.com/products/jain/images/ims-java.gif
Allerdings gibt es zwischen den beiden deutliche Unterschiede, denn es ist nur die jeweils passende
Implementierung adressierbar. Durch den Unterschied im Befehlssatz ist eine JAIN SIP Applikation nicht
auf einem Handy ausführbar und umgekehrt.
Die SIP Verbindung wird vom Mobiltelefon mittels Request zum P-CSCF aufgebaut. Doch dieser reicht
den Request weiter an den I-CSCF. Der I-CSCF nimmt aber den Request ebenfalls nicht an, sondern
leitet alle SIP Nachrichten an den S-CSCF weiter. Erst dort wird die SIP Nachricht bearbeitet und eine
neue SIP Server Connection aufgebaut. Die Antwort (Response) wird über den I-CSCF und P-CSCF wieder an das Mobiltelefon zurück geleitet. Zusätzlich erhält das Mobiltelefon ein Request von der SIP Client
Connection, um eine SIP Server Connection aufzubauen. Danach kann der Datenfluss erfolgen. Zum Beenden wird dann ein Bye versendet und mit 200 OK quittiert.
6
2.4 Messdaten
Unter dem Menüpunkt Traffic-QoS konnten wir die Daten direkt ablesen.
Empfang von 5 Textmessages
Hier ist erkennbar, jede Textnachricht hat 215 Byte
im Header plus je 1 Byte für jedes Chat-Zeichen.
Dabei wurde die erste Nachricht mit 1, die nächste
mit 2 Zeichen usw. versendet. Nach Erhalt einer
Nachricht folgte ein 131 Byte Quittungspaket.
Idlen mit einigen Buddys im Online-Status
Onlinestatusmeldungen erfolgen ohne Quittierung.
Sehr geringer Traffic von 40 - 100 Bytes je Paket.
Idle, danach connected ein Buddy
Zu Beginn befinden wir uns allein online ohne Aktivität. Die dann folgenden Onlinestatusmeldungen sind
ohne Quittierung, ansonsten werden nur 46 Bytes
große Keep Alive Pakete gesendet.
Senden von 4kb an PC - Client
Zu Beginn keine Aktivität, dann wird ein Dateitransfer durchgeführt. Anschließend wieder Ruhezustand.
Je Datenpaket wurden maximal 2091 Byte versendet
Æ 3 Pakete (2 x maximale Größe) nötig. Sendezeit
der max. Pakete fast gleich:
Senden von 24kb an PC - Client
Am Anfang Ruhezustand, dann folgt Datentransfer
mit maximaler Auslastung und 2091 Byte Paketen.
Der konstante Datenstrom ist von gleich bleibender
Größe, doch die Sendezeiten sind zunehmend höher,
wobei 7,8 sowie 9,10 von
gleicher Dauer sind.
Senden von 95kb an PC - Client
Beim Datentransfer haben wir einen konstanten
Strom von 2091 Byte Paketen erhalten. Deutlich
sichtbar ist eine Paarung der Sendezeiten. Diese
Resultiert daher, dass der Provider Vodafone für
GPRS maximal zwei Uploadslots gleichzeitig ermöglicht.
7
2.5 QoS-Parameter
Datendurchsatz:
Idle = 46 Bytes werden alle 120 Sekunden gesendet
Chat = 215 Bytes + Nachrichtentext + 131 Bytes Quittung je Nachricht
Burst = 2091 Bytes je Paket konstant, wobei die Paketsendezeiten steigen
Beim erstmaligem Laden oder Update der Buddylist fallen 3-10kb Transfer je nach
Listengröße an.
Prioritäten:
Kosten:
Beim Chat und Datentransfer kann auf dem Mobiltelefon nur jeweils eine Aktivität
angezeigt werden, daher ist eine Priorisierung nicht nötig.
Sind als gering einzustufen, da je nach Tarif unterschiedlich.
Beispiel Vodafone Classic Business Premium Tarif:
Je 10kb GPRS Volumen 9 Cent + 2 Cent je Nutzungstag.
Verzögerung:
Abhängig vom GSM Empfang und der Nutzung von GPRS durch andere Personen in
der gleichen Funkzelle. Bei voller Ausnutzung aller GPRS Zeitschlitze durch viele
Nutzer würde es zu hohen Verzögerungen kommen.
Stabilität:
Das Programm Jimm selbst lief bei allen Tests und auch im Alltag komplett fehlerfrei. Kommunikationsfehler (bei Chat / Dateitransfer) werden durch OSCAR im Kanal
3 übermittelt. Doch kann es auch zu Datenverlust zum Beispiel durch GSMFunklöcher kommen, wobei es dafür keine Absicherung gibt. Die Daten werden aber
auf dem P-CSCF vorgehalten und bei Erreichbarkeit des Empfängers an diesen
übermittelt.
Verfügbarkeit:
Benutzbarkeit:
Je nach GSM Empfang überall nutzbar. Die ICQ Server selbst hatten keine nennens-
werten Ausfälle, wobei dies auf Erfahrung aus fast 8 Jahre Nutzung zurückgeht.
- langsames Tippen
+ unkomplizierte Installation
+ oftmals deutlich geringe Kosten als SMS oder Telefonat
+ Konzept des Instant Messaging gut umgesetzt – chat anytime, anywhere
8
3. Mopiphant
Die Universitäten von Würzburg und Passau verwirklichten zusammen mit der
Siemens Communication im Rahmen eines Forschungsprojektes das Ziel Peer-
to-Peer über mobile Endgeräte. Die daraus entstandene Umsetzung des eMule-
Client wurde auf den Namen Mopiphant getauft. Angefangen hatte alles mit der Idee,
den immer weiter ansteigenden Konsum von Musik, Filmen usw. über Handy besser
nutzen zu können. Schließlich suchen auch Netzbetreiber nach Möglichkeiten, den Traffic in ihren Netzen zu erhöhen, insbesondere im Hinblick auf UMTS. Mobil-Peer-to-Peer ist das Zauberwort, welches
auf den kommenden Seiten von uns betrachtet wird.
Die Voraussetzungen, die das Mobilfunkendgerät mitbringen muss, werden bereits durch den gängigen
PocketPC’s erfüllt:
-
-
-
WindowsCE-Plattform PocketPC (für Smartphones wie XDA oder MDA),
Microsofts .NET-Compact-Framework (Pocket-PC 2000 & 2002),
mindestens 10MB RAM.
Der Mopiphant setzt auf den Iphant auf, welcher eine abgespeckte Version des edonkey-Client ist. Es
wurden also alle unnötigen und überflüssigen Komponenten des eDonkey-Client weggelassen, wie zum
Beispiel den IRC-Chat.
Es stellt sich die Frage, ob es technisch überhaupt machbar und sinnvoll ist, P2P-Systeme über GPRSoder UMTS-Netze abzuwickeln. Was angesichts geringer Bandbreiten, P2P-hinderlicher Netzbetreiber-
Konfigurationen und hier zu Lande hoher Tarife auf den ersten Blick absurd erscheinen mag, könnte sich
mit einigen Anpassungen aber zu einem sowohl für Nutzer als auch für Netzbetreiber höchst interessanten Ansatz entwickeln.
T-Mobile bot für einen Testzeitraum einen direkten IP-Verkehr zwischen Handys an, so dass der Einsatz
von VPN hier nicht notwendig war. Deutliche Abstriche sind bei direkten Verbindungen von Handy zu
Handy zu verzeichnen, schließlich müssen hier zwei Strecken per Mobilfunk überbrückt werden. Die Zahl
wiederholter Paketübertragungen durch Paketverluste bei der Übermittlung mittels UMTS ist gering und
liegt bei unter 0,5 Prozent. Je nach Netzbetreiber gibt es aber deutliche Unterschiede, was beispielsweise abgebrochene Downloads angeht. eDonkey anfälliger als einfache Dateiübertragungen per FTP zu
sein, was aber auch am frühen Stadium der Endgeräte und Netze liegen kann.
Der Mopiphant kann von der speziellen P2P-Architektur des MoPi-Projekts profitieren, funktioniert aber
auch ohne diese. Die Grundlage für entsprechende Applikationen existiert, seit es IP-Stacks auf mobilen
Endgeräten gibt, insbesondere wenn Java- oder .NET compact als Ausführungsumgebungen vorhanden
sind.
Der Ansatz hat aber auch noch einen positiven
Nebeneffekt, zumindest für den Mobilfunkbetreiber. Dieser hat die Kontrolle über die Proxy Server
und so auch über die getauschten Inhalte und
kann außerdem dafür sorgen, dass möglichst viel
vom ansonsten hoch redundanten P2P-Traffic im
eigenen Netz verbleibt. Dieses ist sinnvoll, um
zum Beispiel Filesharing von DRM-geschützten
Dateien herauszufiltern bzw. zu verhindern.
9
Mit kommenden UMTS-Techniken wie HSDPA erwarten die Entwickler positive Einflüsse auf mobiles P2P.
Für entsprechende Inhalte sorgen nicht zuletzt Kamera-Handys mit wachsender Auflösung.
3.1 Netzwerkstrukturen: Client-Server, Peer-to-Peer, Mobile-Peer-to-Peer
Ein Client-Server-System besteht aus einem Client, der eine Verbindung mit einem Server aufbaut und
aus einem Server der einen Dienst zur Verfügung stellt. Der Client bietet die Benutzeroberfläche oder die
Benutzerschnittstelle der Anwendung an.
In einem Peer-to-Peer-Netz sind alle Computer gleichberechtigt und können sowohl Dienste in An-
spruch nehmen als auch Dienste zur Verfügung stellen. Die Computer können als Arbeitsstationen genutzt werden, aber auch Aufgaben im Netz übernehmen.
-
-
-
-
Es gibt keine zentrale Datenbank, jeder Peer stellt einen Teil der vorhandenen Informationen zur
Verfügung. Kein Peer verwaltet (oder kennt) den Gesamtbestand.
Es gibt keine zentrale Instanz, die Interaktionen steuert oder koordiniert.
Die angebundenen Peers sind autonom.
Kein Peer hat (notwendigerweise) einen Überblick über das Gesamtsystem. Jeder Peer kennt nur
die Peers, mit denen er interagiert.
Das Verhalten des Systems ergibt sich dynamisch aus der Kombination der Interaktionen zwi-
schen den Peers.
Peers, Verbindungen und Informationen sind nicht verlässlich.
Keine „single point of failure“ Architektur, d.h. wird ein Peer aus dem Netz genommen, besteht
keine Gefahr, dass das ganze Netz zusammenbricht.
Beim Mobile P2P ist es möglich, dass mobile Endgeräte eigenständige Peers eines P2P-Systems sind.
3.2 Mopiphant – Aufbau
3.2.1 Architektur
Beim Mopiphant stand man vor dem Problem, dass Aufgrund der derzeit geringen Bandbreite Falschenhälse entstehen könnten, diese galt es zu vermeiden, um so eine effiziente und effektive Nutzung von
P2P-Systemen auch in mobilen Netzen zu ermöglichen. Auch in UMTS-Netzen, die HSDPAGeschwindigkeiten von rund 1,4 MBit/s im Downstream erreichen, fallen die Upstream-Bandbreiten
noch recht bescheiden aus und die Funkübertragungen weisen allgemein noch immer höhere Latenzzeiten auf als bei drahtgebundene Übertragungen.
Es wurden drei neue Elemente in die bestehende P2P-Architektur eingefügt: ein erweiterten Index-
Server, ein Cache-Peer und ein Crawler. Die beiden Letzteren verhalten sich wie normale Peers, sind aber
besonders leistungsfähig ausgelegt und alle drei werden vom Netzbetreiber kontrolliert. Dem Index-
Server werden alle Anfragen nach Ressource-IDs mitgeteilt, so dass eine populäre Ressource, die besonders häufig nachgefragt wird, identifizieren werden kann.
Um von diesen Informationen profitieren zu können, wird ein Cache-Peer eingeführt, der die so ermittelten, besonders populären Ressourcen zwischenspeichern kann. Mobile Peers müssen allerdings dazu
gebracht werden, bevorzugt auf diesen Cache-Peer zuzugreifen, sofern dort die gewünschten Daten zur
Verfügung stehen. Dafür sorgt ebenfalls der Index-Server: Sofern eine zwischengespeicherte Kopie vorliegt, wird der Cache-Peer als Quelle für diese Datei zurückgeliefert.
10
Der Crawler stellt die Verbindung zwischen den Index-Servern sowie den zugehörigen P2P-Communities
innerhalb des Mobilfunknetzes und Festnetz-Index-Servers her. Schließlich ist es wünschenswert, die
mobilen Peers davon abzuhalten, Verbindungen nach außen aufzubauen. Sind diese Voraussetzungen
nicht gegeben könnten sie nicht von den Vorteilen der erweiterten P2P-Architektur profitieren.
In der nachfolgenden Tabelle sind die Upload- und Download-Geschwindigkeiten aufgeführt für gängige
Netzabindungen . Der Cache-Peer soll die Hauptlast tragen und ist daher besonders leistungsfähig.
access type of peer
upload bandwidth
download bandwidth
max. upload connection
UMTS
64 kbps
384 kbps
4
DSL – 1000
128 kbps
768 kpbs
10
Cache
4 Gbps
4 Gbps
400
3.2.2 Cache-Peer
Um die Leistungsfähigkeit des Cache-Peers darzustellen, haben wir uns ein Bespiel zur Verdeutlichung
ausgesucht. Dieses Szenario fand in einem speziellen Testareal statt, welches mit HSDPA ausgestattet ist
(Oberhausen/CentrO) und optimale Übertragungsgeschwindigkeiten bietet.
11
Gegeben waren 3333 Mobil-Peers und 6667 In-
3MB Datei zur Verfügung, welche von den
verbleibenden 9999 Peers in die Download-Liste
genommen wurde.
Angesetzt war ein 150-stündiger Simulations-
zeitraum, während man das Transfervolumen der
einzelnen Peers beobachtete.
Man erkennt, wie der Cache-Peer immer mehr die
Rolle der Internet-Peers übernimmt und somit
den Mobile-Peers eine höhere Bandbreite zur
Verfügung stellt. So erreichten die Mobile-Peers
im Durchschnitt ~900MB/h Transfervolumen.
1.4
transfered volume [GB/h]
ternet-Peers. Eines der Internet-Peers stellte eine
1.2
mobile peer
1
0.8
0.6
0.4
internet peer
cache peer
0.2
0
0
50
100
simulation time [h]
150
3.3 QoS-Parameter
Datendurchsatz:
Ist abhängig vom UMTS-Empfang. Handelt es sich bei dem Download um eine populäre Datei auf dem Cache - Peer, so werden Wartezeiten reduziert und der Datendurchsatz erhöht sich.
Prioritäten:
Wird ebenfalls vom Cache-Peer unterstützt.
Kosten:
Beim Filesharing ist allgemein eine echte Flatrate sinnvoll, von einer Volumenflatrate
ist abzuraten auf Grund des hohen Traffic.
Verzögerung:
Ist abhängig vom Empfang und der Anzahl der Nutzer in der UMTS Zelle.
Stabilität:
Wird eine Datei zum Download hinzugefügt, welche größer als ein eMule-Chunk mit
9,28MB ist, stürzt der Mopiphant ab. Mehr als 1 Chunk wird bisher noch nicht unterstützt.
Verfügbarkeit:
Ist abhängig von der UMTS-Verfügbarkeit, sowie der Anbindung an das Internet P2P.
Die entsprechende server.met, welche zum Mopiphanten dazugehört, beinhaltet
mehrere Indexserver.
Benutzbarkeit:
Einfache Benutzung durch eine textuelle Indexierung und die Textsuche in Dateina-
men.
Der Nutzer muss zudem nicht alle seine Inhalte "blind" hochladen, nur in der Hoffnung, dass irgendwer
diese später herunterladen kann, wie es beispielsweise bei aktuellen Foto-Sharing-Angeboten der Fall
ist. Dennoch steht eine große Vielfalt an Inhalten zur Verfügung. Auch der psychologische Aspekt - die
Befriedigung von Neugier - wird durch den Ansatz beibehalten.
12
4. Quellen
Internet:
http://de.hsupa.com/
http://www.faqs.org/rfcs/rfc3261.html
http://www.golem.de/0504/37235.html
http://scr3.golem.de/?d=0504/mopiphant&a=37235
http://www.vodafone.de/unternehmen/presse/44003.html
http://www.3gpp.org/ftp/Specs/archive/23_series/23.218/
http://www-info3.informatik.uni-wuerzburg.de/staff/mopi/index.shtml
http://www.fokus.gmd.de/bereichsseiten/testbeds/ims_playground/playground/cscf.php?lang=de
http://www.siemens.com/index.jsp?sdc_p=ft3ml0s2u1436o1328988i1328988pMNDEc61z2&sdc_bcpath=1333982.s_2,1333984.
s_2,1332842.s_2,1328988.s_2,&sdc_sid=2792387237&
http://www.semanticmediashowcase.de/WerkstattCM/CrossMedia/SS04/Ausarbeitungen/IP%20Multimedia%20Subsystem(IMS)_Ausarbeitung.pdf
Programmierung:
http://ant.apache.org
http://www.jedit.org
http://www.7-zip.org
http://www.ihse.net/icq
http://jimm.sourceforge.net
http://www.jcp.org/en/jsr/all
http://iserverd1.khstu.ru/oscar
http://proguard.sourceforge.net
http://de.wikipedia.org/wiki/ICQ
http://java.sun.com/products/sjwtoolkit
http://www.mindfusion.org/product1.html
http://www.siemens-mobile.com/developer
http://www.motocoder.com/motorola/pcsHome.jsp
http://www.blackberry.com/developers/index.shtml
Bücher:
Mobile Computing Grundlagen, Jörg Roth, ISBN 3-89864-366-2
13
5. Quellcode
5.1 Contactlist.java I
// QoS Mod Traffic false statt true liefert Byte, hier aber nur Constructor
this.updateTitle(Jimm.jimm.getTrafficRef().getSessionTraffic(false));
5.2 Contactlist.java II
// QoS Mod Traffic false statt true liefert Byte, hier fürs Display
Jimm.jimm.getContactListRef().updateTitle(Jimm.jimm.getTrafficRef().getSessionTraffic(false));
5.3 Contactlist.java III
// QoS Mod kb-> Byte, aus "text += sep + " wurde "text =" und Util.getDateString(true) getauscht gegen letztes Paket
text = traffic + ResourceBundle.getString(" Byte") + sep +
Jimm.jimm.getTrafficRef().QoS_getlastPacket(false);
5.4 Traffic.java I
// Array: Transfervolumen1,Transferzeit1 in Millisekunden; TV2, TZ2; ...
private int[] qos_array = new int[100];
private int qos_i;
// qos_array[qos_i] = xyz;
private long qos_starttimer; // Variable fuer Transferstart
private String qos_messungen_buffer; // Variable für Ausgabe der Messergebnisse
private int qos_last_paket;
private int t1,t2,t3,t4,t5;
private int z1,z2,z3,z4,z5,z6,z7,z8,z9,z10; // z = Zeit
5.5 Traffic.java II
qos_i = 0;
// QoS Mod Variablen initialisieren
qos_starttimer = System.currentTimeMillis(); // Startwert für erste Zeitmessung ist 0
14
5.6 Traffic.java III
ResourceBundle.getString("QoS Mod:") + "\n" +
ResourceBundle.getString("Paketanzahl = ") +
qos_i + "\n" + ResourceBundle.getString("letztes Paket ") + qos_last_paket + "\n" +
qos_messungen_buffer + "\n" +
ResourceBundle.getString("48. Paket ") + qos_array[0] + ResourceBundle.getString(" ") + z1 + "\n" +
ResourceBundle.getString("49. Paket ") + qos_array[1] + ResourceBundle.getString(" ") + z2 + "\n" +
ResourceBundle.getString("50. Paket ") + qos_array[2] + ResourceBundle.getString(" ") + z3 + "\n" +
ResourceBundle.getString("51. Paket ") + qos_array[3] + ResourceBundle.getString(" ") + z4 + "\n" +
ResourceBundle.getString("52. Paket ") + qos_array[4] + ResourceBundle.getString(" ") + z5 + "\n" +
ResourceBundle.getString("53. Paket ") + qos_array[5] + ResourceBundle.getString(" ") + z6 + "\n" +
ResourceBundle.getString("54. Paket ") + qos_array[6] + ResourceBundle.getString(" ") + z7 + "\n" +
ResourceBundle.getString("55. Paket ") + qos_array[7] + ResourceBundle.getString(" ") + z8 + "\n" +
ResourceBundle.getString("56. Paket ") + qos_array[8] + ResourceBundle.getString(" ") + z9 + "\n" +
ResourceBundle.getString("57. Paket ") + qos_array[9] + ResourceBundle.getString(" ") + z10 + "\n"
5.7 Traffic.java IV
//QoS Mod Returns value of last traffic packet
protected int QoS_getlastPacket(boolean kb)
{
if (kb) return (qos_last_paket / 1024);
return (qos_last_paket);
}
15
5.8 Traffic.java V
public void QoS_addTraffic(int bytes)
{
qos_last_paket = bytes;
if (qos_i == 48) qos_starttimer = (int) (System.currentTimeMillis());
if (qos_i == 48) z1 = (int) (System.currentTimeMillis() - qos_starttimer);
if (qos_i == 49) z2 = (int) (System.currentTimeMillis() - qos_starttimer);
if (qos_i == 50) z3 = (int) (System.currentTimeMillis() - qos_starttimer);
if (qos_i == 51) z4 = (int) (System.currentTimeMillis() - qos_starttimer);
if (qos_i == 52) z5 = (int) (System.currentTimeMillis() - qos_starttimer);
if (qos_i == 53) z6 = (int) (System.currentTimeMillis() - qos_starttimer);
if (qos_i == 54) z7 = (int) (System.currentTimeMillis() - qos_starttimer);
if (qos_i == 55) z8 = (int) (System.currentTimeMillis() - qos_starttimer);
if (qos_i == 56) z9 = (int) (System.currentTimeMillis() - qos_starttimer);
if (qos_i == 57) z10 = (int) (System.currentTimeMillis() - qos_starttimer);
if ((qos_i >= 48) && (qos_i <= 99)) qos_array[qos_i-48] = bytes;
//if (qos_i <= 99) qos_array[1][qos_i] = (int) (System.currentTimeMillis() - qos_starttimer);
// Paketanzahl ermitteln
qos_i++;
}
5.9 Traffic.java VI
public void addTraffic(int bytes)
{
session_traffic = session_traffic + bytes;
// QoS Mod sichert aktuelles Packet
this.QoS_addTraffic(bytes);
16
6. Glossar
BOS
BURST
Basic OSCAR Service
Eine Menge von Datenpaketen, die direkt aufeinander folgend (mit der ma-
ximalen bzw. beinahe maximalen Datenrate auf dem Netzinterface) in einem
knoten ankommen bzw. vom Knoten gesendet werden.
DC
EDGE
Direct Connection = direkte Verbindung zwischen Clienten
Enhanced Data Rates for GSM Evolution; Technik zur Erhöhung der Datenrate
in GSM-Mobilfunknetzen
FLAP
FDDITalk Link Access Protokoll
GPRS
General Packet Radio Service; Datenübertragung mit Paketvermittlung über
GSM
Global System for Mobile Communications: digitales Mobilfunksystem der
HSDPA
HSS
GSM.
zweiten Generation (2G)
High Speed Downlink Packet Access (HSDPA) ist ein zukünftiges Übertragungsverfahren des Mobilfunkstandards UMTS.
Home Subscriber Server
HSUPA
High Speed Downlink Packet Access (HSDPA) ist ein zukünftiges Übertra-
I-CSCF
Interrogating Call Session Control Function
IDLE
gungsverfahren des Mobilfunkstandards UMTS.
allgemein für Leerlauf(-zeit). Beispielsweise die Zeit, die ein Benutzer eines
Telekommunikationsnetzes oder –dienstes nicht mehr aktiv das Netz oder
den Dienst genutzt hat.
IM
Instant Messaging
J2ME
Java 2 Micro Edition (J2ME) ist eine reduzierte Version von J2EE und J2SE.
JAIN
Java advanced intelligent network ist ein Satz von Java-basierten APIs mit
J2ME ist optimiert für Mobilgeräte wie Handys, Handhelds, Palmtops.
denen neuen Entwicklungen von Telefonprodukten und -diensten eine JavaPlattform bereitgestellt wird.
JSLEE/JSIP
LLC
MDA
MGCF
MGW
OSCAR
P2P
JAIN Service Logic Execution Environment
Logical Link Control: OSI-Protokoll; identisch für LAN-Subsysteme im
Standard IEEE 802
Mobil Digital Assistant
Media Gateway Control Function
Media Gateway
Open System for Communication in Realtime
Peer-to-Peer: Netzwerk, bei dem jeder angeschlossene PC gleichberechtigt
ist.
17
P-CSCF
RLC/MAC
Proxy Call Session Control Function
Abk. Radio Link Control. In der Protokollarchitektur des Mobilfunksystems
der dritten Generation UMTS (Universal Mobile Telecommunications System)
eine Protokollschicht, die - aufsetzend auf die MAC-Schicht (Media Access
Control) - für die Übertragungssteuerung und -sicherung auf den logischen
Kanälen zuständig ist.
S-CSCF
SIP
Serving Call Session Control Function
Session Initiation Protocol: ist ein Signalisierungsprotokoll zum Einrichten,
Modifizieren und Beenden von Multimedia-Konferenzen, IP-TelefonieVerbindungen und ähnlichen Anwendungen.
SNAC
SNDCP
Simple Network for Atomic Communication
Subnetzwork Dependent Convergence Protocol
TCP
Transmission Control Protocol: Transportschicht 4 von OSI für den verbin-
TLV
Abk. Type, Length, Value. Im Internetprotokoll IPv6 (Internet Protocol, Versi-
dungsorientierten Datenaustausch mit Fehlererkennung
on 6) eine Header-Komponente der so genannten Erweiterungs-Header (Ex-
tension Header, EH) mit den in der Protokollspezifikation festgelegten "Optionen", die von den "besuchten" Routern interpretiert werden.
UMTS
Universal Mobile Telecommunications System: Projekt eines künftigen, universell nutzbaren Mobilfunknetzes der so genannten dritten Generation im
Frequenzband von 2 GHz. UMTS soll die bestehenden zellularen Mobilfunk-
netze (z.B. GSM, C 450), schnurlose Systeme (z.B. CT, DECT), private Bündelfunksysteme (TETRA) sowie drahtlose lokale Netze (WLAN - Wireless Local
Area Network) zusammenführen und neue Dienste bereitstellen.
VoIP
Voice-over-IP: Sprache über das Internetprotokoll, das sowohl über en Backbone eines Netzes geschehen kann, als auch im lokalen Bereich (à IPTelefonie).
XDA
Extended Digital Assistant
18