Verbreitung von Informationen in mobilen Ad-hoc Netzwerken

Inhaltsverzeichnis

1 Einleitung
1.1 iClouds
1.2 Verwandte Arbeiten
1.2.1 Peer-to-Peer auf Personal Computern
1.2.2 Weitere Projekte

2 Ziele der Arbeit
2.1 Entwicklung eines Prototypen
2.2 Performance-Tests

3 Grundlagen
3.1 IP-Netzwerke
3.1.1 IP Auto-Configuration
3.2 Wireless LAN
3.2.1 Netzwerkmodi
3.2.2 802.11 Medium Access Control
3.3 Personal Digital Assistants
3.4 Peer-to-Peer
3.5 MP3 und ID
3.6 Java 2 Micro Edition

4 Verwendung und Design des Prototypen

5 Technische Umsetzung
5.1 Das Netzwerk
5.1.1 Netzwerkebene - OSI Ebene
5.1.2 Verbindungsebene - OSI Ebene
5.2 Das Kommunikationsprotokoll - OSI Ebene
5.2.1 Type
5.2.2 PeerName
5.2.3 FileName
5.2.4 Size
5.2.5 Info
5.2.6 ID
5.2.7 Title, Artist, Album, Rating, Comment, Genre
5.3 Teilnehmererkennung und Time-Outs
5.4 Dateiübertragung
5.5 Textnachrichten
5.6 Das User-Interface
5.6.1 Thinlets
5.7 Der Simulator
5.8 Logging mit log4j

6 Programm-Struktur
6.1 Beschreibung der Klassen
6.1.1 Die Klasse FileHandler
6.1.2 Die Klasse PeerHandler
6.1.3 Die Klasse Sender
6.1.4 Die Klassen RequestListener und FileTransferThread .
6.1.5 Die Klasse MessageHandler
6.1.6 Die Klasse Timer
6.1.7 Die Klasse Listener
6.2 Der Nachrichtenfluss

7 Performance-Tests
7.1 Die verwendete Hardware
7.2 Szenario 1: Zwei Peers
7.2.1 Zwei Peers im Client-Server-Modell
7.2.2 Zwei Peers im Peer-to-Peer-Modell
7.3 Szenario 2: Vier Peers
7.3.1 Ein Peer als Server
7.3.2 Jeder Peer stellt eine andere Datei
7.4 Szenario 3:
7.4.1Information-Sprinkler mit bewegten Clients
7.5Szenario4:’Fußgänger-Test’

8 Evaluation
8.1 Auswertung der Testläufe
8.2 Probleme bei den Testläufen
8.3 Verwendete Hardware

9 Zusammenfassung und Ausblick

A Konfiguration

Kapitel 1 Einleitung

In den letzten Jahren ist in der Gesellschaft eine Entwicklung hin zu immer mehr Flexibilität und Mobilität zu verzeichnen. In Verbindung mit der steigenden Durch- dringung des Alltags durch elektronische Geräte ist der Trend in Richtung elektroni- scher persönlicher Begleiter eine logische Folge. Angefangen hat dies in den neunziger Jahren, als Mobiltelefone vom Nischenprodukt für Manager und Außendienstler zum Alltagsgegenstand avancierten. Zur gleichen Zeit fiel der Preis mobiler Computer, sogenannter Laptops bzw. Notebooks, die die Rechenleistung eines PCs erstmals für den mobilen Einsatz zur Verfügung stellen konnten. Der bislang letzte Schritt dieser Entwicklung sind Personal Digital Assistants (PDAs). Diese Taschen-Computer die- nen dem persönlichen Informations-Management und sollten ursprünglich die Ver- bindung von Kalender und Notizblock zur elektronischen Datenverwaltung schaffen. Die heutigen Geräte sind durch stetige Weiterentwicklung noch leistungsfähiger was Rechen- und Speicherkapazität angeht: aus den ’PersönlichenAssistenten’sindbspw. Navigationssysteme und Multimedia-Abspielgeräte geworden.¹

Eine weitere Entwicklung fand in einem völlig anderen Bereich statt: Mit der Musiktauschbörse Napster [NAPSTER] fand die Idee des Dateiaustauschs mittels Peerto-Peer Technologie im Internet erstmals großen Anklang bei der breiten Masse der Endanwender.² Trotz durch die Musikindustrie eingereichter Klagen wegen Urheberrechts-Verletzungen erfreut sich Peer-to-Peer auch heute noch großer Beliebtheit, was unter anderem durch die stetige Weiter- und Neuentwicklung von Peer-to-Peer Software belegt wird.

Ein Bereich, der bisher allerdings noch kein solches Wachstum erlebt hat und sich noch in seiner Anfangsphase befindet, ist die Konvergenz der oben genannten Tech- nologien: Peer-to-Peer auf mobilen Plattformen. Dieser Ansatz ist naheliegender als er zunächst erscheinen mag: Peer-to-Peer basiert auf dem ’Gemeinsamkeits’- Gedanken; die Idee dahinter ist der Informationsaustausch zwischen Teilnehmern mit gleichen Interessen. Diese Gemeinsamkeit kann in einer mobilen Umgebung gut abgedeckt werden, da örtliche Nähe nicht selten auch gemeinsame Interessen be- deutet - seien diese kommerzieller oder privater Natur. Das Projekt iClouds dazu [Hei[03]b]:

”Wheneverthereisagroupofpeople,theymayshareacommongoal or have a related motivation. Information of interest may be in possession of only a few of them.“

Mit den inzwischen auch im Konsumenten-Markt weit verbreiteten Möglichkeiten, die PDAs bieten - seien es Funknetzwerk, größerer Speicher oder verbesserte Akkulaufzeiten - kann Peer-to-Peer nun auch auf mobilen Geräten Einzug halten. Im Rahmen dieser Arbeit wird eine prototypische Software vorgestellt, die auf Peer-to- Peer basierende Verbreitung von Daten auf solchen mobilen Geräten implementiert. Die Arbeit ist wie folgt gegliedert:

Im nächsten Abschnitt dieser Einleitung wird das Projekt iClouds sowie verschiedene weitere verwandte Arbeiten aufgezählt. Diese reichen vom reinen Peer-to-Peer System bis zu akademischen Pilotprojekten. Darauf folgt in Kapitel[2] eine genauere Beschreibung und Begründung der in dieser Arbeit verfolgten Ziele.

