Endbericht
PG466
Beyond KaZaA: Peer-to-Peer Systeme für mobile Endgeräte mit
Bluetooth und UMTS Technologie
INHALTSVERZEICHNIS INHALTSVERZEICHNIS
Inhaltsverzeichnis
1 Teilnehmer 1
2 Motivation und Zielanpassung 1
2.1 Motivation und erste Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2 Revision der Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.3 Weiterführende Ziele im zweiten Semester . . . . . . . . . . . . . . . . . . . . . . . . 2
3 Installation und Benutzungsanleitung 3
3.1 Installation auf einem mobilen Endgerät . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Installation auf dem Desktop-PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3 Benutzungsanleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3.1 Programm starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3.2 Das Hauptmenü . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3.3 Dateien freigeben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.4 Dateien suchen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.5 Dateien downloaden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.6 Verschiedenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Grundlagen 6
4.1 Grundlagen des P2P-Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Java 2 Micro Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.1 Baseband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.2 L2CAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.3 L2CAP Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.4 Applikationen mit Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4 JSR 82 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5 Tree Scatternet Formation Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5.1 Piconetze & Scatternetze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5.2 TSF: Tree Scatternet Formation . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6 Bluetooth Tree Routing Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6.1 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5 Ablauf der Projektgruppe 17
5.1 Seminarphase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Programmiertest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3 Design Prozess gemäßUML/RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.2 Rational Unified Process (RUP) mit Unified Modelling Language (UML) . . . . 17
5.4 Konventionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.5 Programmdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.6 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.7 Test und Fehlerbehebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.8 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6 Ergebnisse, 1. Semester 21
6.1 Generelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2 Anwendungsebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3 Netzwerkebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
I
INHALTSVERZEICHNIS INHALTSVERZEICHNIS
7 Ergebnisse, 2. Semester 25
7.1 Implementierung des TSF Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2 Adaption des BTR Protokolls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.3 Adaption an den Scatternetzalgorithmus . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.4 Backup-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.5 Erweiterte Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.5.1 ID3-Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.5.2 Upload-Prioritäten und Credit-System. . . . . . . . . . . . . . . . . . . . . . . 27
7.6 BBH-LightTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8 Leistungsmessungen 29
8.1 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1.1 Freigabe von Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1.2 Suche von Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1.3 Download von Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1.4 Resume von Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1.5 Tree Scatternet Formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9 Diagrammbeschreibungen, 1. Semester 31
9.1 Anwendungsfalldiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.2 Aktivitätsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.2.1 Suchanfrage erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.2.2 Download starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.2.3 Auf Suchanfrage Reagieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.2.4 Auf DownloadAnfragen reagieren . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.2.5 Verbindung aufbauen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.2.6 Verbindung aufrechterhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.3 Problembereichsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.4 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.4.1 Klassendiagrammbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.4.2 Klassenbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.5 Sequenzdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.5.1 Suchanfrage erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.5.2 Download starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.5.3 Auf Suchanfrage Reagieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.5.4 StartApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.5.5 Auf DownloadAnfragen reagieren . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.5.6 Auf DownloadAnforderung reagieren . . . . . . . . . . . . . . . . . . . . . . . 40
10 Diagrammbeschreibungen, 2. Semester 41
10.1 Aktivitätsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.1.1 Baumknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.1.2 Fehlerbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.1.3 Freierknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.1.4 Koordinatorknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.1.5 Routingaenderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
10.1.6 Wurzelknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
10.2 Sequenzdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
10.2.1 Bäume durch Wurzel vereinigen . . . . . . . . . . . . . . . . . . . . . . . . . 42
10.2.2 Bäume vereinigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.2.3 Freier Knoten integrieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.2.4 Piconetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.2.5 Routing von BBH-Paketen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.2.6 Verbindungstrennung abfangen . . . . . . . . . . . . . . . . . . . . . . . . . . 44
II
INHALTSVERZEICHNIS INHALTSVERZEICHNIS
11 Anhang A - Tests und Fehlerbehebung 46
11.1 1. Semester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
11.1.1 Dateien freigeben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
11.1.2 Dateien sperren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
11.1.3 Freigegebene Dateien auflisten . . . . . . . . . . . . . . . . . . . . . . . . . . 46
11.1.4 Eine Datei austauschen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
11.1.5 Mehrere Dateien austauschen . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
11.1.6 Dateien suchen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11.1.7 Dateien als Download auswählen . . . . . . . . . . . . . . . . . . . . . . . . . 48
11.1.8 Download starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11.1.9 Download resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11.1.10Download abbrechen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11.1.11Download anhalten/pause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11.1.12Upload einsehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11.1.13Upload abbrechen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11.1.14Fallback aktivieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11.1.15Persistenz prüfen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11.1.16Spezialfall: Es dürfen keine ”leeren” Suchantworten geschickt werden . . . . . . 51
11.1.17Spezialfall: Mehrere Peers haben gesuchte Datei. Kommunikation und Aktuali-
sierung zwischen DLManager und ULManagern. (Downloadabbruch selbststän-
dig senden) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11.1.18Spezialfall: DownloadAntwort oder SuchAntwort trifft nach Ablaufen des Timers
ein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.1.19Spezialfall: Das Überschütten des Netzwerkes mit vielen, gleichzeitigen Suchan-
fragen (Stabilitätstest) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.1.20Spezialfall: Downloadwunsch einer Datei, für die nicht mehr genügend Speicher-
platz zur Verfügung steht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.1.21Spezialfall: Start eines Downloads für den keine Quellen zur Verfügung stehen . 53
11.2 2. Semester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.2.1 Verbindung zweier Freierknoten. . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.2.2 Anschluss einer Freierknoten am vorhandenen Baum . . . . . . . . . . . . . . 53
11.2.3 Verschmelzung zweier unabhängigen Bäume. . . . . . . . . . . . . . . . . . . 54
11.2.4 Wiederanschluss der selben Knoten (BK, KK, WK) am vorhandenen Baum nach
Verlassen (Programm) des Netzes . . . . . . . . . . . . . . . . . . . . . . . . 54
11.2.5 Nach Verbindungsabbruch (Wurzelknoten) freigewordene Knoten schließen sich
wieder an . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
11.2.6 Nach Verbindungsabbruch (Koordinatorknoten) freigewordene Knoten schließen
sich wieder an . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
11.2.7 Verschmelzung nach Verbindungsabbruch zweier unabhängig gewordene Bäume 54
11.2.8 Suche/Download über mehrere Hops . . . . . . . . . . . . . . . . . . . . . . . 55
11.2.9 Resume über mehrere Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.2.10Gleichzeitige Downloads über Brigde-Geräte . . . . . . . . . . . . . . . . . . . 55
11.2.11Gleichzeitige Downloads (=2) über Brigde-Geräte (Große Dateien). Geräte fun-
gieren als Sender und Empfänger . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.2.12Gleichzeitige Downloads(>2) über die Wurzel (Große Dateien). Geräte können
als Sender und Empfänger fungieren . . . . . . . . . . . . . . . . . . . . . . . 55
11.2.13Download von einer entfernten Quelle, die das Scatternetz plötzlich verlässt. . 56
11.2.14AND-Suche nach 1 Keyword / Groß/ Kleinschreibung / Gemischt . . . . . . . 56
11.2.15AND-Suche nach 3 Keywords / Groß/ Kleinschreibung / Gemischt . . . . . . . 56
11.2.16AND-Suche nach 1 Keyword (Substring Anfang vom ersten Wort) / Groß/
Kleinschreibung / Gemischt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
11.2.17AND-Suche nach 1 Keyword (Substring mitten im Wort) / Groß/ Kleinschrei-
bung / Gemischt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
III
INHALTSVERZEICHNIS INHALTSVERZEICHNIS
11.2.18AND-Suche nach 3 Keywords (Substring Anfang vom ersten Wort) / Groß/
Kleinschreibung / Gemischt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
11.2.19AND-Suche nach 3 Keywords (Substring mitten im Wort) / Groß/ Kleinschrei-
bung / Gemischt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
11.2.20OR-Suche nach 1 Keyword / Groß/ Kleinschreibung / Gemischt . . . . . . . . 57
11.2.21AND-Suche nach 3 Keywords / Groß/ Kleinschreibung / Gemischt . . . . . . . 57
11.2.22OR-Suche nach 1 Keyword (Substring Anfang vom ersten Wort) / Groß/ Klein-
schreibung / Gemischt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.2.23OR-Suche nach 1 Keyword (Substring mitten im Wort) / Groß/ Kleinschreibung
/ Gemischt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.2.24OR-Suche nach 3 Keywords (Substring Anfang vom ersten Wort) / Groß/ Klein-
schreibung / Gemischt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.2.25OR-Suche nach 3 Keywords (Substring mitten im Wort), Groß-/Kleinschreibung,
gemischt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.2.26Gutschrift von Credits beim Uplaod . . . . . . . . . . . . . . . . . . . . . . . 57
11.2.27Sortierung der Warteliste nach Credits . . . . . . . . . . . . . . . . . . . . . . 58
11.2.28Uploadpriorität vergeben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
11.2.29Auslesen von Keywords aus ID3-Tags . . . . . . . . . . . . . . . . . . . . . . . 58
12 Anhang B1 - Diagramme, 1. Semester 59
12.1 Anwendungsfalldiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
12.2 Aktivitätsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.2.1 Suchanfrage Erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.2.2 Download Starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12.2.3 Auf Suchanfrage Reagieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
12.2.4 Auf Downloadanfrage Reagieren . . . . . . . . . . . . . . . . . . . . . . . . . 63
12.2.5 Verbindung Aufbauen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
12.2.6 Verbindung Aufrechterhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
12.3 Sequenzdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
12.3.1 Suchanfrage Erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
12.3.2 Download Starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
12.3.3 Auf Suchanfrage Reagieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
12.3.4 StarteApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
12.3.5 Auf Downloadanfragen Reagieren . . . . . . . . . . . . . . . . . . . . . . . . . 70
12.3.6 Auf Downloadanforderungen reagieren . . . . . . . . . . . . . . . . . . . . . . 71
13 Anhang B2 - Diagramme, 2. Semester 72
13.1 Aktivitätsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
13.1.1 Baumknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
13.1.2 Fehlerbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
13.1.3 Freierknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
13.1.4 Koordinatorknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
13.1.5 Master-Slave-Entscheidung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
13.1.6 Routingaenderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
13.1.7 Wurzelknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
13.2 Sequenzdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
13.2.1 2 Bäume durch Wurzel vereinigen (aktiv) . . . . . . . . . . . . . . . . . . . . 79
13.2.2 2 Bäume durch Wurzel vereinigen (passiv) . . . . . . . . . . . . . . . . . . . . 80
13.2.3 2 Bäume vereinigen (Koordinator) . . . . . . . . . . . . . . . . . . . . . . . . 81
13.2.4 Freien Knoten integrieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
13.2.5 Piconetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
13.2.6 Routing von BBH-Paketen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
13.2.7 Verbindungstrennung abfangen . . . . . . . . . . . . . . . . . . . . . . . . . . 85
IV
ABBILDUNGSVERZEICHNIS ABBILDUNGSVERZEICHNIS
14 Anhang B3 - Klassendiagramm 86
15 Anhang C - Literaturverzeichnis 87
Abbildungsverzeichnis
1 Schreibrechte müssen gewährt werden . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Anwedungsfalldiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3 Suchanfrage erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4 Download starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5 Auf Suchanfrage reagieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6 Auf Downloadanfrage reagieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7 Verbindung aufbauen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8 Verbindung aufrechterhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9 Suchanfrage erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
10 Download starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
11 Auf Suchanfrage reagieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
12 Applikation starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
13 Auf Downloadanfrage reagieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
14 Auf Downloadanforderung reagieren . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
15 Baumknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
16 Fehlerbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
17 Freierknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
18 Koordinatorknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
19 Master-Slave-Entscheidung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
20 Routingänderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
21 Wurzelknoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
22 Zwei Bäume durch Wurzel vereinigen, aktiv . . . . . . . . . . . . . . . . . . . . . . . 79
23 Zwei Bäume durch Wurzel vereinigen, passiv . . . . . . . . . . . . . . . . . . . . . . . 80
24 Zwei Bäume vereinigen, Koordinator . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
25 Freien Knoten integrieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
26 Piconetz aufbauen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
27 Routing von BBH-Paketen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
28 Verbindungstrennung abfangen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
29 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
V
2 MOTIVATION UND ZIELANPASSUNG
1 Teilnehmer
Betreuer: Prof. Dr.-Ing. Christoph Lindemann, Dipl. Inform. Christian Lambert, Dipl. Inform. Oliver
Waldhorst
Studenten: Nabil Ben Said, Chris Börgermann, Michael Diel, Carmen Göbel, Gregor Kasmann, Boris
Kißner, Nicolas Krokowski, Paul Leikam, Sebastian Prost, Alain Tigyo, David Zok
2 Motivation und Zielanpassung
2.1 Motivation und erste Zielsetzung
Immer mehr mobile Geräte verfügen heutzutage über Bluetooth. Bluetooth operiert im lizenzfreien
ISM1-Band, deshalb ist die Benutzung kostenfrei. Obwohl Bluetooth nur eine Reichweite von zehn2
Metern besitzt, ist es in der Lage, bis zu acht Geräte in einem Netzwerk zu verbinden. Dadurch, dass
einzelne Netzwerke zu größeren Scatternetzen zusammengeschlossen werden können, steigert sich die
Reichweite und die Kapazität.
Peer-to-Peer (P2P) Filesharing Programme haben sich auf breiter Basis durchgesetzt, weil sie die
epidemieartige Verbreitung von beliebten Dateien einfach erlauben. Programme wie KaZaA, eDonkey
o. Ä. kennt jeder, der öfters Dateien über das Internet austauscht.
Wie wäre es also, wenn man diese beiden Technologien miteinander verschmelzen würde?
Genau das ist die Motivation dieser Projektgruppe. Ziel ist es, ein Programm zu entwickeln, das auf
mobilen Endgeräten (sprich Handys) laufen kann und es erlaubt, Dateien auszutauschen. Dazu muss
das Programm eine Reihe von Funktionen unterstützen, die sich aus dieser Zielbeschreibung zwangsläu-
fig ergeben: angefangen von der Möglichkeit, Dateien auf dem festen Speicher des Endgerätes selektiv
freizugeben, über eine intelligente Suchfunktion bis hin zu einer effizienten Ausnutzung der vorhanden
Technologie im Hinblick auf Zeit und Datenraten.
Bluetooth-Netzwerke unterstützen höchstens acht aktive Endgeräte und sind deshalb per se eigentlich
ungeeignet für eine Filesharing-Applikation. BT bietet jedoch die Möglichkeit, mehrere dieser Piconetze
zu verbinden und damit ein sogenanntes Scatternetz zu erzeugen. Die Algorithmen, die dabei verwendet
werden, genauso wie Algorithmen zur effizienten Verbreitung von Informationen (Dateien im Netzwerk)
waren ebenso Ziele der PG. Im Falle der Scatternetz-Algorithmen sollte der ns2-Netzwerksimulator zum
Einsatz kommen.
2.2 Revision der Ziele
Nach der Seminarphase wurden die ersten der folgenden Sitzungen dazu verwendet, die Möglichkeiten
und angestrebten Features des finalen Produktes zu konkretisieren. Der generelle Konsens war dabei
ein P2P-Filesharing-Programm zu entwickelt, welches auf normalen Mobiltelefonen ausgeführt werden
sollte. Ferner war zunächst festgelegt, dieses in Java3 zu programmieren. Das Programm sollte folgende
Funktionen haben bzw. unterstützten:
• Austausch von Dateien beliebigen Typs und Länge durch eine graphische Oberfläche
• Vernetzen von mehr als acht Endgeräten in einem großen P2P-Netz
• Suche von Dateien innerhalb des Supernetzes (Scatternetzes) an Hand von Schlüsselworten
1 Industrial Scientific Medical: 2,4000 - 2,4835 GHz mit 2 MHz lower bound und 3,5 MHz upper bound Sicherheits-
grenzen (Frequenzangabe spezifisch für Deutschland, andere Länder haben unter Umständen eine kleinere Bandbreite).
2 Neuere BT-Versionen verfügen über eine größere Reichweite (bis zu 100 Metern).
3 Es wurde für kurze Zeit überlegt, in C++ für Symbian zu programmieren (siehe 5.3, S.17 und 6, S.21), am Ende
dann aber doch wieder zu Java zurückgekehrt.
1
2.3 Weiterführende Ziele im zweiten Semester 2 MOTIVATION UND ZIELANPASSUNG
• Die Möglichkeit, nach einer erfolglosen Suche auf einen persistenten (und kostenpflichtigen)
Server im Internet zuzugreifen, um die gewünschten Dateien von dort zu beziehen
Im Verlauf der Projektgruppe und nach tiefgehender Evaluation der zur Verfügung stehenden APIs und
weiterführenden Materialen, mussten die Ziele leicht angepasst werden (siehe 5.3, S.17 und 5.6, S.19).
Aufgrund der Kapselung der Bluetooth Verbindungsprozesse durch acceptAndOpen() war es nicht
möglich, direkten Einfluss auf die Formierung von Pico- und Scatternetzen zu nehmen (siehe auch 6,
S.21). Daraus folgte natürlich die (vorläufige) Unerfüllbarkeit eines der ursprünglichen Ziele, in dem
eine Optimierung der Verbindungsprozesse gefordert war (effizienter Aufbau und Verwaltung von Scat-
ternetzen, Scheduling mit ns2-Netzwerksimulator).
Die neue Zielsetzung forderte als Mindestziele für das erste Semester Folgendes:
• Ein lauffähiges Programm
• Die Erfüllung aller unter 2.2 aufgeführten Ziele
• Das Erstellen eines Zwischenberichtes
2.3 Weiterführende Ziele im zweiten Semester
Im zweiten Semester wurden Ziele aufgestellt, die teilweise den Abschluss bereits begonnener Arbeit
beinhalteten, wie auch völlig neue, der PG-Beschreibung zuträgliche. Die endgültigen Ziele im zweiten
Semesters waren wie folgt:
• Implementierung eines Scatternetz-Algorithmus auf logischer Ebene (wg. API)
• Fertigstellung des Backup-Servers
• Verbesserte Suche und das Auslesen von ID3-Tags bei bestimmten Dateien
• Entwicklung eines abgespeckten Programmes, zum Testen auf realen End-geräten
• Erstellen eines Endberichts
2
3 INSTALLATION UND BENUTZUNGSANLEITUNG
3 Installation und Benutzungsanleitung
3.1 Installation auf einem mobilen Endgerät
Um Blue Brewery Horse (BBH) auf einem mobilen Endgerät zu installieren, müssen lediglich entweder
die „Programme.jad“ oder die „Programm.jar“ (vom Endgerät abhängig) auf das Gerät kopiert werden.
Gestartet wird es dann durch einen einfachen Aufruf.
3.2 Installation auf dem Desktop-PC
Das Programm besteht aus zwei Dateien, „Programm.jad“ und „Programm.jar“. Folgende Schritte
müssen ausgeführt werden, damit das Programm auf einem Rechner mit WTK 2.2 installiert und
getestet werden kann:
1. Folgende Einstellungen im WTK vornehmen: CLDC 1.1, JSR 135 (120), JSR 75 und JSR 82
aktivieren
2. Dateien in ein beliebiges Verzeichnis kopieren
3. In das [WTK]/bin/-Verzeichnis wechseln
4. „runmidlet” aufrufen
5. In dem nun folgenden Dialog, die Datei „Programm.jad” wählen
6. Prozess kann zum Simulieren weiterer Geräte iteriert werden.
Das root-Verzeichnis der simulierten Geräte ist dann „WTK\AppDB\...”.
3.3 Benutzungsanleitung
3.3.1 Programm starten
Bevor das Programm benutzt werden kann, wird abgefragt, ob ihm verschiedene Rechte zugestanden
werden sollen (Siehe Abb. 1, Seite 4). Diese Abfragen müssen unbedingt mit „Ja“ beantwortet werden,
da sonst das Programm nicht richtig funktioniert. Drücken Sie einfach auf den entsprechenden Knopf.
Jetzt sehen Sie den Splash-Bildschirm, von dem aus sie mit einem Druck auf „Done“ ins Hauptmenü
kommen können.
3.3.2 Das Hauptmenü
Das Hauptmenü ist unterteilt in sieben Menüpunkte:
3
3.3 Benutzungsanleitung 3 INSTALLATION UND BENUTZUNGSANLEITUNG
Abbildung 1: Schreibrechte müssen gewährt werden
Freigabeliste anzeigen Zeigt die Freigabeliste an, in der alle Dateien enthalten sind,
die für den Upload freigegeben sind. Dateien, die durch das Pro-
gramm heruntergeladen wurden, werden automatisch freigegeben
und damit dieser Liste hinzugefügt.
Dateien freigeben Erlaubt es, den Speicher des Endgerätes zu durchsuchen und
Dateien zu markieren, die zum Upload freigegeben werden sollen.
Suchen Dient dazu, das Netz nach Dateien zu durchsuchen. Für die Suche
können Wörter und- oder oder-verknüpft werden. MP3-Dateien
werden zusätzlich nach ihren ID3-Tags durchsucht.
Download Hier werden alle momentan laufenden Downloads angezeigt. In
dieses Untermenü muss man auch wechseln, wenn man einen
Download starten möchte, der nicht direkt mit „Download direkt
starten“ begonnen wurde. Downloads können hier angehalten,
fortgesetzt und auch beendet werden.
Upload Zeigt an, welche Dateien im Augenblick an andere Teilnehmer
verschickt werden. Hier kann man auch einzelne Uploads abbre-
chen.
Geraete Listet alle verbundenen Geräte in Reichweite auf und zeigt Infor-
mationen für den TSF-Algorithmus an.
Optionen Ausser diversen Debug-Funktionen kann hier die TTL4-Zeit für
Suchen angegeben werden. Der Standardwert wurde so gewählt,
wie es sich in der Praxis am sinnvollsten erwiesen hat.
4
3.3 Benutzungsanleitung 3 INSTALLATION UND BENUTZUNGSANLEITUNG
3.3.3 Dateien freigeben
Navigieren Sie mit Hilfe des eingebauten Browsers durch Ihr Filesystem und geben Sie Dateien frei,
indem Sie in „Menü“ „Freigeben“ wählen. Entsprechend heben Sie die Freigabe auch wieder auf. Zu-
sätzlich können Sie sich eine Vorschau verschiedener Dateien anzeigen lassen5.
3.3.4 Dateien suchen
Starten Sie eine neue Suche und geben Sie den Suchbegriff ein (standardmäßig verodert) und wählen
Sie „Start“. Die Suche startet nun in einem Broadcast und liefert entsprechende Ergebnisse zurück.
3.3.5 Dateien downloaden
Wenn wenigstens ein Such-Ergebnis gefunden wurde (erkennbar an einer „(1)“ hinter der Suche), kön-
nen Sie anfangen, eine Datei herunterzuladen. Selektieren Sie dafür die entsprechende Datei und wählen
Sie entweder „Zu Downloadliste hinzufügen“, wenn Sie den Download ersteinmal nur vormerken wollen
oder „Download sofort starten“, wenn Sie den Download sofort starten wollen.
Wurde der Download ersteinmal nur vorgemerkt, müssen Sie im Hauptmenü im Untermenü „Dow-
nloads“ die entsprechende Datei wählen und „Download beginnen“ auswählen.
3.3.6 Verschiedenes
Bei „Optionen“ haben Sie die Möglichkeit einzustellen, wie lange eine Suchanfrage dauern kann. Je höher
die Zahl, desto länger wird auf Ergebnisse gewartet. Das ist insbesondere sinnvoll in größeren Netzen,
wo eine Suchantwort viele verschiedene Geräte überspringen muss. In kleineren Netzen empfiehlt es
sich dagegen, einen niedrigen Wert zu wählen.
5 von Dateityp abhängig
5
4 GRUNDLAGEN
4 Grundlagen
4.1 Grundlagen des P2P-Computing
Unter Peer-to-Peer versteht man die direkte, bilaterale Kommunikation zwischen zwei oder mehreren
gleichberechtigten Partnern (Peers), die alle gleichwertige Fähigkeiten und Verantwortlichkeiten haben.
Im Gegensatz zur klassischen Client/Server-Struktur, besteht bei P2P-Strukturen ein völlig dezentral
gehaltenes Konzept wo es keine Rollenverteilung gibt. Die Peers teilen sich somit gegenseitig Ressour-
cen (Dateien, CPU-Zeiten, Speicherkapazität, etc.) und agieren dabei sowohl als Dienstbereitsteller als
auch als Dienstnutzer.
Das Ziel des P2P-Computing ist es meist, in einem Netz auf mehreren Peers verteilte Ressourcen
aufzufinden und gemeinsam zu nutzen. Dabei wird der Zugriff auf diese Ressourcen vom Benutzer des
jeweiligen Peers autorisiert. Peer-to-Peer-Netze sind völlig dezentral. Es besteht direkte Verbindungen
zwischen den Teilnehmern und auf jegliche Zentralinstanz wird verzichtet. Die Teilnehmer (Peers) kön-
nen gleichzeitig als Server und Client fungieren. Peer-to-Peer-Netze nutzen freie Ressourcen. Jeder Peer
weist vergeudete freie Ressourcen auf, die dadurch effizient ausgenutzt werden können.
P2P-Netze weisen verschiedene Architekturmodelle auf, unter anderem eine hybride Struktur, die die
Vorteile der Client/Server und der dezentralen P2P-Struktur miteinander vereinen. Anfragen werden
an einem zentralen Server gestellt, der andere Peers im Netzwerk dem suchenden Peer zu Verfügung
stellt. Dieser baut anschliessend eine direkte Verbindung zu den jeweiligen Knoten auf. Hauptnachteil
bei dieser Struktur ist der Single-Point-Of-Failure. P2P Systeme können auch dezentraler Natur sein,
wobei auf zentrale Instanzen komplett verzichtet wird. Die Peers agieren gleichzeitig (Servents) und fin-
den dynamisch andere verbundene Peers. Wegen der Unabhängigkeit der Knoten ist das Netzwerk sehr
robust. Dem hierarchischen Modell entsprechen P2P in SuperPeer Netzen. SuperPeers verwalten den
globalen Index, wobei jeder SuperPeer als Zentralserver für eine bestimmte Gruppe von Peers (Cluster)
fungiert. Die Folge: Effiziente Suche innerhalb von Clustern, Dynamische Koordinierung, Kontrollierung
des Netzes und Lastverteilung durch SuperPeers.
Zu den Anwendungsgebieten zählt das bekannteste Beispiel des Distributed Computing: SETI@home.
Hierbei beteiligen sich mittlerweile mehr als 4,5 Millionen Peers, die die Daten eines Radio-Teleskops in
Arecibo, Puerto Rico, nach Zeichen außerirdischen Lebens untersuchen. Dagegen sind die Anwendun-
gen bei Collaborativ Computing event-basiert und reichen vom Instant Messaging über Online-Games
bis hin zu Groupware (Groove). Die wesentliche Herausforderung an P2P-Systeme, die Collaborative
Computing unterstützen, ist die Echtzeitübertragung von Daten, wo große Verzögerungen im Inter-
net auftauchen, einige Funktionen beschränken und die Aktualisierungs-Dauer vom Peer bestimmen
(Multiplayer-Spielen).
Die populärste Anwendung bei P2P-Systemen bleiben jedoch das FileSharing, in dem die bekannteste
Programmen wie Napster, Gnutella oder KaZaA in den letzten Jahren stark an Bedeutung gewonnen
haben. Napster basiert auf einer hybriden Peer-to-Peer-Struktur. Das Netz besteht aus einem oder
mehreren zentralen Discovery Servern, die ein Indexverzeichnis der angebotenen Dateien beinhalten.
Die Peers suchen Dateien durch den Server und erhalten dann eine Ergebnisliste inklusive IP-Adresse
und Port der Knoten, die die gewünschte(n) Datei(en) gespeichert haben. Der Download erfolgt nach
direkter Verbindung mittels HTTP-Protokoll.
Gnutella basiert auf einem reinen unstrukturierten P2P-Netzwerk. Die Datei-en liegen verstreut über
das ganze Netz, wobei Dateien eines Peers nur diesem bekannt sind, und so eine gewisse Autonomie
gewährleistet ist. Die Peers stehen alle auf der gleichen Ebene und erledigen dieselben Aufgaben: Res-
sourcen zu Verfügung stellen und in Anspruch nehmen, Suchanfragen weiterleiten (Router), aussenden
und beantworten. Das Protokoll basiert auf fünf verschiedenen Verwaltungspakettypen (Ping, Pong,
Query, QueryHit, Push). Nach erfolgreicher Suche wird die direkte Verbindung per HTTP-Protokoll zu
einem geeigneten Rechner aufgebaut und die Datei herunter geladen. Gnutella hat schließlich wegen
6
4.1 Grundlagen des P2P-Computing 4 GRUNDLAGEN
seiner Einfachheit und Unabhängigkeit von zentralen Instanzen relativ viel Interesse gewonnen. Dabei
weist dieses Protokoll jedoch ein Paar Lücken auf: Ressourcen, die sich hinter dem Horizont von sieben
Hops (standardmäßig) befinden, können nicht erreicht werden. Das System skaliert nicht gut, da die
Anzahl der gebroadcasteten Anfragen und mögliche Antworten exponentiell mit jedem Hop wächst,
was zu einem starken Netzverkehr führt.
KaZaA ist im Gegensatz zu Gnutella kein Protokoll sondern ein Filesharingsoftware der FastTrack
Protokoll-Familie. Die Struktur des KaZaA-Netz weist ein hierarchisches Konzept auf und bewegt sich
im serverbasierenden und serverlosen Bereich, indem sie Aspekte des Gnutella Netzes mit einer flexiblen
zentralen Struktur von SuperPeers verbindet. Nach erfolgreicher Suchanfrage werden die IP-Adressen
der jeweiligen Fundstellen an den Peer geleitet. Die interne Kommunikation findet dann zwischen den
Teilnehmern verschlüsselt statt, und der Download per HTTP-Protokoll. Das KaZaA-Netz ist sehr lei-
stungsfähig und eignet sich gut für alle Dateitypen. Einziger Nachteil ist die Bereitstellung möglicher
SuperPeers.
Die Suche und das Routing bei P2P-Netzen lässt sich in zwei Kategorien unterteilen: Man unterscheidet
zwischen der Suche in unstrukturierten Systemen und der in strukturierten. In unstrukturierten Syste-
men kann die Suche mit oder ohne Routing-Indizes erfolgen. Bei der erste Methode wird das Fluten
des Netzwerks durch einen TTL-Wert eingeschränkt, was sich als ineffizient erweisen kann, weil vor-
handene Dateien womöglich nicht gefunden werden. Iterative Deeping umgeht das Problem indem bei
erfolgloser Suche der TTL-Wert erhöht wird. Die Last bei der Suche kann auch reduziert werden durch
Bewertung von Nachbarknoten oder Neustrukturierung der Narbarschaft. Knoten mit bester Bewer-
tung oder gemeisamen Interessen können schnell besucht werden. Lokale Indizes können dazu dienen,
Anfragen gezielt zu senden, wobei die Schwierigkeit bei dieser Methode ist, sicherzustellen, dass die
lokalen Indizes beim Verlassen oder Hinzukommen von Peers aktualisiert werden. Unter der Suche mit
Routing Indizes stehen verschiedene Methoden wie Compound Routing Indizes (Dokumenten werden
Kategorien zugeordnet), Hop Count Routing Indizes (Gewichtung der Entfernung zu Ressourcen einer
bestimmten Kategorie), Chord und CAN.
Chord realisiert eine konsistente, verteilte Hashfunktion, die die gleichmäßige Verteilung von Informatio-
nen über alle teilnehmenden Knoten ermöglicht. Jeder Knoten und jede Ressource im Chord-Netzwerk
ist mit einem eindeutigen m-bit Identifier auf einem Chord-Ring einer Größe angeordnet, die durch eine
konsistente Hashfunktion errechnet wird. Dabei muss m so gewählt sein, dass verhindert wird, dass zwei
Knoten auf denselben Schlüssel gehasht werden (bzw. die Wahrscheinlichkeit sehr gering ist). Chord
sieht zwei Arten von Routing vor:
• Einfaches Routing: Dabei wird durch einfaches Verfolgen der successor-Zeiger die Suchanfrage
durchgereicht, bis der für den Schlüssel verantwortliche Knoten gefunden wird. Die Suchlaufzeit
ist dann linear zur Knotenanzahl. Bei N Knoten beträgt sie O(N).
• Skalierbares Routing: Bei diesem Routingverfahren verfügt jeder Knoten über zusätzliche Routing-
Informationen in Form einer Finger-Tabelle. Eine Finger-Tabelle hat eine maximale Größe von m
Einträgen.
Die Basis von CAN ist ein d-dimensionaler kartesischer Koordinatenraum, auf den Schlüssel-Wert-Paare
(key, value) durch eine verteilte Hashfunktion abgebildet werden. Die Hashfunktion ordnet einem Key
k einen Punkt P im Koordinatensystem zu. Ein (key, value)-Paar wird von demjenigen Knoten ge-
speichert, in dessen Zone P liegt. Jeder Knoten im Netzwerk speichert die Zonen-Koordinaten und
IP-Adressen seiner Nachbarn. Bei der Suche wird der passende Punkt P zu einem Suchbegriff durch die
Hashfunktion bestimmt. CAN bietet eine Reihe von Verbesserungen, die z.B. die Dauer der Suchan-
frage, die Länge des Suchpfades (auf Anwendungs- oder IP-Ebene) oder die Fehlertoleranz reduzieren.
P2P-Architekturen haben durch ihre grundlegende Struktur mit offenen Problemen zu kämpfen. Die
7
4.2 Java 2 Micro Edition 4 GRUNDLAGEN
Kriterien und Anforderungen, die an P2P Netzen gestellt werden, sind: Skalierbarkeit, Sicherheit, Admi-
nistrierbarkeit/Selbstorganisation, Fehlertoleranz/Robustheit, Anonymität, Performanz und Interopera-
bilität. Ein Beispiel als Plattform für P2P-Anwendungen ist die Opensource-Lösung JXTA der Firma
Sun, mit dem Ziel, Programmierern eine einfache, flexible Möglichkeit zu schaffen, verteilte Anwen-
dungen zu implementieren ohne zuerst ein eigenes P2P Framework zu entwickeln (siehe Sun Website).
Mobile-Computing ist neben Peer-to-Peer-Computing in den letzten fünf Jahren sehr populär gewor-
den, vor allem wegen der schnellen Weiterentwicklung mobiler Endgeräte, die den Markt immer mehr
erobert haben. Die Kombination von mobilen Endgeräten und mobilen Ad-Hoc Netzwerken (MANETs),
ermöglicht die Entwicklung mobiler Peer-to-Peer-Systeme, mit denen mobile Peers mittels drahtloser
Kommunikation (z.B. Bluetooth, UMTS) Verbindungen miteinander aufbauen können. Einige techni-
sche Herausforderungen, mit denen Mobile-P2P-Computing zu kämpfen hat, sind vor allem die de-
zentralen Natur mobiler P2P Systeme, das erhöhtes Risiko bei der Mobilität, die Tatsache, dass die
drahtlose Verbindung stark variabel in Leistung und Robustheit ist, die dynamische Topologie mobiler
P2P Systeme, die Abhängigkeit mobiler Geräte von einer endlichen Energiequelle, sowie die Tatsache,
dass mobile Geräte wenige Ressourcen wie z. B. Speicherkapazität, Prozessorleistung zur Verfügung
stellen. Ein gutes Beispiel ist 7DS6, ein P2P-Filesharing-System, das neben einer eigenen Architektur
eine Reihe von Protokollen und eine Implementierung beinhaltet.
Abschliessend muss man klar erwähnen, dass P2P-Systeme nur mühsam zu kontrollieren sind, da sie
ohne zentrale Instanzen auskommen und deshalb mangelnde QoS7-Garantien (unterschiedliche Anzahl
von Ergebnisse und Bearbeitungszeiten)
aufweisen, wodurch Arbeitsprozesse schwer kalkulierbar sind. Auf Grund dieser Tatsache ist es für Un-
ternehmen kaum möglich, gewinnbringende Architekturen für den Markt zu erschließen. Es ist mehr
davon auszugehen, dass sich eher eine Mischung von P2P- und Client/Server-Modellen in Unterneh-
mensbereich durchsetzen wird. Erst langsam im Laufe der Zeit wird man künftig erkennen können,
welche Potenziale hinter der P2P-Technologie stecken.
4.2 Java 2 Micro Edition
Die J2ME (Java 2 Platform Micro Edition), ist unsere, von Sun erstellte, Ausgangs-Plattform gewe-
sen, die speziell für Mobile Applikationen entwickelt wurde. Die Grundlage von J2ME bilden dabei die
Konfigurationen und die Profile, wobei die Konfigurationen aus CDC (Connected Device Configuration)
und CLDC (Connected Limited Device Configuration) bestehen.
Wir haben in unserem Projekt das CLDC benötigt, da es im Gegensatz zum CDC für mobile End-
geräte gedacht ist, die stark eingeschränkt sind im Bezug auf Speicher und Prozessorleistung. Mit
Profilen sind dabei die APIs8 gemeint, die es zu einer Konfiguration gibt. Einige der APIs der J2ME
waren aus der J2SE (Java 2 Standart Edition) oder J2EE (Java 2 Enterprise Edition) bekannt, teil-
weise waren sie stark gekürzt, um den Speicherbedarf so gering wie möglich zu halten, während andere,
komplett neue APIs hinzugekommen sind.
Die J2ME verfügt zusätzlich über viele verschiedene optionale Pakete und kann somit verschieden
möglich erweitert werden. Wir mussten abwägen, welches der optionalen Pakete für unser Projekt von
Bedeutung war. Als wir mit unserem Projekt begonnen hatten, standen insgesamt sieben dieser optio-
nalen Pakete zur Verfügung. Einige waren noch im Status in progress, so dass wir auf diese verzichten
mussten. Oft stellen sie ein grobes Gerüst dar, welches vom Entwickler, bis auf ein paar kleine Ausnah-
men, beliebig fertig gestellt werden kann. Sie sind in so genannten JSRs (Java Specification Requests)
festgelegt und spezifiziert.
Hier eine Übersicht der einzelnen Pakete :
6Seven (7) Degrees of Separation
7Quality of Service
8Application Programming Interface - eine Programmierschnittstelle
8
4.3 Bluetooth 4 GRUNDLAGEN
• JSR 75 (PDA -> Personal Information Management (PIM))
• JSR 82 (Bluetooth, siehe S. 12)
• JSR 120 (Wireless Messaging API)
• JSR 172 (Web Services Specification)
• JSR 179 (Location)
• JSR 180 (SIP API -> Session Initiation Protocol)
• JSR 234 (Advanced Multimedia Supplements)
Wir haben für unser Projekt die JSR 75 und die JSR 82 benötigt.
Die JSR 75 ermöglichte uns den Zugriff auf das Handy File-System, während die Bluetooth JSR 82
das nötige Protokoll lieferte. Laut Java-Doc war die JSR 75 vorgesehen, um einen Zugang zu Personal
Information Management (PIM) Daten auf einem J2ME Gerät zu ermöglichen.
Mit PIM-Daten sind Informationen im Adressbuch, Kalender oder in to-do-list-Applikationen gemeint.
Diese API stellt Zugänge zu den jeweiligen PIM-Daten zur Verfügung. Oft tauchte auch der Begriff
Generic Connection Framework (low-level Connections) auf. Das GCF wurde mehrfach in den einzelnen
optionalen Paketen erwähnt und ließerahnen, dass es sich um ein zentrales Framework handelt. GCF
ist ein Satz Interfaces, die im javax.microedition.io-Paket definiert sind, mit denen eine Vielzahl
an Verbindungen erstellt werden kann. Die Aufgabe des GCF ist es, die input/output- und networking-
Funktionalitäten in J2ME-Profilen zu übernehmen. Es ist somit das Fundament aller Applikationen, die
beliebige Verbindungen und Netzwerke implementieren. Es wurde ursprünglich definiert, um auf der
J2ME-Plattform aufzubauen, da die vertrauten J2SE java.net und java.io APIs zu großwaren, um
in den begrenzten Speicher der mobilen Geräte zu passen. Beispielsweise besteht das java.io Paket
aus ca. 60 Klassen plus Interfaces und ca. 15 Exception-Klassen. Zusammen, mit den ca. 20 java.net
Klassen und 10 Exception Klassen, würden sich insgesamt 200 kb ergeben, ohne eine einzige Zeile
implementiert zu haben.
Das war entschieden zuviel, um auf einem Java-fähigem Handy zu laufen.
4.3 Bluetooth
4.3.1 Baseband
Das Baseband befindet sich im Transport-layer des Bluetooth Protocol Stacks und setzt direkt auf die
Funkschnittstelle auf.
Der eigentliche BT-Funk findet auf dem 2,4GHz ISM-Band (ISM steht für Industrial, Scientifical and
Medical), dem kosten- und lizenzfreien Band statt. Der Frequenzbereich geht von 2.400 MHz bis
2.483,5 MHz. Aus Interferenzgründen startet das Bluetooth-Band bei 2.402 MHz und geht bis 2480
MHz. Das gesamte Band ist dabei in 79 Kanäle zu je einem MHz unterteilt. Durch die Frequenzmo-
dulation entsteht eine Datenrate von 1 Mbps.
Baseband selbst ist für die Verteilung der Datenpakete zwischen den einzelnen BT-Endgeräten über
die Funkschnittstelle zuständig.
BT ist eine Master/Slave orientierte Verbindung. Sobald ein ad-hoc-Netzwerk aufgebaut wird, sind
automatisch ein Gerät der Master und alle anderen die Slaves. Ein Bluetooth ad-hoc-Netzwerk besteht
im Prinzip aus dem oben genannten Master und bis zu sieben weiteren aktiven Geräten - die aktiven
Slaves. Es gibt Möglichkeiten, um weitere Endgeräte in dieses sogenannte Piconet als passive Slaves
einzubinden. Je nach Adressierungsart kann man damit dem Piconet bis zu theoretisch 255 weitere
9
4.3 Bluetooth 4 GRUNDLAGEN
Geräte hinzufügen.
Das Baseband benutzt vier verschiedene logische Kanäle: Den Basic-Piconet und Adapted-Piconet
Kanal, den Inquiry-Scan und den Page-Scan Kanal. Ein solcher logischer Kanal ist im physikalischen
dadurch charakterisiert, dass in einer pseudo-zufälligen Reihenfolge durch die verfügbaren Kanäle ge-
sprungen wird. So nutzt der Basic-Piconet Kanal alle 79 Frequenzen, während der Adapted-Piconet
normalerweise nicht durch das volle Spektrum geht. Die verschiedenen Kanäle können weiterhin durch
ihren eindeutigen Access-code unterschieden werden.
Der eigentliche Sende-/Empfangsvorgang ist strikt geregelt. Ein Slave kann immer nur an den Master
und nicht an die anderen Slaves in seinem Piconet senden. Der Master selbst bestimmt das Sendever-
halten der Slaves dadurch, dass ein Slave nur dann senden darf, wenn es in dem Sendeslot vorher durch
den Master angesprochen wurde. Ein Slot entspricht dabei ein Hop.
4.3.2 L2CAP
Mit dem Logical Link Control and Adaption Protocol (L2CAP) wird eine Möglichkeit geboten, be-
quem eigene Protokolle zu definieren. Es vereinfacht mit seiner Architektur das Implementieren neuer
Protokolle, so dass man nicht jedes Mal direkt auf der Hardware programmieren muss, sondern schon
eine Software-Schnittstelle verwenden kann. L2CAP ist diese unterste Software-Schnittstelle. Grund-
sätzlich unterscheidet man zwischen zwei Verbindungsarten, die mit Bluetooth möglich sind, nämlich
SCO (synchronous connection-oriented) und ACL (asynchronous connection-less). SCO-Verbindungen
werden überwiegend bei
Sprachübertragung eingesetzt, während ACL-Verbindungen bei Datenübertragungen zum Einsatz kom-
men. Mit L2CAP sind nur ACL-Verbindungen möglich, weshalb man bei Sprachübertragungen direkt
auf das Baseband-Protokoll zurückgreifen muss.
4.3.3 L2CAP Kommunikation
Das L2CAP Protokoll setzt auf Paket-basierten Übertragung und gehört zur Sicherungsschicht des
OSI-Modells. Das heißt, es ist für das Aufteilen der Daten in Pakete verantwortlich. Auch das evtl.
Anfordern fehlerhaft übertragener Pakete gehört zu seinem Aufgabenbereich. Insbesondere gehören
folgende Begriffe hinzu:
• Die Maximum Transmission Unit (MTU) definiert die maximale Paketgröße, die übertragen wer-
den kann. Das Paket kann kleiner sein, darf aber unter keinen Umständen größer als der MTU-
Wert sein.
• Der Flush Timeout bestimmt wie lange der Empfänger brauchen darf, bis er das Paket bestätigt.
Kommt in dieser Zeit keine Bestätigung beim Sender an, wird das Paket nochmals gesendet.
• Die Quality of Service (QoS) legt Prioritäten für den Datenverkehr fest. So kann z.B. Sprach-
übertragung stärker bevorzugt werden als Datenübertragung.
Die Werte Flush Timeout und Quality of Service werden bereits vom Bluetooth-Stack gesetzt. Lediglich
die MTU kann man mit der JSR 82-API einstellen. Wird die Einstellung nicht vorgenommen, so wird ein
DEFAULT_MTU von 672 Bytes benutzt. Der Aufbau einer L2CAP-Verbindung läuft im Wesentlichen
so ab, wie mit SPP9.
4.3.4 Applikationen mit Bluetooth
Eine Applikation, basierend auf Bluetooth Spezifikation, besteht im Wesentlichen aus 6 logischen Schrit-
ten:
1. Stack Initialisation
9Serial Port Protocol (serielle Schnittstelle)
10
4.3 Bluetooth 4 GRUNDLAGEN
2. Device Management
3. Device Discovery
4. Service Registration
5. Service Discovery
6. Kommunikation
Unter Stack Initialisation versteht man eine Reihe von Zuweisungen, wobei die benötigten Geräteei-
genschaften wie z.B. Name, Adresse, Portnummer, Status (sichtbar oder versteckt) u.s.w. eingestellt
werden. Diese sind gerätespezifisch und daher nicht in der Bluetooth API eindeutig festgelegt. Die
Einstellungen werden vom Gerät vorgenommen und schließlich an die Methode getProperty() der
Klasse javax.bluetooth.LocalDevice angebunden.
In der Phase DeviceManagement beschäftigt man sich mit den Klassen LocalDevice und Remote-
Device. Für die Konfiguration des eigenen Gerätes wird zunächst eine Instanz der Klasse LocalDevice
gebildet. Dies geschieht jedoch durch den Aufruf der statischen Methode getLocalDevice(), weil der
klasseneigener Constructor geschützt ist.
Alle Bluetooth Geräte haben ähnlich wie Netzwerkkarten eindeutige Netz-werk-Adressen. Diese werden
in Form eines 12-stelligen Strings gebildet. Mit der Methode getBluetoothAddress() ist es nun mög-
lich diese Adresse auszulesen. Um einem Gerät die Möglichkeit zu gewährleisten von anderen Geräten
gefunden zu werden sorgt die Methode setDiscoverable(int mode). Dabei ist mode eine Zahl die
die Sichtbarkeitszustände, entsprechend Bluetooth Spezifikation, darstellt. Um diesen Zustand abzu-
fragen ist die Methode getDiscoverable() zuständig.
Ähnlich wie mit eigenem Gerät, verhält es sich auch mit dem entfernten Gerät (RemoteDevice). Die
Klasse RemoteDevice ermöglicht einen Zugriff zu einem entfernten Gerät in der Umgebung.
Um eine Verbindung zwischen zwei Bluetooth Geräten herzustellen ist es notwendig, dass minde-
stens einer von beiden den anderen kennt. Um eine Erkennung zu ermöglichen, besitzt die Java
Bluetooth API (JSR 82) die so genannte Device Discovery Phase. Nach einer erfolgreichen Initia-
lisierung eines eigenen Bluetooth Gerätes ist es nun möglich, den DiscoveryAgent zu starten. Ab
diesem Zeitpunkt ist nun der Agent bereit, die entfernten Bluetooth-Geräte zu erkennen. Damit
der aktuelle Thread nicht blockiert wird, ist der Prozess der Erkennung in Form von Events ge-
macht. Die Schnittstelle DiscoveryListener enthält alle Ereignisse, die ausgelöst werden können, wäh-
rend eine Device-Erkennung ausgeführt wird. Um die Erkennung nun zu starten, ruft man die Me-
thode startInquiry(int accessCode, DiscoveryListener listener). Sobald ein neues Devi-
ce gefunden wurde, wird die Methode public void deviceDiscovered(RemoteDevice btDevice,
DeviceClass cod) als Ereignisbehandlung aufgerufen. Mit der Methode retrieveDevices(int
option) bekommt man einen Array von Instanzen aller von StartInquiry gefundenen Geräte.
Als Server legt man eigene Information in der Service Discovery Database ab. Für jede Instanz der
Klasse LocalDevice werden die angebotenen Dienste in Form von ServiceRecord-Einträgen eingestellt.
Java Bluetooth API bietet dafür die Schnittstelle namens ServiceRecord. Darin werden die Attribute in
Form einer UUID10 Nummer gespeichert und durchnummeriert. Der ganze Prozess umfasst folgende 6
Schritte:
1. Initialisierung des eigenes Gerätes:
2. Bilden von Attributen und UUIDs
3. Zusammensetzen von URL
10Universal Unique IDentifier
11
4.4 JSR 82 4 GRUNDLAGEN
4. Öffnen eines StreamConnectionNotifiers
5. Erstellung eines ServiceRecords (mit Hilfe der statischen Methode getRecord())
6. Erstellung eines neuen Datenelements und Setzen von Attributen
Nachdem ein Eintrag in die SDDB erfolgt ist, wird der Thread angehalten, solange kein Client eine Ver-
bindung herstellt. Nachdem das geschehen ist muss der aktuelle StreamConnectionNotifier geschlossen
werden.
Hat man als Client ein Gerät erkannt ist es möglich mit Hilfe folgender Methode der Klasse disco-
veryAgent nach unterstützten Diensten zu erfragen. Sinnvoll ist hier mehrere UUIDs anzugeben. Als
Ergebnis wird ein Integer geliefert, der eine Transaktions-ID für spätere Behandlungen darstellt.
4.4 JSR 82
Ziel der JSR 82-Spezifikation (Java Specification Request 82) ist es, eine Java API zu schaffen, mit
welcher eine Kommunikation via Bluetooth möglich ist. Der vorwiegende Einsatz wird auf Handys,
sowie PDAs sein. Die API ist deshalb so definiert, dass die o.g. Vorraussetzungen erfüllt sind. JSR 82
ist so konstruiert, dass ständig neue Profile hinzugefügt werden.
Eines der Hauptpakete (javax) beinhaltet zwei weitere unabhängige Unterpakete (javax.obex und
javax.bluetooth). Diese Aufteilung ist sinnvoll, weil OBEX-Protokoll auf Bluetooth angepasst wird.
OBEX-Protokoll kann somit auch auf anderen physischen Schichten, wie IR11 angewandt werden. Eine
Applikation, aufbauend auf der Java Bluetooth API, kann eine von beiden oder auch beide Paketen
importieren.
Mit der Methode Connector.open() wird bei der clientseitigen Anwendung eine Verbindungsanfor-
derung geöffnet. Die Schnittstelle javax.bluetooth.L2CAP
Connection bietet eine Reihe von Methoden, die für eine Kommunikation benötigt werden. Darun-
ter sind die Methoden zum Senden und Erhalten eines Byte-Arrays. Bei der Arraylänge ist auf die
MTU-Größe zu achten.
4.5 Tree Scatternet Formation Algorithmus
4.5.1 Piconetze & Scatternetze
Bei der Vernetzung von Bluetooth-fähigen Geräten unterscheidet man zwischen Piconetzen und den
aus mehreren Piconetzen bestehenden Scatternetzen.
Piconetze Ein Piconetz besteht aus bis zu 8 aktiven Knoten und kann max. 255 weitere geparkte,
inaktive Knoten besitzen. Man unterscheidet hierbei zwischen Master- und Slave-Knoten.
In jedem Piconetz gibt es genau einen Master-Knoten, der den gesamten Transfer zwischen den Slaves
steuert und sich normalerweise im Zentrum des jeweiligen Piconetzes befindet. Der Master bestimmt
außerdem die Sequenz der Frequenzen, über die nacheinander gesendet wird. Direkte Transfers zwi-
schen zwei Slaves sind nicht erlaubt und müssen über den Master laufen.
Für das Finden von potenziellen Kommunikationspartnern wird das Inquiry-Verfahren verwendet, in
dem die Geräte abwechselnd durch die verschiedenen Frequenzen springen und nach anderen Geräten
suchen bzw. auf einkommende Nachrichten warten. Im Paging-Verfahren kann dann erst der tatsäch-
liche Verbindungsaufbau stattfinden, weil dort erst bekannt ist, welche Geräte sich in der Umgebung
befinden und wie ihre Addressen (und damit die Sprungvektoren) lauten.
11Infrarot
12
4.5 Tree Scatternet Formation Algorithmus 4 GRUNDLAGEN
Festzustellen ist hierbei, dass ein Slave nur Daten mit dem Master austauschen kann, nicht aber
mit anderen Slaves. Um seinerseits Daten zu den übrigen Einheiten des Piconetzes transferieren zu
können, muss ein Slave die Daten zuerst an seinen Master schicken, der diese dann weiterleitet. Dies
ist jedoch nur in dem Slot möglich, der einer vorhergenden Verbindungsaufnahme durch den Master
selbst folgt.
Scatternetze Mehrere Piconetze können in derselben Umgebung nebeneinander existieren, ohne dass
der Durchsatz in den Teilnetzen wesentlich beeinträchtigt wird. Einen solchen Verbund mehrerer Pi-
conetze nennt man Scatternetz. Die Piconetze sind hierbei über Brückenknoten, die auch Gateways
genannt werden, verbunden. Gateways sind Knoten mit mehr als einer Rolle zwischen Piconetzen. Diese
Gateways können sowohl Master- als auch Slave-Knoten in den verschiedenen Netzen sein, aber nur in
maximal einem Netz als Master fungieren.
Bluetooth Link Formation Der Formationsprozess eines Bluetooth Piconetzes besteht aus zwei
Phasen: Inquiry-Phase und Page-Phase:
Inquiry-Phase In dieser Phase sollen sich alle Geräte, die sich in Reichweite befinden, kennen-
lernen. Dazu wechselt ein Gerät ständig zwischen dem Inquiry Modus und Inquiry Scan-Modus. Im
Inquiry-Modus versucht das Gerät andere Geräte zu finden, indem es ID-Pakete versendet und auf
eine Antwort wartet. Ein Gerät im Inquiry Scan-Modus wartet auf Anfragen der Geräte, die sich im
Inquiry Modus befinden. Wenn es eine Anfrage erhält, sendet es seine Geräte-ID (BT_ADDR) und
seine Clock zurück. Das Gerät im Inquiry Modus wird Master und das im Inquiry Scan-Modus Slave in
dieser Verbindung. Wenn nach einem Timeout ein Gerät mindestens ein anderes Gerät gefunden hat,
geht es in den Page-Modus über.
Page-Phase In diese Phase werden die Informationen, die in der Inquiry-Phase gesammelt wur-
den, genutzt, um eine Kommunikation zwischen zwei Ge-räten aufzubauen.
Da der Master, der sich jetzt im Page-Modus befindet, die Geräte-ID und die Clock des Slaves kennt,
nutzt er diese Informationen um mit dem Slave in Verbindung zu treten. Der Slave geht dann in den
Page Scan-Modus über. Aufgrund des nicht synchronisierten Clocks von Master und Slave kann es zu
Verzögerungen im Verbindungsaufbau kommen.
4.5.2 TSF: Tree Scatternet Formation
Beschreibung Der TSF Algorithmus von Tan12 wurde entwickelt, um der Dynamik, die in Scatter-
netzen durch das Ankommen und Verlassen von Geräten entstehen kann, gerecht zu werden, damit
stets ein zusammenhängendes Scatternetz gewährleistet ist.
Um dies zu erreichen, wird eine Baumstruktur geschaffen. Zu Beginn gibt es nur einzelne Knoten,
so genannte freie Knoten, die jeweils einen Teilbaum des noch nicht verbundenen Scatternetzes bilden.
Das Verbinden zu einem Baum geschieht entsprechend den vom TSF zugewiesenen Rollen:
12Godfrey Tan. Self-organizing Bluetooth Scatternets. Massachusetts Institute of Technnology, Januar 2002.
13
4.5 Tree Scatternet Formation Algorithmus 4 GRUNDLAGEN
Freier Knoten Zunächst versucht jeder freie Knoten, d.h. der noch mit keinem
anderen Knoten in Verbindung steht, andere Knoten zu finden,
um einen Baum zu bilden. Haben sich zwei Knoten gefunden,
wird der Master zur Wurzel des Baumes, der Slave zu seinem
Kind.
Baumknoten Knoten, die bereits einen Elter haben, können sich nur mit freien
Knoten verbinden. Dieser klinkt sich damit entweder in ein bereits
bestehendes Piconetz ein, oder der Elter erzeugt ein neues. Der
ehemalige Freie Knoten bildet damit also eine Brücke zwischen
dem alten und neuen Piconetz.
Wurzeln Wurzeln können sich nur mit Wurzeln aus anderen Bäumen ver-
binden. Bei einer solchen Verbindung wird eine Wurzel Master
des neuen Baumes und die andere Slave der Wurzel des anderen
Baumes. Um dies auszuführen, werden Koordinatorknoten in den
einzelnen Bäumen bestimmt.
Koordinatorknoten Koordinatorknoten sind Wurzeln oder Baumknoten in einem
Baum. Sie versuchen Koordinatorknoten in anderen Bäumen zu
finden. In jedem Baum gibt es jedoch nur einen Koordinatorkno-
ten.
Wenn eine Wurzel nur ein Kind hat, ist sie selbst Koordinatorknoten. Ansonsten wählt sie zufällig
eines ihrer Kinder und bittet es Koordinatorknoten zu werden. Wenn der ausgewählte Kinderknoten
kein Koordinator sein will, wählt das Kind zufällig einen seiner Kinderknoten. Dieser Prozess wird so-
lange ausgeführt, bis ein Koordinator gefunden ist oder ein Blattknoten erreicht ist. Ein ausgewählter
Blattknoten muss Koordinator werden. Blattknoten haben keine Kommunikationsengpässe, und des-
halb haben sie mehr gesparte Energie zum Entdecken der Nachbargeräte. Wenn ein Knoten Koordinator
wird, sendet er ein Wissenspaket an seine Wurzel und beginnt nach Koordinatorknoten anderer Teil-
bäume zu suchen.
Wenn zwei Koordinatoren sich gefunden haben, informieren sie beide ihre Wurzelknoten. Die Koor-
dinatoren brechen dann den Link zwischen sich ab und nehmen ihre vorherigen Rollen wieder auf.
Währenddessen verbinden sich die Wurzelknoten, wie oben beschrieben. Die Wurzel wählt dann zufäl-
lig einen anderen Koordinator. Da auch ein Koordinatorknoten das Netzwerk jederzeit verlassen könnte,
wird der Koordinatorknoten immer nur auf eine begrenzte Zeit bestimmt.
State Machines Auf jedem Knoten im Netzwerk läuft eine State Machine, welche stets zwischen
zwei von drei möglichen Stati wechselt. Die Stati der State Machine können sein: Inquire, Comm, und
Comm/Scan Status
• Inquire-Status: Ein Knoten in diesem Status führt den Inquiry Modus aus.
• Comm-Status:Ein Knoten in diesem Status ist entweder untätig oder überträgt Daten zu den mit
ihm verbundenen Knoten.
• Comm/Scan-Status: Ein Knoten im Comm Status beginnt im Scan-Status, um Daten zu über-
tragen und wechselt periodisch in den Scan-Status, um Inquiry Scan-Operationen auszuführen.
Die Zuweisungen der State Machine erfolgt folgendermaßen:
Freier Knoten und Koordinatorknoten wechseln zwischen Inquire und Comm/
Scan, um Verbindungen mit anderen möglichen Knoten aufzubauen. Wurzeln bleiben immer im Comm
Status, und Baumknoten wechseln zwischen Comm und Comm/Scan.
14
4.6 Bluetooth Tree Routing Protokoll 4 GRUNDLAGEN
Schleifenfreiheit Innerhalb der Baumstruktur des TSF können keine Schleifen auftreten, da nur
folgende Verbindungen erlaubt sind:
1. Das Verbinden von zwei freien Knoten: Ein Knoten wird zum Master, der andere zum Slave des
neuen Baums.
2. Das Verbinden von einem freien Knoten mit einem Baumknoten: Hier wird der freie Knoten zum
Slave und der Baumknoten zum Master.
3. Das Verbinden von zwei Wurzeln: Eine Wurzel wird zum Master, die andere zum Slave.
Das Verbinden von zwei Baumknoten ist nicht erlaubt, da es zur Schleifenbildung führen könnte.
Heilung TSF garantiert, dass die Teilbäume innerhalb kurzer Zeit wieder miteinander verbunden
werden. Es gibt zwei Arten, wie Verbindungen verloren gehen können:
1. wenn ein Master die Verbindung zu einem Slave verliert oder
2. wenn ein Slave die Verbindung zu seinem Master verliert.
Wenn ein Master merkt, dass er kein Kind mehr hat, braucht er nichts zu tun. Er muss lediglich über-
prüfen, ob er jetzt ein freier Knoten ist. Wenn ja, muss er in diese Rolle wechseln. Wenn nicht, bleibt
er weiter Master der anderen Kinder.
Wenn ein Slave merkt, dass er keinen Master mehr hat, muss er seine Rolle verändern. War er ein
Blattknoten, wird er freier Knoten. War er Baumknoten, wird er zur Wurzel des neuen Teilbaumes.
Um die in der Bluetoothspezifikation enthaltene Beschränkung auf maximal sieben Slaves pro Ma-
ster zu gewährleisten, muss eine Wurzel, die die maximale Anzahl von Slaves erreicht hat, ein Kind
zum Master und Wurzel eines neuen Teilbaumes machen.
4.6 Bluetooth Tree Routing Protokoll
Verschiedene Nachrichten müssen nicht an alle Knoten im Netzwerk geschickt werden. Es wäre ineffi-
zient diese per Broadcast zu verschicken.
Da der antwortende Knoten die Zieladresse des Pakets kennt, kann ein direkter Weg über das Netz-
werk gefunden werden. Da es sich aber nicht immer um direkt verbundene Knoten handelt, muss über
mehrere Knoten geroutet werden.
Dieses Routing kann effizient mit dem Bluetooth Tree Routing (BTR) erfüllt werden. Die Routing-
tabelle werden direkt während der Netzwerkerzeugung erstellt. Es handelt sich um ein proaktives Rou-
tingprotokoll und neuzt die Baumstruktur des TSF. Die Routingdaten werden nicht erst erstellt, wenn
sie benötigt werden, sondern bereits während des Aufbaus der Baumstruktur, im Gegensatz zu ein
reaktiven. Dieses Verfahren funktioniert aber nur bei Baumstrukturen.
4.6.1 Funktionsweise
Routing-Tabelle Eine Routing-Tabelle wird aus sieben Hash-Tabellen erstellt. Dies entspricht den
sieben Slaves, mit denen sich ein Master verbinden kann. Als Schlüssel wird die Bluetoothadresse des
Geräts genutzt. Dazu wird die Entfernung zum Gerät gespeichert. Aus dieser Kombination kann der
kürzeste Weg den gleichen Inhalten gefunden werden. Die Routing-Tabellen können verpackt über das
Netz an andere Knoten geschickt werden.
15
4.6 Bluetooth Tree Routing Protokoll 4 GRUNDLAGEN
Tabellenaufbau Der Tabellenaufbau erfolgt während des Scatternetzaufbaus. Es gibt zwei Möglich-
keiten des Baumwachstums. Dann müssen Routingupdates versendet werden.
1. Ein freier Knoten will sich an ein bestehendes Netz anschließen. Der freie Knoten schickt seine
Bluetoothadresse dem Baumknoten, an den er sich angeschlossen hat. Dieser erstellt für den
angeschlossenen Knoten eine neue Hash-Tabelle und trät die Bluetoothadresse mit einer Distanz
von eins ein. Der Baumknoten schickt anschließend ein Routingupdate an seinen Elter, das die
aktualisierte des Baumknotens enthält. Der Elter aktualisiert seine Routingtabelle mit den er-
haltenen Daten des Kindes und sendet wiederum eine Routingupdate-Nachricht an seinen Elter.
Dabei müssen die einzutragenden Distanzen stets um einen erhöht werden. Dieser Vorgang setzt
sich so lange fort, bis die Wurzel erreicht ist.
2. Es kommt zu einer Baumverschmelzung zweier Wurzelknoten. Dabei sendet die Wurzel, die sich
als Kind anschließt ein Routingupdate an die andere Wurzel. Diese legt eine neue Hashtabelle
für diese Wurzel als ihr Kind an und trägt die übertragenen Daten in diese ein. Die Entfernungen
müssen dabei für alle eingetragenen Knoten um eins erhöht werden.
3. Routingupdates müssen auch versendet werden, wenn ein Knoten das Netzwerk verlässt.
4. Wenn ein Elter sein Kind verliert, muss er seine Routingtabelle aktualisieren. Die aktualisierte
Routingtabelle muss anschließend an seinen Elter weitergeleitet werden. Dieser Vorgang wird
ebenfalls solange weitergeleitet bis die Wurzel erreicht ist.
Aus diesen ständig aktuellen Routingtabellen können nun stets alle Kinder eines Elter bis in die Blätter
des Baumes ausgelesen werden. Ein Knoten hat somit immer Wissen über den gesamten Teilbaum, der
an ihn angeschlossen ist.
Routing Um eine Nachricht an einen weiter entfernten Knoten zu senden, durchsucht der Knoten
zuerst seine Routingtabelle, ob der gesuchte Knoten ein entferntes Kind ist. Findet er den Knoten in sei-
nem Teilbaum, sendet er die Nachricht an den Knoten, der die Wurzel für den entsprechenden Teilbaum
bildet. Dieser leitet die Nachricht an den nächsten Knoten des Teilbaums, bis der Zielknoten erreicht ist.
Wird der gesuchte Knoten nicht in der Routingtabelle gefunden, befindet er sich nicht im Teilbaum.
Also sendet er den Knoten an seinen Elter. Dieser sucht den Zielknoten in seiner Routingtabelle. Wird
er dort gefunden, wird die Nachricht in den entsprechenden Teilbaum geleitet, wird er nicht gefunden,
wird die Nachricht wieder an den Elter weiter geleitet. Spätestens wenn die Wurzel erreicht ist, kann
die Nachricht in den richtigen Teilbaum geleitet werden, da die Wurzel alle Knoten im Netzwerk kennt.
Kann auch die Wurzel den Zielknoten nicht finden, wird das Paket verworfen.
16
5 ABLAUF DER PROJEKTGRUPPE
5 Ablauf der Projektgruppe
5.1 Seminarphase
In der Seminarphase bekam jeder PG-Teilnehmer ein Thema (oder ein Teil davon im Falle einer Grup-
penarbeit) aus dem für die Projektgruppe relevantem Bereich, der aufgearbeitet und präsentiert werden
sollte. Im Einzelnen waren das:
• Der Netzwerk-Simulator ns-2 (Prost)
• Software-Entwicklung mit der Java 2 Micro Edition (Ben Said)
• J2ME Pakete und Wireless Toolkit (Krokowski)
• Bluetooth mit J2ME (Leikam)
• Entwicklungswerkzeuge unter Linux (CVS, Autotools, Debugger, ...) (Zok)
• Grundlagen des Peer-to-Peer Computing (Napster, Gnutella, Distributed Hash Tables (CAN,
Chord), KaZaA) (Tigyo, Kißner)
• Mobiles Peer-to-Peer Computing mit Passive Distributed Indexing (Kasmann)
• Bluetooth Grundlagen und Spezifikation (Börgermann, Diel)
• Bluetooth Scatternetz-Konstruktion und Link Scheduling (Göbel)
5.2 Programmiertest
Im Anschluss an die Seminarphase fand ein 24-Stunden-Programmmiertest statt, in dem die PG-
Teilnehmer ihre Programmierkompetenzen unter Beweis stellen sollten. Der Test bestand aus der Auf-
gabe, mathematische Funktionen auf schwach besetzten Vektoren und Matrizen zu realisieren.
Die PG-Teilnehmer wurden dabei in zwei Gruppen aufgeteilt. Eine Gruppe sollte den Test in Java
schreiben, die andere in C++. Die Gruppeneinteilung war wie folgt:
• Java: Ben Said, Kißner, Krokowski, Leikam, Tigyo, Zok
• C++: Börgermann, Diel, Göbel, Kasmann, Prost
5.3 Design Prozess gemäßUML/RUP
5.3.1 Brainstorming
In einem anfänglichen Brainstorming wurden verschiedene Funktionalitäten des Programms erdacht
und wieder verworfen. Ferner gab es Anfangs Schwierigkeiten bei der Entscheidung, welche Program-
mierumgebung benutzt werden und für welches System das Programm entwickelt werden sollte (siehe
„Probleme während des 1. Semesters“, S.21).
5.3.2 Rational Unified Process (RUP) mit Unified Modelling Language (UML)
Das komplette Projekt wurde gemäßdem Unified Process Model von UML entwickelt. Folgende Doku-
mente finden sich deshalb im Anhang:
• Anwendungsfalldiagramm
• Aktivitätsdiagramme
• Problembereichsmodell
17
5.4 Konventionen 5 ABLAUF DER PROJEKTGRUPPE
• Sequenzdiagramme
• Klassendiagramm
Dem Erstellen der Diagramme und der daraus resultierenden klareren Spezifikation des Programmes
und seiner Eigenschaften folgte die Implementierung (siehe 5.6, S.19), der Klassentest, sowie der Pro-
dukttest. Im Anhang finden sich deshalb ebenso die dort erzeugten Artefakte.
5.4 Konventionen
Wir haben uns auf folgende Konventionen geeinigt:
• Klassennamen haben große Anfangsbuchstaben, normal
• Attribute haben kleine Anfangsbuchstaben, normal, Unterstrich am Ende
• Variablen haben kleine Anfangsbuchstaben, normal
• Konstanten werden großgeschrieben
• Reihenfolge in einer Klasse:
1. Attribute, Variablen, Konstanten
2. Konstruktor
3. Methoden
4. set/get-Methoden
• Alles auf Deutsch
• Referenzen auf die Teilnehmer durch Nachnamen
5.5 Programmdesign
Der Name unseres Programmes, auf den wir uns einigten, ist „Blue Brewery Horse“, basierend auf einer
PG-internen Anekdote. Blue Brewery Horse wird im Folgenden mit „BBH“ abgekürzt.
Um die vielfältigen Aufgaben unseres Programms besser zu strukturieren, entschieden wir uns schon
zu Beginn der Entwurfsphase für eine klassenbasierte Aufteilung - ein sogenanntes Managersystem.
Wir benutzten dabei die Unterteilung des Anwendungsfalldiagramms. Es entstanden SuchManager,
EigenDateienManager, DownloadManager und UploadManager. Im folgendem werden nur die Zusam-
menhänge zwischen den wichtigsten Klassen beschrieben. Eine ausführliche Klassenbeschreibung aller
Klassen ist im nächsten Abschnitt zu finden (S. 33).
Die Kommunikation zwischen den einzelnen Managern der jeweiligen Geräte findet über verschiedene
Nachrichtentypen statt. BBHNachricht ist die Oberklasse unserer BBHNachrichtentypen, die jeweils
von bestimmten Managern bearbeitet und versendet werden. Die Nachrichtentypen sind: SuchAn-
frage, SuchAnwort, DownloadAnfrage, DownloadAntwort, DownloadAnforderung, DownloadAbbruch,
Upload, UploadStart und UploadAntwort.
Der SuchManager erstellt SuchAnfragen und bearbeitet alle einkommenden SuchAntworten. Zur Ver-
waltung dieser Nachrichten benutzt er die Klasse SuchMatchListe, in der die MatchListenEinträge
gehalten werden. Zu jedem MatchListenEintrag werden die Downloadquellen mit Verweisen auf die
entsprechenden Peers gespeichert.
Der EigeneDateienManager beantwortet eingehende SuchAnfragen, speichert eingehende Down-
loads und verwaltet die Dateifreigabe in der FreigabeListe. In ihr werden die Dateien gehalten.
18
5.6 Implementierung 5 ABLAUF DER PROJEKTGRUPPE
Der DownloadManager verwaltet die Downloads unserer Anwendung. Er erstellt DownloadAnfragen
und DownloadAnforderungen. Dazu benutzt er die Klasse DownloadListe, die die
DownloadEinträge verwaltet.
Der UploadManager stellt die Gegenseite des DownloadManagers dar. Er bearbeitet eingehende
DownloadAnfragen und DownloadAnforderungen. Außerdem erstellt und verwaltet er die Uploads.
Um auf die Uploads zuzugreifen, verwendet der Manager die UploadListe, die die einzelnen
UploadEintraege enthält.
Die Manager erben vom Interface Nachrichtenmanager. Sie müssen die Methode
empfangeNachricht() implementieren, damit über diesen Methodenaufruf die Nachrichten an den
dafür vorgesehenen Manager gesendet werden kann.
SkyNet ist die Verbindung zwischen Netzwerkschicht und Applikationsschicht und leitet eingehen-
de Nachrichten über die Methode empfangeNachricht() an die Manager weiter, die sich zu Beginn
bei SkyNet für ihre Nachrichten registiert haben.
Programm erbt von Midlet und ist der Rumpf unserer Anwendung. Diese Klasse initialisiert alle Manager,
den Timer, die GUIKontrolle und SkyNet. Im Programm halten wir eine Instanz von BBHTimer, der al-
len Managern zur Verfügung steht und alle Timingaufgaben unseres Programms übernimmt. BBHTimer
hat einen Vektor von BBHTimerEintrag, den er bei jedem Aufruf von der Methode starteTimer()
um einen neuen Eintrag erweitert. Er besitzt weiterhin einen BBHTimerTask, welcher sekündlich über-
prüft, ob ein Zeitpunkt von einem der BBHTimerEinträgen überschritten worden ist. Falls dies der Fall
ist, wird der jeweilige Manager über den EreignisHandler benachrichtigt.
GUIKontrolle dient als visuelle Schnittstelle für den Benutzer.
Auf der Netzwerkschicht wird durch die Klasse Netzwerk ein Thread der Klasse Empfaenger für jede
eingehende Verbindung, gelinkt auf das jeweilige entfernte Endgerät erstellt. Die Endgeräte werden
in der GeraeteListe verwaltet. Zum Senden aller Nachrichten dient ein weiterer, einzelner Thread
der Klasse Sender, der je nach Bedarf aktiviert wird. Außerdem stehen die Klassen Listener und
ServiceSearch zur Verfügung, die die Bluetooth-spezifische Aufgaben für das Finden anderer Geräte
erfüllen (ServiceSearch, Inquiry etc.).
Im 2. Semester wurde der VerwaltungsManger in die Netzwerkebene eingefügt. Dieser implementiert
den TSF- und BTR-Algorithmus. Die Kommunikation zum Verbindungsaufbau des Scatternetzes wird
über Verwaltungspakete, welche von Nachricht erben, geregelt.
5.6 Implementierung
Mit der Implementierung wurde nach Zeitplan gemäßUMP begonnen. Auf das Schreiben der einfa-
chen Funktionen folgte ein Verlinken der Klassen, bis schließlich das gesamte Program an der SkyNet-
Schnittstelle zusammengesetzt wurde. Im Zuge der Implementierung fanden rigorose Tests und parallele
Fehlerbehebung statt.
Folgende Gruppenaufteilung haben wir am Anfang der Implementierungsphase vorgenommen:
• Netzwerkschicht: Börgermann, Göbel, Diel
• SuchManager (SuchMatchListe, MatchListenEintrag, DownloadQuelle,
Peer), Downloadmanager (DownloadListe, DownloadEintrag, Datei), SuchIndexListe, IndexEin-
trag: Tigyo, Kißner
19
5.7 Test und Fehlerbehebung 5 ABLAUF DER PROJEKTGRUPPE
• UploadManager (UploadListe, UploadEintrag), Interfaces, BBHTimer, EigeneDateienManager
(FreigabeListe): Zok, Prost
• Programm, Pakete: Krokowski, Leikam
• GUI: Ben Said, Kasmann
Im zweiten Semester sah die Aufteilung dann folgendermaßen aus:
• Fertigstellen des Backup-Servers: Göbel, Diel
• Konstruktion eines BBHLight Programms zum Testen auf richtigen Handys: Börgermann, Prost
• Verfeinerte Suche, Credit-Point-System und ID3-Tags auslesen: Kißner, Leikam
• Scatternetzkonstruktion: Kasmann, Ben Said, Krokowski, Zok, Tigyo (später dann alle)
• Endbericht: Diel (+ Inhalt von jedem)
5.7 Test und Fehlerbehebung
Das Programm wurde auf zwei Arten getestet13: Erstens als unabhängiger Klassentest und zweitens
als kompletter Produkttest.
Bei dem Klassentest wurde jede Klasse mit einem Treiber und einem Dummy versehen, die die Schnitt-
stellen abdeckten. Dann wurden der Klasse bestimmte Inputs gegeben, die in verschiedenen, für die
Klasse sinnvolle Äquivalenzklassen eingeteilt waren. Dadurch wurde ein umfangreicher, eigenständiger
Test sichergestellt
Für den Produkttest wurde das Program vollständig zusammengeführt und gestartet. Dort wurde dann
das Zusammenspiel der Interfaces, sowie diverser, vorher nicht aufgetretener Fehler beobachtet. Durch
den Produkttest wurde sichergestellt, dass das Program als solches auch fehlerfrei läuft.
5.8 Dokumentation
Die Dokumentation wurde während des UMP angefertig und zu jedem Treffen präsentiert. Änderungen,
die sich im Dialog mit der Projektgruppe ergaben, wurden analysiert und entsprechend aufgenommen.
Das Klassendiagramm wuchs dabei kontinuierlich an, da die Notwendigkeit des Hinzunehmens einer
ganzen Reihe von Hilfsklassen noch während der Implementierung deutlich wurde. Bis zur Implemen-
tierung war das gesamte Klassendiagramm auch noch in Programm- und Netzwerkebene getrennt, bis
es dann am Ende in ein großes überführt wurde.
Die JavaDoc befindet sich online auf http://mobicom.cs.uni-dortmund.de/pg466/intern/Doku/
index.html (passwortgeschützt).
13 Siehe auch Anhang A, S. 46
20
6 ERGEBNISSE, 1. SEMESTER
6 Ergebnisse, 1. Semester
6.1 Generelles
Während des Brainstormings arbeitete man sich parallel auch in die notwendigen APIs und den für
die Verbindung als Modell genutzten BlueChat14 ein. Dabei wurde festgestellt, dass eine direkte Ma-
nipulation der Bluetooth-Algorithmen zur Pico- und Scatternetzkonstruktion nicht möglich ist. Die
bereits angesprochene acceptAndOpen()-Methode liefert eine L2CAP-Connection zurück und damit
eine direkte logische Verbindung - einen Socket. Diese Methode ist allerdings vollständig abgekapselt
und verbietet jegliche Einmischung in die Baseband-Ebene. Im Übrigen gibt es auch keine API, die
Funktionen für die Manipulierung derselben zur Verfügung steht. Es wurde sich darauf geeinigt, das
Programm ersteinmal unter Benutzung von acceptAndOpen() zu realisieren, da die darüberliegenden
Schichten, die zum Verbindungsaufbau nötig sind, ohnehin kompliziert genug sind.
Daraus folgte natürlich, dass ein nutzbringender Einsatz des ns2-Netzwerk-Simulators vorerst nicht
möglich war15.
Während des Sichtens der APIs wurde weiterhin festgestellt, dass Java eigentlich kein direktes Spei-
chern zulässt - für eine P2P-Anwendung recht hinderlich. Normalerweise laufen Java-Anwendungen im
Sandbox-System, d.h., dass ein Speichern zwar möglich, aber nur innerhalb des Programmes zugelassen
ist. Da wir aber die Dateien auf dem Endgerät direkt versenden und empfangen wollten, ohne dafür
extra Kopien anlegen zu müssen, bedeutete das ein Problem.
Es gab zwei Alternativen: Die erste war, in C++ und für Symbian-Endgeräte zu programmieren. Das
Symbian-Betriebssystem erlaubt einen direkten Speicherzugriff und wäre damit eine (workaround-) Lö-
sung gewesen. Die zweite Alternative wäre, das Programm zu signieren lassen, da dies ebenfalls einen
direkte Zugriff erlaubt.
Glücklicherweise erschien wenig später mit der JSR 75 eine Spezifikation, die das direkte Schreiben
auf dem Filesystem des Endgerätes nach Benutzereinwilligung auf normalen Endgeräten ohne weitere
Probleme zulässt. Wir entschieden uns deshalb für Letzteres.
Anfängliche Schiwerigkeiten gab es auch wegen dem Wireless ToolKit (WTK), der erst nur in der
Version 2.1 verfügbar war. Diese Version unterstützt kein Bluetooth. Glücklicherweise kam auch hier
kurze Zeit später der WTK 2.2 heraus, sodass wir damit auch keine Probleme mehr hatten.
6.2 Anwendungsebene
Beim Umwandeln von Variablen, bzw. Datenstrukturen in ein Bytearray zum Versenden über das BT-
Baseband und zurück traten einige Probleme auf:
1. Die eindeutige Länge fehlte.
2. Zugriff auf einzelne Bytes eines Integer- oder Long-Wertes war nicht möglich.
3. Bei komplexeren Datentypen gibt es keine Möglichkeit diese als ein Objekt zum ByteArray zu
konvertieren.
4. Bei einer einfachen Umwandlung eines Arrays oder eines Vektors in Form eines ByteArrays ist es
schwierig die einzelne Werte aus diesem ByteArray wieder zu extrahieren.
Die Probleme wurden wie folgt gelöst:
14 BlueChat ist ein Freeware-Programm, das einen Text-chat via Bluetooth ermöglicht. Der Autor ist Ben Hui, weitere
Informationen gibt es unter http://www.benhui.net/bluetooth.
15 Der Netzwerksimulator sollte ursprünglich dafür eingesetzt werden, einen Scatternetzalgorithmus zu entwerfen. Da
wir im zweiten Semester einen bereits vorhandenen verwendeten, wurde der Simulator dadurch überflüssig.
21
6.2 Anwendungsebene 6 ERGEBNISSE, 1. SEMESTER
1. Eine universelle statische Methode, die es ermöglicht, primitive, sowie komplexere Datentypen
mit Hilfe von festgelegten Steuerzeichen aus einem ByteArray korrekt auszulesen.
2. Die Länge kann variieren. Das Einlesen einer Dateneinheit (Integer-wert, String...) wird mit erstem
Auftreten eines „Start-Steuerzeichen” begonnen und endet sobald ein "Stopp-Steuerzeichen"
ausgelesen wird.
3. Alle primitiven Datentypen werden zunächst in eine Zeichenkette umgewandelt. Anschliessend
werden die ASCII Werte dieser Zeichenkette in ein Bytearray geschrieben.
4. Ein komplexer Datentyp wird als eine Abfolge von primitiven Datentypen interpretiert. Ein-
zelne Elemente des komplexen Datentyps werden in dem ByteArray mit einem "Aufzählung-
Steuerzeichen" getrennt.
5. Ähnlich wie bei komplexen Datentypen werden auch die Elemente eines Arrays oder eines Vektors
durch spezielle "Trenn-Steuerzeichen" getrennt.
Ursprunglich war geplant, dass sich der DownloadManager für die Pakete Upload und Upload_Start
registrieren sollte. Diese Pakete werden nur noch vom EigeneDateienManager empfangen. Wenn der
EigeneDateienManager ein Upload_Start-Paket bekommt oder der Download abgeschlossen ist,
werden beim DownloadManager die entsprechenden Methoden aufgerufen.
Erst war angedacht, dass Dateien sequentiell übertragen werden, und dass das Startbyte aufgrund der
übertragenen Daten laufend aktualisiert wird. Da nicht sichergestellt werden kann, dass die Upload-
Pakete in der richtigen Reihenfolge ankommen, sodass ein Array angelegt wird, das verwaltet, wel-
che Dateiensegmente bisher übertragen worden sind (rohDatenTeile[]). Bei der jetzigen Model-
lierung enthält die DownloadAnforderung ein Startbyte von Typ long. Da wir während der Imple-
mentierungsphase die Schnittstellen nicht wesentlich ändern wollten, berechnen wir das Startbyte aus
rohDatenTeile[].
Beim EigeneDateienManager gab es Probleme beim Empfangen von Upload-Paketen. Ursprünglich
war geplant, dass die Rohdaten einer Datei komplett gelesen werden und in einem Upload-Paket ver-
schickt werden. Da aber der Speicher bei mobilen Endgeräten stark begrenzt ist und der Speicher des
Emulators bei größeren Dateien nicht mehr ausgereicht hat, musste eine Alternative gefunden werden.
Die Dateien werden jetzt in Teilstücken versendet und müssen dann vom EigeneDateienManager
wieder zusammengefügt werden. Ursprünglich war geplant, eine temporäre Datei im Dateisystem zu
erstellen, die dieselbe Größe wie die zu übertagende Datei hat. Dies sollte gewährleisten, das man an-
kommende Upload-Pakete in beliebiger Reihenfolge in das Dateisystem schreiben kann.
Das Vergrößern der Datei auf die Zielgröße war in Tests aber viel zu ineffizient (das Erstellen ei-
ner 3MB großen Datei hat ca. 15 Minuten gedauert) sodass, die Upload-Pakete jetzt immer in der
richtigen Reihenfolge geschrieben werden müssen.
Ein weiteres Problem ist, dass einige Aufrufe der FileConnection-API unter Windows nicht funktio-
nieren. So funktioniert der Aufruf von z.B. rename() nicht. Dies hat zur Folge, dass unter Windows
Systemen z.B. die Dateien nicht umbenannt werden können. Unter dem WTK 2.2 für Linux funktioniert
der Aufruf von rename() hingegen ohne Probleme.
In der Entwurfsphase planten wir, die Datei, die übertragen werden sollte, in eine unserer "Upload-
Nachrichten" zu packen. Bei der Implementierung wurde deutlich, dass dies bei großen Dateien den
Arbeitsspeicher des Geräts überlasten kann. Aus diesem Grunde teilten wir den Versand einer Datei in
mehrere UploadNachrichten auf.
22
6.3 Netzwerkebene 6 ERGEBNISSE, 1. SEMESTER
6.3 Netzwerkebene
Ganz am Anfang war angedacht, dass SkyNet alle von unten empfangene Pakete nach oben an ei-
ne einzige Klassen weiterleiten sollte. Sehr früh stellte sich das als unpraktikabel und hinderlich raus,
da sonst die Klasse Programm die Rolle eines Verteilers hätte annehmen müssen (→Bottleneck). So
entschieden wir uns dafür, alle Manager ein Interface implementieren zu lassen und dieses dafür zu
benutzen, die richtigen Pakete an die richtigen Klassen routen zu lassen16.
Während der Datenübertragung kam es zu Problemen, die zu nicht mehr lesbaren ZIP-Archiven und
korrumpierten MP3-Dateien führten. Die Ursache war ein Parsefehler von einem Object in ein Byte-
Array in der Sender-Queue, bei dem Fragezeichen falsch geparset wurden. Als Lösung wurde eine neue
Klasse implementiert, die den Adressaten und das Paket hält. Dadurch wird verhindert, dass beide in
das Object-Array erst eingefügt werden.
Ein weiteres Problem war, dass zu viele Threads auf dem Endgerät später laufen würden. Wenn für
jedes andere Gerät zwei Threads (Sender, Empfänger) laufen, sind das schon bei 8 Teilnehmern im
Netz 16 Threads. Als Antwort darauf wurden alle Sender-Threads zu einem einzigen Thread gebündelt,
der zusätzlich zu der Nachricht auch noch den Empfänger bekommt. Die Empfänger-Threads dagegen
blockieren sich automatisch, wenn keine Nachricht auf ihrem Link anliegt. Dadurch wird ein effizientes
Link-Scheduling gesichert.
Außerdem gab es noch das Problem, dass sich das empfangende Gerät nicht an die Maximum Re-
cieve MTU17 gehalten hat. Dadurch gab es große Löcher in den Daten, wenn der Sender weniger
geschickt hat, als der Empfänger erwartete. Die Lösung war, die MTU nicht manuell zu setzen, son-
dern sich das Gerät selbst darum kümmern zu lassen.
Während der Planungsphase hatte sich die Projektgruppe dazu entschieden, für den Datenverkehr
eine paketbasierte Verbindungsart zu benutzen, die bei Bluetooth L2CAP18 heisst. Keine streambasier-
te Verbindung zu nehmen hatte den Hintergrund, dass L2CAP laut Spezifikation Flusskontrolle und
Retransmission (etwa bei fehlerhaft übertragenen Paketen) zur Verfügung stellt. Bei der Implementie-
rung traten dann allerdings zwei Probleme auf: Zum einen war es uns aufgrund des sehr begrenzten
Arbeitsspeichers unmöglich, vollständige Dateien zu verschicken, da diese über L2CAP als ByteArray
verschickt werden müssen (es gibt keine andere Methode). Wegen des beschränkten Arbeitsspeichers
im mobilen Endgerätes, können nur Arrays bis zu einer bestimmten Größe (etwa 50KB) erstellt werden.
Das zweite Problem war, dass J2ME nicht die Fragmentierung großer Dateien übernimmt, um der
MTU gerecht zu werden. Letzteres Problem war relativ einfach zu lösen. Mit Hilfe einer Methode lässt
sich die MTU einer Verbindung abfragen. Es wurde somit ein kleines Array mit Größe der MTU erzeugt
und dieses mit den Daten des ByteArray, welches von höheren Schichten an die Netzwerkschicht wei-
tergereicht worden war, gefüllt und dann verschickt. Diesen Vorgang wiederholten wir solange bis das
komplette ByteArray mittels kleiner, MTU-großer Pakete verschickt worden war. Für den Rest eines
großen Paketes, also für die letzten Bytes, die in der Regel kein ganzes Array mehr füllten, wurde ein
eigenes Array mit entsprechender Größe initialisiert und verschickt.
Auf der Empfängerseite mussten nun die Einzelteile wieder zusammengefügt werden und in einem
großen ByteArray an die höheren Schichten weitergeleitet werden. Dazu muss allerdings die Größe
bekannt sein um ein entsprechendes Array zu initialisieren und vor allem, um zu wissen, wieviele Bytes
von der Leitung gelesen werden sollen bzw. wie oft auf ein MTU-großes Paket gewartet wird und wie
großdann das "Restpaket" ist. Aus diesem Grund entschlossen wir uns vor jedem Paket ein 5-Byte-
16 Siehe Abschnitt über Programmdesign, S. 18
17 Maximum Transmission Unit - stellt die maximale Paketgröße dar, die auf einmal über eine L2CAP Verbindung
geschickt werden kann
18Logical Link Control and Adaptation Protocol
23
6.3 Netzwerkebene 6 ERGEBNISSE, 1. SEMESTER
großes Paket zu verschicken19, in dem die Größe der folgenden Übertragung kodiert ist. Auf dieses
wartet die Empfängerseite blockierend und fährt nach dem Erhalt dieses Paketes fort.
Das zweite zu lösende Problem war das Aufsplitten der Datei. Da große Pakete eine gewisse Zeit
zur Übertragung brauchen, wir aber nicht das komplette Programm in einen Wartezustand legen woll-
ten wenn ein großes Paket verschickt wird, führten wir eine Wartequeue für Pakete ein. Da wir aber
wussten, dass zu große ByteArrays den Arbeitsspeicher des mobilen Endgerätes überfordern würden,
mussten wir sicherstellen, dass immer nur ein Uploadpaket (alle anderen Pakete sind relativ klein) in
der Sendequeue steht. Da aus Architekturgründen die Netzwerkschicht aber die Pakete nicht einsehen
darf, um herauszufinden ob es sich um ein Uploadpaket handelt, musste sich eine obere Schicht mer-
ken, an welcher Stelle das Uploadpaket in der Sendequeue befindet. Als Lösung wollten wir die Größe
der Sendequeue in einer Variablen abspeichern, nachdem das Paket eingefügt worden war, und diese
Position jedesmal im 1 dekrementieren, wenn das Netzwerk eine Meldung gab, ein Paket verschickt zu
haben. Wenn die Position dann von 1 auf 0 gesetzt wurde, würde der Uploadmanager benachrichtigt
werden, dass er das nächste Uploadpaket in die Sendequeue einfügen darf. Dabei trat ein weiteres
Problem auf.
Nachdem das zweite Uploadpaket verschickt worden war, bekam der Upload-Manager keine Nach-
richt mehr zugeschickt. Merkwürdigerweise trat dieser Fehler bei einem Mitglied der Projektgruppe
nicht auf, während er bei allen anderen reproduzierbar war. Nach einer langen Reihe von Tests fand
sich das Problem bei der Geschwindigkeit des Sender-Threads: Wie oben erwähnt speicherten wir die
Position nachdem das Paket in der Sendequeue eingetragen worden war. Allerdings war der Thread so
schnell, dass das Paket schon verschickt war, bevor wir auf die Länge der Queue zugriffen. Das führte
dazu, dass wenn kein weiteres Paket in der Sendequeue stand die Position 0 abgespeichert wurde. Der
Downloadmanager wurde aber nur benachrichtigt, wenn die Variable den Wert 1 hatte, also das Paket
an erster Stelle gestanden hatte. Der Fehler wurde beseitigt indem die Queueposition vor dem Einfügen
berechnet wurde (Länge der Queue plus eins).
19L2CAP ist ein paketorientiertes Verfahren, kein streamorientiertes. Das bedeutet, dass man nicht einfach alle Daten
komplett in einen großen Strom bündeln und übertragen kann, sondern sie in entsprechende Stücke partitionieren muss.
24
7 ERGEBNISSE, 2. SEMESTER
7 Ergebnisse, 2. Semester
7.1 Implementierung des TSF Algorithmus
Da die J2ME-Spezifikation uns keine Möglichkeit bot, einen Scatternetzalgorithmus auf physikalischer
Ebene zu implementieren, haben wir eine Adaption auf logischer Ebene vorgenommen.
Die Spezifikation bietet keine Einflussmöglichkeiten auf die Inquiry-Phase der Geräte. Es werden alle
erreichbaren Geräte in eine Geräteliste eingetragen und anschließend in der ServiceDis-covery-Phase
überprüft, ob diese unser Programm unterstüzten. Da es sich bei den Methoden um vom Listenerinter-
face DiscoveryListener vorgeschriebene Methoden handelt, können wir erst nach der Inquiryphase mit
der Auswahl der möglichen Verbindungen ansetzten.
Wir haben die Geräte, die in der Inquiryphase gefunden wurden, zunächst daraufhin geprüft, ob be-
reits Verbindungen bestehen. Wenn dies der Fall ist, wird das Gerät sofort verworfen. Alle Geräte, zu
denen noch keine Verbindung besteht, werden zur Geräteliste andereGeraete im Netzwerk hinzugefügt.
Diese Liste wird an die Klasse Verwaltungsmanager, die die gesamte Verwaltung der Verbindungen
übernimmt, übergeben.
Dem Verwaltungsmanager stehen verschiedene Typen von Verwaltungspaketen zur Verfügung, über
die die Kommunikation im Scatternetz bzgl. des Verbindungsaufbaus geregelt wird. Nach der Inquiry-
phase wird anhand der aktuellen Rolle des Gerätes entschieden, wir weiter verfahren wird.
Ein freier Knoten muss nach der Inquiryphase erst die Geräte in der dem Verwaltungsmanager überge-
benen Geräteliste durchgehen und jedem eine Anfrage als Verwaltungspaket zum Verbindungsaufbau
senden. Erst, wenn ein Knoten eine Antwort auf diese Anfrage erhalten hat, wird das Gerät, welches
positiv geantwortet hat, in die endgültige Geräteliste ElterundKinder im Netzwerk eingefügt und als
Elter gekennzeichnet. Zu allen anderen Geräten, die in der andereGeraete-Liste standen, wird die phy-
sikalische Verbindung geschlossen und die Referenzen auf die Geräte gelöscht.
Nach diesem Prinzip wird auch nach Ende einer Inquiry eines Koordinatorknotens auf der Suche nach
anderen Koordinatoren und Wurzelknoten auf der Suche nach der physikalischen Verbindung zu der zu
verschmelzenden Wurzel verfahren.
Wenn BBH-Nachrichten über das Scatternetz geroutet werden müssen, darf das Gerät nur an seine
direkten Kinder und seinen Elter senden. Diese Geräte befinden sich in der Geräteliste ElterundKinder.
Soll eine Nachricht zu weiter im Baum entfernten Geräten geroutet werden, wird der Knoten, über den
geroutet werden muss, mit Hilfe des Routingprotokolls bestimmt.
7.2 Adaption des BTR Protokolls
Das BTR Protokoll wurde in der Klasse Verwaltungsmanager implementiert. Dieser hält eine Instanz
der Klasse Routingtabelle, welche die aktuellen Bluetoothadressen der topologisch darunterliegenden
Kinder und Kindeskinder verwaltet. Die Routingtabelle beinhaltet eine Liste, in der sich immer sieben
Einträge befinden. Der siebente Eintrag beinhaltet ein Stringarray, in dem die Bluetoothadressen der
direkten Kinder und Kindeskinder eines direkten Kindes gespeichert sind. Zusätzlich zu den Bluetoo-
thadressen werden die Anzahl der Hops gespeichert, d.h. wie weit die Knoten entfernt sind.
Wenn sich ein neues Gerät an einen Baumknoten anschließt, wird die BT-Adresse dieses Geräts als di-
rektes Kind in die Routingtabelle des Baumknotens eingetragen. Es wird eine RoutingUpdate-Nachricht
an den Elter geschickt, der die aktuelle Routingtabelle enthält. Der Elter ändert an der entsprechenden
Stelle seine Routingtablelle und leitet das RoutingUpdateConnect an seinen Elter weiter. Dieser Vor-
gang wird fortgeführt, bis die Wurzel des Baumes erreicht ist.
25
7.3 Adaption an den Scatternetzalgorithmus 7 ERGEBNISSE, 2. SEMESTER
Wenn ein Gerät bemerkt, dass die Verbindung zu einem direkten Kind abgebrochen ist, entfernt er des-
sen BT-Adresse aus seiner Routingtabelle und benachrichtigt seinen Elter durch eine
RoutingUpdateDisconnect-Nachricht, welche wie die RoutingUpdateConnect-Nachrichten bis zur Wur-
zel hochgereicht werden muss.
Wenn eine Nachricht empfangen wird und die Zieladresse nicht die eigene BT-Adresse ist, wird in
der Routingtabelle nach der Zieladresse gesucht. Die Routingtabelle liefert die BT-Adresse des direk-
ten Kindes, in dessen Teilbaum sich das gesuchte Gerät befindet. An dieses Gerät wird die Nachricht
gesendet.
7.3 Adaption an den Scatternetzalgorithmus
Um die korrekte Funktionsweise des Scatternetzalgorithmus garantieren zu können, mussten wir eine
neue Nachrichtenform modellieren und implementieren. Diese haben wir „Verwaltungspaket“ genannt.
Wir unterscheiden zwischen Verwaltungsnachrichten, die ausschließlich dem Scatternetzalgorithmus
zur Verfügung stehen und sich in der Netzwerksicht befinden, und unsere vorherigen Nachrichtentypen
BBH-Nachrichten, die unserer Applikationsschicht angehören.
Sowohl BBH-Nachrichten, als auch Verwaltungsnachricht erben von der Klasse „Nachricht“. Die bis-
her für die eindeutige Konvertierung genutzte Methode byteArrayToObjects() wurde in die Klasse
Nachricht verschoben. Der Aufbau von BBH-Nachrichten und Verwaltungsnachricht sind identisch. Al-
lerdings sollte es eine klare Trennung zwischen Netzwerknachrichten(VerwaltungsPaket) und Nachrich-
ten auf der Applikationsebene(BBHNachricht) geben. Die Standard-Attribute (physikalische Adressen
des Initiators, des Senders und eigene Adresse) und einige Konstanten wurden in die Klasse Nachricht
verschoben.
Im Unterschied zu BBH-Nachricht, wird im Verwaltungspaket kein Typ der Nachricht aus der Sicht der
Vererbung beachtet. Aus Kompatibilitätsgründen wird dieser bei der Umwandlung in den Datenstrom
dennoch gesetzt.
Um eine Verwaltungsnachricht von einer BBH-Nachricht zu unterscheiden, werden alle anstehenden
Nachrichten in der Netzwerkschicht unmittelbar vor dem Absenden mit einem voranstehenden Bit
ergänzt. Dies ermöglicht eine frühzeitige Erkennung einer Verwaltungsnachricht auf der Seite des Emp-
fängers. Aus diesem Grund wurde auch die Methode toStream() ebenfalls zu der Klasse Nachricht
verschoben und als abstrakt gekennzeichnet.
Über das Attribut nachrichtTyp_ der Verwaltungsnachricht kann übermittelt werden, für welchen
Zweck die Nachricht eingesetzt wird. Alle möglichen Aufgaben (Zwecke) wurden als Konstanten ein-
deutig festgelegt und in der Klasse VerwaltungsNachricht abgelegt. Zusätzlich wird noch im Attribut
rolle_ die eigene Bluetooth-Rolle, ob das versendende Gerät ein Master oder Slave ist, kodiert.
7.4 Backup-Server
Die Implementierung des Backup-Servers verlief größtenteils ohne Probleme. Wir haben die Java-
Klassen des J2ME-Programmes übernommen und lediglich den Sender und den Empfänger für die
Server-Version angepasst. Das Resultat war ein zweites Programm, das als Standalone auf dem Server
aufgesetzt wird und auf Verbindungen wartet. Die Kommunikation läuft über standard-TCP/IP.
7.5 Erweiterte Suche
Im ersten Semester war die Suche auf die OR-Suche beschränkt, und es konnten keine Substrings ge-
funden werden (z.B. bei der Suche nach "text", wurde "meintext" nicht gefunden).
26
7.5 Erweiterte Suche 7 ERGEBNISSE, 2. SEMESTER
Die erste Erweiterung ist die AND-Suche. Um die bestehende Struktur so wenig wie möglich zu verän-
dern, haben wir die Unterscheidung zwischen AND- und OR-Suche über das erste Keyword, das in der
Suchanfrage verschickt wird, vorgenommen. Auf dem Bildschirm „Neue Suche" kann man jetzt die Art
der Suche festlegen. Wenn dort AND angewählt ist, trägt die GUI automatisch in dem Keyword-Array,
welches über das SuchAnfrage-Paket verschickt wird, das "keyword" AND an der ersten Stelle ein. Bei
der OR-Suche steht an der ersten Stelle entsprechend das Keyword OR.
Auf der Gegenseite wird beim Empfang einer SuchAnfrage im EigenenDateienManager die Metho-
de sucheKeywords() aufgerufen, welche eine SuchAntwort zurückliefert. Hier wird immer zwischen
der AND- und OR-Suche unterschieden.
Der wesentliche Unterschied zum ersten Semester liegt darin, dass wir anstatt der Methode
gibDateiname() die neu implementierte Methode gibAlleIndexEintraegeZuKeyword() benutzen.
Die Methode gibAlleIndexEintraegeZuKeyword() wurde hauptsächlich deswegen hinzugefügt, da-
mit wir die Substring-Suche realisieren können. Bei einer Suche ohne Substring-Unterstützung kann es
pro Keyword immer nur einen Treffer (MatchListenEintrag) in der SuchIndexListe geben. Nun ist es
aber möglich, dass ein Keyword (z.B. text) innerhalb mehrerer MatchlistenEintraege (z.B. meintext,
neuertext, unseretexte) vorkommt. Dazu liefert die Methode "gibAlleIndexEintraegeZuKeyword" einen
Vector mit allen gefundenen MatchListenEintraegen zurück. Für die Substring-Suche haben wir die
Methode indexOf(String), die in J2ME enthalten ist, benutzt.
Während der Debugging-Phase traten einige Probleme auf:
• SuchAntwort/hinzufuegenSuchAntwortEintrag: mit jedem hinzufuegen eines SuchAntwortEin-
trags bei einer SuchAnwort wurde die Anzahl der SuchAntwortEintraege verdoppelt.
• EigeneDateienManager/SucheKeywords: in einigen Fällen hat die Methode sucheKeywords()
eine NullPointerException verursacht, die dazu führte, dass ein Knoten zum freien Knoten wurde.
7.5.1 ID3-Tags
Zum besseren Auffinden von Audiodateien im "mp3"-Format wurde beschlossen, die ID3-Tags zusätz-
lich aus den mp3-Dateien zu extrahieren. Zum jetzigen Zeitpunkt werden dennoch nur die ID3-Tags
gemäßVersion 1.0 unterstützt. Der Unterschied der beiden Versionen 1.0 und 2.x liegt in der festen
Position von Tags innerhalb der Datei. Da bei der Version 2.x die Feldgröße der Tags und dement-
sprechend die Position dynamisch ist, hätte ein Algorithmus zum Auslesen die Rechenleistung eines
mobilen Geräts überlastet.
Als erstes wurde die Klasse ID3 realisiert, die den Titel, den Interpreten und Albumnamen zu ei-
nem Dateinamen ausliest. Um die Implementierung schlank zu halten, werden die ID3-Tags als String
mit dem vorhandenem Dateinamen konkateniert um anschließend die vorhandenen Methoden zum
Keyword-Generieren benutzen zu können.
Schwierigkeiten der Implementierung traten beim Positionieren des Zeigers innerhalb des Inputstreams
einer Datei auf. Leider funktionierte die J2ME-eigene Methode zum selben Zweck nicht ordnungsge-
mäß. Hilfreich war dort die noch im ersten Semester implementierte Methode positioniereStream()
aus der Klasse EigeneDateienManager.
7.5.2 Upload-Prioritäten und Credit-System.
Eine Möglichkeit das Download/Upload-System fair zu organisieren, bietet das bereits erprobte Credit-
System, welches erfolgreich bei p2p-Netzwerken wie eMule eingesetzt wird, gute Ansätze. Der Gedanke
dabei ist folgender: die Warteschlange zum Upload beim Uploader wird nach Punkten (Credits) sor-
tiert, welche für bereits hochgeladene Datenmengen, Wartezeit vom Uploader und der jeweiligen Da-
27
7.6 BBH-LightTM 7 ERGEBNISSE, 2. SEMESTER
teipriorität der gewunschten Datei vergeben werden. Die Punkte werden für jeden Peer, bei welchem
heruntergeladen wurde, beim Empfänger gespeichert. Z.B. ein Peer A lädt eine Datei "datei1" beim
Peer B, eine Datei "datei2" beim Peer C und eine Datei "datei3" beim Peer D. Somit bekommen die
Peers B, C und D beim Peer A die Punkte. Dennoch handelt es sich um ein lokales System, d.h. nach
dem ein Gerät das Programm verlassen hat, gehen die Credits verloren.
Die Formel zur Berechnung lautet:
CREDITS = WARTEZEIT × MODIFIER × DATEIPRIORITÄT
• WARTEZEIT ist die Zeit seit dem Eintragen des Peers in die Warteschlange.
• MODIFIER = 2 × UPLOADUMFANG / DOWNLOADUMFANG
• DATEIPRIORITÄT wird direkt aus der GUI vom Benutzer vergeben.
Demnach wurde die Klasse Peer um weitere zwei Attribute anzahlAngekommene-Pakete_ und anzahl-
VersendetePakete_ erweitert. Diese werden immer dann hochgezählt, sobald ein neues Datenpaket
ankommt und vom EigeneDateienManager verarbeitet wurde (anzahlAngekommenePakete), oder falls
ein Paket versandt wird (anzahlVersendetePakete). Die Klasse UploadEintrag wurde um Attribut ein-
tragszeit_ erweitert, um die entsprechende Wartezeit ermitteln zu können (Wartezeit = Aktuelle Zeit
- Eintragszeit). Die Creditsberechnung erfolgt mit der neuen Methode der Klasse UploadEintrag.
Nach einem abgeschlossenem Upload werden die Credits für alle DownloadEintraege neu berechnet
und die UploadListe wird neu sortiert (dafür wurde der Quicksort-Algorithmus implementiert).
7.6 BBH-LightTM
Diverse Testergebnisse führten während unserer Arbeit zu der Annahme, dass das WirelessToolkit in
einigen Bereichen noch nicht ganz ausgereift war und sich reale Geräte entsprechend anders verhalten
würden. Da uns bei der Suche nach geeigneten Testgeräten (mit JSR 75 Unterstützung) die Projekt-
leitung nicht helfen konnte, entstand die Idee, eine BBH-Light-Version zu entwerfen, die auch auf uns
verfügbaren Endgeräten laufen würde.
Zu diesem Zweck wurden alle JSR 75 Anteile aus dem BBH-Projekt entfernt und das übrige Programm
entsprechend angepasst. Am Ende stand eine abgespeckte Version des BBH-Projektes zur Verfügung,
mit der zwar kein Datenaustausch stattfinden konnte, aber immerhin das reale Bluetoothverhalten ge-
testet werden konnte. Als Testgeräte standen drei Nokia 6230 und ein Siemens S65 zur Verfügung.
Hier die zusammengefassten Ergebnisse unserer Tests:
1. Die realen Endgeräten hatten kein Problem damit, das Bluetooth-Netz erneut aufzubauen, nach-
dem das Master-Gerät ausgeschaltet wurde. Dies ist ein entscheidender Unterschied zum WTK
Emulator 2.2, der nach der Schließung des Master-Gerätes den Dienst versagte.
2. Die Nokia Geräte haben nur die Möglichkeit, eine eins-zu-eins-Verbindung herzustellen. Diese
Beobachtung wurde bei der darauffolgenden Recherche im Nokia Developer Forum bestätigt.
Nokias Serie 60 Geräte können hingegen Point-to-Multipoint-Verbindungen verwalten. Ebenso
das S65.
3. Das Auffinden von Geräten und Eintragen in die Geräteliste funktionierte wie erwartet und kon-
form zum Emulator.
28
8 LEISTUNGSMESSUNGEN
8 Leistungsmessungen
Die Messungen wurden auf einem Windows-Rechner P4 durchgeführt. Die Werte gelten für die simu-
lierten Geräte und können mit denen auf realen Geräte abweichen.
8.1 Anwendungsfälle
8.1.1 Freigabe von Dateien
Eine Datei wird freigegeben, damit andere Peers sie laden können. Während diesem Vorgang wird die
Datei auch gehasht und entsprechende Suchdaten extrahiert.
• Kleine Dateien (< 5 MB) < 50 sek.
• Mittlere Dateien (5 MB - 10 MB) 50 sek. - 1min 57 sek.
• Große Dateien (> 10 MB) > 1min. 57 sek.
8.1.2 Suche von Dateien
Dateien werden im Netzwerk nach Keywords gesucht. Jeder Peer muss dabei eine komplette Liste seiner
freigegebenen Dateien durchgehen und nach den entsprechenden Wörtern suchen.
• Kleine Dateien( < 5 MB) < 2 sek.
• Mittlere Dateien (5 MB - 10 MB) < 2 sek.
• Große Dateien ( > 10 MB) < 2 sek.
8.1.3 Download von Dateien
Ein Datei wird von einem Client zu einem anderen Übertragen. Dies kann direkt oder über mehrere
Hops geschehen.
• Kleine Dateien (< 5 MB), einzeln < 1min 35 sek.
• Mittlere Dateien (5 MB - 10 MB), einzeln 1min 35sek. - 3min 09 sek.
• Große Dateien (> 10 MB), einzeln > 3min 09 sek.
• Kleine Dateien (< 5 MB), mehrere < 3min 40 sek.
• Mittlere Dateien (5 MB - 10 MB), mehrere 3min 40sek. - 5min 38 sek.
• Große Dateien (> 10 MB), mehrere > 5min 38 sek.
8.1.4 Resume von Dateien
Ein Dateidownload wurde pausiert (manuell oder durch Verbindgunsabbruch). Zu einem Resume wird
eine erneute Suchanfrage in das Netz geschickt und der beste Peer mit der vorrätigen Datei gewählt
und für einen Download angesprochen.
• Download wiederaufnehmen kleiner Dateien (< 5 MB) < 8 sek.
• Download wiederaufnehmen mittlerer Dateien (5 MB - 10 MB) < 8 sek.
• Download wiederaufnehmen großer Dateien (> 10 MB) < 8 sek.
29
8.1 Anwendungsfälle 8 LEISTUNGSMESSUNGEN
8.1.5 Tree Scatternet Formation
Gestartete Endgeräte verbinden sich zu einem großen Baum mittels TSF. Es wird getestet, wie lange
es dauert, bis ein neuer Client in das Netzwerk eingebunden wird, sich zwei separate Bäume zu einem
großen verschmelzen und ein beschädigtes Netz sich selbständig wieder heilen kann.
• Anschluss Freierknoten < 7 sek.
• Baumverschmelzung < 15 sek.
• Scatternetz-Heilung < 15 sek.
30
9 DIAGRAMMBESCHREIBUNGEN, 1. SEMESTER
9 Diagrammbeschreibungen, 1. Semester
9.1 Anwendungsfalldiagramm
Das Anwendungsfalldiagramm weist drei Akteure auf: Benutzer, System und den Fallback-Server. Der
Benutzer kann seine eigenen Dateien managen, wie etwa eine Datei freigeben und sie wieder sperren,
oder eine Auflistung seiner freigegebenen Dateien sehen. Zusätzlich kann er nach Dateien suchen und
sie downloaden. Die Downloads können gestartet/fortgeführt, abgebrochen und angehalten werden.
Alle diese Anwendungsfälle fallen unter dem Oberanwendungsfall "Dateien austauschen". Zusätzlich
fallen unter diesen Anwendungsfall das Managen von einkommenden Verbin-dungen, sprich Uploads
einsehen und upload abbrechen.
Der Akteur System muss auf Such- und Downloadanfragen reagieren. Darüberhinaus muss er sich
um den Aufbau und die Aufrechterhaltung der Verbindung kümmern.
9.2 Aktivitätsdiagramme
9.2.1 Suchanfrage erstellen
Bei der Suchanfrage werden Keywords eingegeben. Zuerst werden sie auf ihre Korrekheit überprüft. Bei
falschen Eingaben wird erneut aufgefordert die Suchwörter einzugeben. Anderfalls wird die Verbindung
geprüft und aufgebaut, wenn dies noch nicht getan wurde. Anhand der Keywords, der GeräteID und
der SuchID wird die Suchanfrage generiert und anschließend geschickt. Der nächste Schritt startet den
Timer und wartet auf Antworten. Solange der Timeout noch nicht erreicht wird, bleibt man in diesem
Zustand. Falls jedoch der Timeout erreicht wird und keine Antwort erhalten wurde, wird der Fallback-
Server eingeschaltet. Beim Erhalt einer Antwort wird sie auf die richtige ID überprüft. Wenn eine
falsche SuchID vorliegt, wird in den wartenden Zustand zurüchgekehrt. Bei richtiger SuchID, werden
die Antworten in die Ergebnisliste eingetragen und angezeigt. Weiterhin wird auf weitere Antworten
gewartet falls der Timeout noch nicht abgelaufen ist, ansonsten ist man am Ende der Suchanfrage
gelangen.
9.2.2 Download starten
Es wird hierbei davon ausgegangen, dass nach einer erfolgreichen Suche ein Download zu Download-
Liste hinzugefügt und nicht mit SofortStarten gestartet wurde. Eine erneute Broadcast-Anfrage wird
nochmals versendet und auf einen Treffer gewartet. Hier gibt es die Möglichkeit, zum Fallback-Server
auszuweichen. Falls genug Speicherplatz zur Verfügung steht, wird eine Sendeaufforderung an Da-
teianbieter abgeschickt und auf eine Antwort mit QueuePosition 1 gewartet. Schließlich werden die
Nutzdaten übertragen, auf Platte gespeichert, und die Datei aus Downloadliste entfernt und zu Frei-
gabeliste hinzugefügt.
9.2.3 Auf Suchanfrage Reagieren
Dieses Diagramm wurde im EigeneDateienManager implementiert. Es beschreibt die Reaktion des
Programmes wenn ein SuchAnfrage-Paket im System eintrifft. Das Programm wartet in einer Schleife,
bis eine Suchanfrage eintrifft. Die angekommene Suchanfrage wird dann verarbeitet, indem in der
SuchIndexListe überprüft wird, ob diese Datei vorhanden bzw. freigegeben wurde. Danach wird die
Queue Position ermittelt und eine passende SuchAntwort generiert und verschickt.
9.2.4 Auf DownloadAnfragen reagieren
Dieses Diagramm beschreibt die Dateianbieterperspektive und die diversen Aktivitäten beim Empfang
von bestimmten Nachrichten. Bei DownloadAnfragen wird mit dem Versand einer DownloadAntwort
reagiert. Bei DownloadAnforderungen (Sendeaufforderungen) wird die Anforderung in die UploadListe
(Queue) aufgenommen und gegebenenfalls wird die Datei versendet. Bei Uploadabbrüchen durch eine
31
9.3 Problembereichsmodell 9 DIAGRAMMBESCHREIBUNGEN, 1. SEMESTER
der beiden Seiten sowie bei erfolgreicher Beendigung des Uploads wird der UploadEintrag aus der
UploadListe entfernt.
9.2.5 Verbindung aufbauen
Dies ist das Diagramm, das den initialen Aufbau aller Verbindungen beschreibt. Zuerst wird eine Re-
ferenz auf das eigene Gerät gebildet, damit damit gearbeitet werden kann. Dann werden die eigenen
Services registriert und ein Service Record kreiert. Anschließend folgt die Inquiry und Service-Search-
Phase.
Wir gehen hier eigentlich von zwei grundlegenden Zuständen aus, in denen sich das Gesamtsystem
befinden kann:
Wenn das momentane Gerät das erste ist, das das Programm gestartet hat, findet es keine weiteren Ge-
räte während der Inquiry-Phase. Alle temporären Listen bleiben leer und es öffnet mit acceptAndOpen()
die Serververbindung.
Wenn es bereits ein bestehendes Netzwerk gibt, wird durch die Inquiry und anschließende Service-
Search-Phase eine Verbindung zu den übrigen Geräten aufgebaut (und zwar nur zu denen, die auch
das richtige Programm laufen haben). Nach diesem uplink als „slave” geht das Gerät in seinen eigenen
Wartemodus und stellt sich ebenfalls als „server” zur Verfügung, indem es in acceptAndOpen() geht
und auf einkommende Verbindungen wartet.
9.2.6 Verbindung aufrechterhalten
Das Programm checkt, ob ein Server ausgefallen ist und wenn ja, ernennt einen neuen Master. Durch
das Kapselungsproblem kann das nur auf der logischen Ebene überprüft werden. Diese besteht allerdings
bei uns aus point-to-point socket Verbindungen, bei denen es keinen Master im eigentlichen Sinne gibt.
9.3 Problembereichsmodell
(siehe Klassendiagramm)
9.4 Klassendiagramm
9.4.1 Klassendiagrammbeschreibung
Um die vielfältigen Aufgaben unseres Programms besser zu strukturieren, entschieden wir uns schon
zu Beginn der Entwurfsphase für eine klassenbasierte Aufteilung - ein sogenanntes Managersystem.
Wir benutzten dabei die Unterteilung des Anwendungsfalldiagramms. Es entstanden SuchManager,
EigenDateienManager, DownloadManager und UploadManager. Im folgendem werden nur die Zusam-
menhänge zwischen den wichtigsten Klassen beschrieben. Eine ausführliche Klassenbeschreibung aller
Klassen ist im nächsten Abschnitt zu finden.
Die Kommunikation zwischen den einzelnen Managern der jeweiligen Geräte findet über verschiedene
Nachrichtentypen statt. BBHNachricht ist die Oberklasse unserer Nachrichtentypen, die jeweils von be-
stimmten Managern bearbeitet und versendet werden. Die Nachrichtentypen sind: DownloadAnfrage,
DownloadAntwort, DownloadAnforderung, DownloadAbbruch, SuchAnfrage, SuchAnwort,
Upload und UploadStart.
Der SuchManager erstellt SuchAnfragen und bearbeitet alle einkommenden SuchAntworten. Zur Ver-
waltung dieser Nachrichten benutzt er die Klasse SuchMatchListe, in der die MatchListenEinträge
gehalten werden. Zu jedem MatchListenEintrag werden die Downloadquellen mit Verweisen auf die
entsprechenden Peers gespeichert.
32
9.4 Klassendiagramm 9 DIAGRAMMBESCHREIBUNGEN, 1. SEMESTER
Der EigeneDateienManager beantwortet eingehende SuchAnfragen, speichert eingehende Downloads
und verwaltet die Dateifreigabe in der FreigabeListe. In ihr werden die Dateien gehalten.
Der DownloadManager verwaltet die Downloads unserer Anwendung. Er erstellt DownloadAnfragen
und DownloadAnforderungen. Dazu benutzt er die Klasse DownloadListe, die die DownloadEinträge
verwaltet.
Der UploadManager stellt die Gegenseite des DownloadManagers dar. Er bearbeitet eingehende Dow-
nloadAnfragen und DownloadAnforderungen. Außerdem erstellt und verwaltet er die Uploads. Um auf
die Uploads zuzugreifen, verwendet der Manager die UploadListe, die die einzelnen UploadEintraege
enthält.
Die Manager implementieren das Interface Nachrichtenmanager. Sie müssen die Methode
empfangeNachricht() implementieren, damit über diesen Methodenaufruf die Nachrichten an den
dafür vorgesehenen Manager gesendet werden kann.
SkyNet ist die Verbindung zwischen Netzwerkschicht und Applikationsschicht und leitet eingehende
Nachrichten über die Methode empfangeNachricht() an die Manager weiter, die sich zu Beginn bei
SkyNet für ihre Nachrichten registiert haben.
Programm erbt von Midlet und ist der Rumpf unserer Anwendung. Diese Klasse initialisiert alle Mana-
ger, den Timer, die GUIKontrolle und Skynet. Im Programm halten wir eine Instanz von BBHTimer, der
allen Managern zur Verfügung steht und alle Timingaufgaben unseres Programms übernimmt. BBHTi-
mer hat einen Vektor von BBHTimerEintrag, den er bei jedem Aufruf von der Methode starteTimer(),
um einen neuen Eintrag erweitert. Er besitzt weiterhin einen BBHTimerTask, welcher sekündlich über-
prüft, ob ein Zeitpunkt von einem der BBHTimerEinträgen überschritten worden ist. Falls dies der Fall
ist, wird der jeweilige Manager über den EreignisHandler benachrichtigt.
GUIKontrolle dient als visuelle Schnittstelle für den Benutzer.
Auf der Netzwerkschicht wird durch die Klasse Netzwerk ein Thread der Klasse Empfaenger für jede
eingehende Verbindung, gelinkt auf das jeweilige entfernte Endgerät erstellt. Die Endgeräte werden
in der GeraeteListe verwaltet. Zum Senden aller Nachrichten dient ein weiterer, einzelner Thread der
Klasse Sender, der je nach Bedarf aktiviert wird. Außerdem stehen die Klassen Listener und Service-
Search zur Verfügung, die die Bluetooth-spezifische Aufgaben für das Finden anderer Geräte erfüllen
(ServiceSearch, Inquiry etc.).
9.4.2 Klassenbeschreibung
Die Klassen sind semantisch geordnet in einem Top-Down-DFS.
Programm Die Klasse Programm erbt von MIDlet und ist damit die "Startklasse". Beim Programm-
start werden Instanzen von allen Mangern (DownloadManger, EigeneDateienManager, UploadManager
und SuchManager) erstellt, sowie von SkyNet und GuiKontrolle. Außerdem hält sie einen Vector aller
Peers, von denen ein Download möglich ist.
EigeneDateienManager Die Klasse EigenDateienManager implementiert das Interface Nachrichten-
Manager, um BBHNachrichten empfangen zu können. Dafür registriert sich die Klasse bei SkyNet. Der
EigenDateienManager ist zuständig für die Verwaltung der freigegebenen Dateien und des Suchindexes.
Diese Klasse enthält weiterhin eine Methode mit der der Suchindex durchsucht werden kann, um auf
eine Suchanfrage zu reagieren.
33
9.4 Klassendiagramm 9 DIAGRAMMBESCHREIBUNGEN, 1. SEMESTER
FreigabeListe Die FreigabeListe hält einen Vector der Dateien, die freigebenen wurden und verwaltet
diese.
Datei Jede Datei, die von dem Benutzer freigegeben wurde, wird mit dieser Klasse beschrieben. Die
Attribute, die in Datei zur Verfügung gestellt werden, beinhalten alle wichtigen Informationen die wir
für eine Datei benötigen. Es besteht eine Komposition zu IndexEintrag. Sobald eine Datei erstellt wird,
wird anhand des Keywords ein IndexEintrag erstellt.
MessageDigest5 Berechnet Hashwerte mit Hilfe von Algorithmus "MessageDigest5". Hat eine Me-
thode, die eine URL erwartet und einen fertigen Hashwert als String zurückliefert.
IndexEintrag Der Eintrag verwaltet für ein Keyword alle Dateien, die dieses Keyword enthalten.
UploadManager Diese Klasse implementiert NachrichtManager und EreignisHandler. Sie ist bei
SkyNet registriert, um BBHNachrichten zu empfangen. Diese Klasse verwaltet eine UploadListe mit
UploadEinträgen, um auf DownloadAnfragen antworten zu können und bei DownloadAnforderungen
den Upload zu starten. Außerdem reagiert sie auf die BBHNachrichten DownloadAbbruch und Uploa-
dAntwort.
UploadListe UploadListe erbt von Vector. Jeder Upload wird als UploadEintrag in der Liste reprä-
sentiert.
UploadEintrag Die Klasse UploadEintrag hält als Attribute den Dateinamen, die Warteposition, den
Peer, der die Datei anfragt und das Startbyte.
TmpEintrag Diese Klasse wird benötigt, um temporäre Dateien zu verwalten. Temporäre Dateien
werden erzeugt, wenn ein Uipload/Upload_Start-Paket hereinkommt. Die Rohdaten werden in diesen
temp. Dateien gespeichert, damit sie nicht im Speicher gehalten werden müssen.
Quicksort Die Klasse ermöglicht das Sortieren der UploadListe. Als Kriterium für die Position werden
die Credits benutzt.
SuchManager Der Suchmanager ist für die Suche verantwortlich. Er verschickt SuchAnfrage-Pakete
und empfängt SuchAntwort-Pakete. Er verwaltet eine Liste von Suchmatchlisten für den Fall, dass
mehrere Suchanfragen gesendet werden. Jeder Suchmatchliste wird eine SuchID zugeordnet.
SuchMatchListe Die SuchMatchListe speichert nach einer Suchanfrage die Ergebnisse. Diese werden
in Form von MatchListenEinträgen verwaltet.
MatchListenEintrag Zu jeder gefundenen Datei, die durch einen Hashwert identifiziert wurde, gibt es
genau einen MatchListenEintrag. Jeder MatchListenEintrag verwaltet eine Liste von DownloadQuellen,
von denen man die Datei runterladen kann.
DownloadQuelle Die DownloadQuelle beinhaltet eine Referenz auf einen Peer und die entsprechende
Warteposition.
SuchIndexListe Hierbei handelt es sich um eine Datenstruktur, die Keywords verwaltet. Wenn eine
neue Datei in die FreigabeListe eingefügt und die Keywords für sie erzeugt wurden, wird die Dateire-
ferenz mit den dazugehörigen Keywords in die SuchIndexListe eingefügt. Wir haben also ein Keyword
und alle dazugehörigen Dateienreferenzen.
34
9.4 Klassendiagramm 9 DIAGRAMMBESCHREIBUNGEN, 1. SEMESTER
ID3 In der Klasse ID3 werden aus einer MP3-Datei die ID3-Tags Titel, Artist und Album extrahiert
und zur Keywordliste der Datei hinzugefügt.
Peer Der Peer ist die Klasse für das eindeutige Verwalten von mobilen Geräten, die Dateien im
Netzwerk freigegeben haben und diese auch tauschen wollen.
DownloadManager Die Klasse DownloadManager implementiert das Interface NachrichtenManager,
um BBHNachrichten empfangen zu können. Der DownloadManager ist für alle Belange des Downloa-
dens zuständig. Er verwaltet eine Downloadliste, deren Einträge (DownloadEintrag) die Dateireferen-
zen enthalten, die heruntergeladen werden sollen. Er empfängt die BBHNachrichten DownloadAntwort,
DownloadAbbruch und UploadStart und reagiert auf diese.
DownloadListe Die DownloadListe verwaltet einen Vector von DownloadEinträgen.
DownloadEintrag Ein DownloadEintrag repräsentiert eine Datei, die von einem Peer heruntergeladen
werden kann. Dazu enthält die Klasse die Attribute Dateiname, Hashwert der Datei, die Dateigröße,
den Dateityp, den Zeitstempel, ein boolesches Attribut, ob die Datei modifiziert wurde, die url und das
Startbyte.
EreignisHandler Dies ist ein Interface, das alle Klassen, die einen Timer benutzen, implementieren.
Diese implementieren die Methode timerEvent(int nachricht), über die der BBHTimerTask die
Klassen nach Ablauf des vorher in der Klasse BBHTimer registrierten Timers benachrichtigen kann.
BBHTimer Die Klasse BBHTimer bietet allen Klassen des Programms, die einen Timer benötigen
(SuchManager, DownloadManager und GUIKontolle), die Möglichkeit sich über Timeouts informieren
zu lassen. Der Manager trägt einen Timeout mit Hilfe der Methode starteTimer(Ereignis-Handler
anforderer, int sekunden, int nachricht) ein. Dabei übergibt er sich selbst als EreignisHand-
ler, die Zeit, wie lange der Timer laufen soll und die Nummer der Nachricht, um nach dem Ablauf des
Timers diesen wieder einer Nachricht zuordnen zu können.
Der BBHTimer hält außerdem noch einen Thread der Klasse BBHTimerTask für die Abarbeitung
der Timer.
BBHTimerEintrag Für jeden in BBHTimer eingehenden Timeraufruf wird ein BBHTimerEintrag
erstellt.
BBHTimerTask In diesem Thread wird zyklis überprüft, ob ein Benachrichtigungszeitpunkt über-
schritten wurde. Falls ja, wird der entsprechende Anforderer mittels Methodenaufruf der Methode
timerEvent(int nachricht) des Interfaces EreignisHandler benachrichtigt, in dem die entsprechen-
de Nachrichtennummer zur Identifizierung übergeben wird.
Nachricht Nachricht ist die Oberklasse der Klasse BBHNachricht der Klasse VerwaltungsPaket. Sie
liefert eine abstrakte Methode toStream(), die in den Unterklassen implementiert wurden, um aus
den Objekten ein Bytearray zu machen. Außerdem liefert sie die Attribute zum Setzen der eigenen
Bluetoothadresse, der Bluetoothadresse des Suchenden, wenn es sich um eine weitergeroutete Nachricht
handelt und der Zielbluetoothadresse.
BBHNachricht Die Klasse BBHNachricht erbt von der Klasse Nachricht und ist selbst die Oberklas-
se für alle weiteren BBHNachrichten, die der Kommunikation innerhalb des BBH Systems dienen.
35
9.4 Klassendiagramm 9 DIAGRAMMBESCHREIBUNGEN, 1. SEMESTER
Die Methode toBBH(stream:Byte[]) ist statisch und ermöglicht BBHNachrichten des entsprechen-
den Typs aus einem Bytearray zusammengestellt zu werden. Um eine BBHNachricht zusammenzustellen
wird der Konstruktor einer BBHNachricht aufgerufen, der für den gewünschten Typ zuständig ist.
SuchAnfrage Die Klasse SuchAnfrage erbt von der Klasse BBHNachricht. Sie implementiert die
Methode toStream(). Zusätzlich enthält diese Klasse Attribute für eine SuchID, Keywords und einen
Timeout. Eine Suchanfrage wird per Broadcast an alle erreichbaren Peers gesendet.
SuchAntwort Die Klasse SuchAntwort erbt von der Klasse BBHNachricht. Die Klasse SuchAntwort
besitzt als zusätzliches Attribut einen Vector von Objekten der Klasse SuchAntwortEintag, die SuchID
und die Warteposition. Als Resultat für eine SuchAnfrage wird eine SuchAntwort von jedem Peer
erwartet.
SuchAntwortEintrag Die Klasse SuchAntwortEintrag stellt eine Antwort auf eine Suchanfrage dar.
Sie enthält als zusätzlicheAttribute den Dateinamen, die Dateigröße und den Hashwert der Datei zur
eindeutigen Identifizierung.
DownloadAnfrage Die Klasse DownloadAnfrage erbt von der Klasse BBHNachricht. Als zustätz-
liches Attibut enthält die DownloadAnfrage den Hashwert der gesuchten Datei. Sie wird vom Peer
geschickt, der etwas downloaden möchte, nachdem bereits eine DownloadAntwort eingegangen ist.
Wenn ein Download aus der DownloadListe gestartet wird, wird diese Nachricht per Broadcast an alle
erreichbaren Peers geschickt. Als Antwort wird eine DownloadAntwort erwartet.
DownloadAnforderung Die Klasse DownloadAnforderung erbt von der Klasse BBHNachricht. Sie
enthält zusätzlich die Attribute Hashwert und das Startbyte. Nachdem eine DownloadAnfrage geschickt
wurde, werden im DownloadManager einige Peers ausgewählt, von denen die Datei herunterladen
werden kann (Das Auswählen geschieht nach den Kriterien „Warteposition“ und „Hops“). An diese
Peers wird dann eine DownloadAnforderung geschickt. Es wird eine DownloadAntwort erwartet.
DownloadAntwort Die Klasse DownloadAntwort erbt von der Klasse BBHNachricht. Die zusätzliche
Attribute der Klasse sind die Warteposition, der Hashwert, die Anzahl der Hops, wie weit der Peer im
Netzwerk entfernt liegt und das boolsche Attribut istDownloadAnfrage, das zeigt, ob die Anfrage beim
anbietenden Peer in der Queue aufgenommen worden ist. Die DownloadAntwort wird entweder als
Antwort auf auf eine DownloadAnfrage oder eine DownloadAnforderung geschickt.
DownloadAbbruch Die Klasse DownloadAbbruch erbt von der Klasse BBHNachricht und enthält
zusätzlich die Attribute Hashwert und Richtung, die angibt, ob sie von einem Dateianbieter oder
Dateisuchenden geschickt wurde. Ein DownloadAbbruch wird geschickt, wenn ein Peer einen anderen
Peer aus seiner UploadListe bzw. Downloadliste entfernt hat. Wenn ein suchender Peer einen Downloa-
dAbbruch empfängt, löscht er die zugehörige DownloadQuelle des Peers. Wenn ein anbietender Peer
einen DownloadAbbruch empfängt, löscht er die Anfrage aus seiner Queue.
UploadStart Die Klasse UploadStart erbt von der Klasse BBHNachricht und enthält zudem die
Attribute AnzahlPakete und Hashwert. UploadStart ist eine Klasse, die für die Ankündigung von Upload
benötigt wird. Wenn ein Empfänger diese Nachricht bekommt, kann er sich bei den anderen Queues
mit Hilfe eines DownloadAbbruch abmelden.
Upload Die Klasse Upload erbt von der Klasse BBHNachricht. Die Uploadnachrichten beinhalten zu-
sätzlich die Startposition innerhalb der angeforderten Datei, ein Bytearray mit Rohdaten, den Hashwert
und die aktuelle Länge der enthaltenden Rohdaten. Falls ein Upload zu einer Gegenstelle erfolgen soll,
wird die Orginaldatei auf mehrere Uploadnachrichten aufgeteilt und an SkyNet übergeben.
36
9.4 Klassendiagramm 9 DIAGRAMMBESCHREIBUNGEN, 1. SEMESTER
UploadAntwort Die Klasse UploadAntwort erbt von der Klasse BBHNachricht. Sie beinhaltet das
Attribut Hashwert zur eindeutigen Identifizierung und wird jeweils auf eine BBHNachricht Upload
gesendet. Erst wenn eine UploadAntwort wieder beim sendenden Peer ankommt, wird der nächste
Upload verschickt.
VerwaltungsPaket Die Klasse VerwaltungsPaket erbt von der Klasse Nachricht. Über das Attribut
nachrichtTyp_ der Verwaltungsnachricht kann übermittelt werden, für welchen Zweck die Nachricht
eingesetzt wird. Alle möglichen Aufgaben (Zwecke) wurden als Konstanten eindeutig festgelegt und in
der Klasse VerwaltungsNachricht abgelegt. Darunter sind:
AnhaengeAnfrage Damit wird erfragt, ob ein Gerät von einem anderen Gerät als Kind anhängen
kann. Fall nach einer gewählten Zeit der Timer ausläuft, wird ein neues Gerät aus der Liste der ge-
fundenen zufällig ausgesucht und diesem eine AnhaengeAnfrage geschickt. Wenn diese Nachricht auf
der Empfängerseite ankommt, muss eine AnhaengeAntwort zurückgeschickt, der Status eventuell auf
Bridge und unter Umständen die Rolle geändert werden.
AnhaengeAntwort Die AnhaengeAntwort wird von dem Empfänger der AnhaengeAnfrage zu-
rückgeschickt. Falls die Rolle des Empfängers ein Wurzelknoten ist, oder der Knoten die Kapazität von
7 Kinderknoten erreicht hat, ist eine Verbindung bzw. das Anhängen nicht mehr möglich. Falls dieser
Fall eintritt, wird in dem Attribut daten_ eine "0" übermittelt, sonst eine "1".
RoutingUpdateConnect Wenn der Baum erweitert wurde, wird an den Elter die neue Knotenin-
formation hochgeleitet (bis es bei der Wurzel ankommt). Jeder Empfänger dieser Nachricht aktualisiert
seine Routingtabelle.
RoutingUpdateDisconnect Wenn der Baum verkleinert wurde, wird diese Information an den El-
ter hochgereicht (bis es bei der Wurzel angekommen ist). Alle Empfänger dieser Nachricht aktualisieren
ihre Routingtabellen.
KoordinatorErnennen Die Wurzel ernennt zyklisch und zufällig einen Knoten aus seinem Teil-
baum als Koordinatorknoten. Das Attribut Daten_ enthält die BT_Adresse des Wurzelknotens. Der
Empfänger ändert seine Rolle zum Koordinatorknoten und speichert die BT_Adresse der Wurzel.
KoordinatorAbwaehlen Die Wurzel wählt ihren Koordinator zyklisch ab. Dieser ändert damit
seine Rolle zum Baumknoten. Diese Nachricht wird auch bei der Baumverschmelzung benutzt.
GibWurzelBTAdresseAnfrage Diese Nachricht wird zyklisch von einem Koordinatorknoten ge-
sendet, um andere Koordinatorknoten zu finden. Sie wird nach einer Inquiry an alle gefundenen Geräte
versendet, die nicht direktes Kind oder Elter des Koordinators sind. Wenn diese Nachricht empfangen
wird, muss eine GibWurzelBTAdresseAntwort-Nachricht zurückgeschickt werden.
GibWurzelBTAdresseAntwort Diese Nachricht ist eine Antwort auf eine Koordinatorknotenan-
frage. Wenn der angefragte Knoten kein Koordinatorknoten ist, dann steht im Attribut Daten_ eine
Null, ansonsten wird dort die BT_Adresse des Wurzelknotens gesendet. Falls die Bluetoothadresse
einer Wurzel als Antwort ankommt, muss eine NeuerBaumGefunden-Nachricht zu der eigenen Wurzel
geschickt werden.
NeuerBaumGefunden Diese Nachricht wird vom Koordinatorknoten zu seiner Wurzel gesendet.
Damit weißdie Wurzel, dass es noch einen Baum in der Umgebung gibt. Im Attribut Daten_ ist
die BT_Adresse der fremden Wurzel enthalten. Daraufhin startet die Wurzel eine WurzelInquiry und
verschickt dann eine Nachricht BaumVerschmelzung zu dem fremden Wurzelknoten.
37
9.4 Klassendiagramm 9 DIAGRAMMBESCHREIBUNGEN, 1. SEMESTER
BaumVerschmelzung Diese Nachricht wird von einer Wurzel zu der fremden Wurzel geschickt,
um diese als Teilbaum anzuhängen. Diese wählt bei Erhalt dieser Nachricht ihren Koordinatorknoten
ab, ändert die Rolle zu einem Baumknoten um, trägt den Sender der Nachricht als Elter bei sich ein,
wird zur Bridge und schickt eine BaumVerschmelzungAntwort-Nachricht zurück.
BaumVerschmelzungAntwort Diese Nachricht enthält die komplette
RoutingTabelle des ehemaligen Wurzelknotens. Die eigene Routingtabelle muss aktualisiert (bzw. er-
weitert) werden.
VerwaltungsManager Die Klasse VerwaltungsManager implementiert
den TSF- und BTR-Algorithmus. Dazu reagiert der Verwaltungsmanager auf alle eingehenden Verwal-
tungsPakete, wie im Abschnitt VerwaltungsPaket beschrieben. Er hält eine Instanz der RoutingTabelle.
Zusätzlich verwaltet er Referenzen auf seinen Elterknoten und seine direkten Kinder.
RoutingTabelle Die Klasse RoutingTabelle ist eine Datenstuktur die alle Bluetooth-Adres-sen der
Kinder und Kindeskinder eines Teilbaumes verwaltet. Unter anderem ermöglicht die Routingtabelle eine
effiziente Suche nach Bluetooth-Adressen eines direkten Kindes, um Nachrichten in einem Teilbaum in
den richtigen Pfad routen zu können.
SkyNet SkyNet ist die direkte Schnittstelle zwischen Netzwerk- und Applikationsschicht. SkyNet
startet das Netzwerk und beendet es bei Programmende. Die Klasse stellt Methoden für den Austausch
von Nachrichten zur Verfügung. Außerdem können sich die Klassen bei SkyNet für den Nachrichtentyp
registrieren, den sie empfangen möchten. SkyNet routet diese dann bei Empfang weiter.
Netzwerk Diese Klasse ist für die Verwaltung der Geräte zuständig. Die Klasse implementiert das
Interface Runnable und lauscht in der run()-Methode ständig auf eingehende Verbindungen. Auch
der Sender zum Senden aller Nachrichtentypen befindet sich in der Klasse Netzwerk. Außerdem wird
in ihr eine Geräteliste namens andereGeraete gehalten, in der sich die Geräte befinden, zu denen eine
vorläufige Verbindung nach der Inquiry-Phase besteht, und eine Geräteliste ElterundKinder, in der die
Geräte stehen, zu denen eine permante Verbindung besteht. Die Klasse bietet Methoden an, um eine
Verbindung zum Fallbackserver aufzubauen und Nachrichten mit diesem auszutauschen, Methoden
zum Senden und Empfangen von BBHNachrichten und Verwaltungsnachrichten und zum Verwalten
der enthaltenen Gerätelisten.
Sender Implementiert das Interface Runnable. Wenn ein Paket versandt werden soll, kommt es hier
als Bytearray an, zusammen mit der Zieladresse. Der Sender wird vom Netzwerk geweckt. Die Nachricht
wird im Sender in MTUs aufgeteilt und per L2Cap-Verbindung an den übergebenen Adressat versendet.
Empfaenger Implementiert das Interface Runnable. Es gibt für jedes Gerät einen Empfänger, der
auf eingehende Nachrichten lauscht. Wenn eine Nachricht empfangen wird, wird diese an das Netz-
werk weitergeleitet. Wenn die L2CAP-Verbindung zum sendenden Gerät abbricht, wird die Verbindung
geschlossen, der Thread gestoppt und eine Nachricht über den Verbindungsabbruch an das Netzwerk
geschickt.
Geraet Repräsentiert ein entferntes Endegerät und hält als Attribut den Empfänger für dieses Gerät
und die Attribute für die Verbindung.
GeraeteListe Die Klasse erbt von Vector und dient dazu, Geräte zu verwalten.
38
9.5 Sequenzdiagramme 9 DIAGRAMMBESCHREIBUNGEN, 1. SEMESTER
Listener Die Klasse Listener implementiert das Interface DiscoveryListener. Die implementieren Me-
thoden werden in der Inquiry-Phase vom DisvoceryAgent, der vor dem Start der Inquiry-Phase im
Netzwerk erzeugt wurde, angesprochen, wenn ein Gerät entdeckt wurde, wenn der Service entdeckt
wurde, wenn die Suche nach den Services abgeschlossen wurde und wenn die Inquiry beendet ist. Wenn
die Inquiry-Phase beendet ist, werden die gefundenen Geräte an das Netzwerk übergeben.
Konvertierung Eine Klasse, die verschiedene Kovertierungsmethoden zur Verfügung stellt. Das wird
zum Beispiel benutzt, um Nachrichten in ByteArrays zu verwandeln.
GUIKontrolle Die GUIKontrolle implementiert das Interface EreignisHandler, um den Timer nutzen
zu können. Dazu wird timerEvent(nachricht:int) implementiert. Die Klasse GUI Kontrolle erbt
von dem Interface CommandListener und implementiert damit implizit die Methode commandAction(
c:Command, d:Displayable). Zusätzlich muss es alle NachrichtManager explizit kennen, um Infor-
mationen von diesen zu erhalten und zu senden.
FileBrowser Diese Klasse wurde seperat implimentiert. Sie erbt von Liste, stellt einen FileBrowser
dar und wird von GUIKontrolle benutzt.
9.5 Sequenzdiagramme
9.5.1 Suchanfrage erstellen
Von der GUI aus startet der Benutzer eine Suchanfrage indem er die Keywords eingibt. Vom Such-
Manager wird Suchanfrageobjekt und eine leere SuchMatchListe erzeugt. Anschließend wird der Timer
gestartet und die SuchAnfrage an SkyNet geschickt. Durch Aufruf der Methode empfangeNachricht()
werden durch den SuchManager SuchantwortPaketen anhand der SuchID empfangen und in die ent-
sprechenden SuchMatchListe in Form von MatchListenEinträge (MatchListenEintragobjekten werden
dabei erzeugt) hinzugefügt bis den Timer erreicht wird. Beim unbekannten SuchID werden die Ant-
wortpaketen verworfen. Mit gibSuchMatchListen() werden von der GUI die Listen aktualisiert.
9.5.2 Download starten
Von der GUI aus wählt ein Benutzer einen DownloadEintrag in der DownloadListe, den er runterladen
möchte und bestätigt mit "start" den Download. Bei einer positiven Überprüfung des Speicherplat-
zes wird vom DownloadManager eine DownloadAnfrage (broadcast) durch SkyNet geschickt, falls der
Eintrag keine DownloadQuellen enthält. Falls doch wird eine DownloadAnforderung an den nach War-
teposition bestplatzierten Quellen durch SkyNet geschickt. Der Timer wird gestartet. Im ersten Fall
wird für jede eingegangene DownloadAntwort jeweils ein neues DownloadQuelle-Objekt erzeugt und in
die DownloadQuellenListe des DownloadEintrages hinzugefügt.
Beim zweiten Fall bekommt man eine DownloadAntworten, in der steht, wo man in der Queue einge-
tragen wurde. Alle DownloadAntworten werden allerdings verworfen in dem Fall wo wir Antwortpakete
mit Warteposition -1 und -2 erhalten oder der Timer abgelaufen ist.
Beim Erhalt eines UploadStart-Pakets wird von der Gegenstelle signalisiert, dass wir in der Queue
an erster Stelle gelangen und bereit sind, die Daten zu empfangen. Dann werden Download-Abbruch-
Nachrichten generiert und an die restlichen Partner gesendet. Weitere UploadStart-Nachrichten für
diese Datei werden verworfen.
9.5.3 Auf Suchanfrage Reagieren
Das Reagieren auf Suchanfragen wurde in der Klasse EigeneDateienManager realisiert. Es be-schreibt
die Reaktion des Programmes, wenn ein SuchAnfrage-Paket im System eintrifft. Wenn eine Suchanfrage
im System eintrifft, wird die Methode empfangeNachricht() im EigeneDateienManager aufgrufen.
39
9.5 Sequenzdiagramme 9 DIAGRAMMBESCHREIBUNGEN, 1. SEMESTER
In dieser Methode wird überprüft, um welchen Nachrichtentyp es sich handelt. Wenn die ankommende
Nachricht eine SuchAnfrage ist, werden die Keywords aus der Nachricht mit den Keywords in der
SuchIndexListe verglichen. Dabei wird eine Referenz jeder Datei auf die die Keywords zutreffen in
eine Menge eingefügt. Hier wird auch sichergestellt, das jede Referenz nur einmal eingefügt wird,
auch falls mehrere Keywords auf die Datei zutreffen. Aus diesen Dateireferenzen werden jetzt die
SuchAnwortEinträge generiert und in ein SuchAntwort-Paket eingefügt. Dieses SuchAntwort-Paket
wird dann an den Suchenden verschickt, indem das Paket an SkyNet mittels der Methode senden()
weitergereicht wird.
9.5.4 StartApp
Zunächst wird eine Instanz der Klasse Programm erzeugt. Diese instanziiert alle Managern
(EigeneDateienManager, SuchManager, DownloadManager, UploadManager), GuiKontrolle,
Timer, SkyNet und Peers. Dabei werden alle nötigen Listen, wie Freigabeliste, SuchIndexliste,
DownloadListe u.s.w. angelegt. Anschliessend wird die Freigabeliste überprüft, eventuell aus Datei
geladen und Netzwerk (starteNetzwerk() bei SkyNet) gestartet.
9.5.5 Auf DownloadAnfragen reagieren
Dieses Diagramm beschreibt das Verhalten des UploadManagers nach dem Empfang einer DownloadAn-
frage mittels empfangeNachricht(), welche von SkyNet aufgerufen wird. Zuerst wird
existiertDatei() des EigeneDateienManager aufgerufen um zu überprüfen, ob die angefragte Datei
auf diesem Gerät freigegeben wurde. Falls dies zutrifft, wird eine DownloadAntwort generiert und diese
via SkyNet an den Anfrager gesendet.
9.5.6 Auf DownloadAnforderung reagieren
Dieses Diagramm beschreibt das Verhalten des UploadManagers nach dem Empfang einer Downloa-
dAnforderung mittels empfangeNachricht(), welche von SkyNet aufgerufen wird. Bei einer Down-
loadAnforderung wird ein UploadEintrag erstellt und dieser in die UploadListe eingetragen, wenn nicht
schon zu viele Uploads eingetragen sind und die Datei freigegeben wurde. Falls dies nicht der Fall ist,
wird eine DownloadAntwort mit einem Errorcode versendet. Wenn alles ok ist und es nur diesen einen
UploadEintrag gibt, wird eine UploadStart Nachricht versendet, die anzeigt, dass der Upload stattfinden
wird und danach wird die Datei in Uploadnachrichten geschickt.lassendiagramm
40
10 DIAGRAMMBESCHREIBUNGEN, 2. SEMESTER
10 Diagrammbeschreibungen, 2. Semester
10.1 Aktivitätsdiagramme
10.1.1 Baumknoten
Dieses Diagramm beschreibt die Aufgaben eines Geraetes, welches die Rolle "Baumknoten" hat.
Wenn der Knoten zum Koordinator ernannt wird (ein VerwaltungsPaket mit Typ KoordinatorErnennen
trifft ein), dann wird ein Rollenwechsel zum Koordinator durchgefuehrt.
Wenn der Knoten eine Verbindungsanfrage bekommt (ein VerwaltungsPaket mit Typ AnhaengeAnfrage
trifft ein), dann wird die Rolle des Anfragers ueberprueft. Falls die Rolle des Anfragers "FreierKnoten"
ist, dann wird die Liste der eigenen Kinderknoten erweitert und der Status wird auf Bridge gesetzt,
falls er zuvor noch nicht Bridge war. Danach wird der Anfrager als Kind in die RoutingTabelle (mit
Distanz 1) eingetragen. Schließlich wird die neue HashTabelle an den Elter weitergeleitet (mittels eines
"RoutingUpdateConnect" VerwaltungsPakets).
10.1.2 Fehlerbehandlung
Dieses Diagramm beschreibt die Behandlung von Verbindungsabbruechen. Eine auf diese Art abgebro-
chene Verbindung ist immer eine Verbindung zu einem direkt verbundenen Geraet (direktes Kind oder
Elter).
Zuerst wird ueberprueft, ob die Verbindung zum Elter abgebrochen ist. Falls ja, wird in jedem Fall
ein Rollenwechsel vollzogen und die RoutingTabelle wird aktualisiert. Wenn die Verbindung zum El-
ter abgebrochen ist und keine weiteren Kinder existieren, wird das Geraet zu einem Freien Knoten,
ansonsten zu einem Wurzelknoten (mit Status = Master). Falls nein, muss ebenfalls die RoutingTa-
belle aktualisiert werden und zusaetzlich muss der Elter (bzw alle Knoten auf dem Pfad zur Wurzel)
ueber den Abbruch informiert werden. Dies geschieht mittels des Verwaltungspakets RoutingUpdate-
Disconnect, welches die RoutingTabelle des Geraets an den Elter weitergibt. Sind keine Kinder mehr
vorhanden wird der Status auf Slave gesetzt.
10.1.3 Freierknoten
Dieses Diagramm beschreibt die Aufgaben eines Geraetes, welches die Rolle Freierknoten hat. Nach
der Initialisierung des Geraetes wird ein Timer randomisiert gestartet. Wenn dieser Timer sein Ti-
meOut liefert, dann wird eine Inquiry gestartet. Diese Inquiry liefert eine Geraeteliste mit temporaer
verbundenen Geraeten zurueck. Solange das Geraet noch in keinen Baum integriert wurde, werden Ver-
waltungsPakete des Typs AnhaengeAnfrage an andere Geraete versendet. Diese Geraete antworten
mit einem VerwaltungsPaketes des Typs AnhaengeAntwort. Bei einem erfolgreichen Anhaengen wird
die Rolle auf Baumknoten und der Elternzeiger auf das antwortende Geraet gesetzt. Die temporaeren
Verbindungen werden nach diesem Ablauf unterbrochen. Sollten zwei Geraete mit Rolle Freierknoten
Verwaltungspakete des Typs AnhaengeAnfragen austauschen, so wird der Antwortende zu einem Wur-
zelknoten und der Anfragende zu einem Baumknoten. Der Wurzelknoten muss das andere Geraet in
diesem Fall in seine Routingtabelle aufnehmen.
10.1.4 Koordinatorknoten
Der Koordinatorknoten wird in periodischen Zeitabstände von seiner Wurzel (Verwaltungspaket vom
Typ Koordinatorabwaehlen) abgewählt, womit seine Rolle dann zu einem Baumknoten wechselt.
In der gleichen Phase kann der Koordinatorknoten eine Wurzelanfrage eines anderen Koordinatorknotens
erhalten (Verwaltungspaket vom Typ GibWurzelBTAdresseAnfrage), auf die er dann reagiert indem er
die Adresse seiner Wurzel zurückschickt (Verwaltungspaket vom Typ GibWurzelBTAdresseAntwort).
41
10.2 Sequenzdiagramme 10 DIAGRAMMBESCHREIBUNGEN, 2. SEMESTER
Wenn ein Koordinatorkonten eine Inquiry startet, findet er eine gewisse Anzahl an Geräten, die in einer
Geräteliste abgespeichert werden. Falls die Geräteliste leer ist, wird ein Timeout gestartet und anschlie-
ßend eine neue Inquiry durchgeführt. Die Geräteliste wird dann sequentiell durchlaufen, um zu jedem
Gerät (außer zum Elter und den direkten Kindern) eine temporäre Verbindung aufzubauen, in der die
Rolle des jeweiligen Gerätes abgefragt wird, bis der Koordinatorknoten einen anderen Koordinatorkno-
ten findet. Falls ein Gerät nicht mehr antwortet oder die Rolle des Gerätes gleich einem WurzelKnoten,
BaumKnoten oder FreierKnoten ist wird das nächste Gerät aus der Geräteliste ausgewählt. Der gefun-
dene Koordinatorknoten K bekommt ein Verwaltungspaket vom Typ GibWurzelBTAdresseAnfrage
und wird nach der BT-Adresse seiner Wurzel gefragt. Die Antwort des Koordinatorknotens K mit der
BT-Adresse der Wurzel (Verwaltungspaket vom Typ GibWurzelBTAdresseAntwort), wird an die ei-
gene Wurzel weitergeleitet.
Wichtig ist zu erwähnen, dass der KoordinatorKnoten auch die gleiche Funktionalität eines Baum-
knotens besitzt, das heißt, ein FreierKnoten der ein Inquiry startet, kann sich auch an einen Koordina-
torKnoten hängen, wenn er diesen in seiner Geräteliste findet.
10.1.5 Routingaenderung
Bei einer Routingaenderung wird die eigene Routingtabelle aktualisiert und an den Elter weitergeleitet,
solange bis sie an der Wurzel angekommen ist.
10.1.6 Wurzelknoten
Ein Wurzelknoten hat verschiedene Aufgaben: zum einen muss er seinen Koordinatorknoten in be-
stimmten Zyklen abwählen und zum anderen einen neuen Koordinatorknoten ernennen.
Wenn der Wurzelknoten eine BT-Adresse eines anderen Wurzelknotens bekommt, startet dieser ein
Inquiry und sucht nach der erhaltenen BT-Adresse um eine Baumverschmelzung einzuleiten. Wenn das
Gerät mit der zugehörigen BT-Adresse gefunden wird, muss der Wurzelknoten ein Verwaltungspaket
vom Typ Baumverschmelzung an dieses senden. Die Rolle des gefundenen Geräts wird dann von Wur-
zelknoten auf Baumknoten gewechselt und anschließend an den Wurzelknoten, der die Inquiry gestartet
hat angehängt. Falls die Wurzel bereits sechs direkte Kinder hat, findet die Baumverschmelzung nicht
statt und beide Bäume bleiben nebeneinander bestehen. Die Routingtabelle des Wurzelknotens muss
anschließend aktualisiert werden. Der Wurzelknoten, der die Inquiry gestartet hat, muss dann die Liste
seiner Kinder aktualisieren. Der Koordinatorknoten wird beibehalten, da dieser zyklisch bestimmt wird.
Der Wurzelknoten der an den neuen Baum angehängt wurde, muss die Wurzel als Elter eintragen
und seinen eigenen Koordinatorknoten abwählen.
10.2 Sequenzdiagramme
10.2.1 Bäume durch Wurzel vereinigen
Passiv Die Rolle des Geräts ist Wurzelknoten. Wenn übers Netzwerk ein Verwaltungspaket vom
Typ BaumverschmelzungsAntwort eintrifft, wird dieses an den Verwaltungsmanager weitergeleitet
(empfangenachricht(VerwaltungsPaket)). Dort wird das Paket an die Methode
reagiereAufBaumverschmelzung() bearbeitet, indem die Rolle der Wurzel auf Baumknoten ge-
setzt wird, an den Koordinatorknoten ein Verwaltungspaket Koordinatorabwählen geschickt wird und
als neuer Elter des Geräts der Wurzelknoten aus dem Verwaltungspaket gesetzt wird.
Anschließend muss noch die neue Wurzel über den dem Gerät angehängten Teilbaum mit Hilfe ei-
nes Verwaltungspakets RoutingUpdate informiert werden. Die Verwaltungspakete werden zum Senden
an das Netzwerk in der Methode sendeVerwaltungsPaket(VerwaltungsPaket()) geschickt.
42
10.2 Sequenzdiagramme 10 DIAGRAMMBESCHREIBUNGEN, 2. SEMESTER
Aktiv Die Rolle des Geräts ist Wurzelknoten. Wenn übers Netzwerk ein Verwaltungspaket vom
Typ BaumverschmelzungsAnfrage eintrifft, wird dieses an den Verwaltungsmanager weitergeleitet
(empfangenachricht(VerwaltungsPaket)). Es muss eine Inquiry zum Finden der anderen Wurzel
gestartet werden (wurzelInquiryStart(String)). Wird die andere Wurzel gefunden, wird dies über
die Methode wuzelInquiryFertig() vom Netzwerk an den Verwaltungsmanager gemeldet. Anschlie-
ßend wird ein Verwaltungspaket BaumverschmelzungsAntwort an die andere Wurzel über die Methode
sendeVerwaltungsPaket(VerwaltungsPaket) im Netzwerk. Danach erhält der Verwaltungsmana-
ger ein Verwaltungspaket RoutingUpdate, in dem die Informationen des Teilbaumes der anderen Wurzel
mitgeteilt werden. Diese werden in die Routingtabelle der Wurzel aufgenommen.
10.2.2 Bäume vereinigen
Koordinatorknoten starten in gewissen Zeitabständen Inquirys, um andere Koordinatorknoten zu finden
und somit die Teilbäume zu vereinigen (koordinatorInquiryStart()). Wird ein anderer Koordinator
gefunden, wird dieser über die Methode vereinigungBaeume(Geraet) an den Verwaltungsmanager
geschickt. Mit einem Verwaltungspaket wird die Wurzel des Koordinators erfragt. Wenn diese Nachricht
eintrifft, wird ein Verwaltungspaket an die Wurzel geschickt, um die Wurzel über die Baumverschmel-
zung zu informieren.
10.2.3 Freier Knoten integrieren
Wenn ein freier Knoten eine Inquiry zum finden eines Baumes gestartet hat, wird nach der Inqui-
ry in der Klasse Listener die Methode inquiryCompleted(int discType) ausgelöst. Diese startet
im Netzwerk die Methode inquiryAbgeschlossen(). In dieser Methode wird die mit der in denIn-
quiry gefundenen Geräten gefülltenGeraeteListe an den Verwaltungsmanager übergeben. Dieser sucht
sich randomisiert ein Gerät aus der Liste und sendet diesem ein Verwaltungspaket über die Methode
sendeVerwaltungspaket(VerwaltungsPaket Paket) im Netzwerk. Ist nach einem Timeout keine
Antwort gekommen, wird ein anderes Gerät aus der Gerätliste ausgewählt und diesem eine Verwal-
tungsnachricht geschickt. Ist eine positive Antwort eingegangen, wird diese an den Verwaltungsmanager
weitergeleitet. Dort wird der Elter gesetzt und die Rolle auf Baumknoten geändert.
10.2.4 Piconetz
In diesem Diagramm wird der Programmablauf von BBH dargestellt, wenn sich einzelne Geräte zu
einem Piconetz zusammenschliessen. Nachdem die Bluetooth Inquiry-Phase abgeschlossen ist, wird
in der Klasse Netzwerk die Methode gibMaster() aufgerufen. Diese Methode liefert ein Gerät zu-
rück, das Master ist und noch einen weiteren Slave aufnehmen kann. Falls kein solches Gerät existiert,
wird NULL zurückgeliefert. Die Methode geht folgendermaßen vor: von allen Geräten, die während der
Inquiry-Phase gefunden worden sind, wird ein Gerät zufällig ausgewählt. An dieses Gerät wird dann
eine Anfrage gesendet, ob es Master ist und noch einen freien Platz für ein Slave-Gerät hat.
Falls das angefragte Gerät Master ist und noch mindestens einen freien Platz hat, kann die Methode
beendet werden, und es kann ein Verweis auf dieses Gerät zurückgegeben werden. Falls dies noch nicht
der Fall ist, werden die anderen während der Inquiry-Phase gefundenen Geräte gefragt. Dies wird so-
lange wiederholt bis ein freier Platz gefunden wurde oder alle Geräte gefragt wurden.
Falls gibMaster() NULL zurückgeliefert hat, wird der eigene Status auf Master gesetzt. Falls
gibMaster() ein Gerät zurückgeliefert hat, kann die Methode setzeGeraete() aus der Klasse Ande-
reGeraete aufgerufen werden, um das eben gefundene Gerät dort einzutragen. Diese Klasse verwaltet
alle Geräte mit denen die Filesharing-Schicht von BBH kommunizieren kann.
10.2.5 Routing von BBH-Paketen
Dieses Diagramm stellt den Ablauf des Routings von BBH Nachrichten dar. Wenn die Applikations-
schicht eine Nachricht verschicken will, ruft sie die Methode sende() aus der Klasse SkyNet auf und
43
10.2 Sequenzdiagramme 10 DIAGRAMMBESCHREIBUNGEN, 2. SEMESTER
übergibt die zu sendende Nachricht als Parameter. SkyNet reicht die Nachricht zu der Klasse Netzwerk
weiter, die das eigentliche Routing in die Wege leitet. Dazu wird die Methode gibEchtenEmpfaenger()
aus der Klasse VerwaltungsManager aufgerufen. Als Parameter dieses Methodenaufrufes wird die zu
versendende BBHNachricht übergeben. Diese Methode sucht nach der Zieladresse der BBHNachricht
in der eigenen Routingtabelle. Falls die Zieladresse gefunden wurde, wird die Adresse des nächsten
Hops der Nachricht zurückgegeben. Falls die Zieladresse nicht in der Routingtabelle zu finden ist und
wir kein Wurzelknoten sind, wird die Adresse des eigenen Elters zurückgeliefert.
Für den Fall, dass wir selber Wurzelknoten sind, und die Zieladresse nicht in der Routingtabelle finden
können, verwerfen wir das Paket und liefern NULL zurück.
Nachdem wir von der Methode gibEchtenEmpfänger() eine Bluetooth-Adresse geliefert bekommen
haben, können wir die Nachricht jetzt versenden. Dazu wird die Methode gibGeraet() aus der Klasse
andereGeraete aufgerufen, um einen Verweis auf das Gerät mit der eben zurückgelieferten Bluetooth
Adresse zu bekommen. Danach kann die Nachricht in einen Bytestream konvertiert werden, indem die
Methode toBBH() aufgerufen wird. Dieser Stream kann jetzt dem Sender-Thread zum Verschicken
übergeben werden.
Der Ablauf des Routings bei einer einkommenden Nachricht ist ähnlich: Zuerst wird die Zieladres-
se der einkommenden Nachricht überprüft, ob sie mit der eigenen Adresse übereinstimmt. Falls das
der Fall ist, wird die Nachricht von SkyNet an die entsprechenden BBHManager weitergeleitet. Falls
die Nachricht nicht an uns adressiert wurde, wird wieder sendeNachricht() aus Netzwerk aufgerufen.
Wenn eine Nachricht per Broadcast verschickt werden soll, wird die Nachricht an alle Geräte in der
Routingtabelle und den Elter verschickt. Dabei wird allerdings das Gerät ausgenommen, das uns die
Nachricht geschickt hat.
10.2.6 Verbindungstrennung abfangen
Das Diagramm beschreibt den zeitliche Ablauf des Programms bei einem Verbindungsabbruch. Ein
Verbindungsabbruch erfolgt dann, wenn Geräte, die unmittelbar mit anderen Geräten in Verbindung
stehen, plötzlich ausfallen. Dieser Ausfall kann durch den Benutzer erfolgen (z.B. nach Beendigung des
Programms) oder auch unabhängig sein (z.B. Energieausfall).
Die Trennung der Verbindung bleibt allerdings dem Benutzer verborgen. Sie wird auf der Netzwer-
kebene gehandhabt und durch entsprechende Verwaltungsmaßnahmen abgefangen. Falls jedoch die
Verbindung während eines Downloads abbricht, wird dieser gestoppt und durch Resume von anderen
potentiellen Quellen weiter heruntergeladen.
Nachdem ein Gerät vom Netzwerk getrennt ist, wird das Netzwerk vom Listener durch Aufruf der
Methode verbindungAbgebrochen(Geraet) benachrichtigt. Dabei wird als Parameter das Gerät,
das das Netzwerk verlassen hat, übergeben. Daraufhin wird die Methode empfangeReport(String)
im Verwaltungsmanager aufgerufen. Diese Methode bekommt vom Netzwerk die BTAdresse des Gerä-
tes und ruft dann die Methode reagiereAufVerbindungsAbbruch(String) im Verwaltungsmanager
auf. Diese Methode leitet dann alle erforderlichen Maßnahmen ein, um die Verbindungstrennung ab-
zufangen. Alle Knoten, die unmittelbar mit dem ausgefallenen Knoten eine Verbindung zum Zeitpunkt
des Abbruchs haben, reagieren dann auf diese Methode.
In der Methode wird zuerst geprüft, ob der aktuelle Knoten ein Wurzelknoten ist, dann ob er noch
Kinder hat. Falls er keine Kinder mehr hat, wird er auf FreierKnoten gesetzt. Bei noch vorhandenen
Kinder überprüft er, ob der verschwundene Knoten sein KoordinatorKnoten ist. Falls ja, setzt er den
alte KoordinatorKnoten auf null und ernennt einen neuen. Ansonsten muss er nichts tun. In dem Fall,
in dem der aktuelle Knoten kein Wurzelknoten ist, uberprüft er, ob der Ausfall vom Elter kommt. Wenn
ja, werden die TimeOuts, falls der aktuelle Knoten ein KoordinatorKnoten ist, gestoppt. Wenn er zuvor
44
10.2 Sequenzdiagramme 10 DIAGRAMMBESCHREIBUNGEN, 2. SEMESTER
keine Kinder hatte, wird er zum FreienKnoten ernannt, ansonsten wird er als WurzelKnoten. Dabei
werden die Routingtabellen aktualisiert (das entsprechende Gerät wird gelöscht). Falls der Ausfall je-
doch vom Kind stammt, wird das Kind aus der Routingstabelle entfernt, und ein RoutingUpdatePaket
wird an den Elter bis zum Wurzel hochgereicht.
45
11 ANHANG A - TESTS UND FEHLERBEHEBUNG
11 Anhang A - Tests und Fehlerbehebung
11.1 1. Semester
Folgendes Testprotokoll wurde gemäßden Anwedungsfällen erstellt:
11.1.1 Dateien freigeben
Datum: 27.01.05
Verantwortliche Person: Zok, Prost
Was wird erwartet: Man kann in seinem Gerätefilesystem browsen. Es wird eine Hier-
archie von Ordnern und Dateien angezeigt. Wenn man eine Datei
oder Ordner makiert hat, kann man ihn auch freigeben. Dieser
wird dann in der Freigabeliste angezeigt.
Was ist passiert: Funktioniert; Freigabe von einer 6MB Datei dauert 100sec.; ca.
10 Tage vorher wurde das hashen schon auf einem richtigem
Handy gestestet, was dort wesentlich schneller ging.
11.1.2 Dateien sperren
Datum: 27.01.05
Verantwortliche Person: Zok, Prost
Was wird erwartet: Die Datei, die zuvor freigegeben wurde, wird gesperrt. Somit wird
sie aus der der Freigabeliste entfernt.
Was ist passiert: Funktioniert.
11.1.3 Freigegebene Dateien auflisten
Datum: 27.01.05
Verantwortliche Person: Zok, Prost
Was wird erwartet: Dateien, die man freigegeben hat, werden angezeigt.
Was ist passiert: Funktioniert.
46
11.1 1. Semester 11 ANHANG A - TESTS UND FEHLERBEHEBUNG
11.1.4 Eine Datei austauschen
Datum: 27.01.05
Verantwortliche Person: Börgermann, Diel, Göbel, Prost, Zok
Was wird erwartet: Eine Datei, die man sucht und downloaden will, soll von einem
Gerät zum nächsten übertragen werden.
Was ist passiert: Funktioniert bei kleinen Dateien.
Falls Fehler, welche?: Bei großen Dateien kommen OutOfMemoryExceptions.
Maßnamen: Die maximale Paketgröße wurde von 480kb auf 50kb verringert.
Der Arbeitsspeicher des Geräts wurde zuvor überlastet.
Fehler behoben am: 02.02.05
Fehler behoben durch: Die Paketgröße wurde verringert (auf 50kb)
11.1.5 Mehrere Dateien austauschen
Datum: 27.01.05
Verantwortliche Person: Börgermann, Diel, Göbel, Prost, Zok
Was wird erwartet: Mehrere Dateien sollen von gleichem Gerät runtergeladen wer-
den. Dann sollen mehrere Dateien von unterschiedlichen Geräten
runtergeladen werden.
Was ist passiert: Ab zweiter Datei wurde nicht übertragen. Stattdessen kommt
eine DownloadAntwort an.
Falls Fehler, welche?: Dateien nicht übertragen
Maßnamen: Queueverhalten des UploadManagers prüfen.
Fehler behoben am: 31.01.05
Fehler behoben durch: Keine Fehler beim Überprüfen des UploadManagers gefunden.
Danach überpüft, ob SkyNet nach dem Versand einer Upload-
Nachricht dem UploadManager Bescheid gibt. SkyNet tat dies
nicht, sondern benachrichtigte den EigeneDateienManager. Pa-
rameter verändert - nun funktioniert es!
47
11.1 1. Semester 11 ANHANG A - TESTS UND FEHLERBEHEBUNG
11.1.6 Dateien suchen
Datum: 27.01.05
Verantwortliche Person: Tigyo, Kißner, Zok, Prost
Was wird erwartet: Wir bekommen SuchAntworten, von den Peers, die Dateien mit
den eingegeben Keywords freigegeben haben. Diese werden in
die richtige SuchMatchListe eingetragen und bei „MeineSuchen”
angezeigt.
Was ist passiert: Funktioniert, aber bei nicht vorhandenen Keywords gab es eine
NullPointerException. Dies wurde direkt behoben.
Falls Fehler, welche?: Bei nicht vorhandenen Keywords gab es eine
NullPointerException.
Maßnamen: direkt behoben
Fehler behoben am: 27.01.05
Fehler behoben durch: -
11.1.7 Dateien als Download auswählen
Datum: 27.01.05
Verantwortliche Person: Tigyo, Kißner
Was wird erwartet: Es wird ein MatchListenEintrag, den man downloaden aber nicht
direkt starten möchte, dem DownloadManager übergeben. Dort
wird der MatchListenEintrag in die DownloadListe hinzugefügt.
Was ist passiert: Funktioniert.
11.1.8 Download starten
Datum: 27.01.05
Verantwortliche Person: igyo, Kißner, Prost, Zok
Was wird erwartet: Man wählt aus der DownloadListe oder der SuchMatchListe eine
Datei aus, die man gerne runterladen möchte. Die Datei wird in
der Downloadliste angezeigt und direkt heruntergeladen. Wenn
sie fertig geladen ist, wird sie aus der Downloadliste ausgetragen
und in die FreigabeListe eingetragen.
Was ist passiert: Funktioniert.
48
11.1 1. Semester 11 ANHANG A - TESTS UND FEHLERBEHEBUNG
11.1.9 Download resumen
Datum: 02.02.05
Verantwortliche Person: Tigyo, Kißner, Prost, Zok
Was wird erwartet: Wenn eine Datei pausiert wurde, kann sie ab dem gestoppten Zu-
stand wieder gedownloaded werden. Die Datei sollte dabei nicht
beschädigt werden.
Was ist passiert: Der Download wird wieder aufgenommen.
Falls Fehler, welche?: Die TempDatei wird komplett neu geschrieben und nicht erst ab
dem aktuellem Startbyte.
Maßnamen: ktualisiereStartByte muss vom EigenenDateienManager aufge-
rufen werden sobald die Rohdaten eines UploadPacketes in die
Temp-Datei geschrieben worden sind.
Fehler behoben am: 08.02.05
Fehler behoben durch: aktualisiereStartByte wird jetzt im EigeneDateienManager auf-
gerufen
11.1.10 Download abbrechen
Datum: 27.01.05
Verantwortliche Person: Kißner, Tigyo, Prost, Zok
Was wird erwartet: Der Download wird mittels einer DownloadAbbruch Nachricht
abgebrochen und der DownloadEintrag aus der DownloadListe
gelöscht und die evtl. bereits geschriebene Temp-Datei gelöscht.
Was ist passiert: Beim Klicken auf den MenuEintrag "abbrechen" von der Down-
loadListe wird abgebrochen und der DownloadEintrag gelöscht.
Funktioniert ohne die loescheTemp()-Methode
Falls Fehler, welche?: Es wird eine NullPointerException ausgelöst.
Maßnamen: Lokalisierung des Fehlers.
Fehler behoben am: 01.02.05
Fehler behoben durch: Der DownloadManager hatte den EigeneDateienManager nicht
richtig initialisiert. Wird jetzt ihm durch das Programm überge-
ben. Jetzt funktioniert alles.
49
11.1 1. Semester 11 ANHANG A - TESTS UND FEHLERBEHEBUNG
11.1.11 Download anhalten/pause
Datum: 02.02.05
Verantwortliche Person: Tigyo, Kißner, Kasmann
Was wird erwartet: Der Download einer Datei soll angehalten werden. Dabei wird der
Startbytezeiger an das Ende der schon heruntergeladenen Daten
gesetzt und der Download angehalten. Diese temporäre Datei
darf nicht gelöscht werden, solange sie nicht vollständig empfan-
gen wurde.
Was ist passiert: Funktioniert, Temp-Datei wird nicht weiter geschrieben, der
„Uploader” wird benachrichtigt und sendet nicht weiter.
Falls Fehler, welche?: Das StartByte wird nicht auf die aktuelle Position gesetzt.
Maßnamen: aktualisiereStartByte muss vom EigenenDateienManager aufge-
rufen werden sobald die Rohdaten eines UploadPacketes in die
Temp-Datei geschrieben worden sind.
Fehler behoben am: 08.02.05
Fehler behoben durch: Zok
11.1.12 Upload einsehen
Datum: 31.01.05
Verantwortliche Person: Zok, Prost
Was wird erwartet: Es wird im Upload-Fenster angezeigt, welche Dateien vom eige-
nen Gerät upgeloaded werden.
Was ist passiert: Funktioniert.
11.1.13 Upload abbrechen
Datum: 31.01.05
Verantwortliche Person: Zok, Prost
Was wird erwartet: Hier wird durch den Benutzer explizit ein Upload abgebrochen.
Danach wird die Datei nicht mehr im Upload-Fenster zu sehen
sein. Aber immer noch im Freigegebene Dateien-Fenster.
Was ist passiert: Funktioniert.
50
11.1 1. Semester 11 ANHANG A - TESTS UND FEHLERBEHEBUNG
11.1.14 Fallback aktivieren
Datum: 31.01.05
Verantwortliche Person: Börgermann, Diel, Göbel
Was wird erwartet: Man kann auf einem Fallback-Server zugreifen. Wenn man ihn
aktiviert, kann man dort wie sonst nach Dateien suchen.
Was ist passiert: Man kommt nur auf ein GUI Fenster, welches den Fallbackserver
symbolisiert.
11.1.15 Persistenz prüfen
Datum: 31.01.05
Verantwortliche Person: Krokowski
Was wird erwartet: Alle Einstellungen und alle Listen werden kurz vor Programmende
bzw., falls das Midlet pausiert wird, persistent auf dem mobilen
Gerät gespeichert werden.
Was ist passiert: Funktioniert.
11.1.16 Spezialfall: Es dürfen keine „leeren” Suchantworten geschickt werden
Datum: 31.01.05
Verantwortliche Person: Prost
Was wird erwartet: Falls das Suchfeld leer ist, darf keine Nachricht an Skynet ge-
schickt werden.
Was ist passiert: Funktioniert.
11.1.17 Spezialfall: Mehrere Peers haben gesuchte Datei. Kommunikation und Aktualisie-
rung zwischen DLManager und ULManagern. (Downloadabbruch selbstständig sen-
den)
Datum: 02.02.05
Verantwortliche Person: Alle
Was wird erwartet: siehe oben
Was ist passiert: Die Datei wird nur bei einem Peer gefunden.
Falls Fehler, welche?: GUI macht Quark
Maßnamen: GUI geändert
Fehler behoben am: 10.02.05
Fehler behoben durch: Alle
51
11.1 1. Semester 11 ANHANG A - TESTS UND FEHLERBEHEBUNG
11.1.18 Spezialfall: DownloadAntwort oder SuchAntwort trifft nach Ablaufen des Timers ein
Datum: 31.01.05
Verantwortliche Person: Kißner, Tigyo
Was wird erwartet: Falls DownloadAntwort oder SuchAntwort nach Ablaufen des Ti-
mers eintrifft, werden diese verworfen.
Was ist passiert: Funktioniert.
11.1.19 Spezialfall: Das Überschütten des Netzwerkes mit vielen, gleichzeitigen Suchanfra-
gen (Stabilitätstest)
Datum: 31.01.05
Verantwortliche Person: Alle
Was wird erwartet: Die mobilen Geräte sollten dadurch nicht überlastet werden. Zur
Not werden Pakete verworfen.
Was ist passiert: Unbekannt
Falls Fehler, welche?: Unbekannt
Maßnamen: Kann nur in realer Umgebung vernünftig getestet werden.
11.1.20 Spezialfall: Downloadwunsch einer Datei, für die nicht mehr genügend Speicherplatz
zur Verfügung steht
Datum: 31.01.05
Verantwortliche Person: Prost
Was wird erwartet: Es mußeine Fehlermeldung auf dem Bildschirmangezeigt werden,
die den Benutzer hinweißt Platz zu schaffen.
Was ist passiert: Kann nicht getestet werden, da wir kein reales Gerät haben
Falls Fehler, welche?: Unbekannt
Maßnamen: Sicherheitsabfrage eingebaut, Datei wird nicht mehr geschrieben,
wenn kein Speicherplatz vorhanden ist.
Fehler behoben am: 08.02.05
Fehler behoben durch: Zok, Tigyo, Kißner
52
11.2 2. Semester 11 ANHANG A - TESTS UND FEHLERBEHEBUNG
11.1.21 Spezialfall: Start eines Downloads für den keine Quellen zur Verfügung stehen
Datum: 31.01.05
Verantwortliche Person: Kasmann
Was wird erwartet: Falls ein Download, für den es keine Quellen zur Verfügung gibt
(oder wo alle Quellen „Nein” sagen) gestartet wurde, wird er
sofort abgebrochen.
Was ist passiert: Alles hängt sich auf.
Falls Fehler, welche?: Unbekannt
Maßnamen: Abfrage eingebaut, die einen nicht vorhandenen Addressaten ab-
fängt.
Fehler behoben am: 08.02.05
Fehler behoben durch: Diel
11.2 2. Semester
Hinweise zum Testprotokoll:
• Bei der Durchführung der Testfälle wurde das Gerät (erstes angeschaltetes Gerät) mit der Bezeich-
nung "+5550000", was für den Simulator der physikalisch Master darstellt, nicht ausgeschaltet,
da sonst das JSR-82-Netzwerk nicht mehr verfügbar war.
• Die Testfälle wurden mit dem WTK auf einem Windows-Rechner durchgeführt.
11.2.1 Verbindung zweier Freierknoten.
Datum: 06.07.05
Verantwortliche Person: Topologen (siehe oben)
Was wird erwartet: Beide Knoten schließen sich an. Einer wird Wurzelknoten und
ernennt der andere zum Koordinatorknoten. Die Routingtabellen
werden aktualisiert.
Was ist passiert: Funktioniert erwartungsgemäßproblemlos und schnell.
11.2.2 Anschluss einer Freierknoten am vorhandenen Baum
Datum: 06.07.05
Verantwortliche Person: Topologen
Was wird erwartet: Der Freierknoten wird dann zum Baumknoten. Alle Knoten im
Baum aktualisieren ihre Routingtabellen.
Was ist passiert: Funktioniert.
53
11.2 2. Semester 11 ANHANG A - TESTS UND FEHLERBEHEBUNG
11.2.3 Verschmelzung zweier unabhängigen Bäume.
Datum: 06.07.05
Verantwortliche Person: Topologen
Was wird erwartet: Verschmelzung der Bäume, indem die fremde Wurzel sein Ko-
ordinatorknoten abwählt und sich an der neuen Wurzel als Kind
anhängt und zum Baumknoten wird. Alle Routingtabellen werden
aktualisiert.
Was ist passiert: Die Bäume verschmelzen sich problemlos nach ca. 7 Sek.
11.2.4 Wiederanschluss der selben Knoten (BK, KK, WK) am vorhandenen Baum nach
Verlassen (Programm) des Netzes
Datum: 06.07.05
Verantwortliche Person: Topologen
Was wird erwartet: Die Knoten schließen wieder an und werden dann zum Baum-
knoten. Der Wurzelknoten wird gewählt und ernennt ein neuer
K-Knoten. Alle Knoten im Baum aktualisieren ihre Routingtabel-
len.
Was ist passiert: Funktioniert erwartungsgemäß.
11.2.5 Nach Verbindungsabbruch (Wurzelknoten) freigewordene Knoten schließen sich wie-
der an
Datum: 06.07.05
Verantwortliche Person: Topologen
Was wird erwartet: Die Freierknoten schließen sich an und je nach Konstellation bil-
det sich ein neuer Baum. Alle Routingtabellen werden aktuali-
siert.
Was ist passiert: 4 Geräten gestartet. Der Wurzelknoten ausgeschaltet (Pro-
gramm), nach 3 Sek. hat sich ein Baum formiert.
11.2.6 Nach Verbindungsabbruch (Koordinatorknoten) freigewordene Knoten schließen sich
wieder an
Datum: 06.07.05
Verantwortliche Person: Topologen
Was wird erwartet: ie Freierknoten schließen sich an und je nach Konstellation bildet
sich ein neuer Baum. Der Wurzelknoten ernennt einen neuen K-
Knoten. Alle Routingtabellen werden aktualisiert.
Was ist passiert: 4 Geräten gestartet. Der Koordinatorknoten mehrmals ausge-
schaltet (Programm), nach 5 Sek. hat sich ein Baum formiert.
11.2.7 Verschmelzung nach Verbindungsabbruch zweier unabhängig gewordene Bäume
Datum: 06.07.05
Verantwortliche Person: Topologen
Was wird erwartet: Die beide Bäume verschmelzen sich (sieh. Anwendungsfall 3).
Was ist passiert: Eine Kette von 5 Geräten gestartet. Das mittlere Gerät ausge-
schaltet(Programm), nach ca. 20 Sek. findet die Verschmelzung
statt. Die Routingtabellen werden aktualisiert.
54
11.2 2. Semester 11 ANHANG A - TESTS UND FEHLERBEHEBUNG
11.2.8 Suche/Download über mehrere Hops
Datum: 06.07.05
Verantwortliche Person: Topologen
Was wird erwartet: ie Dateien werden gefunden und problemlos herunter geladen. Die
Routing von Verwaltungsnachrichten muss anhand von Lämp-
chen sichtbar sein.
Was ist passiert: Das suchende Gerät befand sich 4 Hops von der Quelle entfernt.
Die Suche ergab 1 Treffer und der Download (5,5MB) lief pro-
blemlos.
11.2.9 Resume über mehrere Hops
Datum: 06.07.05
Verantwortliche Person: Topologen
Was wird erwartet: Der Download muss stoppen und die Lämpchen der beteiligten
Geräte nicht mehr leuchten. Dann muss der Download fortgesetzt
werden und die Lämpchen leuchten.
Was ist passiert: Das Gerät befand sich 4 Hops von der Quelle entfernt. Der Re-
sume der Datei (5,5MB) lief problemlos.
11.2.10 Gleichzeitige Downloads über Brigde-Geräte
Datum: 06.07.05
Verantwortliche Person: Topologen
Was wird erwartet: Die Dateien werden problemlos herunter geladen und die Lämp-
chen leuchten entsprechend.
Was ist passiert: Die Dateien (4MB / 3MB) werden vollständig übertragen, bei
jedem Gerät läuft nur ein Thread (Sender oder Empfänger), nicht
beides.
11.2.11 Gleichzeitige Downloads (=2) über Brigde-Geräte (Große Dateien). Geräte fungie-
ren als Sender und Empfänger
Datum: 06.07.05
Verantwortliche Person: Topologen
Was wird erwartet: Die Dateien werden problemlos herunter geladen und die Lämp-
chen leuchten entsprechend.
Was ist passiert: Die Dateien (11MB / 15MB) werden vollständig übertragen, bei
jedem Gerät laufen beide Threads (Sender und Empfänger). Die
beteiligten Geräte leuchten.
11.2.12 Gleichzeitige Downloads(>2) über die Wurzel (Große Dateien). Geräte können als
Sender und Empfänger fungieren
Datum: 06.07.05
Verantwortliche Person: Topologen
Was wird erwartet: Über die Wurzel laufen mehr als 2 Downloads. Die Geräte können
gleichzeitig senden und empfangen. Die Dateien werden problem-
los herunter geladen.
Was ist passiert: Die Dateien (6MB / 11MB / 15MB) werden vollständig über-
tragen. Die Geräte leuchten aber der Download dauert einige
Minuten.
55
11.2 2. Semester 11 ANHANG A - TESTS UND FEHLERBEHEBUNG
11.2.13 Download von einer entfernten Quelle, die das Scatternetz plötzlich verlässt.
Datum: 06.07.05
Verantwortliche Person: Topologen
Was wird erwartet: Der Download wird abgebrochen und durch Resume von einer
anderen Quelle ergänzt. Die entsprechenden Geräte leuchten.
Was ist passiert: Der Download der Datei (4 MB) wurde abgebrochen und durch
Resume fertig herunter geladen. Funktioniert.
11.2.14 AND-Suche nach 1 Keyword / Groß/ Kleinschreibung / Gemischt
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Die Datei wird gefunden.
Was ist passiert: Datei wurde gefunden.
11.2.15 AND-Suche nach 3 Keywords / Groß/ Kleinschreibung / Gemischt
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Die Datei wird gefunden.
Was ist passiert: Datei wurde gefunden.
11.2.16 AND-Suche nach 1 Keyword (Substring Anfang vom ersten Wort) / Groß/ Klein-
schreibung / Gemischt
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Die Datei wird gefunden.
Was ist passiert: Datei wurde gefunden.
11.2.17 AND-Suche nach 1 Keyword (Substring mitten im Wort) / Groß/ Kleinschreibung
/ Gemischt
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Die Datei wird gefunden.
Was ist passiert: Datei wurde gefunden.
11.2.18 AND-Suche nach 3 Keywords (Substring Anfang vom ersten Wort) / Groß/ Klein-
schreibung / Gemischt
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Die Datei wird gefunden.
Was ist passiert: Datei wurde gefunden.
11.2.19 AND-Suche nach 3 Keywords (Substring mitten im Wort) / Groß/ Kleinschreibung
/ Gemischt
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Die Datei wird gefunden.
Was ist passiert: Datei wurde gefunden.
56
11.2 2. Semester 11 ANHANG A - TESTS UND FEHLERBEHEBUNG
11.2.20 OR-Suche nach 1 Keyword / Groß/ Kleinschreibung / Gemischt
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Die Datei wird gefunden.
Was ist passiert: Datei wurde gefunden.
11.2.21 AND-Suche nach 3 Keywords / Groß/ Kleinschreibung / Gemischt
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Die Datei wird gefunden.
Was ist passiert: Datei wurde gefunden.
11.2.22 OR-Suche nach 1 Keyword (Substring Anfang vom ersten Wort) / Groß/ Klein-
schreibung / Gemischt
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Die Datei wird gefunden.
Was ist passiert: Datei wurde gefunden.
11.2.23 OR-Suche nach 1 Keyword (Substring mitten im Wort) / Groß/ Kleinschreibung /
Gemischt
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Die Datei wird gefunden.
Was ist passiert: Datei wurde gefunden.
11.2.24 OR-Suche nach 3 Keywords (Substring Anfang vom ersten Wort) / Groß/ Klein-
schreibung / Gemischt
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Die Datei wird gefunden.
Was ist passiert: Datei wurde gefunden.
11.2.25 OR-Suche nach 3 Keywords (Substring mitten im Wort), Groß-/Kleinschreibung,
gemischt
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Die Datei wird gefunden.
Was ist passiert: Datei wurde gefunden.
11.2.26 Gutschrift von Credits beim Uplaod
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Der Peer, der hochlädt, bekommt beim Empfänger Credits gut-
geschrieben.
Was ist passiert: Credits werden gutgeschrieben (Durch Konsolenausgabe gete-
stet).
57
11.2 2. Semester 11 ANHANG A - TESTS UND FEHLERBEHEBUNG
11.2.27 Sortierung der Warteliste nach Credits
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Die Warteliste wird per Quicksort nach Credits sortiert.
Was ist passiert: Geräte mit den meisten Credits stehen am Anfang der Liste
(Durch Konsolenausgabe getestet).
11.2.28 Uploadpriorität vergeben
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: Dateien mit der höheren Priorität werden zuerst hochgeladen.
Was ist passiert: Dateien mit niedrigerer Priorität zuerst in der Warteschlange,
werden aber nach Dateien mit hoher Priorität hochgeladen.
11.2.29 Auslesen von Keywords aus ID3-Tags
Datum: 14.07.05
Verantwortliche Person: Paul, Boris, David
Was wird erwartet: ID3-Tags werden als Keywords hinzugefügt.
Was ist passiert: Alle Tags wurden korrekt extrahiert.
58
12 ANHANG B1 - DIAGRAMME, 1. SEMESTER
12 Anhang B1 - Diagramme, 1. Semester
12.1 Anwendungsfalldiagramm
Benutzer
eigene Dateien
managen
Dateien freigeben
Dateien sperren
freigegebene Dateien
auflisten
Dateien
austauschen Dateien suchen alsDownload
auswählen
System
Verbindung
aufrechterhalten
BTVerbindun
g aufbauen
Download
DL starten/resume
DL abbrechen
Fallback aktivieren
einkommende
Verbindungen managen
Uploads einsehen Uploads abbrechen
#Uploads
beschränkenauf Suchanfragen
reagieren
auf Downloadanfragen
reagieren
DL anhalten
Fallback Server
<<extend>>
<<extend>><<extend>>
<<extend>> <<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>><<extend>>
<<extend>>
<<include>>
<<extend>>
<<extend>>
Abbildung 2: Anwedungsfalldiagramm
59
12.2 Aktivitätsdiagramme 12 ANHANG B1 - DIAGRAMME, 1. SEMESTER
12.2 Aktivitätsdiagramme
12.2.1 Suchanfrage Erstellen
Keyword eingeben
Verbindung
Suchanfrage mit Keyword,
Geräte−ID, Such−ID generieren
Suchanfrage schicken
Warten auf Antwort
Antwort in Ergebnisliste
eintragen
mit Fallback−Server
verbinden
Ergebnisliste anzeigen
Antwort verwerfen
Timeout starten
ja
nein
nein
ja
ja
nein
nein
ja
janein
nein
ja
richtige
Abbildung 3: Suchanfrage erstellen
60
12.2 Aktivitätsdiagramme 12 ANHANG B1 - DIAGRAMME, 1. SEMESTER
12.2.2 Download Starten
Download anfragen (Broadcast)
Warten auf Antwort (mit Timeout)
Auflisten der Matchliste (Nach
Queueposition sortieren)
Benutze Fallback Server
Eintrag auswählen (vom
Benutzer)
An Dateianbieter eine
Sendeaufforderung schicken.
(Timeout starten)
Daten empfangen
warten!
Download abbrechen
Datei speichern Datei aus Download liste
entfernen
Datei in Freigabeliste eintragen
Meldung
Daten aus Downloadliste
bereitstellen (Hashwert und
Startbyte)
[else]
[genug freier Speicherplatz
vorhanden]
Abbruch durch Benutzer
[Antwort erhalten][else]
[Queueposition = 1]
[keine weitere Einträge in
Matchliste vorhanden]
[else]
[Antwort erhalten]
[else]
Abbruch durch Benutzer
[Antworten erhalten (Liste mit
Hashwerten, Queueposition,
Dateigröße und  deviceID)]
[else]
Datei in
Shareverzeichniss
speichern
Antworten
Download
start/resume
Sucher Perspektive
Datei aus
Downloadliste
löschen.
und Gegenseite
benachrichtigen
mit DeviceID und
Hashwert
Abbildung 4: Download starten
61
12.2 Aktivitätsdiagramme 12 ANHANG B1 - DIAGRAMME, 1. SEMESTER
12.2.3 Auf Suchanfrage Reagieren
Generierung der Antwort mit
Dateiname, Hashwert, Queue−Pos.,
Geräte−ID, Dateigröße, Such−ID
Liste durchsuchen nach
Keywords
Emittlung der
Queue−Position
Warte auf Suchanfrage
senden der Antwort an den
Dateisuchenden
nein
ja
Programm beenden
neinja
Abbildung 5: Auf Suchanfrage reagieren
62
12.2 Aktivitätsdiagramme 12 ANHANG B1 - DIAGRAMME, 1. SEMESTER
12.2.4 Auf Downloadanfrage Reagieren
Antworten mit Queueposition
und Hashwert
Auf Anfragen warten
Senden ab Startposition
In Queue aufnehmen (Hashwert
und DeviceID speichern)
Upload abbrechen
Aus Queue entfernen
Queue aktualisieren
(Queueteilnehmer
benachrichtigen)
[Queue nicht leer]
[Queue leer]
Upload erfolgreich
abgeschlossen
Uploadabbruch durch Benutzer
(Suchender oder Sendender)
[Queue leer oder Suchende auf
Position 1] [else]
Sendeanforderung vom
Suchenden
Downloadanfrage
Auf Download Anfrage
reagieren
Dateianbieter Perspektive
Abbildung 6: Auf Downloadanfrage reagieren
63
12.2 Aktivitätsdiagramme 12 ANHANG B1 - DIAGRAMME, 1. SEMESTER
12.2.5 Verbindung Aufbauen
eigene Services registrieren
Inquiry starten
trage die
Geräteadresse in eine
Liste ein
Gerät stellt sich selbst zur
Verfügung und wartet auf andere
Clients; Filesharing−Netz
eröffnen
in bestehendes Filesharing−Netz
als Client einloggen
Instanz vom eigenen Gerät
bilden
ja
nein
nein
ja
Ist (weiteres) Gerät
DeviceDiscovered() und 
InquiryCompleted() werden  
währenddessen auto− 
matisch aufgerufen 
DeviceDiscovered ist selbst 
zu implementieren: Innerhalb
dessen 
kann zum Beispiel festgestellt
werden 
auf welchenGeräten unser
FileSharing 
Programm läuft
steht in der Geräteliste ein Gerät
mit (unserem) aktiviertem
Abbildung 7: Verbindung aufbauen
64
12.2 Aktivitätsdiagramme 12 ANHANG B1 - DIAGRAMME, 1. SEMESTER
12.2.6 Verbindung Aufrechterhalten
ernenne neuen Master
ja
nein
Tests nach zu urteilen, macht Java das alles selber. 
Wir haben z.B. den Master aus einem Bluechat mit 9(!) 
Endgeräten verschwinden lassen, ohne dass es Probleme 
gegeben hätte. Ob bei den 9 Geräten schon eine 
Scatternetz Implementierung zum Tragen kommt, oder 
das ein Gerät nur in den Park Modus gesetzt wird, 
konnten wir noch nicht herausfinden. Jedenfalls kamen 
Chat Nachrichten bei allen neun Geräten an
Abbildung 8: Verbindung aufrechterhalten
65
12.3 Sequenzdiagramme 12 ANHANG B1 - DIAGRAMME, 1. SEMESTER
12.3 Sequenzdiagramme
12.3.1 Suchanfrage Erstellen
Be
nu
tze
r
Me
inG
UIK
on
tro
lle
GU
IKo
ntr
olle
Me
inS
uc
hM
an
ag
er
Su
chM
an
ag
er
Me
ine
Su
ch
An
fra
ge
Su
chA
nfr
ag
e
Me
ine
Su
ch
Ma
tch
Lis
te
Su
chM
atc
hL
iste
Me
inT
im
er
Tim
er
Me
inS
ky
Ne
t
Sk
yN
et
ne
ue
rE
int
rag
Ma
tch
Lis
ten
Ein
tra
g
2: 
em
pfa
ng
eN
ach
rich
t(na
chr
icht
:BB
HN
ach
rich
t):v
oid
4: 
tim
erE
ve
nt(i
nt):
void
3: 
tim
erE
ve
nt(n
ach
rich
t:int
):vo
id
2.1
.2:
 hi
