QoS Ausarbeitung Has..
Werbung
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