In Kapitel[3] sollen zunächst Grundlagen geschaffen werden, die zum Verständnis der folgenden Arbeit benötigt werden. Diese bestehen aus Netzwerktechnik (IP und

WLAN), der Erläuterung des Begriffs ”Peer-to-Peer“sowieausweiterenhierver- wendeten Technologien (MP3 und Java).

In Kapitel[4] wird erstmals näher auf den vorgestellten Prototypen eingegangen. Grundlegende Entscheidungen für oder wider bestimmte Techniken werden darge- legt, zum Beispiel die Teilnehmer-Entdeckung, Suchstrategien und Benutzerinterak- tion.

Kapitel[5] geht auf die in Kapitel[4] angesprochenen Punkte genauer ein: Zu jedem Bereich des Prototypen wird eine genauere Beschreibung der verwendeten Lösung gegeben. Dazu gehören die Netzwerk-Konfiguration, das Kommunikations-Protokoll, Peer-Management, die Methodik der Textnachrichten- und Dateiübertragung sowie das Design der Benutzer-Schnittstelle. Das Kapitel wird abgeschlossen durch die Erläuterung weiterer, speziell bei den Performance-Tests benötigter Erweiterungen des Prototypen.

Eine Erklärung der im Prototypen gegebenen Programm-Struktur wird in Kapitel 6 gegeben. Dieses Kapitel soll aufzeigen, wie die einzelnen Klassen im Prototypen zusammenhängen und welche Klassen miteinander kommunizieren. Dazu werden zunächst die einzelnen Klassen erläutert, abschließend soll ein beispielhafter Nach- richtenfluss anhand eines Diagramms dieses Zusammenspiel veranschaulichen.

Kapitel 7 geht auf das zweite Ziel der Arbeit ein: In verschiedenen Testszenarien wurde untersucht, inwieweit der Prototyp bzw. die verwendete Hardware für den Einsatz in der Praxis geeignet sind. Die Szenarien sind so gewählt, dass zunächst Erkenntnisse über Engpässe und Probleme gewonnen werden, andere Szenarien gehen näher auf den alltäglichen Einsatz ein. Es konnte gezeigt werden, dass die verwendete Hardware zusammen mit der hier vorgestellten Software das Suchen und Übermitteln von Dateien in mobilen Umgebungen ermöglicht.

Schließlich werden die im Rahmen dieser Arbeit erreichten Erkenntnisse in Kapitel 8 zusammengefasst und bewertet; Probleme und Grenzen von Hard- und Software werden erläutert. Kapitel 9 enthält abschließende Bemerkungen sowie einen Ausblick in die weitere Entwicklung der vorgestellten Technologien.

1.1 iClouds

Diese Arbeit entstand im Rahmen des Projektes iClouds [Hei03a] und soll einige Ideen dieses Projektes realisieren. iCloudsbeschäftigt sich mit mobilen Netzwerken, in denen Informationen vielfältiger Art getauscht werden können [HKLM03b]. Da es sich dabei nicht um geschlossene Benutzergruppen sondern um zufällig zustande gekommene (ad hoc) Kommunikation zwischen anonymen Nutzern handelt, ist ein Weiterleiten der Kommunikation (Routing) nicht gewünscht. Es kann weder das Vertrauen in die weitergeleiteten Daten noch die Bereitschaft zur Bereitstellung der für Routing notwendigen Ressourcen vorausgesetzt werden. Daher werden durch iClouds ausschließlich One-Hop-Netzwerke gebildet. Als Plattform dienen - wie es auch im hier vorgestellten Prototypen der Fall ist - hauptsächlich mobile Taschen- Computer, sog. PDAs³. Das Projekt iClouds geht grundsätzlich davon aus, dass räumliche Nähe fast immer auch eine Überschneidung von Interessen bedeutet, und dass das Bereitstellen bestimmter Informationen für alle Teilnehmer von Nutzen sein kann. Das direkte, spontane Einrichten des Netzwerks (ad hoc) bedeutet schnelle Kommunikationsmöglichkeit mit der Umgebung. Das Design als One-Hop-Netzwerk wurde u.a. gewählt, damit die Teilnehmer alle Kommunikationspartner innerhalb kurzer Zeit für ein persönliches Gespräch erreichen können. Die einzige Variante, in der Informationen über Dritte transportiert werden, ist deren geografische Mobilität: Lädt sich ein Teilnehmer A von Teilnehmer B eine Information herunter und bewegt sich dann weg von der Quelle B in die Reichweite eines dritten Anwenders C, so kann C die Daten von A erhalten, ohne je in Reichweite der ursprünglichen Quelle B gewesen zu sein.

Um den Informationsaustausch zu realisieren hat jeder Benutzer ein entsprechendes Profil, in dem seine Wünsche (iWish) bzw. die bei ihm verfügbaren Informationen (iHave) gespeichert sind. Durch automatischen Abgleich dieser Profile sammeln die Teilnehmer gewünschte Informationen und verbreiten diese auch automatisch wei- ter. Die semantische Beschreibung der Daten muss gegeben sein, um einen effektiven Abgleich von iWish und iHave zu ermöglichen. Da die Art der Informationen bzw. deren Thema keinerlei Beschränkungen unterliegt, ist dies ein schwer zu realisie- render Punkt. Der zum Zeitpunkt dieser Arbeit aktuelle Ansatz geht diesbezüglich in Richtung hierarchischer Strukturen bzw. Taxonomien. Als weiterer Schritt sol- len Technologien aus dem Bereich des Semantic Web [BLHL01] erprobt werden [HKLM03b].

1.2 Verwandte Arbeiten

1.2.1 Peer-to-Peer auf Personal Computern

In diesem Abschnitt wird kurz auf einige wichtige Peer-to-Peer Tauschbörsen eingegangen. Diese sollen die Entwicklung und unterschiedliche Techniken des P2P- Bereichs darstellen.