nz
ufu
eg
en
()
2.1
.1:
 M
atc
hL
iste
nE
int
rag
2.1
: h
inz
ufu
eg
en
Ma
tch
Lis
ten
Ein
tra
g(s
Ant
wor
t:Su
chA
ntw
ort)
:voi
d
1.1
.4:
 se
nd
e(B
BH
Nac
hric
ht):
boo
lean
1.1
.3:
 st
art
eT
im
er(m
ana
ger
:Na
chr
icht
Ma
nag
er,s
eku
nde
n.in
t,na
ch..
.
1.1
.2:
 Su
chM
atc
hL
iste
1.1
.1:
 Su
chA
nfr
ag
e
6: 
ze
ich
ne
GU
I(in
t):v
oid
1.2
: s
tar
teT
im
er(E
reig
nisH
and
ler,
int,i
nt):
void
5: 
gib
Su
chM
atc
hL
iste
(int
):Su
chM
atch
List
e
1.1
: ’s
tar
teS
uch
e(S
trin
g[])
:Su
chM
atch
List
e’(k
eyw
ord
s:S
trin
g)
1: 
co
mm
an
dA
ctio
n(c
:Co
mm
and
,d:D
ispl
aya
ble)
:voi
d
Me
ine
Su
chM
atc
hL
iste
 in 
Me
ine
Su
che
n e
intr
ag
en
  
Su
chI
DZ
ae
hle
r e
rho
eh
en
Ve
rw
erf
en
 fa
lls 
Su
chI
D a
us
sA
ntw
ort
 un
be
kan
nt 
 
od
er 
tim
erA
bg
ela
ufe
n =
 TR
UE
in 
de
r p
ass
en
de
n
Su
chM
atc
hL
iste
sta
rte
 Ti
me
r 6
 m
al 
hin
ter
ein
an
de
r für
je 5
 Se
kun
den
. Üb
erg
ebe
 als
Pa
ram
ete
r R
efe
ren
z a
uf 
sic
h s
elb
st, 
5
Se
kun
de
n u
nd
 Na
chr
ich
t =
 Su
chI
D
die
ser
 Su
che
 (au
s de
r Re
fere
nz a
uf
Su
chM
atc
hL
iste
, d
ie a
ls R
ückg
ab
ew
ert
be
i st
art
eS
uch
e üb
erg
eb
en
 wi
rd).
Für 
jede
s ob
en 
ges
tart
ete
"s
tar
teT
im
er"
 we
rde
n 5
. u
nd
 6.
jede
s m
al a
usg
efüh
rt.
Ve
rw
erf
en
 fa
lls 
Su
chI
D u
nb
eka
nn
t 
an
so
ns
ten
 Ti
me
rAb
ge
lau
fen
 in 
de
r p
ass
en
de
n
Su
chM
atc
hL
iste
 au
f T
RU
E
für je
den
 Su
chM
atch
List
enE
intr
ag 
aus
 sA
ntw
ort
ein
en
 M
atc
hL
iste
nE
int
rag
 er
ste
llen
 un
d in
 die
pa
sse
nd
e S
uch
Ma
tch
Lis
te 
au
s M
ein
eS
uch
en
ein
tra
ge
n
Abbildung 9: Suchanfrage erstellen
66
12.3 Sequenzdiagramme 12 ANHANG B1 - DIAGRAMME, 1. SEMESTER
12.3.2 Download Starten
GU
IKo
ntr
oll
e
m
ein
Do
wn
loa
dM
an
ag
er_
Do
wn
loa
dM
an
ag
er
m
ein
eD
ow
nlo
ad
An
fra
ge
Do
wn
loa
dA
nfr
ag
e
m
ein
Sk
yN
et_
Sk
yN
et
m
ein
Tim
er_
Tim
er
m
ein
eQ
ue
lle
Do
wn
loa
dQ
uel
le
m
ein
eD
ow
nlo
ad
An
for
de
run
g
Do
wn
loa
dA
nfo
rde
run
g
9: 
tim
erE
ve
nt(i
nt):
void
4: 
tim
erE
ve
nt(i
nt):
void
10
: e
mp
fan
ge
Na
chr
ich
t(Up
loa
dSt
art)
:vo
id
8: 
em
pfa
ng
eN
ach
rich
t(ei
neD
own
loa
dAn
two
rt):v
oid
2: 
em
pfa
ng
eN
ach
rich
t(do
wnlo
ada
ntwo
rt):v
oid
7: 
sta
rte
Tim
er(m
ein
Dow
nlo
adM
ana
ger
,):v
oid
6: 
se
nd
e(m
ein
eDo
wnl
oad
Anf
ord
eru
ng)
:bo
ole
an
5:3: 
Do
wn
loa
dQ
uel
le
1.3
: s
tar
teT
im
er(E
reig
nisH
and
ler,
int,
int)
:vo
id
1.2
: s
en
de
(me
ine
dow
nlo
ada
nfra
ge)
:bo
ole
an
1.1
:
1: 
sta
rt(D
own
loa
dEi
ntra
g):v
oid
Ke
ine
 Qu
elle
n im
Do
wn
loa
dE
int
rag
vo
rha
nd
enÜbe
rprüf
en 
ob 
gen
ug
fre
ier
 Sp
eic
he
rpl
atz
vo
rha
nd
en
 ist
. W
en
n
ne
in,
 da
nn
 En
de
.
m
ein
eQ
uel
le w
ird 
zu
Do
wn
loa
dE
int
rag
(de
r vo
n d
er G
UI)
hin
zu
ge
fügt
.
Ve
rw
erf
e a
lle
Do
wn
loa
dA
ntw
ort
en
 m
it
Wa
rte
po
siti
on
 −1
 un
d −
2 u
nd
en
tfe
rne
 di
e e
nts
pre
che
nd
e
Do
wn
loa
dq
ue
llen
 au
s d
em
Do
wn
loa
de
int
rag
.
All
e w
eit
ere
n
Do
wn
loa
dA
ntw
ort
en
 we
rde
n
ve
rw
or
fen
.
1. 
So
ba
ld T
ime
r a
bg
ela
ufe
n,
we
rde
n w
eit
ere
Do
wn
loa
dA
ntw
ort
en
 ve
rw
orf
en
.
2. 
Wä
hle
 5 
be
ste
n P
art
ne
r a
us
,
na
ch
 Qu
eue
pos
itio
n o
der
 Ho
ps.
Für 
jed
e e
ing
ega
nge
ne
Do
wn
loa
da
ntw
ort
 wi
rd
jew
eils
 ein
 ne
ues
Do
wn
loa
dQ
uel
le O
bje
kt
er
ze
ug
t u
nd
 in
do
wn
loa
dQ
uel
len
 vo
n
Do
wn
loa
de
int
rag
hin
zu
ge
fügt
.
Ge
ne
rie
re 
Do
wn
loa
dA
bb
ruc
h
Na
ch
ric
hte
n u
nd
 ve
rsc
hic
ke
sie
 an
 di
e r
es
tlic
he
n P
art
ne
r,
die
 vo
rhi
n a
us
ge
suc
ht
wo
rde
n s
ind
. W
eit
ere
Up
loa
dS
tar
t N
ach
rich
ten
 für
die
se
 Da
tei
 we
rde
n
ve
rw
or
fen
.
Sc
hri
tte
 5 
un
d 6
 we
rde
n f
ür
alle
 5 
be
ste
n P
art
ne
r
du
rch
ge
führ
t
Abbildung 10: Download starten
67
12.3 Sequenzdiagramme 12 ANHANG B1 - DIAGRAMME, 1. SEMESTER
12.3.3 Auf Suchanfrage Reagieren
Sk
yN
et
m
ein
eE
ige
ne
Da
tei
en
Ma
na
ge
r_
Eig
en
eD
ate
ien
Ma
na
ge
r
tem
p1
Su
chA
ntw
ort
Ein
tra
g
m
ein
eS
uc
hIn
de
xL
ist
e
Su
chI
nd
exL
iste
sA
Te
mp
Su
chA
ntw
ort
m
ein
Up
loa
dM
an
ag
er
Up
loa
dM
an
ag
er
m
ein
Sk
yN
et
Sk
yN
et
1.3
: s
en
de
(BB
HN
ach
rich
t):b
oole
an
1.2
: g
ibW
art
ep
osi
tion
():in
t
1.1
.4:
 ’e
inf
ue
ge
nS
uch
An
two
rtE
intr
ag
():v
oid’
1.1.3: <co
ns
tru
cto
r>()
1.1
.1:
 gib
Da
tein
am
en
(Str
ing)
:Ind
exE
intr
ag
1.1
.2:
 <c
on
str
uc
tor
>()
1.1
: s
uc
he
Ke
yw
ord
s(S
trin
g[])
:Su
chA
ntw
ort
1: 
em
pfa
ng
eN
ach
rich
t(BB
HN
ach
rich
t):v
oid
Sc
hri
tt 1
.1.
1 w
ird
 für 
jede
s K
eyw
ord
 wie
der
holt
.
Au
s je
dem
 Ele
me
nt (
Dat
eire
fere
nz)
 de
r M
eng
e w
ird 
ein
Su
chA
ntw
ort
Ein
tra
g g
en
eri
ert
. D
ie D
azu
 be
nötig
ten
Inf
orm
ati
on
ne
n w
erd
en
 au
s d
en
 Da
teir
efe
ren
zen
 ge
ho
lt.
1.1
.4 
wir
d f
ür je
den
 Su
chA
ntw
ortE
intr
ag
au
fge
ruf
en
.
Na
ch
 1.
2 m
us
s a
us
 de
r S
uch
An
fra
ge
 die
su
ch
ID 
ex
tra
hie
rt w
erd
en
.   
An
sch
ließ
en
d m
uss
 zie
lBT
Ad
r_ 
un
d
eig
en
eB
T_
 m
it W
ert
en
 au
s d
er 
Su
chA
nfr
ag
e
be
leg
t w
erd
en
.
Na
ch
 de
m 
Erh
alt 
jede
s In
dex
Ein
trag
s w
ird 
jede
 Da
teir
efe
ren
z in
 ein
e 
Me
ng
e e
ing
efüg
t, s
o d
ass
 sic
he
r g
est
ellt
 wi
rd 
da
ss 
kei
ne
 Da
tei 
do
pp
elt 
ein
ge
fügt
 wi
rd.
Abbildung 11: Auf Suchanfrage reagieren
68
12.3 Sequenzdiagramme 12 ANHANG B1 - DIAGRAMME, 1. SEMESTER
12.3.4 StarteApp
m
ein
Pr
og
ram
m_
Pro
gra
mm
m
ein
Tim
er_
Tim
er
ze
itp
un
kte
_
m
ein
eP
ee
rs_
Be
nu
tze
r
m
ein
Sk
yN
et_
Sk
yN
et
m
an
ag
erL
ist
e_
m
ein
Eig
en
eD
ate
ien
Ma
na
ge
r_
Eig
en
eD
ate
ien
Ma
na
ge
r
su
ch
Ind
ex
_
Su
chI
nd
exL
iste
fre
ige
ge
be
ne
Da
tei
en
_
Fre
iga
be
Lis
te
m
ein
Do
wn
loa
dM
an
ag
er
Do
wn
loa
dM
an
ag
er
m
ein
eL
ist
e_
Do
wn
loa
dL
iste
m
ein
Up
loa
dM
an
ag
er_
Up
loa
dM
an
ag
er
m
ein
GU
IKo
ntr
oll
e_
GU
IKo
ntr
olle
m
ein
eL
ist
e
Up
loa
dL
iste
m
ein
eS
uc
he
n_
m
ein
Su
ch
Ma
na
ge
r_
Su
chM
an
ag
er
1.7
.5:
 re
gis
trie
reM
an
ag
er(t
his,
 BB
HN
ach
rich
t.DO
WN
LOA
D_A
NFR
A...
1.7
.4:
 re
gis
trie
reM
an
ag
er(t
his,
 BB
HN
ach
rich
t.DO
WN
LOA
D_A
NFO
R...
1.7
.2:
 <s
up
er>
 //a
nza
hlU
plo
ad
s=x
;
1.7
.1:
 ’U
plo
ad
Lis
te()
:voi
d’
1.6
.5:
 re
gis
trie
reM
an
ag
er(t
his,
 BB
HN
ach
rich
t.UP
LOA
D_S
TAR
T):v
oid
1.6
.4:
 re
gis
trie
reM
an
ag
er(t
his,
 BB
HN
ach
rich
t.UP
LOA
D):v
oid
1.6
.3:
 re
gis
trie
reM
an
ag
er(t
his,
 BB
HN
ach
rich
t.DO
WN
LOA
D_A
NTW
...
1.6
.2:
 re
gis
trie
reM
an
ag
er(t
his,
 BB
HN
ach
rich
t.SU
CH
_AN
TW
OR
T):v
oid
1.6
.1:
 ’D
ow
nlo
ad
Lis
te()
:voi
d’
1.5
.3:
 re
gis
trie
reM
an
ag
er(t
his,
 BB
HN
ach
rich
t.SU
CH
_AN
TW
OR
T):v
oid
1.5
.2:
 <s
up
er>
 //s
uch
IDZ
ae
hle
r =
 0;
1.5.1:
1.4
.3:
 re
gis
trie
reM
an
ag
er(t
his,
 BB
HN
ach
rich
t.SU
CH
_AN
FRA
GE
):vo
id
1.4
.2:
 ’F
rei
ga
be
Lis
te(S
trin
g):v
oid’
(UR
L:S
trin
g)
1.4
.1:
 ’S
uch
Ind
exL
iste
(Str
ing)
:voi
d’(U
RL:
Stri
ng)
1.3
.1:
1: 
sta
rtA
pp
():v
oid
1.1
.1:
1.9
: u
eb
erp
rue
feF
rei
ga
be
Lis
te()
:voi
d
1.8
: ’G
UIK
on
tro
lle(d
own
load
Ma
nag
er,U
ploa
dM
ana
ger
,Su
chM
ana
g...
1.10: sta
rte
Ne
tzw
erk
():voi
d
1.7
: ’U
plo
ad
Ma
na
ge
r():v
oid’
1.6
: <
co
ns
tru
cto
r>()
1.5
: <
co
ns
tru
cto
r>()
1.4
: <
co
ns
tru
cto
r>()
1.3: <co
ns
tru
cto
r>()
1.2:1.1
: ’T
im
er()
:voi
d’
1.7
.3:
 re
gis
trie
reM
an
ag
er(t
his,
 BB
HN
ach
rich
t.DO
WN
LOA
D_A
BBR
U...
Lis
te
Abbildung 12: Applikation starten
69
12.3 Sequenzdiagramme 12 ANHANG B1 - DIAGRAMME, 1. SEMESTER
12.3.5 Auf Downloadanfragen Reagieren
Sk
yN
et
Up
Ma
na
ge
r
Up
loa
dM
an
ag
er
Me
ine
An
tw
ort
Do
wn
loa
dA
ntw
ort
Me
inS
ky
Ne
t
Sk
yN
et
m
ein
Eig
en
eD
ate
ien
Ma
na
ge
r_
Eig
en
eD
ate
ien
Ma
na
ge
r
1.1
: v
era
rbe
iteD
ow
nlo
ad
An
fra
ge
(Do
wnl
oad
Anf
rag
e):v
oid
1.2
: e
xis
tie
rtD
ate
i(ha
shw
ert)
:bo
olea
n
1.4
: s
en
de
(Me
ineA
ntw
ort:
BBH
Nac
hric
ht):
boo
lean
1.3
: D
ow
nlo
ad
An
two
rt
1: 
em
pfa
ng
eN
ach
rich
t(Do
wnl
oad
anf
rag
e:D
own
load
Anf
rag
e):v
oid
We
nn
 Da
tei
 ni
ch
t e
xis
tie
rt d
an
n
en
de
Abbildung 13: Auf Downloadanfrage reagieren
70
12.3 Sequenzdiagramme 12 ANHANG B1 - DIAGRAMME, 1. SEMESTER
12.3.6 Auf Downloadanforderungen reagieren
Sk
yN
et
m
ein
Up
loa
dM
an
ag
er_
Up
loa
dM
an
ag
er
Me
inE
int
rag
Up
loa
dE
intr
ag
Me
ine
Up
loa
dL
ist
e
Up
loa
dL
iste
m
ein
Eig
en
eD
ate
ien
Ma
na
ge
r_
Eig
en
eD
ate
ien
Ma
na
ge
r
Me
ine
Up
loa
dN
ac
hri
ch
t
Up
loa
d
m
ein
Sk
yN
et_
Sk
yN
et
1.1
: a
ufn
eh
me
nIn
Qu
eue
(Do
wnl
oad
Anf
ord
eru
ng)
:voi
d
1.6
: s
en
de
(Me
ineU
ploa
dNa
chr
icht
):bo
olea
n
1.5
: U
plo
ad
1.2
: g
ibD
ate
i(ha
shw
ert:
Stri
ng)
:Da
tei
1.4
: h
inz
ufu
eg
en
()
1.3
: U
plo
ad
Ein
tra
g
1: 
em
pfa
ng
eN
ach
rich
t(Do
wnl
oad
anf
ord
eru
ng:
BBH
Nac
hric
ht):
void
We
nn
 die
 Qu
eue
 lee
r is
t U
plo
adP
ake
t
er
ste
llen
, in
 die
 Qu
eue
 au
f 0−
te P
osi
tion
au
fne
hm
en
, s
on
st 
nu
r in
 die
 Qu
eue
au
fne
hm
en
 un
d D
ow
nlo
ad
An
two
rt P
ake
t
m
it a
ktu
elle
r Q
ueu
epo
siti
on 
ers
tell
en
fal
ls d
ie D
ate
i ni
cht
 ex
isti
ert
, lie
fer
t
gib
Da
tei 
NU
LL
 zu
rück
 un
d e
s w
ird
 ein
e
Do
wn
loa
dA
ntw
ort
 m
it Q
ueu
epo
siti
on 
−2
zu
rück
ge
sch
ick
t, d
an
n E
nd
e
An
na
hm
e: 
Ein
tra
g is
t a
n 0
−te
r Q
ueu
epo
siti
on
Se
tze
n d
er 
Att
rib
ute
 vo
n
Me
ine
Up
loa
dN
ach
rich
t: 
sta
rtB
yte
_, 
ha
shw
ert
_ a
us
Do
wn
loa
da
nfo
rde
run
g. 
ro
hD
ate
n_
 wi
rd 
ge
füllt 
mit
 Hi
lfe 
de
r v
on
gib
Da
tei(
) zu
rückg
elie
fert
en 
Dat
ei−
Ref
ere
nz
Ch
eck
, o
b Q
ueu
e v
oll 
ist:
 Up
loa
dlis
te.s
ize
 >=
an
za
hlU
plo
ad
s_ 
We
nn
 ja: 
Ers
telle
n e
iner
 Do
wnl
oad
Ant
wor
t m
it
Qu
eue
pos
itio
n =
 −1
 un
d s
end
en 
über
 Sk
yN
et, 
dan
n
En
de
Abbildung 14: Auf Downloadanforderung reagieren
71
13 ANHANG B2 - DIAGRAMME, 2. SEMESTER
13 Anhang B2 - Diagramme, 2. Semester
13.1 Aktivitätsdiagramme
13.1.1 Baumknoten
Comm
Rollenwechsel (zu
Koordinator)
Routingtabelle
aktualisieren
Liste
aktualisieren
eigene Rolle
senden
Verbindunganfrage
angekommen
Rolle F
sonst
Knoten als Koordinatorknoten
ernannt
Rolle
überprüfen
Liste der eigenen Kinderknoten wird
erweitert.    
Der Baumknoten falls noch nicht Bridge
dann auf Bridge setzen
− Neue Hashtabelle erstellen und BT
Adresse von F eintragen (Distanz 1)  
− Neue Hashtabelle an Elter
weiterreichen.
Abbildung 15: Baumknoten
72
13.1 Aktivitätsdiagramme 13 ANHANG B2 - DIAGRAMME, 2. SEMESTER
13.1.2 Fehlerbehandlung
Rollenwechsel (zu
Freiem Knoten)
und
Statuswechsel zu
Slave
Rollenwechsel (zu Wurzelknoten)
und Statuswechsel zu Master
Liste
aktualisieren
Statuswechsel zu
Slave
Liste
aktualisieren
Routingtabelle
aktualisieren
(Nein)
(Ja)
(Nein)
(Ja)
[Nein]
(Ja)
Report über
Verbindungsabbruch
BT add == BT Add
vom Elter
Noch ein Kind
Reports werden geworfen, wenn die Verbindung zu einem direkt verbundenen Gerät
abbricht.
Noch ein Kind
Kind aus
Kinderliste
entfernen
Hashtabelle vom Kind
löschen  
Elter für Routingänderung
informieren
Abbildung 16: Fehlerbehandlung
73
13.1 Aktivitätsdiagramme 13 ANHANG B2 - DIAGRAMME, 2. SEMESTER
13.1.3 Freierknoten
Inquiry
starten
Geräteliste
durchgehen
temporär
verbinden
Geräterolle
abfragen
temporär
verbinden
Geräterolle
abfragen
Liste
aktualisieren
Routingtabelle
aktualisieren
Initialisierung
Wait and
Listen
Liste
aktualisieren
Routingtabelle
aktualisieren
Liste
aktualiersieren
Verbindung
aufbauen
sonst
Falls: W
Falls: B, K
Timeout for Inquirystart
F
Verbindung von einem anderen
Knoten angestoßen
Geräterolle:
Freienknoten
Routingtabelle
leeren  
Auf Slave setzen
Liste der eigenen Kinderknoten
wird erweitert.  
Rolle auf Wurzel setzen  
Status auf Master setzen
Geräterollen:  
W= Wurzelknoten  
B=Baumknoten  
F=FreierKnoten  
K=Koordinatorknoten
Elter wird gesetzt   
Rolle auf Baum setzen
  
Status auf Slave
setzen
Neue Hashtabelle erstellen
Der Elterzeiger wird
gesetzt.   
Bleibt Slave  
Die Knotenrolle wird
gesetzt 
auf Baumknoten
Neue Hashtabelle erstellen
und BT Add des Slaves
eintragen (Distanz 1)
Abbildung 17: Freierknoten
74
13.1 Aktivitätsdiagramme 13 ANHANG B2 - DIAGRAMME, 2. SEMESTER
13.1.4 Koordinatorknoten
Comm/Scan Modus
durchführen Wurzeladresse zurück
senden
Rollenwechsel (zu
Baumknoten)
Inquiry
starten
Geräteliste
durchgehen
temporär
verbinden
Geräterolle
abfragen
Info an Wurzelknoten
weiterleiten
Wurzel BT Add von K
erfragen
Falls: W, F, B
Falls: K
sonst
Wurzelanfrage von anderem
Koordinator erhalten
Koordinator wird von Wurzel
abgesetzt
Time out : nachjedem TO
randomisiert  
neu setzen
Geräterollen:  
W= Wurzelknoten  
B=Baumknoten  
F=FreierKnoten  
K=Koordinatorknoten
WICHTIG: Koordinatorknoten hat auch gleiche Aktivitäten wie
Baumknoten.
Abbildung 18: Koordinatorknoten
75
13.1 Aktivitätsdiagramme 13 ANHANG B2 - DIAGRAMME, 2. SEMESTER
13.1.5 Master-Slave-Entscheidung
Inquiry Phase
Slave
Master
Geräteliste durchgehen
Verbindung mit dem ersten
Master der noch freie Plätze hat
ja
nein
ja
nein
Andere Geräte
Bei einem Master
Abbildung 19: Master-Slave-Entscheidung
76
13.1 Aktivitätsdiagramme 13 ANHANG B2 - DIAGRAMME, 2. SEMESTER
13.1.6 Routingaenderung
aktualisierte Routingtabelle an
Elter weiterleiten. Falls selber
nicht Wurzel
eigene Routingtabelle
aktualisieren
Routingänderung erhalten
Abbildung 20: Routingänderung
77
13.1 Aktivitätsdiagramme 13 ANHANG B2 - DIAGRAMME, 2. SEMESTER
13.1.7 Wurzelknoten
Comm
Zustand
alten Koordinator absetzen und
neuen Koordinator randomisiert
ernennen
Rollenwechsel (zum Baum)
andere Wurzel benachrichtigen,
dass sie zum Baumknoten
mutiert
Verbindung herstellen (zum
anderen Wurzelknoten)
Liste
aktualisieren
Routingtabelle
aktualisieren
Nachricht vom
Koordinatenknoten,dass er einen
neuen Baum gefunden hat.
Nachricht von anderer Wurzel
bekommen
Time out : Zeitintervall nach
jedem TO randomisiert neu
setzen
Geräterolle:
Wurzelknoten
Nur wenn Rolle Baum: Routingtablle komplett an Elter
weiterleiten
Fall 1 (Baum):  
Der Elterzeiger wird gesetzt.  
Bridge Status einnehmen.  
Alter Koordinator verliert Job.  
Fall 2 (Wurzel):  
Liste der eigenen Kinderknoten wird
erweitert.  
Alter Koordinator verliert Job.  
neuen Koordinatorknoten zufällig wählen
Abbildung 21: Wurzelknoten
78
13.2 Sequenzdiagramme 13 ANHANG B2 - DIAGRAMME, 2. SEMESTER
13.2 Sequenzdiagramme
13.2.1 2 Bäume durch Wurzel vereinigen (aktiv)
Wu
rze
lkn
ote
n
m
ein
Ne
tzw
erk
Ne
tzw
erk
m
ein
Ve
rw
alt
un
gs
Ma
na
ge
r
Ve
rw
alt
un
gsM
an
ag
er
m
ein
Ve
rw
alt
un
gs
pa
ke
t
Ve
rw
alt
un
gsP
ake
t
2.2
: s
en
de
Ve
rwa
ltun
gsP
ake
t(Ve
rwa
ltun
gsP
ake
t):v
oid
2.1
:
1.1
.1:
 wu
rze
lIn
qu
iryS
tar
t(St
ring
):vo
id
3: 
em
pfa
ng
eN
ach
rich
t(Ve
rwa
ltun
gsP
ake
t):v
oid
2: 
wu
rze
lIn
qu
iryF
ert
ig(S
trin
g):v
oid
1.1
: e
mp
fan
ge
Na
chr
ich
t(Ve
rwa
ltun
gsP
ake
t):v
oid
1:
eig
en
e R
ou
ting
tab
elle
du
rch
 ne
ue
 In
for
ma
tion
en
er
gä
nze
n
Ve
rw
alt
un
gsp
ake
t
en
thä
lt N
ac
hri
ch
t v
om
Ko
ord
ina
tor
 m
it d
er 
BT
Ad
dr 
de
r a
nd
ere
n
Wu
rze
l
leit
et 
2
Ba
eu
me
du
rch
Wu
rze
lve
rin
ige
n(p
ass
iv)
be
i de
r a
nd
ere
n W
urz
el e
in
Abbildung 22: Zwei Bäume durch Wurzel vereinigen, aktiv
79
13.2 Sequenzdiagramme 13 ANHANG B2 - DIAGRAMME, 2. SEMESTER
13.2.2 2 Bäume durch Wurzel vereinigen (passiv)
Wu
rze
lKn
ote
n
m
ein
Ne
tzw
erk
Ne
tzw
erk
m
ein
Ve
rw
alt
un
gs
Ma
na
ge
r
Ve
rw
alt
un
gsM
an
ag
er
m
ein
Na
ch
ric
ht
Ve
rw
alt
un
gsP
ake
t
1.1
.1.
2: 
se
nd
eV
erw
altu
ng
sP
ake
t(Ve
rwa
ltun
gsP
ake
t):v
oid
1.1
.1:
 re
ag
ier
eA
ufB
au
mv
ers
chm
elz
un
g():
void
1.1
.1.
1:
1.1
: e
mp
fan
ge
Na
chr
ich
t(Ve
rwa
ltun
gsP
ake
t):v
oid
1:
Ad
res
se 
de
r W
urz
el u
nd
Ro
uti
ng
sta
be
lle 
de
r
eig
en
en
 W
urz
el s
en
de
n
Ro
lle 
de
r W
urz
el w
ird
 au
f
Ba
um
 ge
set
zt
Ko
ord
ina
tor
kno
ten
ab
wä
hle
n
Elt
er 
au
f S
en
de
r d
es
Ve
rw
alt
un
gsp
ake
t se
tze
n
Abbildung 23: Zwei Bäume durch Wurzel vereinigen, passiv
80
13.2 Sequenzdiagramme 13 ANHANG B2 - DIAGRAMME, 2. SEMESTER
13.2.3 2 Bäume vereinigen (Koordinator)
Ko
ord
ina
tor
Kn
ote
n
m
ein
Ne
tzw
erk
Ne
tzw
erk
m
ein
Ve
rw
alt
un
gs
Ma
na
ge
r
Ve
rw
alt
un
gsM
an
ag
er
m
ein
eN
ac
hri
ch
t
Ve
rw
alt
un
gsP
ake
t
m
ein
eN
ac
hri
ch
tA
nW
urz
el
Ve
rw
alt
un
gsP
ake
t
2.2
: s
en
de
Ve
rw
alt
un
gsP
ake
t(Ve
rwa
ltun
gsP
ake
t):v
oid
2.1
:
1.1
.2:
 se
nd
eV
erw
alt
un
gsP
ake
t(Ve
rwa
ltun
gsP
ake
t):v
oid
1.1
.1:
2: 
em
pfa
ng
eN
ach
rich
t(Ve
rwa
ltun
gsP
ake
t):v
oid
1.1
: v
ere
inig
un
gB
ae
um
e(G
era
et):
void
1: 
ko
ord
ina
tor
Inq
uir
yS
tar
t():v
oid
ge
sch
ieh
t in
ein
em
 
ra
nd
om
isie
rt
fes
tge
leg
tem
Int
erv
all
Blu
eT
oo
th 
Ad
res
se
de
r W
urz
el 
erf
rag
en
Tim
eo
ut 
ge
sta
rte
t
tei
lt B
T A
dd
r d
er
an
de
ren
 W
urz
el 
mi
t
Abbildung 24: Zwei Bäume vereinigen, Koordinator
81
13.2 Sequenzdiagramme 13 ANHANG B2 - DIAGRAMME, 2. SEMESTER
13.2.4 Freien Knoten integrieren
Lis
ten
er
m
ein
Ne
tzw
erk
Ne
tzw
erk
m
ein
Ve
rw
alt
un
gs
Ma
na
ge
r
Ve
rw
alt
un
gsM
an
ag
er
m
ein
eN
ac
hri
ch
t
Ve
rw
alt
un
gsP
ake
t
2.3
: e
ntf
ern
eG
era
et(G
era
et):
void
2.2
: s
etz
eR
olle
(ch
ar):
void
2.1
: s
etz
eE
lte
r(St
ring
):vo
id
1.1
.2:
 se
nd
eV
erw
altu
ng
sP
ake
t(Ve
rwa
ltun
gsP
ake
t):v
oid
1.1
.1:
2: 
em
pfa
ng
eN
ach
rich
t(Ve
rwa
ltun
gsP
ake
t):v
oid
1.1
: fi
nd
eE
lter
(Ge
rae
teL
iste
):St
ring
1: 
inq
uir
yA
bg
esc
hlo
sse
n():
void
Tim
eO
ut 
wir
d g
est
art
et
Wi
rd 
für a
lle 
Ge
rae
te
au
ss
er
 de
m 
Elt
er
au
fge
ruf
en
De
r A
ufr
uf 
vo
n
se
nd
eR
ep
ort
() w
ird
für d
ies
e G
era
ete
un
ter
drüc
kt
Ro
lle 
wir
d a
ls
Ba
um
 ge
set
zt
Ge
ge
nse
ite 
em
pfä
ng
t N
ach
rich
t, a
ntw
ort
et 
mit
Ve
rw
alt
un
gsP
ake
t, w
ech
sel
t e
ven
tue
ll S
tat
us 
au
f B
rig
de
, w
en
n
vo
rhe
r S
lav
e u
nd
 ak
tua
lisi
ert
 die
 Ro
utin
g T
ab
elle
n
Abbildung 25: Freien Knoten integrieren
82
13.2 Sequenzdiagramme 13 ANHANG B2 - DIAGRAMME, 2. SEMESTER
13.2.5 Piconetz
Ac
tor
Ne
tzw
erk
Te
mp
Lis
te
Se
nd
er
An
de
reG
era
ete
1.1
.1:
 se
nd
eA
nfr
ag
e
2: 
se
tze
Ge
rae
te
1.1
: g
ibM
ast
er
1: 
Inq
uir
y fe
rtig
We
nn
 Ru
ec
kga
be
tru
e: 
Ma
ste
r is
t
fre
i 
We
nn
 Ru
ec
kga
be
fal
se
: M
as
ter
 vo
ll
od
er 
Sla
ve
Fa
lls 
wir
 Nu
ll
zu
rück
be
kom
me
n, 
 
we
rde
n w
ir M
ast
er 
un
d
tra
ge
n n
ich
ts i
n d
ie 
An
de
reG
era
ete
. 
Fa
lls 
wir
 ei
ne
n f
rei
en
Ma
ste
r
zu
rück
be
kom
me
n, 
tra
ge
n w
ir d
ies
en
 zu
 de
r
An
de
reG
era
ete
−L
iste
.
wir
d f
ue
r a
lle
Ge
rae
te 
au
s d
er 
Lis
te
au
sge
fue
hrt
.
Abbildung 26: Piconetz aufbauen
83
13.2 Sequenzdiagramme 13 ANHANG B2 - DIAGRAMME, 2. SEMESTER
13.2.6 Routing von BBH-Paketen
m
ein
Ve
rw
alt
un
gs
Ma
na
ge
r
Ve
rw
alt
un
gsM
an
ag
er
m
ein
Se
nd
er
Se
nd
er
m
ein
eN
ac
hri
ch
t
BB
HN
ac
hri
ch
t
an
de
reG
era
ete
Ge
rae
teL
iste
Ap
pli
ka
tio
ns
sc
hic
ht
m
ein
Ne
tzw
erk
Ne
tzw
erk
m
ein
Sk
yN
et
Sk
yN
et 1.1: s
en
de
Na
ch
ric
ht(B
BH
Nac
hric
ht):b
ool
ean
2: 
rou
teN
ac
hri
ch
t(by
te[]
):vo
id
1.1.4: fue
ge
Zu
Qu
eu
eH
inz
u(by
te[]
,Ger
aet
):boo
lea
n
1.1.2: gib
Ge
rae
t(Str
ing
):Ger
aet
1.1
.3:
 to
Str
ea
m()
:byte
[]
1.1
.1:
 gib
Ec
hte
nE
mp
fae
ng
er(B
BH
Nac
hric
ht):
Stri
ng
1: 
se
nd
e(B
BH
Nac
hric
ht):
boo
lean AB
LA
UF
 BE
I E
INE
R E
ING
EH
EN
DE
N N
AC
HR
ICH
T
−
toB
BH
() w
ird 
auf
ger
ufe
n
−
es
 w
ird
 ue
be
rpr
ue
ft, 
ob
 zie
lBT
Ad
dr_
 de
rBB
HN
ach
rich
t =
Ne
tzw
erk
.gib
Eig
en
eB
TA
dr()
 ist
fal
ls ja
 wir
d d
as P
ake
t an
 die
 da
für re
gist
rier
ten
 Ma
nag
er w
eite
rge
geb
en,
an
so
ns
ten
 w
ird
 Ne
tzw
erk
.se
nd
eN
ach
rich
t() a
ufg
eru
fen
 na
chd
em
 de
r
Pa
ram
ete
r e
ige
ne
BT
Ad
r_ 
de
r N
ach
rich
t ve
rae
nd
ert
 wu
rde
be
i B
roa
dca
st: 
an
 all
e K
ind
er 
un
d a
n E
lter
 sc
hic
ken
, b
is a
uf 
die
Ve
rbi
nd
un
g z
u d
em
 Ge
rae
t, b
ei d
em
 BT
Ad
dr 
= e
ige
ne
BT
Ad
r_
de
r B
BH
Na
chr
ich
t is
t
Abbildung 27: Routing von BBH-Paketen
84
13.2 Sequenzdiagramme 13 ANHANG B2 - DIAGRAMME, 2. SEMESTER
13.2.7 Verbindungstrennung abfangen
Lis
ten
er
m
ein
Ne
tzw
erk
Ne
tzw
erk
m
ein
Ve
rw
alt
un
gs
Ma
na
ge
r
Ve
rw
alt
un
gsM
an
ag
er
m
ein
Ve
rw
alt
un
gs
Pa
ke
t
Ve
rw
alt
un
gsP
ake
t
1.1
.1.
2: 
se
nd
eV
erw
altu
ng
sP
ake
t(Ve
rwa
ltun
gsP
ake
t):v
oid
1.1
.1.
1: 
ne
w
1.1
.1:
 re
ag
ier
eA
ufV
erb
ind
un
gsA
bb
ruc
h(S
trin
g):v
oid
1.1
: e
mp
fan
ge
Re
po
rt(S
trin
g):v
oid
1: 
se
nd
eR
ep
ort
(Str
ing)
:voi
d
Nu
r F
alls
 es
 se
lbe
r k
ein
e W
urz
el i
st. 
so
ns
t w
ird
 ke
in V
erw
altu
ng
sP
ake
t e
rze
ug
t
Abbildung 28: Verbindungstrennung abfangen
85
14 ANHANG B3 - KLASSENDIAGRAMM
14 Anhang B3 - Klassendiagramm
0..1
1
1
Suc
hIn
dex
List
e
−
eint
rae
ge_
:Ve
ctor
+Su
chIn
dex
List
e()
+be
rein
igen
():vo
id
+hin
zufu
ege
n(me
inEin
trag:
Inde
xEin
trag)
:void
+e
ntfe
rne
n(me
inEin
trag:
Inde
xEin
trag)
:void
+gib
Dat
eina
men
(key
word
:Strin
g):In
dexE
intra
g
+gib
Eint
raeg
e():V
ecto
r
Ind
exE
intr
ag
−
date
ien_
:Ve
ctor
−
key
wor
d_:S
tring
+In
dex
Ein
trag
(key
word
:Strin
g,da
teien
Vect
or:Ve
ctor)
+In
dex
Ein
trag
(key
word
:Strin
g)
+In
dex
Ein
trag
(key
word
:Strin
g,da
tei:D
atei)
+hin
zufu
ege
n(me
ineD
atei:
Date
i):vo
id
+e
ntfe
rne
n(me
ineD
atei:
Date
i):vo
id
+gib
Dat
eien
():Ve
ctor
+gib
Key
wor
d():S
tring
inte
rfac
e
Nac
hric
htM
ana
ger
+e
mpf
ang
eNa
chri
cht(n
achr
icht:B
BHN
achr
icht)
:void
+v
ers
en
detP
ake
t(has
hwer
t:Stri
ng,b
t_Ad
dr:St
ring,
erfol
greic
h:bo
olea
n):vo
id
Ver
bin
dun
gen
+Ge
raet
+Ne
tzw
erk
+Se
nde
r
+Em
pfae
nge
r
+Lo
calD
evic
e
+St
ream
Con
nec
tion
Not
ifier
+St
ream
Con
nec
tion
+Re
mot
eDe
vice
+Th
rea
d
<<
con
trol>
>
Upl
oad
Man
age
r
−
an
zah
lUp
load
s_:i
nt
−
me
ineL
iste
_:U
ploa
dLis
te
−
me
inE
igen
eDa
teie
nMa
nag
er_:
Eige
neD
atei
enM
ana
ger
−
me
inSk
yNe
t_:S
kyN
et
−
me
inP
rogr
amm
_:P
rogr
amm
−
uplo
adL
aeu
ft_:b
oole
an
−
an
zah
lPa
kete
_:in
t
−
aktu
elle
sPa
ket_
:int
+Up
load
Man
age
r(eD
M:Ei
gene
Date
ienM
anag
er,sN
:Sky
Net,p
:Prog
ramm
)
+a
bbr
ech
en(h
ashw
ert:S
tring
,bt_A
ddr:S
tring
):voi
d
+v
ers
en
detP
ake
t(has
hwer
t:Stri
ng,b
t_Ad
dr:St
ring,
erfol
greic
h:bo
olea
n):vo
id
+a
ufne
hme
nInQ
ueu
e(an
forde
rung
:Dow
nloa
dAnf
orde
rung
):voi
d
+v
era
rbe
iteD
own
load
Anf
rage
(dow
nloa
danf
rage
:Dow
nloa
dAnf
rage
):voi
d
+a
ktua
lisie
ren
():vo
id
+n
ae
chs
terU
ploa
d(ha
shwe
rt:Str
ing,b
t_Ad
dr:St
ring,
start
byte
:long
):voi
d
+bit
teB
ena
chri
chti
gen
(has
hwer
t:Stri
ng,b
t_Ad
dr:St
ring,
queu
epos
ition:
int):v
oid
+e
mpf
ang
eNa
chri
cht(n
achr
icht:B
BHN
achr
icht)
:void
+v
era
rbe
iteD
own
load
Abb
rech
en(d
ownl
oada
bbru
ch:D
ownl
oadA
bbru
ch):v
oid
+gib
Wa
rtep
osit
ion()
:int
+gib
Anz
ahlU
ploa
ds():
int
+gib
Upl
oad
List
e():U
ploa
dList
e
Suc
hMa
tch
List
e
−
eint
rag_
:Ve
ctor
−
suc
hID
_:in
t
−
time
rAb
gela
ufen
_:bo
olea
n
−
me
inSu
chM
ana
ger:
Suc
hMa
nag
er
−
key
wor
ds_
:Str
ing 
[]
Dow
nlo
adL
iste
−
me
inD
own
load
Man
age
r_:D
own
load
Man
age
r
−
dow
nloa
dEi
ntra
g_:V
ecto
r
+Do
wnl
oad
List
e()
+Do
wnl
oad
List
e(me
inDo
wnlo
adM
anag
er:D
ownl
oadM
anag
er)
+gib
Dow
nloa
dLis
te():V
ecto
r
+gib
Dow
nloa
dLis
teG
roes
se():
int
+fue
geD
own
load
Eint
ragH
inzu
(dow
nloa
dEin
trag:
Dow
nloa
dEin
trag)
:void
+e
ntha
lteD
own
load
Ein
trag
(mei
neDo
wnlo
adEi
ntrag
:Dow
nloa
dEin
trag)
:boo
lean
+e
ntha
lteD
own
load
Ein
trag
Aus
Has
hwe
rt(ha
shwe
rt:Str
ing):
bool
ean
+gib
Dow
nloa
dEin
trag
(has
hwer
t:Stri
ng):D
ownl
oadE
intra
g
+e
ntfe
rne
Dow
nloa
dEi
ntra
g(do
wnlo
adEi
ntrag
:Dow
nloa
dEin
trag)
:void
+e
ntfe
rne
Dow
nloa
dEi
ntra
gAu
sHa
shw
ert(h
ashw
ert:S
tring
):voi
d
Tim
er
−
zeit
pun
kte_
:Lis
te
+st
arte
Tim
er(an
forde
rer:E
reign
isHa
ndle
r,sek
unde
n:int
,nac
hrich
t:int)
:void
<<
con
trol>
> Sky
Net
+AN
ZAH
L_N
ACH
RIC
HTE
N:in
t=8
−
ma
na
gerL
iste
_:V
ecto
r[]
−
me
inN
etzw
erk_
:Ne
tzw
erk
−
na
chri
chtB
uffe
r_:V
ecto
r
−
Wie
Vie
lteN
ach
rich
tistU
ploa
dPa
ket:
int
−
Has
wer
tUp
load
Pak
et:S
tring
−
BTA
drU
ploa
dPa
ket:
Stri
ng
+Sk
yNe
t()
+se
nde
(Pak
et:BB
HNa
chric
ht):b
oole
an
−
sen
deB
roa
dca
st(Pa
ket:B
BHN
achr
icht)
:boo
lean
+ro
ute
Nac
hric
ht(na
chric
ht:by
te[]):
void
+te
rmin
iere
():vo
id
+a
ktiv
iere
Fall
bac
k():v
oid
+st
arte
Net
zwe
rk():v
oid
+re
gist
riere
Man
age
r(ma
nage
r:Na
chric
htMa
nage
r,bbh
typ:b
yte):
void
+ge
sen
det()
:void
+gib
Eige
neB
tadr
():St
ring
+gib
Hop
sVo
nBT
_Ad
dr(bt
_Add
r_:St
ring)
:int
+gib
Frie
ndly
Nam
eVo
nBT
_Ad
dr(bt
_Add
r:Str
ing):
Strin
g
+se
nde
rFre
i():bo
olea
n
Eig
ene
Dat
eien
Man
age
r
−
tem
pDa
teie
n_:V
ecto
r
−
me
ineF
ileC
onn
ecti
on_
:File
Con
nec
tion
−
me
inD
ataI
npu
tStr
eam
_:D
ataI
npu
tStr
eam
−
me
inH
ash
wer
t_:S
tring
letz
tesB
yte_
:lon
g
−
MA
XUP
LOA
D:in
t
−
DEF
AUL
TSA
VED
IR:S
tring
="fil
e:///
root
1/in
com
ing/
"
−
suc
hInd
ex_
:Su
chIn
dex
List
e
−
freig
ege
ben
eDa
teie
n_:F
reig
abe
List
e
−
me
inSk
yNe
t_:S
kyN
et
−
me
inP
rogr
amm
_:P
rogr
amm
−
me
inD
LMa
nag
er_:
Dow
nloa
dMa
nag
er
+Ei
gen
eDa
teie
nMa
nag
er(m
einS
kyNe
t:Sky
Net,m
einP
rogra
mm:
Prog
ramm
)
+Ei
gen
eDa
teie
nMa
nag
er(m
einS
kyNe
t:Sky
Net,m
einP
rogra
mm:
Prog
ramm
,freig
abeL
iste:F
reiga
beLi
ste,s
uchI
ndex
:Suc
hInd
exLis
te)
+Ei
gen
eDa
teie
nMa
nag
er()
+gib
Fre
iDa
tei(u
rl:Str
ing):
bool
ean
−
gibF
reiD
atei
(url:S
tring
,has
hwer
t:Stri
ng):v
oid
−
gibF
reiD
atei
(url:S
tring
,has
hwer
t:Stri
ng,m
odifie
d:lon
g):vo
id
+sp
erre
Dat
ei(ur
l:Stri
ng):v
oid
+e
xist
iertD
atei
(has
hwer
t:Stri
ng):b
oole
an
+u
mbe
nen
nen
Dat
ei(da
tei:D
atei,
neue
rNam
e:Str
ing):
bool
ean
+su
che
Key
wor
ds(k
eywo
rds:S
tring
[]):Su
chAn
twor
t
+e
mpf
ang
eNa
chri
cht(n
achr
icht:B
BHN
achr
icht)
:void
−
rea
gier
eAu
fUp
load
Sta
rt(na
chric
ht:Up
load
Start
):voi
d
−
rea
gier
eAu
fUp
load
(nac
hrich
t:Upl
oad)
:void
−
gibT
mp(h
ashw
ert:S
tring
):Tm
pEin
trag
+gib
Fre
iOrd
ner(u
rl:Str
ing):
bool
ean
+u
ebe
rpru
efeF
reig
abe
List
e():v
oid
+gib
Roh
date
n(ha
shwe
rt:Str
ing,s
tartb
yte:lo
ng,e
ndby
te:lo
ng):b
yte[]
+gib
Anz
ahlU
ploa
dPa
kete
(has
hwer
t:Stri
ng,s
tartb
yte:lo
ng):i
nt
−
sch
reib
eDa
tei(u
rl:Str
ing,in
halt:
byte
[],sta
rtbyt
e:lon
g):vo
id
+loe
sch
eTe
mp(h
ash:
Strin
g):vo
id
−
ber
ech
neP
ake
tNr(d
ateig
roes
se:lo
ng,s
tartb
yte:lo
ng):i
nt
+sp
eich
ern(s
peich
erUR
L:Str
ing):
void
+lad
en(s
peich
erUR
L:Str
ing):
void
+loe
sch
en(U
RL:S
tring
):voi
d
+v
ers
en
detP
ake
t(has
hwer
t:Stri
ng,b
t_Ad
dr:St
ring,
erfol
greic
h:bo
olea
n):vo
id
+se
tze
Dow
nloa
dve
rzei
chn
is(ur
l:Stri
ng):v
oid
+gib
Dat
ei(ha
shwe
rt:Str
ing):
Date
i
+gib
Suc
hInd
ex():
Such
Inde
xList
e
+lis
teD
atei
en():
Freig
abeL
iste
BB
HTi
me
r
−
zeit
pun
kte_
:Ve
ctor
−
me
inTi
mer
_:T
ime
r
−
me
inTa
sk_
:BB
HTi
mer
Tas
k
+BB
HTi
mer
()
+st
arte
Tim
er(an
forde
rer:E
reign
isHa
ndle
r,sek
unde
n:int
,nac
hrich
t:int)
:void
+be
end
eTim
er():v
oid
+gib
Zeit
pun
kte()
:Vec
tor
Run
nab
le
HTT
PSS
end
er
−
fert
ig:b
oole
an
+HT
TPS
Sen
der()
+ru
n():v
oid
pos
tVia
Http
Con
nec
tion
(url:S
tring
,pak
et:by
te[]):
void
+st
op():
void
−
proc
ess
(date
n:by
te[]):
void
−
proc
ess
(date
n:by
te):v
oid
−
proc
ess
Typ
e(blu
b:Str
ing):
void
Run
nab
le
Em
pfa
eng
er
−
ne
tzw
erk_
:Ne
tzw
erk
−
fert
ig_:
boo
lean
+a
dre
ssa
t_:G
erae
t
+Em
pfae
nge
r(adr
essa
t:Ge
raet,
netz
:Netz
werk
)
+ru
n():v
oid
+st
op():
void
Tm
pEi
ntra
g
−
an
zah
lPa
kete
_:in
t
−
has
hwe
rt_:
Stri
ng
−
tmp
Dat
eiU
RL_
:Str
ing
−
fert
ig_:
byte
[]
+Tm
pEin
trag
(anz
ahlP
aket
e:int
)
+fer
tig(p
aket
nr:in
t):vo
id
+ist
Kom
plet
t():bo
olea
n
+gib
Fer
tig():
byte
[]
+ist
Fer
tig(p
aket
Num
mer:
int):b
oole
an
+gib
Anz
ahlP
ake
te_()
:int
+se
tze
Anz
ahlP
ake
te_(a
nzah
lPak
ete_
:int):
void
+gib
Has
hwe
rt_():
Strin
g
+se
tze
Has
hwe
rt_(h
ashw
ert_:
Strin
g):vo
id
+gib
Tmp
Dat
eiU
RL_
():St
ring
+se
tze
Tm
pDa
teiU
RL_
(tmp
Date
iURL
_:Str
ing):
void
Util
s
+M
ess
age
Dig
est5
Run
nab
le
Net
zwe
rk
−
an
der
eGe
raet
e_:G
erae
teLi
ste=
new
 Ge
raet
eLis
te()
−
lock
_:O
bjec
t=ne
w Ob
ject(
)
−
me
inSk
yNe
t_:S
kyN
et
+se
nde
r_:S
end
er
−
age
nt_:
Disc
ove
ryA
gen
t=nu
ll
−
rec
_:S
ervi
ceR
eco
rd
−
fert
ig_:
boo
lean
=fal
se
−
con
n_
:L2C
APC
onn
ecti
on
−
me
inH
TTP
SSe
nde
r_:H
TTP
SSe
nde
r
−
me
inH
TTP
SEm
pfae
nge
r_:H
TTP
SEm
pfae
nge
r
−
uu
id_:
UUI
D=n
ew 
UUI
D("
112
233
445
566
778
899
a0b
0c0
d0e
0f01
0", 
fals
e)
−
SER
VIC
E_T
ELE
PHO
NY:
int=
0x4
000
00
−
ser
ver
URL
:Str
ing=
"ww
w.c
s.un
i−do
rtmu
nd.d
e/se
rver
/"
+de
bug
:boo
lean
=tru
e
−
loka
lesG
erae
t_:L
oca
lDe
vice
−
ser
ver
_:L2
CAP
Con
nec
tion
Not
ifier
−
me
inV
erw
altu
ngs
Man
age
r_:V
erw
altu
ngs
Man
age
r
+se
nde
Ver
wal
tung
sPa
ket(n
achr
icht:V
erwa
ltung
sPak
et):v
oid
+Ne
tzw
erk(n
et:Sk
yNet
)
+st
arte
Net
zwe
rk():v
oid
+ru
n():v
oid
+st
op():
void
+hin
zufu
ege
Ger
aet(e
inGe
raet:
Gera
et):v
oid
+sc
hon
Vor
han
den
(p0:G
erae
t):bo
olea
n
+e
mpf
ang
eNa
chri
cht(n
achr
icht:b
yte[]
):voi
d
+se
nde
Bro
adc
ast(P
aket
:BBH
Nach
richt
):boo
lean
+se
nde
Nac
hric
ht(Pa
ket:B
BHN
achr
icht)
:boo
lean
+te
rmin
iere
n():v
oid
+a
ktiv
iere
Fall
bac
k():v
oid
+v
erb
indu
ngA
bge
broc
hen
(einG
erae
t:Ge
raet)
:void
+ge
sen
det()
:void
+se
nde
Rep
ort(m
essa
ge:S
tring
):voi
d
+de
bug
(mes
sage
:Strin
g):vo
id
+gib
Eige
neB
tadr
():St
ring
+gib
Frie
ndly
Nam
eVo
nBT
_Ad
dr(bt
_Add
r:Str
ing):
Strin
g
+gib
Age
nt():D
iscov
eryA
gent
+gib
uuid
():UU
ID
+gib
Sen
der()
:Sen
der
+gib
Alle
BTA
dres
sen
():St
ring[
]
+inq
uiry
Abg
esc
hlos
sen
():vo
id
+e
ntfe
rne
Ger
aet(m
einG
erae
t:Ge
raet)
:void
+ko
ord
inat
orIn
quir
ySta
rt():v
oid
+e
mpf
ang
eNa
chri
cht(p
0:Ve
rwalt
ungs
pake
t):vo
id
+se
nde
AnW
urze
l(p0:
gera
et,p1
:Rou
tings
tabe
lle):v
oid
+w
urz
elIn
quir
ySta
rt(BT
addr
:Strin
g):vo
id
Pee
r
−
hop
s_:i
nt
−
frien
dlyN
ame
_:S
tring
−
btA
dr_
:Str
ing
−
dow
nloa
dUm
fang
:int
−
uplo
adU
mfa
ng:i
nt
+Pe
er()
+Pe
er(ho
ps:in
t,frie
ndlyN
ame
:Strin
g,btA
dr:St
ring)
+gib
Hop
s():in
t
+gib
Frie
ndly
Nam
e():S
tring
+gib
BTA
dr():S
tring
+se
tze
Hop
s(ho
ps:in
t):vo
id
+se
tze
Frie
ndly
Nam
e(frie
ndlyN
ame
:Strin
g):vo
id
+se
tze
BTA
dr(bT
Adr:S
tring
):voi
d
+to
Stri
ng():
Strin
g
+gib
Mod
ifier
():Int
eger
Kon
ver
tier
ung
+v
ect
orT
oBy
teA
rray
(vec
tor:V
ecto
r):by
te[]
+v
ect
orT
oSt
ring
Arra
y(ve
ctor:
Vect
or):S
tring
[]
+sc
hre
ibeB
yteA
rray
InV
ecto
r(my
Vect
or:Ve
ctor,
myA
rray:
byte
[]):Ve
ctor
+By
teA
rray
ToS
tring
(zuK
onve
rtiere
n:by
te[]):
Strin
g
+St
ring
ToB
yteA
rray
(zuK
onve
rtiere
n:Str
ing):
byte
[]
+By
teA
rray
ToL
ong
(zuK
onve
rtiere
n:by
te[]):
long
+Lo
ngT
oBy
teA
rray
(zuK
onve
rtiere
n:lon
g):by
te[]
+By
teA
rray
ToIn
t(zuK
onve
rtiere
n:by
te[]):
int
+La
eng
eTo
Lae
nge
nAr
ray(z
uKon
verti
eren
:int):
byte
[]
+La
eng
enA
rray
ToL
aen
ge(z
uKon
verti
eren
:byte
[]):in
t
+By
teTo
Int(z
uKon
verti
eren
:byte
):int
+In
tTo
Byte
Arra
y(zu
Konv
ertie
ren:i
nt):b
yte[]
Fre
igab
eLis
te
−
me
ineL
iste
_:V
ecto
r
+Fr
eiga
beL
iste
()
+hin
zufu
ege
n(me
ineD
atei:
Date
i):vo
id
+e
ntfe
rne
n(me
ineD
atei:
Date
i):vo
id
+gib
Dat
ei(ha
shwe
rt:Str
ing):
Date
i
+gib
Dat
eiM
itUR
L(url
:Strin
g):D
atei
+gib
List
e():V
ecto
r
<<
con
trol>
>
Dow
nlo
adM
ana
ger
−
me
ineL
iste
_:D
own
load
List
e
−
me
inSu
chM
ana
ger_
:Su
chM
ana
ger
−
me
inE
igen
eDa
teie
nMa
nag
er_:
Eige
neD
atei
enM
ana
ger
−
time
r_:B
BHT
ime
r
−
me
inSk
yNe
t_:S
kyN
et
−
me
inP
rogr
amm
_:P
rogr
amm
−
lauf
end
eTim
erID
_:in
t
−
time
outs
_:V
ecto
r
+Do
wnl
oad
Man
age
r()
+Do
wnl
oad
Man
age
r(suc
hMa
nage
r:Suc
hMa
nage
r,me
inEig
eneD
ateie
nMa
nage
r:Eig
eneD
ateie
nMa
nage
r,sky
Net:S
kyNe
t,pro
gram
m:Pr
ogra
mm,
t:BB
HTim
er)
+Do
wnl
oad
Man
age
r(suc
hMa
nage
r:Suc
hMa
nage
r,me
inEig
eneD
ateie
nMa
nage
r:Eig
eneD
ateie
nMa
nage
r,sky
Net:S
kyNe
t,t:BB
HTim
er)
+gib
Dow
nloa
dLis
te():D
ownl
oadL
iste
+st
art(m
einD
ownl
oadE
intra
g:Do
wnlo
adEi
ntrag
):voi
d
+a
bbr
ech
en(m
einD
ownl
oadE
intra
g:Do
wnlo
adEi
ntrag
):voi
d
+pa
use
(mei
nDow
nloa
dEin
trag:
Dow
nloa
dEin
trag)
:void
−
sch
icke
Abb
ruch
Nac
hric
ht(m
einD
ownl
oadE
intra
g:Do
wnlo
adEi
ntrag
):voi
d
+hin
zufu
ege
nDo
wnl
oad
(mat
chLis
tenE
intra
g:Ma
tchL
isten
Eintr
ag):D
ownl
oadE
intra
g
+v
era
rbe
iteD
own
load
Ant
wor
tAu
fAn
frag
e(me
ineD
ownl
oadA
ntwo
rt:Do
wnlo
adAn
twor
t):vo
id
+v
era
rbe
iteD
own
load
Ant
wor
tAu
fAn
ford
eru
ng(m
eine
Dow
nloa
dAnt
wort
:Dow
nloa
dAnt
wort
):voi
d
+u
ploa
dSt
art(h
ashw
ert:S
tring
):voi
d
+do
wnl
oad
Fer
tig(h
ashw
ert:S
tring
):voi
d
+e
mpf
ang
eNa
chri
cht(n
achr
icht:B
BHN
achr
icht)
:void
+v
ers
en
detP
ake
t(has
hwer
t:Stri
ng,b
t_Ad
dr:St
ring,
erfol
greic
h:bo
olea
n):vo
id
+tim
erE
ven
t(id:i
nt):v
oid
+sp
eich
ern(s
peich
erUR
L:Str
ing):
void
+lad
en(s
peich
erUR
L:Str
ing):
void
−
Tim
eou
tOb
jekt
Ger
aet
−
me
inE
mpf
aen
ger_
:Em
pfae
nge
r
−
rde
v_:R
emo
teD
evic
e
−
con
_:L2
CAP
Con
nec
tion
−
me
inN
etzw
erk_
:Ne
tzw
erk
−
Tra
nsID
:int
+Ge
raet
(p0:R
emo
teDe
vice,
p1:N
etzw
erk)
+Ge
raet
(p0:R
emo
teDe
vice,
p1:N
etzw
erk,p
2:L2
CAP
Conn
ectio
n)
+te
rmin
iere
Thr
ead
s():v
oid
+se
nde
Nac
hric
ht(na
chric
ht:by
te[]):
bool
ean
+e
mpf
ang
eNa
chri
cht(n
achr
icht:b
yte[]
):voi
d
+se
tze
Con
_(co
n:L2
CAP
Conn
ectio
n):vo
id
+gib
Rem
oteD
evic
e():R
emo
teDe
vice
+gib
Em
pfae
nge
r():E
mpfa
enge
r
+gib
Ver
bind
ung
():L2
CAP
Conn
ectio
n
+gib
BTA
dres
se():
Strin
g
+gib
Frie
ndly
Nam
e():S
tring
 
tran
sID
:int
List
Com
man
dLis
tene
r
File
Bro
wse
r
−
play
er:P
laye
r
−
cm
dBe
end
en:C
omm
and
=ne
w C
omm
and
("Zu
rück",
 Com
man
d.EX
IT, 1
)
−
cm
dOp
en:C
omm
and
=ne
w C
omm
and
("Öff
nen"
, Com
man
d.ITE
M, 1
)
−
cm
dFr
eige
ben
:Co
mm
and
=ne
w C
omm
and
("Fre
igeb
en", 
Com
man
d.ITE
M,
2)
−
cur
ren
tDir
:Str
ing=
"/"
−
fcon
n:F
ileC
onn
ecti
on
−
dirC
onte
nt:E
num
erat
ion
−
img
_dir
:Ima
ge
−
img
_file
:Ima
ge
−
img
_so
und
:Ima
ge
−
img
_pic
:Ima
ge
−
img
_txt
:Ima
ge
−
img
_vid
eo:I
mag
e
−
sta
rted
Fro
m:G
UIK
ontr
olle
−
self
:File
Bro
wse
r
−
DEB
UG
:boo
lean
=fal
se
+Fi
leB
row
ser(m
ain:G
UIKo
ntrol
le,ro
ots:E
num
erati
on)
+co
mm
an
dAc
tion
(com
man
d:Co
mma
nd,d
ispla
yable
:Disp
layab
le):v
oid
−
sho
wD
ir(cu
rDir:
Strin
g):vo
id
inte
rfac
e
Ere
igni
sHa
ndle
r
+tim
erE
ven
t(nac
hrich
t:int)
:void
Suc
hAn
two
rtEi
ntra
g
−
date
inam
e_:S
tring
−
has
hwe
rt_:
Stri
ng
−
groe
sse
_:lo
ng
+Su
chA
ntw
ortE
intra
g()
+Su
chA
ntw
ortE
intra
g(da
teina
me:S
tring
,has
hwer
t:Stri
ng,g
roes
se:lo
ng)
+gib
Dat
eina
me()
:Strin
g
+se
tze
Dat
eina
me(d
atein
ame
:Strin
g):vo
id
+gib
Gro
ess
e():lo
ng
+se
tze
Gro
ess
e(gro
esse
:long
):voi
d
+gib
Has
hwe
rt():S
tring
+se
tze
Has
hwe
rt(ha
shwe
rt:Str
ing):
void
MID
let
<<
con
trol>
>
Pro
gra
mm
−
me
inD
own
load
Man
age
r_:D
own
load
Man
age
r
−
me
inE
igen
eDa
teie
nMa
nag
er_:
Eige
neD
atei
enM
ana
ger
−
me
inU
ploa
dMa
nag
er_:
Upl
oad
Man
age
r
−
disp
lay_
:Dis
play
−
me
ineU
rlDo
wnl
oad
_:S
tring
="fil
e:///
root
1/B
BHC
onfi
g/co
nfig
Dow
nloa
d.bb
h"
−
me
ineU
rlEig
ene
Dat
eien
_:S
tring
="fil
e:///
root
1/B
BHC
onfi
g/co
nfig
Eige
neD
atei
en.b
bh"
−
an
kom
men
deD
atei
en_
:Str
ing=
"file
:///ro
ot1/
inco
min
g/"
−
me
ineP
eer
s_:V
ecto
r
−
me
inB
BHT
ime
r_:B
BHT
ime
r
−
me
inG
UIK
ontr
olle
_:G
UIK
ontr
olle
−
me
inSk
yNe
t_:S
kyN
et
+st
artA
pp():
void
+pa
use
App
():vo
id
+de
stro
yAp
p(co
nditio
nal:b
oole
an):v
oid
+ist
Pee
rBe
kan
nt(bt
_Add
r:Str
ing):
bool
ean
+fue
geH
inzu
Pee
r(bt_
Addr
:Strin
g):vo
id
+gib
Pee
r(bt_
Addr
:Strin
g):Pe
er
−
date
iVo
rha
nde
nDo
wnl
oad
():bo
olea
n
−
date
iVo
rha
nde
nEi
gen
eDa
teie
n():b
oole
an
+gib
Wa
rteP
osit
ion()
:int
+gib
Dow
nloa
dMa
nag
er():D
ownl
oadM
anag
er
+gib
Upl
oad
Man
age
r():U
ploa
dMa
nage
r
+gib
Suc
hMa
nag
er():S
uchM
anag
er
+gib
Eige
neD
atei
enM
ana
ger()
:Eige
neDa
teien
Man
ager
+gib
Mei
neU
rlDo
wnl
oad
():St
ring
+se
tze
Mei
neU
rlDo
wnl
oad
(neu
eUrl:
Strin
g):vo
id
+gib
Mei
neU
rlEig
ene
Dat
eien
():St
ring
+gib
Ank
omm
end
eDa
teie
n():S
tring
+se
tze
Mei
neU
rlEig
ene
Dat
eien
(neu
eUrl:
Strin
g):vo
id
Sen
deQ
ueu
eEin
trag
−
einG
erae
t_:G
erae
t
−
Pak
etS
trea
m_:
byte
[]
+Se
nde
Que
ueE
intra
g(ein
Gera
et_:G
erae
t,Pak
etStr
eam
_:by
te[])
+gib
Pak
etS
trea
m():b
yte[]
+gib
Ger
aet()
:Ger
aet
Thr
ead
Dis
cov
eryL
iste
ner
Lis
ten
er
time
r:Ti
mer
ne
tzw
erk_
:Ne
tzw
erk
tem
plis
te_:
Ger
aete
List
e
lock
_:O
bjec
t
+Lis
tene
r(gel
ocke
d_:O
bject
,netz
werk
:Netz
werk
)
+de
vice
Disc
ove
red
(dev
:Rem
oteD
evice
,dcla
ss:D
evice
Clas
s):vo
id
+inq
uiry
Com
plet
ed(d
iscTy
pe:in
t):vo
id
+se
rvic
esD
isco
vere
d(tra
nsID
:int,s
ervR
ec:S
ervic
eRec
ord[]
):voi
d
+se
rvic
eSe
arch
Com
plet
ed(tr
ansI
D:int
,resp
Code
:int):
void
+gib
Ger
aete
List
e():G
erae
teLis
te
Vec
tor
Ger
aete
List
e
+Ge
raet
eLis
te()
+hin
zufu
ege
Ger
aet(e
inGe
raet:
Gera
et):v
oid
−
suc
hen
Bin
aer
(einG
erae
t:Ge
raet)
:int
−
suc
hen
Line
ar(B
TAdr
esse
:Strin
g):in
t
−
suc
hen
Bin
aer
(BTA
dres
se:S
tring
):int
−
suc
hen
Bin
aer
Hilf
(suc
hBTA
dres
se:S
tring
,star
t:int,
ende
:int):
int
−
einf
ueg
eGe
raet
Pos
ition
swa
hl(su
chBT
Adre
sse_
:Strin
g,sta
rt:int
,end
e:int
):int
+sc
hon
Vor
han
den
(einG
erae
t:Ge
raet)
:boo
lean
+gib
Letz
tenI
nde
x():in
t
+gib
Ger
aet(B
TAdr
esse
:Strin
g):G
erae
t
+e
ntfe
rne
Ger
aet(e
inGe
raet:
Gera
et):v
oid
Ver
wal
tun
gsP
ake
t
−
eige
neB
TAd
dr_:
Stri
ng
−
ziel
BTA
ddr
_:S
tring
−
eige
neR
olle
_:ch
ar
−
typ_
:byt
e
−
date
n_:S
tring
Ver
wal
tun
gsM
ana
ger
−
me
ineR
olle
_:ch
ar
−
me
inSt
atus
_:ch
ar
−
me
inE
lter_
:Ge
raet
−
me
ineR
outi
ngT
abe
lle_
:Ve
ctor
−
me
inN
etzw
erk_
:Ne
tzw
erk
+e
mpf
ang
eNa
chri
cht(n
achr
icht:V
erwa
ltung
sPak
et):v
oid
+e
mpf
ang
eNa
chri
cht(n
achr
icht:S
tring
):voi
d
+fin
deE
lter(p
0:Ge
raete
Liste
):Str
ing
+se
tze
Elte
r(adr
esse
:Strin
g):vo
id
+se
tze
Rol
le(ro
lle:ch
ar):v
oid
+v
ere
inig
ung
Bae
ume
(Koo
rdina
tor:G
erae
t):vo
id
+e
mpf
ang
eRe
port
(repo
rt:Str
ing):
void
+re
agie
reA
ufB
aum
vers
chm
elzu
ng():
void
+w
urz
elIn
quir
yFe
rtig(B
TAdd
r:Str
ing):
void
+gib
Ech
tenE
mpf
aen
ger(n
achr
icht:B
BHN
achr
icht)
:Strin
g
+re
agie
reA
ufV
erbi
ndu
ngs
Abb
ruch
(BTA
dr:St
ring)
:void
Upl
oad
Ein
trag
−
DEL
war
tepo
sitio
n_:i
nt
−
date
i_:D
atei
−
ziel
_:P
eer
−
sta
rtby
te_:
long
−
ges
tarte
t_:b
oole
an
−
cre
dits
_:in
t
−
eint
rags
zeit
_:D
ate
+Up
load
Eint
rag(w
artep
ositio
n:int
,date
i:Dat
ei,zie
l:Pee
r,sta
rtbyt
e:lon
g)
+st
arte
n():v
oid
+a
nha
lten
():vo
id
+gib
Dat
ei():D
atei
+gib
Sta
rtby
te():l
ong
+gib
Ges
tarte
t():bo
olea
n
+gib
Pee
r():P
eer
+gib
Has
hwe
rt():S
tring
+cr
edit
sNe
uBe
rech
nen
():vo
id
+gib
Cre
dits
():int
+gib
Wa
rtez
eit():
int
Tim
erT
ask
BB
HTi
me
rTa
sk
−
zeit
pun
kte_
:Ve
ctor
−
me
inD
ate_
:Da
te
−
me
inE
intra
g_:B
BHT
ime
rEin
trag
+BB
HTi
mer
Tas
k(ze
itpun
kte:V
ecto
r)
+ru
n():v
oid
Stre
amC
onn
ecti
on
+St
ream
():vo
id
ID3
−
artis
t:St
ring
−
titel
:Str
ing
−
albu
m:S
tring
+gib
artis
t():S
tring
+gib
Tite
l():St
ring
+gib
Albu
m():S
tring
+gib
Key
wor
ds():
Strin
g
Com
man
dLis
tene
r
GU
IKo
ntro
lle
−
me
inD
own
load
Man
age
r_:D
own
load
Man
age
r
−
me
inE
igen
eDa
teie
nMa
nag
er_:
Eige
neD
atei
enM
ana
ger
−
me
inSu
chM
ana
ger_
:Su
chM
ana
ger
−
me
inU
ploa
dMa
nag
er_:
Upl
oad
Man
age
r
−
me
inP
rogr
amm
_:P
rogr
amm
−
me
inB
BHT
ime
r_:B
BHT
ime
r
−
disp
lay_
:Dis
play
=nu
ll
−
sta
rtAl
ert_
:Ale
rt=n
ew 
Ale
rt("B
lue B
rewe
ry Ho
rse!"
)
−
spe
rren
Bild
sch
irm_
:Ale
rt=n
ew 
Aler
t("Da
tei sp
erren
")
−
fallb
ack
Bild
sch
irm_
:Ale
rt=n
ew 
Ale
rt("
Sie 
sind
 auf
 dem
 Fal
lbac
kse
rver
")
−
deta
ilsD
LBi
ldsc
hirm
_:A
lert=
new
 Ale
rt("D
ownl
oad 
Deta
ils")
−
deta
ilsU
LBil
dsc
hirm
_:A
lert=
new
 Ale
rt("U
ploa
d De
tails"
)
−
date
iUm
ben
nen
Bild
sch
irm_
:For
m=n
ew 
For
m("D
atei 
umb
enne
n")
−
ne
ue
Suc
heB
ilds
chir
m_:
For
m=n
ew 
For
m("N
eue 
Such
e")
−
me
nu
Icon
s_:I
mag
e[]
−
hau
ptB
ilds
chir
m_:
List
−
freig
abe
List
eBil
dsc
hirm
_:Li
st=n
ew 
List
("Fre
igab
e−Li
ste",
Cho
ice.
IMP
LIC
IT)
−
uplo
adL
iste
Bild
sch
irm_
:Lis
t=ne
w L
ist("U
ploa
d−Li
ste",
Cho
ice.
IMP
LIC
IT)
−
dow
nloa
dLis
teB
ilds
chir
m_:
List
=ne
w L
ist("D
ownl
oad−
Liste
",C
hoic
e.IM
PLI
CIT
)
−
date
ienF
reig
ebe
nBil
dsc
hirm
_:Fi
leBr
ows
er=n
ew 
File
Bro
wse
r(this
,Fi
leSy
stem
Reg
istry
.list
Roo
ts())
−
date
iSuc
hen
Bild
sch
irm_
:Lis
t=ne
w L
ist("D
ateie
n su
chen
",C
hoic
e.IM
PLI
CIT
, ne
w S
tring
[] { "N
eue 
Such
e ", "
Mein
e Su
chen
 ",
"Fa
llba
ck S
erve
r" }, 
null)
−
me
ineS
uch
enB
ilds
chir
m_:
List
=ne
w L
ist("M
eine
 Suc
hen"
,Ch
oice
.IMP
LIC
IT)
−
suc
her
geb
niss
eBil
dsc
hirm
_:Li
st=n
ew 
List
("Su
cher
gebn
isse"
,Ch
oice
.IMP
LIC
IT)
−
gera
eteB
ilds
chir
m_:
List
=ne
w L
ist("G
eräte
 in U
mge
bung
",C
hoic
e.IM
PLI
CIT
)
−
opti
onB
ilds
chir
m_:
For
m=n
ew 
For
m("O
ption
en")
−
exit
Com
man
d_:C
omm
and
=ne
w C
omm
and
("Be
ende
n",
Com
man
d.E
XIT
, 1)
−
deta
ilsC
omm
and
_:C
omm
and
=ne
w C
omm
and
("De
tails"
,Co
mm
and
.SC
REE
N, 2
)
−
spe
rren
Com
man
d_:C
omm
and
=ne
w C
omm
and
("spe
rren"
,Co
mm
and
.SC
REE
N, 2
)
−
um
ben
nen
Com
man
d_:C
omm
and
=ne
w C
omm
and
("Um
benn
en",
Com
man
d.S
CRE
EN,
 2)
−
bac
kCo
mm
and
_:C
omm
and
=ne
w C
omm
and
("Zu
rück",
Com
man
d.B
ACK
, 1)
−
jaCo
mma
nd_:
Com
man
d=ne
w Co
mma
nd("J
a", C
omm
and.
OK, 
1)
−
ne
inC
omm
and
_:C
omm
and
=ne
w C
omm
and
("Ne
in",
Com
man
d.C
ANC
EL,
 1)
−
abb
rech
enC
omm
and
_:C
omm
and
=ne
w C
omm
and
("Ab
brec
hen"
,Co
mm
and
.SC
REE
N, 2
)
−
sta
rtCo
mm
and
_:C
omm
and
=ne
w C
omm
and
("Sta
rt",
Com
man
d.IT
EM
, 1)
−
pau
seC
omm
and
_:C
omm
and
=ne
w C
omm
and
("Pa
use"
,Co
mm
and
.ITE
M, 1
)
−
an
zeig
enC
omm
and
_:C
omm
and
=ne
w C
omm
and
("An
zeige
n",
Com
man
d.S
CRE
EN,
 2)
−
loes
che
nCo
mm
and
_:C
omm
and
=ne
w C
omm
and
("Lösc
hen"
,Co
mm
and
.SC
REE
N, 2
)
−
alle
Loe
sch
enC
omm
and
_:C
omm
and
=ne
w C
omm
and
("A
lle l
ösch
en"
, Co
mm
and
.SC
REE
N, 2
)
−
ne
ue
Suc
heC
omm
and
_:C
omm
and
=ne
w C
omm
and
("Ne
ue S
uche
",C
omm
and
.SC
REE
N, 2
)
−
hau
ptM
enu
eCo
mm
and
_:C
omm
and
=ne
w C
omm
and
("Ha
uptm
enü",
Com
man
d.S
CRE
EN,
 2)
−
dow
nloa
dCo
mm
and
_:C
omm
and
=ne
w C
omm
and
("z
u D
L hi
nzu
fügen
", C
omm
and
.SC
REE
N, 2
)
−
dow
nloa
dSt
artC
omm
and
_:C
omm
and
=ne
w C
omm
and
("D
own
load
 sta
rten
", C
omm
and
.SC
REE
N, 2
)
−
fallb
ack
Com
man
d_:C
omm
and
=ne
w C
omm
and
("F
allb
ack
 sta
rten
", C
omm
and
.SC
REE
N, 2
)
−
spe
iche
rnC
omm
and
_:C
omm
and
=ne
w C
omm
and
("Sp
eiche
rn",
Com
man
d.S
CRE
EN,
 2)
−
okC
omm
and
_:C
omm
and
=ne
w C
omm
and
("OK
", Co
mma
nd.S
CRE
EN,
1)
−
date
iUm
ben
nen
Tex
tfiel
d_:T
extF
ield
=ne
w T
extF
ield
("", "
", 25
,Te
xtFi
eld.
URL
)
−
suc
hTe
xtIte
m_:
Tex
tFie
ld=n
ew 
Tex
tFie
ld("S
uchb
egrif
f: ", "
", 30
,Te
xtFi
eld.
ANY
)
−
suc
heti
meo
utIte
m_:
Tex
tFie
ld=n
ew 
Tex
tFie
ld(
"De
r Ti
meo
ut für
 die
 Su
che
 bet
rägt
: ", "
", 3,
 Tex
tFie
ld.N
UM
ERI
C)
−
inqu
iryti
meo
utIte
m_:
Tex
tFie
ld=n
ew 
Tex
tFie
ld(
"Ze
it A
bsta
nd d
er S
uch
e na
ch G
erät
e:", 
"", 4
, Te
xtFi
eld.
NUM
ERI
C)
−
suc
htim
eou
t_:in
t
−
inqu
iryti
meo
ut_:
int
−
suc
hID
:int[]
−
aktu
elle
Sm
l:Ve
ctor
−
tem
pDa
teiR
ef_:
Dat
ei=n
ull
+GU
IKo
ntro
lle(d
is:Di
splay
,mid
let:P
rogra
mm,
time
r:BB
HTim
er)
−
freig
abe
Bild
sch
irmA
ktua
lisie
ren()
:void
−
dow
nloa
dBi
ldsc
hirm
Akt
uali
sier
en():
void
−
uplo
adB
ilds
chir
mA
ktua
lisie
ren()
:void
−
me
ineS
uch
enB
ilds
chir
mA
ktua
lisie
ren()
:void
−
suc
her
geb
niss
eBil
dsc
hirm
Aktu
alis
iere
n():v
oid
−
gera
eteB
ilds
chir
mA
ktua
lisie
ren()
:void
−
opti
one
nLa
den
():vo
id
−
opti
one
nSp
eich
ern()
:void
+co
mm
an
dAc
tion
(c:Co
mma
nd,d
:Disp
layab
le):v
oid
+ba
ckT
oMa
in():v
oid
+fre
igeb
enV
onB
row
ser(p
fad:S
tring
):boo
lean
+z
eich
neG
UI(za
hl:int
):voi
d
+tim
erE
ven
t(id:i
nt):v
oid
+gib
Disp
lay()
:Disp
lay
BB
HTi
me
rEin
trag
−
an
ford
ere
r_:E
reig
nisH
and
ler
−
zPu
nkt_
:lon
g
−
na
chri
cht_
:int
+BB
HTi
mer
Ein
trag
(anfo
rdere
r:Ere
ignis
Hand
ler,s
ekun
den:
int,n
achr
icht:i
nt)
+gib
ZPu
nkt()
:long
+gib
Anf
orde
rer()
:Erei
gnisH
andl
er
+gib
Nac
hric
ht():i
nt
Tim
erT
ask
Ser
vice
Dis
cov
ery
−
liste
ner
_:Li
sten
er
−
ne
tzw
erk_
:Ne
tzw
erk
lock
:Ob
ject
+Se
rvic
eDi
sco
very
(liste
ner:L
isten
er,ne
tzwe
rk:Ne
tzwe
rk,lo
ck:O
bject
)
+ru
n():v
oid
Mes
sag
eDi
ges
t5
buf:
int[]
bits
:lon
g
in:b
yte[]
inin
t:int
[]
−
F1:
Fco
re=
new
 Fco
re() {
int f
(int x
, int 
y, int
 z) { 
retur
n (z 
^ (x 
& (y 
^ z))
); }}
−
F2:
Fco
re=
new
 Fco
re() {
int f
(int x
, int 
y, int
 z) { 
retur
n (y 
^ (z 
& (x 
^ y))
); }}
−
F3:
Fco
re=
new
 Fco
re() {
int f
(int x
, int 
y, int
 z) { 
retur
n (x 
^ y ^
 z); }
}
−
F4:
Fco
re=
new
 Fco
re() {
int f
(int x
, int 
y, int
 z) { 
retur
n (y 
^ (x 
| ~z))
; }}
+M
ess
age
Dig
est5
()
+u
pda
te(ne
wbuf
:byte
[]):vo
id
+u
pda
te(ne
wbuf
:byte
[],len
gth:i
nt):v
oid
+u
pda
te(ne
wbuf
:byte
[],bu
fstar
t:int,
bufle
n:int
):voi
d
+m
d5fi
nal(d
igest
:byte
[]):vo
id
−
zer
oBy
teA
rray
(a:by
te[]):
void
−
zer
oBy
teA
rray
(a:by
te[],s
tart:i
nt,le
ngth
:int):
void
−
set
Byte
Arra
y(a:b
yte[]
,val:b
yte,s
tart:i
nt,le
ngth
:int):
void
−
zer
oInt
Arra
y(a:i
nt[]):
void
−
zer
oInt
Arra
y(a:i
nt[],s
tart:i
nt,le
ngth
:int):
void
−
set
IntA
rray
(a:in
t[],va
l:int,s
tart:i
nt,le
ngth
:int):
void
−
MD
5ST
EP(f
:Fco
re,w
:int,x
:int,y
:int,z
:int,d
ata:i
nt,s:
int):i
nt
−
tran
sfor
m():v
oid
−
GET
_32
BIT
_LS
B_F
IRS
T(b:b
yte[]
,off:i
nt):in
t
−
PUT
_32
BIT
_LS
B_F
IRS
T(b:b
yte[]
,off:i
nt,va
lue:in
t):vo
id
+du
mpB
ytes
(byte
s:byt
e[]):S
tring
+ge
tHa
sh(fi
lena
me:S
tring
):Str
ing
−
Fco
re
Dat
ei
#gro
ess
e_:l
ong
#ha
shw
ert_
:Str
ing
#ke
ywo
rds_
:Ve
ctor
#m
odif
izie
rt_:
long
#na
me
_:S
tring
#typ
_:S
tring
#ur
l_:S
tring
#ze
itste
mpe
l_:S
tring
−
NCH
ARS
:cha
r[]={ 
’−’, ’.
’, ’+’,
 ’*’, ’
 ’, ’_
’, ’,’ }
−
ZW
OER
TER
:Ve
ctor
−
uplo
adP
riori
taet
:int
−
key
wor
dSt
ring
:Str
ing
+Da
tei()
+Da
tei(n
ame
:Strin
g,ha
shwe
rt:Str
ing,g
roes
se:lo
ng,ty
p:Str
ing,z
eitste
mpe
l:Stri
ng,m
odifiz
iert:l
ong,
url:S
tring
)
+gib
Nam
e():S
tring
+gib
Typ
():St
ring
+gib
Url()
:Strin
g
+gib
Zeit
Ste
mpe
l():St
ring
+gib
Gro
ess
e():lo
ng
+gib
Has
hwe
rt():S
tring
+gib
Key
wor
ds():
Vect
or
+gib
Key
wor
dsA
sStr
ing()
:Strin
g
+se
tze
Nam
e(na
me:S
tring
):voi
d
+se
tze
Typ
(typ:
Strin
g):vo
id
+se
tze
Url(u
rl:Str
ing):
void
+se
tze
Zeit
Ste
mpe
l(zeit
stem
pel:S
tring
):voi
d
+se
tze
Gro
ess
e(gro
esse
:long
):voi
d
+se
tze
Has
hwe
rt(ha
shwe
rt:Str
ing):
void
+se
tze
Mod
ifizie
rt(mo
difizi
ert:lo
ng):v
oid
+e
rken
neT
yp(d
ateiN
ame
:Strin
g):St
ring
+a
ktua
lisie
ren
():Ve
ctor
+gib
Key
wor
dsL
iste
():Ve
ctor
+z
erle
geK
eyw
ords
(s:St
ring)
:Vec
tor
+re
inig
eKe
ywo
rds()
:Strin
g
+e
ntfe
rne
For
mat
(date
iNam
e:Str
ing):
Strin
g
+to
Stri
ng():
Strin
g
+m
ain(a
rgs:S
tring
[]):vo
id
 
Ass
ertio
n
Dow
nlo
adQ
uell
e
−
wa
rtep
osit
ion_
:int
−
que
lle_
:Pe
er
−
date
inam
e_:S
tring
+Do
wnl
oad
Que
lle(w
artep
ositio
n:int
,que
lle:P
eer,d
atein
ame
:Strin
g)
+gib
Wa
rteP
osit
ion()
:int
+gib
Que
lle():
Peer
+gib
Dat
eina
me()
:Strin
g
+se
tze
Wa
rteP
osit
ion(w
artep
ositio
n:int
):voi
d
+to
Stri
ng():
Strin
g
Dow
nlo
adE
intr
ag
−
sta
rtby
te_:
long
−
dow
nloa
dQu
ellen
_:Ve
ctor
−
dlA
nfra
geG
esc
hick
t_:b
oole
an
−
dlA
nfor
der
ung
Ges
chic
kt_:
boo
lean
−
time
rAb
gela
ufen
Anf
rage
_:bo
olea
n
−
time
rAb
gela
ufen
Anf
orde
rung
_:bo
olea
n
+Do
wnl
oad
Ein
trag
()
+Do
wnl
oad
Ein
trag
(nam
e:Str
ing,h
ashw
ert:S
tring
,groe
sse:l
ong,
typ:S
tring
,zeits
temp
el:St
ring,
mod
ifizie
rt:lon
g,url
:Strin
g,sta
rtbyt
e:lon
g)
+gib
Sta
rtBy
te():l
ong
+gib
Dow
nloa
dQu
ellen
():Ve
ctor
+gib
Anz
ahlD
own
load
Que
llen(
):int
+gib
Dow
nloa
dQu
elle(
mein
eBtA
dr:St
ring)
:Dow
nloa
dQu
elle
+ist
DLA
nfra
geG
esc
hick
t():bo
olea
n
+ist
DLA
nfor
der
ung
Ges
chic
kt():b
oole
an
+ist
Tim
erA
bge
lauf
enA
nfra
ge():
bool
ean
+ist
Tim
erA
bge
lauf
enA
nfor
deru
ng():
bool
ean
+gib
Pau
seS
tatu
s():b
oole
an
+se
tze
DLA
nfor
der
ung
Ges
chic
kt(dl
Anfo
rderu
ngG
esch
ickt:b
oole
an):v
oid
+se
tze
DLA
nfra
geG
esc
hick
t(dlA
nfrag
eGe
schic
kt:bo
olea
n):vo
id
+se
tze
Tim
erA
bge
lauf
enA
nfra
ge(ti
merA
bgel
aufe
n:bo
olea
n):vo
id
+se
tze
Tim
erA
bge
lauf
enA
nfor
deru
ng(ti
merA
bgel
aufe
n:bo
olea
n):vo
id
+se
tze
Sta
rtBy
te(st
artby
te:lo
ng):v
oid
+se
tze
Pau
seS
tatu
s():v
oid
+fue
geD
own
load
Que
llehi
nzu
(dow
nloa
dQu
elle:D
ownl
oadQ
uelle
):voi
d
+se
tze
Dow
nloa
dQu
ellen
AufN
ull(m
eine
Dow
nloa
dEin
trag:
Dow
nloa
dEin
trag)
:void
+e
ntha
lteD
own
load
Que
llen(
):boo
lean
+e
ntfe
rne
Dow
nloa
dQu
elle(
mein
eBtA
dr:St
ring)
:void
+v
erta
usc
heQ
uelle
n(a:i
nt,b:
int):v
oid
+gib
Mei
neB
este
n(an
zahlB
este
n:int
):Vec
tor
+a
ktua
lisie
reS
tartB
yte(r
ohda
tenT
eile:b
yte [
]):vo
id
+to
Stri
ng():
Strin
g
Stre
amC
onn
ecti
onN
otif
ier
+st
rea
mC
onn
ecti
onN
otifi
er():v
oid
+a
cce
ptA
ndO
pen
():St
ream
Conn
ectio
n
Run
nab
le
HTT
PSE
mp
faen
ger
−
fert
ig:b
oole
an
−
ne
tzw
erk_
:Ne
tzw
erk
+HT
TPS
Em
pfae
nge
r(net
zwer
k_:N
etzw
erk)
+ru
n():v
oid
+ge
tVia
Http
sCo
nne
ctio
n(url
:Strin
g):vo
id
+st
op():
void
−
sen
deR
epo
rt(rep
ortC
ode:
int):v
oid
Mat
chL
iste
nEi
ntra
g
−
que
llen
_:V
ecto
r
−
date
igro
ess
e_:l
ong
−
suc
hID
_:in
t
−
has
hwe
rt_:
Stri
ng
+M
atch
List
enE
intra
g(ha
shwe
rt:Str
ing,d
ateig
roes
se:lo
ng,s
uchI
D:int
)
+gib
Has
hwe
rt():S
tring
+gib
Dat
eigr
oes
se():
long
+gib
Que
llen(
):Vec
tor
+gib
Suc
hID
():int
+fue
geD
own
load
Que
lleH
inzu
(mei
neDo
wnlo
adQ
uelle
:Dow
nloa
dQu
elle)
:void
+e
ntfe
rne
Alle
Dow
nloa
dQu
ellen
():vo
id
+to
Stri
ng():
Strin
g
Upl
oad
List
e
−
eint
rag_
:Ve
ctor
−
me
inU
ploa
dMa
nag
er_:
Upl
oad
Man
age
r
+Up
load
List
e(ulM
:Uplo
adM
anag
er)
+hin
zufu
ege
Upl
oad
Eint
rag(d
atei:
Date
i,ziel
:Pee
r,sta
rtbyt
e:lon
g):vo
id
+e
ntfe
rne
Upl
oad
Eint
rag(h
ashw
ert:S
tring
,bt_A
ddr:S
tring
):boo
lean
+st
arte
Upl
oad
(has
hwer
t:Stri
ng,b
t_Ad
dr:St
ring)
:void
+ist
Ges
tarte
t(has
hwer
t:Stri
ng,b
t_Ad
dr:St
ring)
:boo
lean
+a
ktua
lisie
ren
():vo
id
+gib
Gro
ess
e():in
t
+gib
Elem
ent(n
umm
er:in
t):Up
load
Eintr
ag
+a
ktua
lisie
reW
arte
pos
ition
():vo
id
Run
nab
le
Sen
der
−
fert
ig_:
boo
lean
+n
ach
rich
t_:b
yte[]
+a
dre
ssa
t_:G
erae
t
−
na
chri
chtV
erfu
egb
ar_:
boo
lean
=fal
se
−
na
chri
chtL
aen
ge_
:int=
0
−
mtu
Sch
nips
el_:
int=
0
−
res
tLae
nge
_:in
t=0
−
ne
tzw
erk_
:Ne
tzw
erk
−
zuV
erse
nde
n:V
ecto
r
−
zuV
erse
nde
nEm
pfae
nge
r:Ve
ctor
−
lock
_:O
bjec
t
+Se
nde
r(abo
veLa
yer:N
etzw
erk,l
ock_
:Obje
ct)
+ru
n():v
oid
+a
ufw
ach
en():
void
+fue
geZ
uQu
eue
Hinz
u(Pa
ket:b
yte[]
,emp
faen
ger:G
erae
t):bo
olea
n
+st
op():
void
+se
tze
Nac
hric
ht(n:
byte
[]):vo
id
+se
tze
Adr
ess
at(n:
Gera
et):v
oid
+se
tze
Nac
hric
htV
erfu
egb
ar():b
oole
an
+se
nde
rFre
i():bo
olea
n
+gib
Nac
hric
hten
Anz
ahlI
nQu
eue
():int
<<
con
trol>
>
Suc
hMa
nag
er
−
suc
hID
Zae
hler
_:in
t
−
me
ineS
uch
en_
:Ve
ctor
−
me
inD
own
load
Man
age
r_:D
own
load
Man
age
r
−
me
inSk
yNe
t_:S
kyN
et
−
me
inP
rogr
amm
_:P
rogr
amm
−
me
inTi
mer
_:B
BHT
ime
r
+Su
chM
ana
ger()
+Su
chM
ana
ger(d
M:Do
wnlo
adM
anag
er,sN
:Sky
Net,p
:Prog
ramm
,t:BB
HTim
er)
+Su
chM
ana
ger(d
M:Do
wnlo
adM
anag
er,sN
:Sky
Net,t
:BBH
Time
r)
+gib
Mei
neS
uch
en():
Vect
or
+gib
Anz
ahlS
uch
en():
int
+gib
Anz
ahlS
uch
Mat
chL
iste
n():in
t
+gib
Suc
hMa
tchL
iste
(Suc
hID:i
nt):S
uchM
atch
Liste
+gib
Key
wor
ds(S
uchI
D:int
):Str
ing [
]
+st
arte
Suc
he(k
eywo
rds:S
tring
[],tim
eout
:int):
Such
Matc
hList
e
+st
arte
Dire
kt(m
einM
atch
Liste
nEin
trag:
Matc
hList
enEi
ntrag
):voi
d
+w
ae
hleD
own
load
(mei
nMa
tchL
isten
Eintr
ag:M
atch
Liste
nEin
trag)
:void
+hin
zufu
ege
nMa
tchL
iste
nEin
trag
(sAn
twor
t:Suc
hAnt
wort
):voi
d
+e
mpf
ang
eNa
chri
cht(n
achr
icht:B
BHN
achr
icht)
:void
+v
ers
en
detP
ake
t(has
hwer
t:Stri
ng,b
t_Ad
dr:St
ring,
erfol
greic
h:bo
olea
n):vo
id
+tim
erE
ven
t(suc
hId:i
nt):v
oid
+loe
sch
eSu
chM
atch
List
e(su
chID
:int):
bool
ean
+loe
sch
eSu
chM
atch
List
en():
void
Suc
hAn
two
rt
−
suc
hAn
two
rten
_:V
ecto
r
−
wa
rtep
osit
ion_
:int
−
hop
s_:i
nt
−
suc
hID
_:in
t
+Su
chA
ntw
ort()
+Su
chA
ntw
ort(ty
p:by
te,su
cher
BT_A
ddr:S
tring
,eige
neBT
_Add
r:Str
ing,z
ielBT
_Add
r:Str
ing,w
artep
ositio
n:int
,such
ID:in
t,hop
s:int)
+Su
chA
ntw
ort(m
yStre
am:b
yte[]
)
+e
infu
ege
nSu
chA
ntw
ortE
intra
g(su
chAn
twor
tEint
rag:S
uchA
ntwo
rtEin
trag)
:void
+to
Stre
am()
:byte
[]
+gib
Lae
nge
():int
+gib
Kap
azit
aet()
:int
+gib
Hop
s():in
t
+se
tze
Hop
s(ho
ps:in
t):vo
id
+gib
Suc
hAn
two
rten
():Ve
ctor
+se
tze
Suc
hAn
two
rten
(suc
hAnt
wort
en:V
ecto
r):vo
id
+gib
Suc
hID
():int
+gib
Wa
rtep
osit
ion()
:int
+se
tze
Wa
rtep
osit
ion_
(war
tepo
sition
:int):
void
+se
tze
Suc
hID
(suc
hID:i
nt):v
oid
BB
HN
ach
rich
t
+SU
CH_
ANF
RAG
E:b
yte=
0
+SU
CH_
ANT
WO
RT:
byte
=1
+DO
WN
LOA
D_A
NFR
AGE
:byt
e=2
+DO
WN
LOA
D_A
NTW
OR
T:by
te=3
+DO
WN
LOA
D_A
NFO
RDE
RUN
G:b
yte=
4
+UP
LOA
D:b
yte=
5
+DO
WN
LOA
D_A
BBR
UCH
:byt
e=6
+UP
LOA
D_S
TAR
T:by
te=7
+RO
H_D
ATE
N_L
AEN
GE:
int=
100
00−
300
−
suc
her
BTA
dr_
:Str
ing
−
eige
neB
TAd
r_:S
tring
−
ziel
BTA
dr_
:Str
ing
−
typ_
:byt
e
+BB
HN
ach
rich
t()
+BB
HN
ach
rich
t(typ
:byte
,sAd
dr:St
ring,
eAdd
r:Str
ing,z
Addr
:Strin
g)
+gib
Typ
():by
te
+gib
Suc
herB
TAd
r():S
tring
+gib
Eige
neB
TAd
r():S
tring
+gib
Ziel
BTA
dr():S
tring
+se
tze
Typ
(typ:
byte
):voi
d
+se
tze
Suc
herB
TAd
r(suc
herB
TAdr
:Strin
g):vo
id
+se
tze
Eige
neB
TAd
r(eig
eneB
TAdr
:Strin
g):vo
id
+se
tze
Ziel
BTA
dr(zi
elBT
Adr:S
tring
):voi
d
+to
BBH
(myS
tream
:byte
[]):BB
HNa
chric
ht
+by
teA
rray
ToO
bjec
ts(ei
nStre
am:b
yte[]
):Vec
tor
+to
Stre
am()
:byte
[]
+fue
lleS
trea
mM
itBB
HPa
ram
eter
(suc
herB
TAdr
:Strin
g,eig
eneB
TAdr
:Strin
g,zie
lBTA
dr:St
ring,
typ:b
yte):
Vect
or
Upl
oad
−
sta
rtby
te_:
long
−
roh
date
n_:b
yte[]
−
has
hwe
rt_:
Stri
ng
−
aktu
elle
Lae
nge
_:in
t
+Up
load
()
+Up
load
(typ:
byte
,such
erBT
_Add
r:Str
ing,e
igen
eBT_
Addr
:Strin
g,zie
lBT_
Addr
:Strin
g,sta
rtbyt
e:lon
g,roh
d
+Up
load
(myS
tream
:byte
[])
+se
tze
Sta
rtby
te(st
artby
te:lo
ng):v
oid
+gib
Sta
rtby
te():l
ong
+se
tze
Roh
date
n(roh
date
n:by
te[]):
void
+gib
Roh
date
n():b
yte[]
+se
tze
Has
hwe
rt(ha
shwe
rt:Str
ing):
void
+gib
Has
hwe
rt():S
tring
+gib
Aktu
elle
Lae
nge
():int
+se
tze
Akt
uell
eLa
eng
e(ak
tuelle
Laen
ge:in
t):vo
id
+to
Stre
am()
:byte
[]
Dow
nlo
adA
nfo
rde
run
g
−
has
hwe
rt_:
Stri
ng
−
sta
rtby
te_:
long
+Do
wnl
oad
Anf
ord
eru
ng()
+Do
wnl
oad
Anf
ord
eru
ng(ty
p:by
te,su
cher
BT_A
ddr:S
tring
,eige
neBT
_Add
r:Str
ing,z
ielBT
_Add
r:Str
ing,s
tartb
+Do
wnl
oad
Anf
ord
eru
ng(m
yStre
am:b
yte[]
)
+to
Stre
am()
:byte
[]
+gib
Has
hwe
rt():S
tring
+se
tze
Has
hwe
rt(ha
shwe
rt:Str
ing):
void
+gib
Sta
rtby
te():l
ong
+se
tze
Sta
rtby
te(st
artby
te:lo
ng):v
oid
Dow
nlo
adA
bbr
uch
−
rich
tung
_:bo
olea
n
−
has
hwe
rt_:
Stri
ng
+Do
wnl
oad
Abb
ruch
()
+Do
wnl
oad
Abb
ruch
(typ:
byte
,such
erBT
_Add
r:Str
ing,e
igen
eBT_
Addr
:Strin
g,zie
lBT_
Addr
:Strin
g,ric
htun
g:b
+Do
wnl
oad
Abb
ruch
(myS
tream
:byte
[])
+to
Stre
am()
:byte
[]
+se
tze
Ric
htun
g(ric
htun
g:bo
olea
n):vo
id
+gib
Rich
tung
():bo
olea
n
+se
tze
Has
hwe
rt(ha
shwe
rt:Str
ing):
void
+gib
Has
hwe
rt():S
tring
Upl
oad
Sta
rt
−
has
hwe
rt_:
Stri
ng
−
an
zah
lPa
kete
_:in
t
+Up
load
Sta
rt()
+Up
load
Sta
rt(typ
:byte
,such
erBT
_Add
r:Str
ing,e
igen
eBT_
Addr
:Strin
g,zie
lBT_
Addr
:Strin
g,ha
shwe
rt:Str
ing,a
+to
Stre
am()
:byte
[]
+Up
load
Sta
rt(my
Strea
m:by
te[])
+gib
Has
hwe
rt():S
tring
+se
tze
Has
hwe
rt(ha
shwe
rt:Str
ing):
void
+gib
Anz
ahlP
ake
te():i
nt
+se
tze
Anz
ahlP
ake
te(ne
ueAn
zahl:
int):v
oid
Dow
nlo
adA
nfra
ge
−
has
hwe
rt_:
Stri
ng
+Do
wnl
oad
Anf
rage
()
+Do
wnl
oad
Anf
rage
(typ:
byte
,such
erBT
_Add
r:Str
ing,e
igen
eBT_
Addr
:Strin
g,zie
lBT_
Addr
:Strin
g,ha
shwe
rt:
+Do
wnl
oad
Anf
rage
(myS
tream
:byte
[])
+to
Stre
am()
:byte
[]
+gib
Has
hwe
rt():S
tring
 
has
hwe
rt:S
tring
Dow
nlo
adA
ntw
ort
−
wa
rtep
osit
ion_
:int
−
has
hwe
rt_:
Stri
ng
−
hop
s_:i
nt
−
istD
own
load
Anf
rage
_:bo
olea
n
+Do
wnl
oad
Ant
wor
t()
+Do
wnl
oad
Ant
wor
t(typ
:byte
,such
erBT
_Add
r:Str
ing,e
igen
eBT_
Addr
:Strin
g,zie
lBT_
Addr
:Strin
g,ha
shwe
rt:
+Do
wnl
oad
Ant
wor
t(my
Strea
m:by
te[])
+to
Stre
am()
:byte
[]
+se
tze
Wa
rtep
osit
ion(w
artep
ositio
n:int
):voi
d
+gib
Wa
rtep
osit
ion()
:int
+se
tze
Has
hwe
rt(ha
shwe
rt:Str
ing):
void
+gib
Has
hwe
rt():S
tring
+se
tze
IstD
own
load
Anf
rage
(istD
ownl
oadA
nfrag
e:bo
olea
n):vo
id
+gib
IstD
own
load
Anf
rage
():bo
olea
n
+se
tze
Hop
s(ho
ps:in
t):vo
id
+gib
Hop
s():in
t
Suc
hAn
frag
e
−
suc
hID
_:in
t
−
key
wor
ds_
:Str
ing[]
−
time
out_
:int
+Su
chA
nfra
ge()
+Su
chA
nfra
ge(ty
p:by
te,sA
ddr:S
tring
,eAd
dr:St
ring,
zAdd
r:Str
ing,s
uchid
:int,k
eywo
rds:S
tring
[],tim
eout
:int)
+Su
chA
nfra
ge(m
yStre
am:b
yte[]
)
+to
Stre
am()
:byte
[]
+gib
Key
wor
ds():
Strin
g[]
+se
tze
Key
wor
ds(k
eywo
rds:S
tring
[]):vo
id
+gib
Suc
hID
():int
+se
tze
Suc
hID
(suc
hID:i
nt):v
oid
+gib
Tim
eou
t():in
t
+se
tze
Tim
eou
t(tim
eout
:int):
void
Abbildung 29: Klassendiagramm
86
LITERATUR
15 Anhang C - Literaturverzeichnis
Literatur
[1] Rüdiger Schollmeier, A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer
Architectures and Applications, http://csdl.computer.org/comp/proceedings/p2p/2001/
1503/00/15030101.pdf
[2] Peer-to-Peer DatenManagement; Prof. Dr. Kai-Uwe Sattler, Computer Science and Auto-
mation Department Technical University Ilmenau, http://www3.tu-ilmenau.de/site/dbis/
fileadmin/template/FakIA/StruktFakultaet_IA/ipim/dbis/vdm/vdm-1.pdf
[3] Peer-to-Peer Computing, Dejan S. Milojicic, Vana Kalogeraki, Rajan Lukose, Kiran Nagaraja1,
Jim Pruyne, Bruno Richard, Sami Rollins 2 ,Zhichen Xu; HP Laboratories Palo Alto, http:
//www.hpl.hp.com/techreports/2002/HPL-2002-57.pdf
[4] P2P Systems, Keith W. Ross Polytechnic University: http://cis.poly.edu/~ross, Dan Ru-
benstein Columbia University: http://www.cs.columbia.edu/~danr, http://cis.poly.edu/
~ross/tutorials/P2PtutorialInfocom.pdf
[5] Peer-to-Peer Computing, Björn Jung, Technische Universität Kaiserslautern, Datenban-
ken und Informationssysteme, http://wwwdvs.informatik.uni-kl.de/courses/seminar/
SS2004/ausarbeitung2.pdf
[6] 1. Einführung (S.Gebhardt), http://dbs.uni-leipzig.de/en/seminararbeiten/
semWS0304/ar-beit1/ausarbeitung1.pdf
[7] 2. File Sharing Systeme (Napster, Gnutella, KazaA .) (X.Baldauf), http://dbs.uni-leipzig.
de/en/seminararbeiten/semWS0304/arbeit2/Skript.pdf
[8] Routing Indices for Peer-to-Peer Systems; Arturo Crespo, Hector Garcia-Molina Computer Science
Department Stanford University Stanford, CA 94305-2140, USA, http://www-db.stanford.
edu/~crespo/publications/crespoa_ri.pdf
[9] CHORD: A Scalable Peer-to-peer Lookup Service for Internet Applications; Ion Stoica, Robert
Morris, David Karger, M. Frans Kaashoek and Hari Balakrishnan. In the Proceedings of ACM
SIGCOMM 2001, San Deigo, CA, August 2001, http://www.pdos.lcs.mit.edu/chord/
[10] CAN: A scalable Content-Addressable Network SIGCOMM 2001, Sylvia Ratnasamy, Paul Francis,
Mark Handley, Richard Karp, Scott Shenker, Dept. of Electrical Eng. & Comp. Sci. UC Berkeley
Berkeley, CA, USA, AT&T Center for Internet Research at ICSI Berkeley, CA, USA
[11] Open Problems in Data-Sharing Peer-to-Peer Systems; Neil Daswani, Hector Garcia-Molina, and
Beverly Yang Stanford University, Stanford CA 94305, USA, http://www-db.stanford.edu
[12] JXTA: An Open, Innovative Collaboration, Sun Microsystems, Inc., http://www.jxta.org
[13] Napster Webseite, http://www.napster.com
[14] Emule Webseite, http://www.emule-project.net
[15] Paralleler, Kooperativer Download mit eDonkey, http://www.edonkey2000.com/
documenta-tion/mftp.html
[16] Kademlia: A Peer-to-peer Information System Based on the XOR Metric, Petar Maymounkov and
David Mazieres, New York University, http://www.cs.rice.edu/Conferences/IPTPS02/109.
pdf
[17] Gnutella Homepage http://rfc-gnutella.sourceforge.net, The Annotated Gnutella Proto-
col Specification v0.4, http://rfc-gnutella.sourceforge.net/developer/stable/#t1
87
LITERATUR LITERATUR
[18] KaZaA Homepage, http://www.kazaa.com
[19] P2P Papers (Übersicht über diverse Quellen), http://cis.poly.edu/~ross/p2pTheory/
P2Prea-ding.htm
[20] 7DS Webseite, Maria Papadopouli, Henning Schulzrinne; Department of Computer Science Co-
lumbia University New York, NY 10027, http://www.cs.unc.edu/~maria/7ds/
[21] Design and Implementation of a Peer-to-Peer Data Dissemination and Prefetching Tool for Mobile
Users
[22] Seven Degrees of Separation in Mobile Ad Hoc Networks
[23] Fundamental Challenges in Mobile Computing, M. Satyanarayanan, School of Computer Science
Carnegie Mellon University, http://www-2.cs.cmu.edu/afs/cs/project/coda/Web/docdir/
podc95.pdf
[24] iMobile ME - A Lightweight Mobile Service Platform for P2P Mobile Computing, Yih-Farn Chen,
Huale Huang, Bin Wei, AT&T Labs - Research, USA; Ming-Feng Chen, National Chiao-Tung
University; Taiwan Herman Rao Far Eastone Telecommunications Co., Ltd., Taiwan
[25] Proem: A Middleware Platform for Mobile Peer-to-Peer Computing, Gerd Kortuem, Department
of Computer Science, University of Oregon, USA, ACM SIGMOBILE Mobile Computing and
Communications Review (MC2R), Special Feature on Middleware for Mobile Computing, Vol. 6,
No 4, October 2002, www.cs.uoregon.edu/research/wearables/papers.html
[26] XMIDDLE: A Data-Sharing Middleware for Mobile Computing, Cecilia Mascolo, Licia Capra,
Stefanos Zachariadis and Wolfgang Emmerich, Dept. of Computer Science, University College
London, UK
[27] FolkMusic: A Mobile Peer-to-Peer Entertainment System, Mikael Wiberg, Department of Infor-
matics, Umea, Schweden
[28] A Platform and Applications for Mobile Peer-to-Peer Communications, Takeshi Kato, Norihiro Is-
hikawa, Hiromitsu Sumino, Johan Hjelm, Ye Yu, Shingo Murakami, Ericsson Research (Stockholm
Schweden, Kanagawa Japan), NTT DoCoMo Inc.(Kanagawa Japan)
[29] SETI@home Homepage, http://setiathome.ssl.berkeley.edu/index.html
[30] Bluetooth Spezifikation v1.2, Bluetooth SIG, http://www.bluetooth.org/spec
[31] Java API for Bluetooth Wireless Technology (JSR-82) 1.0a, Motorola, Wireless Software, Appli-
cations and Services
[32] C. Lindemann and O. P. Waldhorst, Passive Distributed Indexing (PDI) v1.0, Internet-Draft 2004
[33] C. Lindemann and O. P. Waldhorst, Customizing a Distributed Lookup Service for Specific Mobile
Applications, Department of Computer Science University of Dortmund 2004
[34] C. Lindemann and O. Waldhorst, Consistency Mechanisms for a Distributed Lookup Service sup-
porting Mobile Applications, MobiDE 2003
[35] C. Lindemann and O. Waldhorst, A Distributed Search Service for Peer-to- Peer File Sharing in
Mobile Applications
[36] C. Lambert,C. Lindemann and O. Waldhorst, PG 466 Beyond KaZaA -Peer-to-Peer Systeme für
mobile Endgeräte mit Bluetooth und UMTS Technologie
[37] https://www.cvshome.org/docs/
[38] http://www.kde.org/apps/cervisia/
88
LITERATUR LITERATUR
[39] http://www.wincvs.org/
[40] http://sources.redhat.com/autobook/
[41] http://autotoolset.sourceforge.net/tutorial.html
[42] http://sources.redhat.com/gdb/documentation/
[43] http://www.gnu.org/manual/ddd/
[44] http://www.bluemarsh.com/java/jswat/
[45] NS by Example, http://nile.wpi.edu/NS/
[46] The Network Simulator ns-2, http://www.isi.edu/nsnam/ns/v
[47] Marc Greis’ Tutorial for the UCB/LBNL/VINT Network Simulator „ns”, http://www.isi.edu/
nsnam/ns/tutorial/index.html
[48] UCBT - Bluetooth extension for NS2 at Univ. of Cincinnati http://www.ececs.uc.edu/~cdmc/
ucbt/
[49] Blueware: Support for Self-organizing Scatternets http://nms.lcs.mit.edu/projects/
blueware/
[50] Godfrey Tan, Self-organizing Bueltooth Scatternets, Massachusetts Institute of Technology, Januar
2002
[51] http://today.java.net/pub/a/today/2004/07/27/bluetooth.html
[52] Bluetooth for Java, Bruce Hopkins and Ranjith Antony, Apress ľ 2003
[53] Java APIs for Bluetooth Wireless Technology (JSR-82) 2002, 6501 William Cannon Drive West
MD: OE112 Austin, TX 78735-8598
[54] http://medien.informatik.uni-ulm.de/lehre/current/PS%20Mobile%20JAVA/
Bluetooth.pdf
[55] http://www-ds.e-technik.uni-dortmund.de/embedded/de/textonly/content/diplom/
java_-bluetooth/java_bluetooth.html
[56] http://www.fm-i.de/de/downloads/pm_270504_activepilot_Technik.doc
[57] http://java.sun.com/xml/jaxp/index.jsp
[58] http://java.sun.com/j2se/1.4.2/docs/api/index.html
[59] http://developers.sun.com/techtopics/mobility
[60] http://java.sun.com/j2me/index.jsp
[61] Die offizielle Java Website java.sun.com von Sun Microsystems
[62] J2ME Developer’s Guide von Michael Kroll und Stefan Haustein, Markt + Technik Verlag, 2003
[63] Java 2 Micro Edition: Klaus-Dieter Schmatz 2004, dpunk
89