Seine erste Welle der Popularität erlebte Peer-to-Peer durch ein Programm namens Napster. Diese 1998 von Shawn Fanning programmierte Software gab die Möglichkeit Daten direkt zwischen PCs der Teilnehmer zu tauschen. Um eine effiziente Suche zu ermöglichen werden alle Anfragen an einen zentralen Indeizierungs-Server gesen- det, der Informationen über Clients mit potenziellen Antworten zurückgibt. Die Da- teiübertragung selbst findet dann direkt zwischen den Peers statt. Napster hat somit erstmals eine Technik auf breiter Ebene eingeführt, die hybrides Peer-to-Peer⁴ ge- nannt wird: Das Management der Suchanfragen übernimmt ein Server, während die eigentlichen Ressourcen direkt zwischen den Peers ausgetauscht werden [CWW+03]. Diese Technik wurde Napster ironischerweise zum Verhängnis, da die Musikindus- trie im zentralen Server einen Angriffspunkt für Urheberrechts-Verletzungen fand und Napster aufgrund entsprechender Klagen (in seiner ursprünglichen, kostenlosen Variante) vom Netz genommen wurde [Wik04b].

Die Technik der Suchanfragen-Bearbeitung ist es, die GNUtella [Wik04a] von Naps- ter unterscheidet: Statt eines hybriden Protokolls verwendet GNUtella reines Peer- to-Peer, d.h. es existieren keine zentralen Verwaltungs-Instanzen, da dieser Aufwand von den Peers selbst übernommen wird. Suchanfragen werden an einige ’bekannte’ (z.B. über Listen von im Internet veröffentlichten IP-Adressen gefundene) Peers ge- sendet; diese wiederum leiten die Anfrage an die ihrerseits bekannten Peers weiter. So pflanzt sich die Anfrage - eine gewissen ’Lebensdauer’lang-imNetzwerkfort. Daher kann im Fall GNUtella wirklich von reinem Peer-to-Peer gesprochen wer- den, was das Netzwerk an keiner zentralen Instanz angreifbar macht. Diese enorme Ausfallsicherheit wird jedoch mit erheblicher Netzwerklast erkauft: Das teils ziellose weiterleiten von Suchanfragen bedeutet regen Datenverkehr, der auf Kosten der zur Datenübertragung verbleibenden Bandbreite übermittelt werden muss [CHK+03].

Die zum Zeitpunkt dieser Arbeit beliebteste Peer-to-Peer Tauschbörse ist KaZaA [KAZAA]. In dieser auf FastTrack⁵ basierenden Variante kann jeder Peer ein sog. Supernode werden, der für die Verwaltung von Suchanfragen zuständig ist. Auch KaZaA sieht sich von Urheberrechts-Klagen attackiert und hat in dieser Form wohl nur geringe Überlebenschancen [Hei04].

Alle diese PC-basierten Peer-to-Peer-Implementierungen verwenden - im Gegensatz zum vorgestellten Prototypen - selbstverständlich Multi-Hop Netzwerke, da das Internet als Plattform dient.

1.2.2 Weitere Projekte

Da Peer-to-Peer in mobilen Ad-hoc-Netzwerken (MANETs⁶ ) ein relativ neu aufgekommenes Thema ist, gibt es insbesondere im akademischen Umfeld mehrere Arbeiten, die sich damit befassen.

Das Projekt Shark befasst sich mit dem Austausch von Wissen in Ad-hoc-Netzen [SG02]. Dabei wird von geschlossenen Benutzergruppen ausgegangen, zwischen de- nen Wissen ausgetauscht werden kann. Zu einer solchen Gruppe existiert ein Server (Shark Central Station, CS ), der das Wissen der Gruppe verwaltet. Die Gruppe be- steht aus mobilen Geräten (Shark Mobile Stations, MS ), die sich mit dem Server syn- chronisieren. Zwischen verschiedenen Benutzergruppen kann Wissen ausgetauscht werden. Dazu wird zunächst abgeglichen, ob gemeinsame Interessen vorliegen und ob der Sender dieses Thema bereitstellen will bzw. ob der Empfänger Wissen zu diesem Thema empfangen will. Nach Überprüfen der Rechte kann dann das Wissen ausgetauscht werden. Das gesammelte Wissen wird nach der Synchronisation mit der CS der gesamten Gruppe zur Verfügung gestellt. Benutzereingriffe sind für den Datenaustausch nicht erforderlich.

Ein wichtiger Punkt bei diesem Projekt ist die Organisation des Wissens. Um die Informationen zu strukturieren, sind die Themen als XML Topic Maps (XTMs) [PM01] organisiert. Beim Wissensaustausch und bei der Synchronisation mit der CS kann das Wissen mittels so strukturierter Dokumente dem entsprechenden Thema zugeordnet werden. Um nicht wörtlich gleiche, aber sinnverwandte Themen in den Prozess des Wissensaustauschs einzubeziehen, sollen in zukünftigen Versionen von Shark Vater-Sohn-Beziehungen ermöglicht werden.

Ein weiteres Projekt ist Proem, eine Middleware, die das Programmieren eben sol- cher mobiler Peer-to-Peer Software erleichtern soll [Kor02]. Proem geht auf spezifi- sche Probleme wie das Peer-Management und die hohe Netzwerkdynamik in solchen Netzwerken ein und bietet den Anwendungen (Proem nennt diese Peerlets) ver- schiedene Dienste an, zum Beispiel den Presence Manager, der Informationen über in Reichweite befindliche Peers gibt, oder den Profile Manager, der Informationen über den Anwender speichert und verwaltet. Weitere hilfreiche Dienste sind der Data Space Manager (Verwaltung des Datenspeichers), der Community Manager (Verwaltung von Gruppenmitgliedschaft) und die Peer Database (Sammlung von Informationen über Kommunikation mit anderen Peers). Proem befindet sich noch im Entwicklungsstadium, wurde aber bereits mehrfach durch Software-Ingenieure getestet, wobei eine erhebliche Zeitersparnis festzustellen war [Kor02].

JAVA-Entwickler Sun Microsystems selbst bietet ebenfalls eine Middleware zur Programmierung von Peer-to-Peer Software: Das Projekt JXTA [JXTA], das von Sun mitentwickelt wird, wird inzwischen auch in Form von JXME für mobile Anwendung bereitgestellt (JXTA for J2ME = JXME) [AHP02].

Kapitel 2 Ziele der Arbeit

Am Ende der Arbeit sollen folgende Punkte erreicht sein:

1. Entwicklung eines Prototypen für mobiles MP3-Sharing

Mit Hilfe des Programms sollen von den Anwendern öffentlich bereitgestellte Daten ohne ihr späteres Zutun im Netzwerk gesucht und getauscht werden können. Um dies zu erreichen muss ein entsprechendes Programm geschrieben werden, das auf mobilen Endgeräten lauffähig ist. Dieses muss unter anderem das kleine Display, die oft auftretenden Veränderungen in mobilen Netzen und die unterschiedliche Prozessor-Architektur solcher Geräte berücksichtigen.

2. Praxisnahe Performance-Tests und Machbarkeits-Beurteilung

Das oben genannte Programm muss sich nach seiner Entwicklung Tests in der Praxis stellen: Hierzu werden verschiedene Szenarien bestimmt, die den realen Einsatz einer solchen Software nachbilden. In diesen Szenarien werden Daten- durchsatz, Netzwerklast und Reichweite untersucht. Schließlich soll beurteilt werden, inwiefern sich ein solches Programm in der Realität bewähren könnte.

2.1 Entwicklung eines Prototypen

Die Entwicklung eines prototypischen Programms beginnt mit der Frage nach dem zu tauschenden Datentyp. Da die Wurzeln moderner Peer-to-Peer Netzwerke in der Verbreitung von Musikdateien liegen, wurde auch in diesem Projekt der Ansatz des MP3-Sharing verfolgt [Kor02, KSP+02]. Die gesellschaftliche Akzeptanz von Musik in Form von MP3-Dateien, sowie das Verständnis bezüglich der Beschreibung der Daten durch Titel, Interpret und ähnlicher Metadaten sind bereits gegebene Vor- aussetzungen. Die Wahrscheinlichkeit, dass Treffer auf eine Suchanfrage gefunden werden, steigt nicht nur mit der Verbreitung der Geräte und der zu Grunde lie- genden Software, sondern auch mit der Beliebtheit der gesuchten Daten. Im Fall von Musikdaten kann zum Beispiel davon ausgegangen werden, dass die Besucher eines Konzerts einen ähnlichen Musikgeschmack haben, also auch ähnliche Titel der Allgemeinheit zur Verfügung stellen, bzw. diese suchen. Mit der somit steigenden Anzahl von Treffern steigt auch die Akzeptanz durch den Anwender und damit die Verbreitung der Software. Des Weiteren benötigen Musikdateien im Allgemeinen eine Menge an Speicherplatz, die die anderer (textueller) Daten weit übersteigt. Auf diese Weise wird in einem Bereich getestet, von dem angenommen werden darf, dass die Ergebnisse der Performance-Tests eine untere Schranke für die Verwendung kleinerer Datenmengen in Form von textbasierten, semantisch beschriebenen Infor- mationen darstellt: Sind die Textdaten semantisch beschrieben, so ermöglicht das - wie es bei MP3-codierten Dateien genutzt wird - eine Suche über die Metadaten. Da ihre Größe im Normalfall nicht an die von digitalen Musikdaten heranreicht, dürfte die Performance bei Verwendung von Textdaten als Tauschobjekt, also die Performance bei der Verwendung von Musikdaten, nicht unterschreiten.

Beim Bearbeiten der Aufgabenstellung ist mit verschiedenen Teilproblemen zu rechnen, die im folgenden erläutert werden:

Der Prototyp benötigt Metadaten, um eine Suche über die angebotenen Daten durchzuführen. Im Falle von MP3-codierten Musikdaten ist die Formatierung der Metadaten bereits gegeben: Der MP3 Standard sieht die Beschreibung des Liedes im sogenannten ID3-Tag vor [Nil99]. In diesem Tag, von welchem es Version 1 (ID3v1 ) und Version 2 (ID3v2 ) gibt, sind Informationen über das Lied verfügbar. Unter an- derem können Interpret, Titel, Album und ein Kommentar gespeichert werden; das Genre des betreffenden Liedes lässt sich aus 64 (ID3v1 Standard) bzw. 125 (Erweite- rung durch das weit verbreitete MP3-Programm WinAmp [WINAMP]) auswählen. Diese Vorgabe der möglichen Genres bindet den Anwender an proprietäre Genre- Bezeichnungen, was die Trefferwahrscheinlichkeit einer Suche nach einem bestimm- ten Genre erhöht. Nichtsdestotrotz bleibt es eine individuelle Entscheidung, ein Lied einem bestimmten Genre zuzuordnen. Dies kann zwar auch von zentraler Seite aus geschehen, wie es beispielsweise bei der CDDB [CDDB] der Fall ist, der ID3-Tag einer MP3-Datei kann jedoch von jedem Anwender geschrieben oder verändert wer- den. Somit liegt es immer auch in der Hand der anderen Anwender, ob eine Suche nach einem gewissen Genre Erfolg hat.

Die Mensch-Maschine-Schnittstelle bedeutet bei der Software-Entwicklung für mobi- le Endgeräte eine besondere Herausforderung: Im Gegensatz zum PC ist die Anzeige solcher Geräte wesentlich kleiner, außerdem besteht fast nie die Möglichkeit einer (beidhändigen) Interaktion durch die Tastatur bzw. mittels der Kombination Tas- tatur und Maus. Diese Einschränkungen bedeuten für die zu entwickelnde Software, dass sie die Steuerungsoptionen auf kleinstem Raum anbieten muss, ohne den An- wender zu verwirren oder zu überfordern. Es muss genau ausgewählt werden, welche Informationen über den Status des Programms dargestellt werden, um keinen Platz auf dem User-Interface zu verschwenden. So ließe sich zum Beispiel darüber streiten, ob der Anwender Informationen über einen von seinem Gerät ausgehenden Upload wirklich sehen sollte oder ob ihm dieser Vorgang eher egal sein wird, solange er In- formationen über auf seinem Gerät neu eintreffende Daten erhält. Die Bedienung mittels des bei PDAs üblichen Stiftes in Kombination mit dem berührungssensitiven Display (Touchscreen) legt eine Steuerung durch grafische Elemente nahe. Durch die- se kann eine direkte Interaktion erfolgen, während die Häufigkeit der Benutzung der ’virtuellenTastatur’möglichstgeringgehaltenwerdensollte.Dieseistnurlangsam und umständlich zu bedienen. Obwohl Verbesserungen im Bereich der Texteingabe (z.B. Handschrifterkennung) gemacht werden, sollte diese nicht häufiger als unbe- dingt nötig - z.B. zur Eingabe des Suchbegriffs - verwendet werden [Wan[93], S 193 ff.].

Der erste und naheliegende Ansatz einer Such- bzw. Download-Strategie ist der, dass der Benutzer sieht, welche anderen Geräte sich in seiner Reichweite befinden, eine Suche anhand der bereits genannten ID 3 -Tag-Informationen starten kann, und sich aus den Ergebnissen die Daten auswählen kann, die er auf sein Gerät herun- terladen möchte. Dieser Ansatz wird auch von fast allen PC-basierten Tauschbörsen verfolgt. Durch das hohe Maß an Mobilität ändern sich jedoch die Anforderungen: ständig ist damit zu rechnen, dass neue Peers in Reichweite des Suchenden kommen und sich dadurch der verfügbare Datenbestand verändert. Eine Suche, die eben noch keinen Treffer ergab, könnte schon wenige Minuten später mehrere den Suchkriterien entsprechende Dateien finden. Der Anwender müsste, um dies zu berücksichtigen, die selbe Suche dauernd (spätestens nachdem ein neuer Kommunikationspartner in Reichweite gekommen ist) neu starten. Es ist also eine logischer Schluss, dass die Software die Möglichkeit anbieten muss, die Suchkriterien zu speichern um die Suche dann selbständig zu wiederholen. Doch selbst wenn dies der Fall ist, würde es noch einen Benutzereingriff erfordern, um aus den gefundenen Treffern die gewünschten Downloads zu starten. Daher soll der Prototyp einerseits die ’einmalige’Suchemit manueller Auswahl der herunterzuladenden Dateien und anderseits eine ’dauerhafte’ Suche, die den Suchkriterien entsprechende Daten sofort herunterlädt, anbieten. Die- se dauerhaften Sucheinträge müssen vom Anwender so exakt gehalten werden, dass sie nicht zu viele Daten herunterladen, dürfen andererseits jedoch nicht zu restriktiv sein, um überhaupt einen Treffer zu finden. Bei beiden Arten der Suche müssen kleinere Fehler bei der Texteingabe toleriert werden, da erstens die Texteingabe auf solchen Geräten komplizierter ist als mit einer PC-Tastatur, und zweitens insbesondere bei Interpreten und Liedtiteln Rechtschreibfehler aufgrund von Unwissen über die richtige Schreibweise vorkommen können.

Der Erfolg des Teilens und Verteilens von Daten durch die Peer-to-Peer Technik steht und fällt mit der Bereitschaft der Anwender, die bei ihnen verfügbaren Ressourcen anderen Anwendern zugänglich zu machen. Mit anderen Worten müssen die Benut- zer möglichst viele Daten öffentlich zur Verfügung stellen, denn nur so können sie damit rechnen, dass auch die eigenen Suchanfragen Erfolg haben werden. Daher wird jede heruntergeladene Datei automatisch als den anderen Anwendern zur Verfügung stehend registriert und kann sofort nach Beendigung des Downloads verbreitet wer- den. Zwar soll es eine Funktion geben, mit der der Anwender selbst Daten im der Öffentlichkeit zugänglichen Verzeichnis vor deren Augen (d.h. Suchanfragen) verber- gen kann, jedoch muss dazu ein expliziter Benutzereingriff nötig sein [HKLM03a]. Auf diese Weise soll erreicht werden, dass sich die verfügbaren Daten immer weiter fortpflanzen, um möglichst viele Suchanfragen auch bedienen zu können [HKLM03a]. Abb. 2.1 zeigt, wie eine Datei (file2 ) von Peer A an Peer B übertragen wird; die- ser bewegt sich nun weg von Peer A in Reichweite von Peer C. Da dieser ebenfalls Interesse an file2 hat, bisher aber nicht in Reichweite von Peer A war, profitiert er von der Mobilität von Peer B, der die Datei von A nach C gebracht hat.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Peer B lädt sich Datei file2 herunter und bewegt sich dann in Reichweite von Peer C, der sofort auf file2 zugreifen kann.

2.2 Performance-Tests

Ein weiteres Ziel der Arbeit ist das ausführliche Testen der entwickelten Software auf mobilen Endgeräten. Hierbei sollen verschiedene Grenzen der aktuell verfügbaren Hardware erarbeitet werden:

- Bis zu welcher Entfernung können Teilnehmer miteinander kommunizieren? Wie groß dürfen evtl. im Weg befindliche Hindernisse sein?
- Funktioniert die Dateiübertragung auch bei sich bewegenden Endgeräten?
- Welche Übertragungsgeschwindigkeit wird erreicht und wodurch wird sie be- grenzt?
- Wie zuverlässig funktioniert die Kommunikation in Gegenwart vieler Teilneh- mer?
- Genügt der persistente Speicherplatz den Anforderungen?
- Batterielaufzeit während dauerhafter Kommunikation
- Benutzerfreundlichkeit der Mensch-Maschine-Schnittstelle

Zu diesem Zweck werden verschiedene Szenarien entworfen, die Aufschlüsse über die genannten Qualitätskriterien geben können.

In den Testumgebungen werden die Anzahl parallel arbeitender Clients, die zu Grun- de liegende Hardware, sowie andere Bereiche variieren, so dass schließlich eine Aus- sage getroffen werden kann, inwieweit mobiles MP3-Sharing machbar ist, welche Hürden bereits genommen sind und mit welchen Schwierigkeiten noch zu rechnen ist.

Außer den genannten technischen Grenzen gibt es noch weitere Probleme zu erkunden, zum Beispiel Anforderungen an den Datenschutz oder Urheberrechts-Ver- letzungen. Diese Themen sind jedoch nicht Teil der Arbeit und können an anderer Stelle nachgelesen werden [SFT02].

Kapitel 3 Grundlagen

In diesem Kapitel werden zunächst verschiedene Techniken, die in der Entwicklung des Prototypen verwendet wurden, näher erklärt. Die Erläuterungen sollen ein grundlegendes Verständnis der vorgestellten Technologien schaffen, um den Aufbau und Kontext des Programms besser verständlich zu machen.

3.1 IP-Netzwerke

Wie in Kapitel 4 näher erläutert werden wird, verwendet der Prototyp das betriebssystem-seitig verwaltete IP-Netzwerk. Daher soll hier eine kurze Einführung zur IP-Technologie gegeben werden.

Das Internet Protocol ist Teil des TCP/IP Protokoll-Stacks, einer Variante des OSI-Referenz-Modells. Abb. 3.1 vergleicht beide Modelle miteinander. Die einzel- nen Ebenen dienen der Kapselung von Daten zur Weiterverarbeitung in darüber- bzw. darunterliegenden Schichten. Hierzu fügt jede Schicht den von oben kommen- den (ausgehenden) Daten die schicht-spezifischen Protokolldaten hinzu bzw. entfernt den der darunterliegenden Schicht bei nach oben weiterzureichenden (eingehenden) Daten. Dieses Abstrahieren von anderen Schichten schafft klare Schnittstellen und trennt die durch die Ebenen angebotenen Dienste voneinander. [Tan96, S. 17]

Zu unterst liegt die Physikalische Schicht (Physical Layer ), hier werden die Da- ten als elektrische Signale übertragen. Darüber folgt die Datenübertragungs-Schicht

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Vergleich des OSI-Stacks mit dem des IP Modells

(Data Link Layer ), die im LAN zum Beispiel durch MAC 802.x¹ implementiert wird [IE802b]. Diese Schicht spaltet die Daten in einzelne Rahmen (Frames² ) und regelt den Zugriff auf das Medium, z.B. durch Kollisionsvermeidung und -erkennung. Die MAC-Adresse besteht aus zwölf Hexadezimal-Zahlen und ist i.A. den Netzwerkkar- ten fest zugeordnet.

Über dem Data Link Layer folgt die Netzwerk-Schicht (Network Layer), die Funk- tionen für Routing, Stauvermeidung und weitere Kontroll-Funktionen anbietet. Als Protokoll auf dieser Ebene ist u.a. das IP-Protokoll implementiert. IP-Adressen be- stehen aus vier Bytes, d.h. sie haben die Form 0.0.0.0 bis 255.255.255.255 (s. Abb.

3.2). Jede IP-Adresse wird durch das ihr zugehörige Subnetz maskiert, das angibt, welche anderen Adressen via IP-Broadcast von ihr erreicht werden können. Pakete an Adressen, die sich nicht im Subnetz des Absenders befinden, müssen geroutet, d.h. an andere Netze weitergeleitet werden. Hat zum Beispiel die Adresse 169.254.68.47 die Subnetz-Maske 255.255.0.0 (d.h. die ersten 16 Bit sind ’maskiert’),sobefinden sich alle Adressen, die mit169.254 beginnen im selben Subnetz und können direkt (d.h. mit nur einem Hop³ ) erreicht werden. Da der vorgestellte Prototyp via OneHop-Kommunikation interagieren soll, ist die Konfiguration des Clients im selben Subnetz grundlegende Voraussetzung.⁴

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Format eines IP-Paketes.

Die Netzwerk-Schicht wird abstrahiert durch die Transport-Schicht (Transport-Layer ), die die Daten von ’oben’ entgegennimmt, sie gegebenenfalls aufteilt und an die Netzwerk-Schicht weiterreicht. Hierfür haben sich zwei Protokolle etabliert: TCP (Transmission Control Protocol ) ist ein verbindungsorientiertes Protokoll, das für jede Kommunikation eine Verbindung aufbaut und mit Empfangsbestätigungen ar- beitet. Durch diese Techniken kann es Daten zuverlässig übermitteln, es kümmert sich selbst um evtl. notwendiges Wiederholen von Paketen. Allerdings hat es den Nachteil, durch diese Zuverlässigkeit viel Datenverkehr zusätzlich zur eigentlichen Nutzlast zu erzeugen. Das andere Protokoll, UDP (User Datagram Protocol ) ist ein verbindungsloses Protokoll, das von sich aus keine Dienste wie bspw. Emp- fangsbestätigungen anbietet - diese müssten falls erwünscht von der Anwendung selbst implementiert werden. UDP ist bzgl. Rechen- und Netzwerklast mit wenig zusätzlichem Aufwand behaftet, bietet aber auch keine Kontrolle, ob und in welcher Reihenfolge Pakete beim Empfänger ankommen.

Die höchste Ebene ist das Application-Layer. Im TCP/IP-Modell existiert kein Session- oder Presentation-Layer. Die Implementierung der Funktionen dieser Ebe- nen wurden, da selten benötigt, den Anwendungen überlassen. Im Application-Layer finden sich die durch die Anwendungen definierten Protokolle wieder, zum Beispiel DNS, Telnet, SMTP, FTP und HTTP. Der Prototyp verwendet auf dieser Ebene ein eigenes Protokoll, das in Kapitel 5.2 genau beschrieben wird.

3.1.1 IP Auto-Configuration

In lokalen Netzen werden Adressen aus für ’privateNetze’vorgesehenenAdressbe- reichen an die Rechner vergeben. Geschieht dies statisch, so wird einem Rechner eine IP-Adresse eingetragen, die er bis auf weiteres behält. Um diesen Vorgang zu automatisieren und um Adresskonflikte (d.h. zwei Rechner haben die selbe Adresse) zu vermeiden, wurde DHCP⁵ eingeführt. Für DHCP konfigurierte Clients senden auf MAC-Ebene ein Broadcast durch das angeschlossene Netz. Ein so erreichbarer DHCP-Server verwaltet die verfügbaren IP-Adressen und weist dem Client eine freie Adresse zu [Ale97].

Da in einigen - speziell in mobilen - Szenarien kaum mit einem verfügbaren DHCP- Server zu rechnen ist, gibt es eine weitere Technik, wie Clients eine IP-Adresse zugeordnet bekommen, ohne dass Konflikte entstehen: Bei dieser Auto-Configuration genannten Methode wählen sich die Clients zunächst zufällig eine Adresse aus dem Netz 169.254.0.0 (Subnetzmaske 255.255.0.0). Dann senden sie ein Broadcast an das Netz um herauszufinden, ob diese Adresse von einem erreichbaren Peer verwendet wird. Ist dies der Fall, so wählt der Client eine andere Adresse und beginnt den Vorgang erneut; ist die Adresse frei, so wird sie verwendet. Bei einem erneuten Start des Auto-Configuration-Vorgangs versucht der Client zunächst, die IP-Adresse, unter der er zuvor erreichbar war, wiederzuverwenden. Wird diese Adresse aber bereits von einem anderen Client verwendet, so muss eine neue gewählt werden [RFC3330].

In Microsoft-Betriebssystemen, die nach 1995 entwickelt wurden, muss der Netzwerkadapter zunächst auf DHCP gestellt werden. Bekommt er nach einer gewissen Zeit keine Adresse zugeordnet, so wählt er sich eine Adresse aus dem Subnetz 169.254.0.0/24 [APIPA].

Auto-Configuration wird auch im hier vorgestellten Prototypen verwendet, um alle Peers für ein gemeinsames IP-Subnetz zu konfigurieren. Eine andere Möglichkeit der Adressvergabe wäre die Vergabe statischer Adressen in einem vordefinierten Subnetz gewesen; dies würde aber zu Adresskonflikten führen, sobald zwei Peers mit gleicher statischer IP-Adresse in Reichweite sind. Auch die Verwendung von MulticastAdressen is nicht sinnvoll, da die Daten aus in Kapitel 4 erläuterten Gründen nicht geroutet werden sollen. Einige für Multicast konfigurierte Router jedoch würden, sobald ein Peer die vorgestellte Software am laufen hätte, die Multicast-Signale weiterleiten. Aus diesen Gründen bleibt die Auto-Configuration die für diese Software sinnvollste Methode zur Vergabe von IP-Adressen.

3.2 Wireless LAN

Als Wireless Local Area Networks (auch: Wireless LAN oder WLAN) werden Netz- werke bezeichnet, in welchen die Verbindung zwischen Sender und Empfänger kabel- los, d.h. über Funk geschaffen wird. Wie andere Arten von Netzwerk-Technologien (Ethernet, Token Ring. . . ) ist auch die WLAN-Technologie in der Netzwerk-Stan- dardisierung IEEE 802 definiert, dort zu finden in der Subkategorie 802.11 [IE802a]. Da innerhalb des 802.11-Standards weitere unterschiedliche Techniken existieren, werden auch hier Subkategorien gebildet, wie in Tab. 3.1 dargestellt. Die Reichweite eines WLAN-Gerätes hängt von der Leistung der Antenne ab. Mit mobilen Geräten, die meist PCMCIA-Karten⁶ verwenden, ist mit einer maximalen Reichweite von 50 bis 100 Metern zu rechnen, standortgebundene Geräte können leistungsfähiger sein [WLAN]. Das Haupt-Hemmnis von WLAN-Verbindungen stellen massive Hinder- nisse wie Mauern oder geografische Gegebenheiten dar. Bereits zwei Betondecken einer Dicke von jeweils 30cm zwischen den Geräten können einen Verbindungsver- lust bedingen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.1: Vergleich der 802.11 Standards

3.2.1 Netzwerkmodi

Grundsätzlich gibt es für WLAN-Geräte zwei Betriebsmodi: Den Infrastruktur- und den Ad-hoc-Modus (s. Abb. 3.3).

Im Infrastruktur-Modus (auch: Basic Service Set, BSS ) kommunizieren die Geräte über einen Zugangsknoten (Access Point). Jeglicher Datenverkehr im WLAN wird an diesen zentralen Knoten gesendet, um von dort aus an die Empfänger weitergeleitet zu werden: Die Kommunikation zwischen zwei Geräten im selben Netzwerk benötigt hier immer zwei Hops, nämlich vom Absender zum Access Point und vom Access Point zum Empfänger. Mögliche Reichweiten hängen daher ausschließlich von der Entfernung der Geräte vom Access Point ab, nicht jedoch von der Entfernung der Geräte untereinander. Auf diese Weise werden zwar mehr Netzwerkressourcen als bei direkter Kommunikation verwendet, die Clients müssen sich aber nicht um die Erreichbarkeit der anderen Geräte kümmern.

Der Ad-hoc-Modus (auch: Independent Basic Service Set, IBSS ) lässt die direkte (One-Hop) Kommunikation der Geräte untereinander zu, der jeweilige Kommunika- tionspartner muss daher in Reichweite des Absenders sein. Typischerweise werden Ad-hoc-Netzwerke verwendet, um eine geringe Anzahl von Geräten, die sich für begrenzte Zeit in geografischer Nähe befinden, miteinander zu verbinden. Der Ad- hoc-Modus ist zwingende Voraussetzung für mobile Netzwerke, da hier ohne Access Point kommuniziert werden muss.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3: Vergleich: Infrastruktur - Ad-hoc-Modus

3.2.2 802.11 Medium Access Control

Da zwei WLAN-Clients nicht gleichzeitig senden dürfen, wenn sie in Reichweite des anderen sind, muss die Erlaubnis zum Senden organisiert werden. Anders als z.B. bei Ethernet (IEEE 802.3) bestehen bei kabellosen Netzen grundsätzlich zwei Probleme (s. Abb. 3.4):

1. Hidden Node Problem: Node B ist in Reichweite von Node A und Node C. A und C sind jedoch außerhalb der Reichweite des jeweils anderen. Somit erhält Node A keinerlei Informationen darüber, ob C gerade sendet, das selbe gilt umgekehrt. Senden nun Nodes A und C gleichzeitig (da beide wissen, dass gerade kein anderes Gerät in ihrer Reichweite sendet), so empfängt Node B die Pakete beider Sender - bei Node B träten also Kollisionen auf, von denen die Absender so nichts mitbekommen.

2. Exposed Node Problem: Das Szenario ist ähnlich dem Hidden Node Problem. Außer den vorhandenen drei Nodes kommt noch ein Node D hinzu, der reich- weitenbedingt nur für C erreichbar ist. Während B Daten an A sendet kann C nicht mit D kommunizieren, obwohl dies keinerlei Kollisionen verursachen würde (da Node A außerhalb der Reichweite von C ist): Node C ist also der Kommunikation zwischen B und A ausgesetzt und wird von dieser am Senden gehindert, da er nicht senden darf, wenn ein anderes Gerät in seiner Umgebung sendet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.4: Probleme des WLAN - Medium Access Control

Während z.B. Ethernet (IEEE 802.3) Kollisionen erst im Nachhinein entdeckt und erneut sendet (CSMA/CD: Carrier Sense Multiple Access with Collision Detecti- on) verwendet WLAN CSMA/CA (Collision Avoidance). Diese Vermeidung von Kollisionen übernimmt die Distributed Collision Function (DCF): Der Sender muss zunächst eine Sende-Anfrage (Request-To-Send, RTS ) senden, auf die alle in Reich- weite befindlichen Geräte mit einer Bestätigung (Clear-To-Send, CTS ) antworten, falls sie das Netz freigeben. Der Empfänger eines RTS oder CTS-Signals stellt eige- nes Senden für eine im Network Allocation Vector (NAV) festgelegte Dauer ein. Der NAV ist ein in allen Nodes vorhandener Vektor von Timern, die durch bestimmte Empfangsereignisse ausgelöst werden und durch andere Empfangsereignisse vorzei- tig beendet werden können. In Abb. 3.5 ist dargestellt, dass der Transmitter erst eine DIFS (IFS = Inter-Frame-Space) genannte Zeit, in der keine andere Nachricht bei ihm eintreffen darf, warten muss, bevor er ein RTS abschickt. Das Empfangen des RTS löst die Blockade NAV(RTS) aus, während der der Node nicht senden darf. Nach einer Wartezeit SIFS (Short IFS ) sendet jeder Empfänger des RTS ein CTS, was NAV(CTS) auslöst. Der Transmitter wartet ein SIFS ab, um dann seine eigent- lichen Daten zu senden - NAV(DATA) wird ausgelöst. Die Empfänger der Daten senden abschließend nach einem SIFS ein Acknowledgement, dessen Empfang alle Timer des NAV beendet: Die Peers werden jetzt nicht mehr durch ihren NAV am Senden gehindert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.5: Kollisionsvermeidung durch DCF

Nicht zuletzt durch oben genannte Probleme stellt Wireless LAN erhöhte Anforderungen an Medium-Access-Methoden. Insbesondere MAC-Algorithmen für die Verwendung im Ad-hoc-Modus werden stetig weiterentwickelt, um die Effizienz bei der Netzauslastung zu erhöhen [BCG01].

3.3 Personal Digital Assistants

Die Hauptrepräsentanten der mobilen Geräte, für die der Prototyp vorgesehen ist, sind die sogenannten Pesonal Digital Assistants (PDAs). Hierbei handelt es sich um brieftaschengroße Rechner (daher auch Handheld Devices), deren Hauptfläche durch

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.6: Einer der in den Tests verwendeten PDAs: Compaq h3870

eine berührungssensitive Anzeige (Touchscreen) eingenommen wird. Diese Anzeige stellt die Interaktionsmöglichkeiten dar, die der Anwender mittels eines Stabes ausführen kann (s. Abb. 3.6). Einige Tasten am Rand des Gehäuses vereinfachen die Bedienung durch Direktzugriffe, echte Tastaturen sind eher die Ausnahme. Zur Texteingabe wird eine Tastatur auf der Anzeige eingeblendet oder eine Handschrifterkennung verwendet [Wik04c].

Die ursprünglich angedachten Verwendungen der Geräte waren Adressbuch, Ter- minplaner, Notizblock, Aufgabenplaner und Taschenrechner, inzwischen gehen die Möglichkeiten der Geräte jedoch weit darüber hinaus: Navigationssysteme, Kameras oder das Abspielen von Musik gehören schon jetzt zu den verbreiteten Anwendung- en von PDAs. Auch die Kommunikations-Schnittstellen werden immer vielfältiger: neben den üblichen Anschlüssen via serieller Schnittstelle (RS232) oder USB sind auch immer häufiger drahtlose Kommunikationsmölichkeiten wie Bluetooth [BT], Infrarot oder Wireless LAN verfügbar.

Die geringe Größe der Geräte in Verbindung mit relativ hoher Rechenleistung und drahtloser Kommunikation ist es, die solche Geräte für die hier besprochene Anwen- dung interessant macht. Der PDA kann in der Jackentasche transportiert werden und über die Wireless-LAN-Schnittstelle Kontakt zu anderen Geräten aufnehmen. Idea- le Voraussetzungen also, um Kommunikation ohne Benutzereingriff zu ermöglichen. Die übertragenen Daten können im integrierten Speicher gelagert werden, außer- dem erfreuen sich Wechselmedien wie CompactFlash [CF] und SmartMedia [SM].

[...]

---

¹ Vgl. Kapitel 3.3.

² Vgl. Kapitel 3.4.

³ Vgl. Kap. 3.3.

⁴ Vgl. Kap. 3.4.

⁵ FastTrack ist ein Netzwerk, das von verschiedenen Implementierungen (KaZaA, Grokster, Neo) genutzt wird. Vgl. [FT].

⁶ Vgl. [MANET].

¹ MAC: (engl.) Medium Access Control, ’Medien-Zugangs-Kontrolle’.DerStandardIEEE 802 .x definiert die Technologie verschiedener Netzwerkarten, z.B. Ethernet, Token Ring oder Wireless- LAN.

² Frames sind Folgen einiger hundert oder tausend Bits, die durch das Data Link Layer aus den Nutzdaten generiert werden. Da die Physikalische Schicht nur mit binär kodierten Signalen arbeitet wird den Daten durch Rahmen eine erste Struktur gegeben.

³ Als Hop wird das Senden eines IP-Paketes von einem Netzwerk-Interface zum nächsten be- zeichnet.

⁴ Vgl. Kap. 4.

⁵ DHCP: Dynamic Host Configuration Protocol

⁶ PCMCIA: Personal Computer Memory Card International Association. Vgl. [PCMCIA].