als PDF-Dokument

FAKULTÄT II - DEPARTMENT FÜR INFORMATIK
Abteilung Software Engineering
Diplomarbeit
Suchverfahren für
organisations-orientierte
Super-Peer-Architekturen
21. Oktober 2005
Bearbeitet von:
Stefan Willer
Bürgereschstr. 10
26123 Oldenburg
[email protected]
Betreut von:
Erstgutachter: Prof. Dr. Wilhelm Hasselbring
Zweitgutachter: Dipl.-Inform. Ludger Bischofs
Selbstständigkeitserklärung
Ich erkläre hiermit, dass ich diese Diplomarbeit selbstständig angefertigt habe und
alle Teile, die wörtlich oder inhaltlich anderen Quellen entstammen, als solche kenntlich gemacht und in das Literaturverzeichnis aufgenommen habe. Diese Arbeit wurde
weder in dieser noch einer ähnlichen Form einer anderen Prüfungsbehörde vorgelegt.
Oldenburg, den 21. Oktober 2005
(Stefan Willer)
ii
Zusammenfassung
Kommunikation ist die Grundlage neuer Wissensakquisition. Dieser Prozess unterliegt einem Beziehungsgeflecht unterschiedlicher Dynamik, das durch die Dauer und
die Semantik dieser Beziehungen geprägt ist. So variiert häufig nur der Weg zum
Ziel. Diese natürlichen dynamischen Kommunikationswege können in der Softwareentwicklung durch dezentrale Peer-to-Peer-Architekturen nachgebildet werden. Der
dieser Arbeit zugrunde liegende Einsatzbereich umfasst organisatorische Strukturen,
wie sie in einer Entwickler-Community zu beobachten sind. Zur Kommunikation innerhalb dieser Domäne kann eine Peer-to-Peer-Architektur genutzt werden, indem
organisatorische Strukturen auf Peers abgebildet werden.
In der vorliegenden Arbeit wird eine grafische Simulationsumgebung zur Performanzanalyse von Such- und Routingverfahren in Peer-to-Peer-Architekturen vorgestellt.
Von entscheidender Bedeutung ist die Unterstützung einer Vielzahl an Verfahren,
so dass vorab ein umfassender Überblick erstellt wird, aus dem sich die Anforderungen an die Simulationsumgebung ergeben. Um die Verwendbarkeit in anderen
Domänen zu ermöglichen, werden organisations-orientierte Strukturen optional als
zusätzliches Overlay simuliert. Durchgeführte Experimente verdeutlichen den Einsatz
des Simulators und resultieren abschließend in einem Vorschlag eines Suchverfahrens
in organisations-orientierten Super-Peer-Architekturen.
iii
Inhaltsverzeichnis
Selbstständigkeitserklärung
ii
Zusammenfassung
iii
Abbildungsverzeichnis
viii
Tabellenverzeichnis
xii
1. Einleitung
1.1. Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Einordnung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Organisations-orientierte Super-Peer-Architekturen
2.1. Peer-to-Peer . . . . . . . . . . . . . . . . . . . . .
2.1.1. Definitionen . . . . . . . . . . . . . . . . .
2.1.2. Klassifikation von P2P Architekturen . . .
2.2. Super-Peer-Architekturen . . . . . . . . . . . . .
2.2.1. Aufbau . . . . . . . . . . . . . . . . . . . .
2.2.2. Funktionsweise . . . . . . . . . . . . . . .
2.2.3. Startvorgang . . . . . . . . . . . . . . . .
2.2.4. Suche . . . . . . . . . . . . . . . . . . . .
2.2.5. Lastverteilung . . . . . . . . . . . . . . . .
2.2.6. Bewertung . . . . . . . . . . . . . . . . . .
2.3. Organisationen . . . . . . . . . . . . . . . . . . .
2.3.1. Das betrachtete System . . . . . . . . . .
2.3.2. Overlay-Strukturen . . . . . . . . . . . . .
3. Such- und Routingverfahren
3.1. Einführung . . . . . . . . . . . . . . . . . . . .
3.1.1. Gliederung des Kapitels . . . . . . . . .
3.1.2. Verwendete Begriffe . . . . . . . . . . . .
3.2. Verfahren der 1.ten Generation . . . . . . . . .
3.2.1. Breitensuche - Breath-first traversal BFS
3.2.2. Tiefensuche (Depth-first traversal DFS) .
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
5
7
7
8
9
10
10
11
12
13
15
.
.
.
.
.
.
18
18
18
20
20
21
26
Inhaltsverzeichnis
3.2.3. Random Walks . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4. APS - Adaptive Probabilistic Search . . . . . . . . . . . . . .
3.2.5. Local Indices . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.6. Routing Index - RI . . . . . . . . . . . . . . . . . . . . . . . .
3.2.7. DLRP - Distributed Resource Location Protocol . . . . . . . .
3.2.8. SUPS - Scalable Unstructured P2P System . . . . . . . . . . .
3.3. Verfahren der 2.ten Generation . . . . . . . . . . . . . . . . . . . . .
3.3.1. CHORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2. CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3. Tapestry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.4. AGILE - Adaptive, Group-of-Interest-based Lookup Engine .
3.3.5. SHARK - Symmetric Hierarchy Adaption for Routing of Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.6. Kademlia . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.7. YAPPERS - Yet Another Peer-to-PEeR System . . . . . . . .
3.3.8. CANDy - (Content Addressable Network DirectorY . . . . . .
3.3.9. Kelips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.10. SkipNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4. Verfahren der 3.ten Generation . . . . . . . . . . . . . . . . . . . . .
3.4.1. Viceroy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.2. Distance Halving . . . . . . . . . . . . . . . . . . . . . . . . .
3.5. Überblick und Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1. Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.2. Auswahl der zu simulierenden Verfahren . . . . . . . . . . . .
4. Anforderungsdefinition
4.1. Ausgangssituation . . . . . . .
4.2. Rollenanalyse . . . . . . . . .
4.3. Funktionale Anforderungen .
4.4. Technische Anforderungen . .
4.5. Konzeptionelle Anforderungen
4.6. Strukturelle Anforderungen .
28
28
30
30
32
33
33
34
41
44
47
47
49
49
50
50
51
53
53
53
53
54
57
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
58
58
59
60
60
61
62
5. Beschreibung der Simulation
5.1. Einführung . . . . . . . . . . . . . . .
5.1.1. Grundlegendes . . . . . . . . .
5.1.2. Validation und Verifikation . . .
5.1.3. Sichtweisen dieser Simulation .
5.1.4. Gliederung der Simulation . . .
5.2. Simulationsmodell . . . . . . . . . . . .
5.2.1. Messen nach der GQM-Methode
5.2.2. Simulationszyklus . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
63
63
65
65
65
66
67
70
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
v
Inhaltsverzeichnis
5.2.3. Ereignisbehandlung . . . . .
5.3. Ein-/Ausgabemodell . . . . . . . .
5.3.1. Konfiguration . . . . . . . .
5.3.2. Topologie . . . . . . . . . .
5.3.3. Such- und Routingstrategien
5.3.4. Suchanfragen . . . . . . . .
5.3.5. Ausgabebericht . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6. Entwurf und Implementierung
6.1. Grobentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1. Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Feinentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1. Abgrenzung von bestehenden Rahmenwerken zur Simulation
6.2.2. Strukturelle Sicht . . . . . . . . . . . . . . . . . . . . . . . .
6.2.3. Verhaltenssicht . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.4. Ablaufsicht . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.5. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3. Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1. Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . .
6.3.2. Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . . .
7. Experimente
7.1. Abgrenzung eines Experimentes .
7.2. Beschreibung der Experimente . .
7.3. Analyse der Experimente . . . . .
7.3.1. Vergleich VRW-VC . . . .
7.3.2. Vergleich ORW-OIBFS . .
7.3.3. Vergleich OIBFS-VC . . .
7.3.4. Validation der Ergebnisse
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
71
73
73
75
78
78
80
.
.
.
.
.
.
.
.
.
.
.
81
81
82
82
83
84
89
90
91
93
93
93
.
.
.
.
.
.
.
97
97
97
98
98
100
100
101
8. Schlussfolgerung und Ausblick
8.1. Vorschlag eines organisations-orientierten Suchverfahrens für SuperPeer-Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.1. Aufbau der virtuellen Ebene . . . . . . . . . . . . . . . . . . .
8.1.2. Aufbau der organisatorischen Ebene . . . . . . . . . . . . . .
8.1.3. Verbindung der virtuellen und organisatorischen Ebene . . . .
8.2. Zusammenfassung und Fazit . . . . . . . . . . . . . . . . . . . . . . .
8.3. Anknüpfungspunkte und Ausblick . . . . . . . . . . . . . . . . . . . .
103
Literaturverzeichnis
109
vi
103
103
104
104
106
107
Inhaltsverzeichnis
A. Suchstrategien
A.1. Aufbau einer Suchstrategie .
A.2. Beispiel einer Suchstrategie
A.3. Beispiel ORW . . . . . . . .
A.4. Beispiel VC . . . . . . . . .
A.5. Beispiel OIBFS . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
118
118
119
121
122
123
B. Experimente
B.1. Aufbau der Beschreibungen . . . .
B.2. Experiment VRW-VC . . . . . . .
B.2.1. Konfiguration VRW1“ . . .
”
B.2.2. Konfiguration VRW2“ . . .
”
B.2.3. Konfiguration VRW3“ . . .
”
B.2.4. Konfiguration VRW4“ . . .
”
B.2.5. Konfiguration VRW5“ . . .
”
B.2.6. Konfiguration VRW6“ . . .
”
B.2.7. Konfiguration VC1“ . . . .
”
B.2.8. Konfiguration VC2“ . . . .
”
B.3. Experiment ORW-OIBFS . . . . .
B.3.1. Konfiguration ORW“ . . .
”
B.3.2. Konfiguration OIBFS“ . . .
”
B.4. Experiment OIBFS-VC . . . . . . .
B.4.1. Konfiguration OIBFS-VC1“
”
B.4.2. Konfiguration OIBFS-VC2“
”
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
125
125
126
126
128
130
132
134
136
138
140
142
142
144
146
146
148
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
C. Buildmanagement
150
C.1. Aufbau und Umgang . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
C.2. Verzeichnisstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
D. Danksagung
153
vii
Abbildungsverzeichnis
2.1. Einfache Super-Peer-Architektur . . . . . . . . . . . . . . . . . . . . .
8
2.2. Redundante Super-Peer-Architektur . . . . . . . . . . . . . . . . . . .
8
2.3. Abstraktionsebenen in einer organisations-orientierten Super-Peer-Architektur
[BS05] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4. Super-Peer Overlay. Verbindungen repräsentieren Registrierungen zwischen Peers und Super-Peers. . . . . . . . . . . . . . . . . . . . . . . 17
2.5. Organisatorisches Overlay. Verbindungen stellen organisatorische Beziehungen dar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Ausschnitt des Netzwerkes mit jeweiligen Indextabellen. Anfrage nach
Ressource aus Kategorie K1 und K3 an Knoten A versandt. Auswahlroute fett gekennzeichnet mit Gütewert als Auswahlkriterium. Berechnung des Gütewertes G von Knoten C. . . . . . . . . . . . . . . . . .
3.2. Chord-Ring mit drei Knoten und m=3 . . . . . . . . . . . . . . . . .
3.3. Aufbau des Chord-Ringes wie in Abb. 3.2. Knoten 192.168.0.12 sucht
Ressource R1, die von Knoten 192.168.0.17 verwaltet wird. Verweis
über dritten Eintrag der gezeigten Fingertabelle. . . . . . . . . . . . .
3.4. Systemarchitektur nach Mizrak et. al. . . . . . . . . . . . . . . . . . .
3.5. a) Aufbau eines CAN bestehend aus vier Knoten b) Hinzufügen von
Knoten K5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6. Nachbarschaftsliste des Knotens mit der ID=4567 . . . . . . . . . . .
3.7. a)Suchbaum und b)Routing-Tabelle(n) eines Knotens . . . . . . . . .
3.8. Multidimensionale Hierarchie in SHARK . . . . . . . . . . . . . . . .
3.9. Hierarchische Darstellung der Routinginformationen jedes im Netzwerk bestehenden Knotens. Knoten C (dunkelgrau) mit diesen Informationen (hellgrau) sind hervorgehoben. Ringe sind binär bezeichnet.
3.10. Zeitlicher Überblick über die Entstehung der beschriebenen Suchverfahren. Die vertikale Achse zeigt hierbei den Verlauf der Generationen
auf. Ursprünge der Verfahren sind durch Pfeile gekennzeichnet. . . . .
4.1. Fachliches Klassenmodell des Simulators. Simulationselemente treten
in Form der Elementtypen eines Architekturstils auf. Die Struktur der
Topologie, sowie das Verhalten und die initialen Suchanfragen werden
ausgelagert und dem Simulationselement zugeführt. . . . . . . . . . .
viii
31
35
36
39
41
45
48
48
52
54
62
Abbildungsverzeichnis
5.1.
5.2.
5.3.
5.4.
5.5.
.
.
.
.
.
66
68
70
72
73
Paketaufbau des Simlators . . . . . . . . . . . . . . . . . . . . . . . .
Die wichtigsten Klassen und Beziehungen innerhalb des Simulators .
Darstellung der Integration von Suchstrategien . . . . . . . . . . . . .
Initialisierungsprozess des Simulators . . . . . . . . . . . . . . . . . .
Ablauf des Nachrichtenversandes von einem Simulationselement zu einem Empfänger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6. Konfiguration der zu simulierenden Overlays . . . . . . . . . . . . . .
6.7. Konfiguration der zu simulierenden Strategien . . . . . . . . . . . . .
6.8. Topologiegenerator zur Erzeugung einer virtuellen Topologie . . . . .
6.9. Aktuelle Betrachung der Messergebnisse aller gewählten Metriken während der Laufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.10. Ausgabebericht mit Darstellung der Experimenteinstellungen und Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.11. Zeitliche Auflistung aller während der Simulation eingetretenden Ereignisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
87
89
90
6.1.
6.2.
6.3.
6.4.
6.5.
Vorgehensmodell der Simulationsstudie
Messplanung nach der GQM-Methode .
Simulationszyklus . . . . . . . . . . . .
Nachrichtenbehandlung einer Entität .
Ein-/Ausgabe Modell des Simulators .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
92
94
94
95
96
96
96
7.1. Gegenüberstellung der Verfahren VRW und VC. Suche nach eindeutigen Peernamen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.2. Gegenüberstellung der Verfahren VRW und VC. Suche nach (mehrfach
vorhandenen) Ressourcen. . . . . . . . . . . . . . . . . . . . . . . . . 99
7.3. Gegenüberstellung der Verfahren ORW und OIBFS . . . . . . . . . . 100
7.4. Gegenüberstellung der Verfahren OIBFS-VC1 und OIBFS-VC2 . . . 101
8.1. Ausschnitt der Ebenenverknüpfung, die durch die gleichverteilte Verbindungsfunktion h entstehen . . . . . . . . . . . . . . . . . . . . . . 105
8.2. Ausschnitt der Ebenenverknüpfung, die durch die Organisationen abbildende Verbindungsfunktion h entstehen . . . . . . . . . . . . . . . 106
B.1. Ausgabe Experiment 1: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage
(APM) d) Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im
System (VMS) f) Virtuelle Nachrichten pro Element (VME) . . . . . 127
B.2. Ausgabe Experiment 2: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage
(APM) d) Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im
System (VMS) f) Virtuelle Nachrichten pro Element (VME) . . . . . 129
ix
Abbildungsverzeichnis
B.3. Ausgabe Experiment 3: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage
(APM) d) Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im
System (VMS) f) Virtuelle Nachrichten pro Element (VME) . . . . .
B.4. Ausgabe Experiment 4: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage
(APM) d) Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im
System (VMS) f) Virtuelle Nachrichten pro Element (VME) . . . . .
B.5. Ausgabe Experiment 5: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage
(APM) d) Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im
System (VMS) f) Virtuelle Nachrichten pro Element (VME) . . . . .
B.6. Ausgabe Experiment 6: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage
(APM) d) Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im
System (VMS) f) Virtuelle Nachrichten pro Element (VME) . . . . .
B.7. Ausgabe Experiment 7: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage
(APM) d) Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im
System (VMS) f) Virtuelle Nachrichten pro Element (VME) . . . . .
B.8. Ausgabe Experiment 8: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage
(APM) d) Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im
System (VMS) f) Virtuelle Nachrichten pro Element (VME) . . . . .
B.9. Ausgabe Experiment 9: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage
(APM) d) Schritte pro Antwort (HPQ) e) Organisatorische Nachrichten im System (OMS) f) Organisatorische Nachrichten pro Element
(OME) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.10.Ausgabe Experiment 10: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage
(APM) d) Schritte pro Antwort (HPQ) e) Organisatorische Nachrichten im System (OMS) f) Organisatorische Nachrichten pro Element
(OME) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.11.Ausgabe Experiment 12: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage (APM) d) Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten
im System (VMS) f) Virtuelle Nachrichten pro Element (VME) g)
Organisatorische Nachrichten im System (OMS) h) Organisatorische
Nachrichten pro Element (OME) . . . . . . . . . . . . . . . . . . . .
x
131
133
135
137
139
141
143
145
147
Abbildungsverzeichnis
B.12.Ausgabe Experiment 13: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage (APM) d) Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten
im System (VMS) f) Virtuelle Nachrichten pro Element (VME) g)
Organisatorische Nachrichten im System (OMS) h) Organisatorische
Nachrichten pro Element (OME) . . . . . . . . . . . . . . . . . . . . 149
C.1. Verzeichnisstruktur des Simulators . . . . . . . . . . . . . . . . . . . 152
xi
Tabellenverzeichnis
3.1. Einordnung der Suchverfahren anhand von Architekturstil, Suchsatz, Komplexität und Performanz. . . . . . . . . . . . . . . . . . . .
B.1.
B.2.
B.3.
B.4.
B.5.
B.6.
B.7.
B.8.
xii
Parametereinstellungen
Parametereinstellungen
Parametereinstellungen
Parametereinstellungen
Parametereinstellungen
Parametereinstellungen
Parametereinstellungen
Parametereinstellungen
zum
zum
zum
zum
zum
zum
zum
zum
Experiment
Experiment
Experiment
Experiment
Experiment
Experiment
Experiment
Experiment
VRW1
VRW2
VRW3
VRW4
VRW5
VRW6
VC1 .
ORW .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
grund56
126
128
130
132
134
136
138
142
1. Einleitung
Der Vertrieb von Software blieb in der Vergangenheit den kommerziellen Herstellern
vorbehalten, die leistungsbezogen ihre Produkte anboten. Alle an der Erstellung beteiligten Personen einer Organisation verrichteten ihre Arbeit in geordneten meist
hierarchischen Beschäftigungsverhältnissen und wurden dafür entlohnt. Ein Trend,
der seit Jahren zu verzeichnen ist, lockert sowohl die bisherige Struktur wie auch
die Kontinuität der involvierten Parteien und die festen Arbeitszeiten. Der Trend ist
vermutlich bekannter unter dem Namen Open Source.
Eine stetig wachsende Anzahl an Freier Software bedingt Änderungen in der Entwicklungsstruktur. Die Zeit, der Ort und die Entwickler selbst sind nicht mehr durch
das alltägliche Arbeitsumfeld gegeben, sondern unterliegen einer fortwährenden Dynamik und teilweisen Anonymität. Zur näheren Veranschaulichung dessen und der
Größe eines virtuellen Softwareunternehmens soll hierbei die Entwicklungs-Webseite
Sourceforge1 dienen. Um der dezentralen und dynamischen Arbeitsweise eine geeignete Kommunikationsplattform zu geben, kann anhand der gewünschten Eigenschaften
eine Peer-to-Peer Architektur die benötigen Dienste und Kommunikationsstrukturen liefern. Bisher bekannte dezentrale Systeme vergleichbarer Größenordnung sind
Tauschbörsen im Internet.
Die Frage, der sich diese Arbeit widmet ist, inwieweit sich eine effiziente Kommunikation mittels organisatorischer Beziehungen auf der Basis von P2P-Architekturen
verwirklichen lässt.
1.1. Zielsetzung
Ziel dieser Arbeit ist die Analyse bestehender Suchverfahren für Peer-to-Peer-Architekturen sowie die Entwicklung einer grafischen generischen Simulationsumgebung für
Super-Peer-Architekturen, die durch eine vereinfachte Integration von Suchstrategien
Performanzaussagen über das Verhalten von Such- und Routingverfahren gestattet.
Die Vorstellung eines geeigneten Verfahrens für die organisations-orientierte SuperPeer-Architekturen bettet die Arbeit in einen bestehenden Anwendungskontext ein.
1
http://sourceforge.net/
1
1. Einleitung
1.2. Vorgehensweise
Die vorgestellte Arbeit gibt einen Einblick in die Kommunikationsmöglichkeiten eines
dezentralen Peer-to-Peer-Netzwerkes in Verbindung mit einem domänen-spezifischen
Nutzungswert. Der behandelte Anwendungskontext wird zu Beginn in Form einer
Grundlagenbeschreibung in Kapitel 2 formuliert. Der Entwurf einer geeigneten Simulationsumgebung zur Analyse von Such- und Routingverfahren in P2P-Netzwerken
setzt das Verständnis bestehender Verfahren voraus, die in einen Überblick in Kapitel 3 zu finden sind und den Grundstein des späteren Entwurfes bilden. Nach einer
Anforderungsanalyse in Kapitel 4 erfolgt die Beschreibung der Simulation in Kapitel 5, die in dem Entwurf des Simulators in Kapitel 6 umgesetzt wird. Durch die
abschließende Darstellung einiger Experimente in Kapitel 7 wird die Verwendbarkeit verdeutlicht, die in dem Kapitel 8 in einen Vorschlag eines Suchverfahrens für
organisations-orientierte Super-Peer-Architekturen mündet.
1.3. Einordnung der Arbeit
Dezentrale Systeme, die sich neben der Lastbalanzierung eine hohe Verfügbarkeit
mit geringen Engpässen, die Selbstorganisation und die Fehlertoleranz, eine Gewährleistung der Anonymität und der Dynamik zur Aufgabe machen, sind seit geraumer
Zeit ein intensives Forschungsgebiet. Existierende Such- und Routingverfahren innerhalb dieser dezentralen Netzwerke legen unterschiedlichste Schwerpunkte hinsichtlich
dieser Eigenschaften, so dass eine Vielzahl an Variationen entstanden ist. Lv et.al.
[LCC+ 02] entgegneten dieser Vielfalt mit einer Kategorisierung in Verfahren der 1.,
2. und 3. Generation.
Als Architektur eines verteilten Systems haben in den letzten Jahren Peer-to-PeerArchitekturen an Bekanntheit gewonnen, nicht zuletzt durch den Einsatz von Tauschbörsen wie Napster und Gnutella, in denen mehrere Millionen Nutzer sich dieser als
Kommunikationsplattform bedienen. Die Abstrahierung der dortigen Anwendungsdomäne eröffnet viele weitere Einsatzbereiche, denen eine Peer-to-Peer Architektur
dienen kann. In der vorliegenden Arbeit wird der von Bischofs und Hasselbring [BH04]
beschriebene Ansatz zur verteilten Software-Entwicklung als Anlass genommen, bestehende wie auch neue domänen-spezifische Suchstrategien zu simulieren und zu
entwickeln.
Simulationen sind in der Informatik wie auch in anderen Disziplinen eine etablierte
Form der Untersuchung komplexer Zusammenhänge. Nach Law und Kelton[LK99]
sind die meisten realen Systeme zu komplex, als dass ein realistisches Modell analytisch bewertet werden kann. Die Verhaltenssimulation von Peer-to-Peer-Netzwerken
ist bereits in einigen abgregrenzten Bereichen geschehen. So entstammen einige Si-
2
1.3. Einordnung der Arbeit
mulatoren den Projekten spezieller Suchverfahren wie Freepastry2 und Freenet3 und
sind exakt darauf abgestimmt, wohingegen andere wie PlanetSim und 3LS einen allgemeineren Weg einschlagen [Jos03; TD03].
2
FreePastry: http://www.cs.rice.edu/CS/Systems/Pastry/FreePastry/, zuletzt besucht am
19.10.2005
3
The Free Network Project: http://freenet.sourceforge.net, zuletzt besucht am 19.10.2005
3
2. Organisations-orientierte Super-Peer-Architekturen
Bischofs und Steffens [BS05] präsentieren in ihrer Arbeit ein organisations-orientiertes
Super-Peer-Netzwerk, welches organisatorische Strukturen verteilter digitaler Bibliotheken repräsentiert, um verteilte Ressourcen zu integrieren. Dieser Ansatz der Verbindung eines Peer-to-Peer-Overlays mit einem weiteren domänen-spezifischen Overlay liegt in einer allgemeineren Sichtweise auch dieser Arbeit zu Grunde. Ein Overlay
soll an dieser Stelle als Überlagerung von Ebenen verstanden werden (Näheres dazu
in Kapitel 3).
Zum Verständnis der späteren Untersuchungen sind einige Grundlagen erforderlich,
die nun beschrieben werden. Nach einer Einführung in Super-Peer-Architekturen folgt
die Beschreibung der betrachteten Domäne sowie den inbegriffenen Strukturen.
2.1. Peer-to-Peer
Zur Beschreibung der Grundlagen sind einige Begriffe erforderlich, die in ihrer Bedeutung nun vorgestellt werden und [BHW05] entstammen.
Peer-to-Peer (P2P) ist ein Kommunikationsmodell gleichberechtigter Einheiten (Peers),
die direkt oder indirekt miteinander kommunizieren. Peers fungieren sowohl als Klient wie auch als Server und werden daher als Servent (Server und Klient) bezeichnet. Sie treten in einem verteilten Peer-to-Peer-System auf, das dem Peer-to-PeerKommunikationsmodell zugrunde liegt. Der Aufbau und die Struktur des Systems
wird durch die Peer-to-Peer-Architektur beschrieben. Peers - die in diesem Kontext
häufig als Knoten bezeichnet werden - bilden ein Peer-to-Peer-Netzwerk, wenn sie
nach dem P2P-Kommunikationsmodell verbunden sind.
P2P erreichte seinen Bekanntheitsgrad durch Systeme wie Napster und Gnutella
und späteren Tauschbörsen. Weitere, jedoch weniger populäre Anwendungsfelder sind
Groupware-Systeme und die Internettelefonie.
Wegen der vielseitigen Interpretation der P2P-Thematik werden einige Definitionen
vorgestellt und anschließend bisher existierende Architekturen klassifiziert. Die anfangs beschriebenen Begrifflichkeiten werden häufig in der Literatur synonym verwendet und stimmen daher nicht genau mit den anfolgenden Definitionen überein.
Im späteren Verlauf dieser Arbeit werden diese Begriffe nach obiger Beschreibung
verwendet. Die Definitionen sollen neben einer Erhöhung des Verständnisses, die
Schwierigkeit einer allgemeinen eindeutigen Eingliederung der Thematik zum Vorschein bringen.
4
2.1. Peer-to-Peer
2.1.1. Definitionen
Peer-to-Peer Netzwerke lassen sich anhand von Definitionen charakterisieren. Da keine allgemeingültige aussagekräftige Definition existiert, werden nun verschiedene, teilweise übersetzt, vorgestellt. Vorab kann ein ’Peer’(eng.) als ’Gleichgestellter’ angesehen werden, wobei die Bedeutung in den folgenden Definitionen ebenfalls voneinander
abweicht.
Shirky [Shi00] P2P ist eine Klasse von Anwendungen, die sich verfügbare Ressourcen [..] zunutze macht.
Steinmetz und Wehrle [SW03] P2P-Systeme sind sich selbst organisierende Systeme gleichberechtigter, autonomer vernetzter Einheiten (so genannte Peers),
die ohne zentrale Koordination mit dem Ziel der gegenseitigen Nutzung von
Ressourcen operieren.
Tsoumakos [TR03b] Das P2P Paradigma schreibt einen vollkommen verteilten, kooperativen Netzwerkentwurf vor, in dem Knoten zusammen ein System ohne
jegliche Kontrolle bilden.
Stoica [SMK+ 01] P2P-Systeme und -Anwendungen sind verteilte Systeme ohne zentrale Kontrolle oder hierarchischer Organisation, in der die auf den Knoten
laufende Software in ihrer Funktionaltiät gleichwertig ist.
Yang und Garcia-Molina [BY01] P2P-Systeme sind verteilte Systeme, in denen
Knoten mit gleichen Rollen und Befähigungen Informationen und Dienste direkt miteinander austauschen.
Mobileman Projects 1 P2P beschreibt das Austauschen von Dateien von Computern, die in einem Netzwerk verbunden sind. Hierarchisch sind Anbietender
und Anfragender auf der gleichen Ebene angeordnet.
Wie an diesen Definitionen ersichtlich ist, scheint der Begriff Peer-to-Peer nicht eindeutig beschreibbar zu sein. Nach Schindelhauer und Mahlmann [SM04] können P2PSysteme zumindest nicht als Client-Server-Systeme aufgefasst werden.
2.1.2. Klassifikation von P2P Architekturen
Uneinig sind sich die Autoren der Definitionen über die Existenz von Hierarchien,
der Kommunikation und den Kontrolleigenschaften. Yang und Garcia-Molina [BY01]
sprechen von Kommunikation zwischen Knoten gleicher Rollen und Befähigungen
1
http://mobileman.projects.supsi.ch/glossary.html Zuletzt besucht am 01.06.2005.
5
2. Organisations-orientierte Super-Peer-Architekturen
und schließen somit nicht die Existenz von Hierarchien aus. Stoica versteht ein
P2P-System eindeutig als ein System ohne Hierarchie und zentrale Koordination
[SMK+ 01]. Steinmetz und Wehrle hingegen weisen lediglich eine zentrale Koordination von sich. Tsoumakos [TR03b] lässt keinerlei Kontrolle zu. So lassen sich P2PArchitekturen anhand ihrer Architekturstiles gliedern. Nach Garlan und Shaw [GS93]
besagt ein Architekturstil folgendes:
”[..]an architectural style determines the vocabulary of components and connectors
that can be used in instances of that style, together with a set of constraints on how
they can be combined.”
Die Autoren betonen somit die Elementtypen einer Architektur und die mögliche
Struktur der Architekturelemente untereinander. Anhand dieser beiden Punkte und
der Einteilung von Schollmeier [Sch01] ist die folgende Einteilung der Architekturen
zu verstehen:
Client-Server-Architektur
Eine verteilte Netzwerk-Architektur wird als Client-Server-Architektur bezeichnet,
wenn Klienten und Server sich erstens in der Performanz unterscheiden und zweitens
Ressourcen und Dienste nur vom Server angeboten werden. Klienten stellen lediglich
Anfragen und registrieren sich bei einem Server.
Reine P2P-Architektur
Eine verteilte Netzwerk-Architektur wird als reine (pure) P2P-Architektur bezeichnet,
wenn sie einerseits die Struktur eines P2P-Netzwerkes beschreibt und andererseits
jedes willkürlich ausgewählte Element aus dem Netz entfernt werden kann, ohne dass
das System mit dem angebotenen Dienst darunter leidet.
Diese Charakterisierung kann wiederum anhand ihrer Topologie verfeinert werden.
So existieren strukturierte und unstrukturierte reine P2P-Architekturen. Strukturierte Architekturen sind an Bedingungen geknüpft zur Einhaltung signifikanter Merkmale der jeweiligen Topologie. Als strukturierte Topologien werden allgemeine Formen wie baumartige, ringförmige und gitterartige Topologien und spezielle Formen
wie Butterfly-Netzwerke und multi-dimensionale Koordinatenräume bezeichnet. Zur
Strukturerhaltung kann das Ein- und Austreten eines Knotens weitere Aktionen hervorrufen. Unstrukturierte (vermaschte) Topologien unterliegen keinen derartigen Einschränkungen. Lediglich die Konnektivität aller Knoten muss gewährleistet werden.
Sie erscheinen somit willkürlich und chaotisch. Das Ein- und Austreten hat nur Konsequenzen für direkt verbundene Nachbarn und ist somit leicht wartbar. Jedoch weisen
diese Formen ein schlechtes Performanz- und Lastverhalten auf.
6
2.2. Super-Peer-Architekturen
Hybride P2P-Architektur
Eine verteilte Netzwerk-Architektur wird als hybride P2P-Architektur bezeichnet,
wenn es sich zum einen um eine P2P-Architektur handelt, andererseits jedoch eine
zentrale Komponente zur Durchführung des angebotenen Dienstes notwendig ist.
Zentralisierte Architekturen ähneln den Client-Server-Architekturen mit dem Unterschied, dass nicht alle Dienste vom Server bereitgestellt werden, sondern lediglich
Dienste, die bestimmten Anforderungen genügen müssen. So wurde in der Tauschbörse Napster der zentrale Server zur Indexierung der von den Klienten bereitgestellten
Ressourcen verwendet, um die Suchperformanz zu erhöhen.
Gemischte P2P-Architektur
Eine Mischung aus einer reinen und einer hybriden Architektur stellen sog. SuperPeer-Architekturen dar. Super-Peer-Architekturen bestehen aus vielen kleinen zentralisierten Architekturen, sog. Cluster, die miteinander über Super-Peers verbunden
sind. Diese Super-Peers stellen einen Netzübergang (im Folgenden engl. Gateway)
für die Peers in ihrem Cluster dar, über den eine Kommunikation mit dem gesamten
Netzwerk ermöglicht wird. Die Architektur wird in Abschnitt 2.2 näher untersucht.
2.2. Super-Peer-Architekturen
Super-Peer-Architekturen verbinden zentralisierte und dezentralisierte Ansätze zuvor
beschriebener Architekturen. Sie entstanden in der Absicht, die Vorteile der reinen
und hybriden Architekturen zu verbinden. Diese münden in der Zusammenführung
der Effizienz der zentralisierten Suche und der Autonomie, Lastbalanzierung und
Robustheit der dezentralisierten P2P-Architektur.
Nach [YGM03] ist ein Super-Peer ein Knoten in einem P2P-Netzwerk, der einerseits
als Server einer Menge von Klienten operiert und andererseits als ein Servent innerhalb eines Super-Peer-Netzwerkes agiert. Unterstützt durch eine Studie von Gummadi u.a. [GSG02], die die Heterogenität der Peers in einem reinen P2P-Netzwerk aufzeigt, liegt die Entscheidung nahe, Peers mit besonderen Eigenschaften entsprechende
Funktionalität zu erteilen. So kann als Einteilung die zur Verfügung stehende Bandbreite, die sich oft in die Bereiche Modem/ISDN, DSL/Cable und T1/T3 einteilen
lässt, ein Kriterium dafür sein.
2.2.1. Aufbau
Wie bereits erwähnt agiert ein Super-Peer als Server für eine Menge an Peers (Cluster). Ein Super-Peer-Netzwerk besteht somit aus einer Menge an Clustern, deren
7
2. Organisations-orientierte Super-Peer-Architekturen
Verknüpfung durch die jeweiligen Super-Peers untereinander erfolgt. Diese Verbindungen untereinander verdeutlichen den dezentralen Teil der Architektur. Eine reine P2P-Architektur kann als Super-Peer-Architektur mit Clustergröße 1 angesehen
werden. Abbildung 2.1 veranschaulicht den beschriebenen Zusammenhang. Peers innerhalb eines Clusters melden sich bei einem Super-Peer an und gehen somit eine
Verbindung zu diesem ein. Peers untereinander sind nicht verbunden. Jeder SuperPeer pflegt zudem eine Indextabelle bestehend aus den Metadaten aller zur Verfügung
gestellten Ressourcen seiner in dem Cluster befindlichen Peers.
Da ein Super-Peer für das jeweilige Cluster einen Gateway zum restlichen Netzwerk
darstellt, sind diese auf die Existenz und Verfügbarkeit des Super-Peers angewiesen,
um Suchanfragen zu stellen. Um einerseits diesem Single-Point-of-Failure zu entgehen
und andererseits eine gute Lastverteilung des Super-Peers zu gewährleisten, kann
durch redundante Super-Peers ein Engpass des Clusters vermieden werden. In diesem
Fall spricht man von k-redundanten Super-Peer-Architekturen. Jeder Peer pflegt eine
Verbindung zu jedem Super-Peer des Clusters, womit sich bei redundanten SuperPeer-Architekturen der Verwaltungsaufwand erhöht. Die Verbindungen außerhalb der
Cluster nehmen gleichermaßen zu. Redundante Super-Peers eines Clusters werden
zusammenfassend als virtueller Super-Peer bezeichnet. Die Abbildungen 2.1 und 2.2
veranschaulichen die durch Redundanz entstehenden Veränderungen.
Peer
Peer
Peer
Peer
Peer
Peer
Peer
Peer
Peer
Peer
SuperPeer
SuperPeer
Peer
Peer
Cluster
Peer
SuperPeer
Peer
SuperPeer
SuperPeer
SuperPeer
Peer
Peer
Peer
SuperPeer
SuperPeer
Peer
Peer
Peer
IndexTabelle
Peer1 ..
Peer2 ..
..
Einfache
Peer1 ..
Peer2 ..
..
SuperPeer
IndexTabelle
Bild
2.1..
Architektur
Cluster
IndexTabelle
SuperPeer
Peer
Peer
SuperPeer
Virtueller
Super-Peer
Peer
Peer
SuperPeer
Peer1 ..
Peer2 ..
..
Super-Peer-Bild 2.2..
Architektur
Redundante
Super-Peer-
2.2.2. Funktionsweise
Super-Peer-Architekturen bestehen aus einer zentralen und einer dezentralen Ebene,
die durch Super-Peers miteinander verknüpft sind. Anfragen aus einem Cluster werden entweder direkt vom zugehörigen Super-Peer beantwortet oder weitergeleitet. Zur
Beantwortung dienen Indextabellen, die Metadaten über alle Ressourcen des Clusters
8
2.2. Super-Peer-Architekturen
beinhalten. Diese Indextabellen werden Super-Peer / Peer Index genannt. Jeder Peer
sendet bei Eintreten in das Netzwerk sowie bei Änderungen der Ressourcen Aktualisierungsnachrichten an den Super-Peer, der daraus einen konsistenten Index aufbaut.
Das Austreten eines Peers bewirkt eine dementsprechende Nachricht, die den SuperPeer ebenfalls veranlasst, den Index zu aktualisieren. Unbeabsichtigtes Austreten
wird über regelmäßiges Überprüfen der Anwesenheit seitens des Super-Peers erkannt.
Der Index wird somit regelmäßig auf seine Konsistenz überprüft. Suchen, die nicht im
eigenen Cluster erfüllt werden können und diesen verlassen, können auf unterschiedlichste Weise weitergeleitet (engl. route) werden. Jedes dezentrale Routingverfahren
(siehe Abschnitt 3.2ff.) kann hierfür eingesetzt werden. Diese Nachbarschaftsinformationen können in einem Super-Peer / Super-Peer Index gepflegt werden. Neben
einfachen Routingverfahren, die als blind oder informiert charakterisiert werden, ist
auch der Einsatz von verteilten Hashtabellen möglich [MCKS03].
Neben der grundlegenden Funktionalität existieren weitere Konzepte zur Effizienzsteigerung, wie Caches und Nachrichtenhistorien über besuchte Peers. Mittels der
temporären Speicherung von weitergeleiteten Suchanfragen können zukünftige ähnliche Suchen beschleunigt werden (Abschnitt 3.2.4). Je nach Ausmaß der gewünschten
Anonymität der einzelnen Peers können auch Ressourcen in einem Cache seitens des
Super-Peers gespeichert werden. Entweder beinhaltet die Suche die Senderadresse,
damit der Ziel-Peer direkt Kontakt mit dem Suchenden aufnehmen kann, oder der
Suchende wird durch einen oder mehrere Super-Peers auf dem Suchpfad verborgen,
die dann ein schrittweises Rückverfolgen erlauben.
2.2.3. Startvorgang
Der Startvorgang (engl. Bootstrapping) bezeichnet den Prozess, auf welche Art und
Weise ein in das Netzwerk neu eintretender Peer einen bereits dort Existierenden
finden und kontaktieren kann. Nach Yang et.al. [YGM03] ist dieser Vorgang, einen
Ansprechpartner sowohl in reinen als auch in Super-Peer-Architekturen zu finden,
immer noch Gegenstand der Forschung. Es existieren diverse Ansätze, die jedoch alle
auf einer zentralen Instanz beruhen.
Über zentrale Verzeichnisdienste können Adressen bestehender Peers gesammelt werden. Im Gnutella-Netzwerk werden diese Instanzen als Gnutella Web Caching-System
2
bezeichnet [KAD+ 04]. Freiwillige Peers pflegen einen Cache von aktuell im Netzwerk
befindlichen Peers. Diese sind über feste Adressen zugänglich und verteilen Adressen
von Ansprechpartnern auf Anfrage.
2
http://www.gnucleus.com/gwebcache/. Zuletzt besucht am 03.06.2005.
9
2. Organisations-orientierte Super-Peer-Architekturen
2.2.4. Suche
Die Suche nach einer Ressource wird von einem Peer eines Clusters initiiert und an
den (die) jeweiligen Super-Peer(s) weitergeleitet. Dieser überprüft dahingehend seine
Indextabelle. Bei Erfolg wird die Adresse des Zielknotens als Antwort zurückgeschickt.
Um die Anonymität des Zieknotens zu wahren, wäre es ebenfalls denkbar, statt einer direkten Verbindung zwischen Anfrage- und Zielknoten den Transfer über den
Super-Peer zu tunneln, wobei damit eine erhöhte Netzwerklast in Kauf genommen
würde. Falls die Indextabelle keinen Treffer liefert, wird nach dezentralen Routingverfahren die Suchanfrage zwischen den Super-Peers weitergeleitet. Die einfachste
Methode wäre eine Breitensuche, nach der alle jeweiligen direkten Nachbarn rekursiv
angesprochen werden, ihre Indextabellen zu überprüfen. Bei einem Treffer wird nach
bereits vorgestellten Prinzip verfahren. In einem redundanten Super-Peer-Netzwerk
würden alle Super-Peers angesprochen und parallel verfahren oder sich gegenseitig
über die Zuständigkeit vereinbaren.
2.2.5. Lastverteilung
Die Last stellt die zu verrichtende Menge an Arbeit einer Zeiteinheit dar. Sie kann
in einem Netzwerk an eingehender und ausgehender Bandbreite, sowie an der Verarbeitung der Nachrichten gemessen werden. In einem dynamischen System, so wie es
ein Super-Peer-System darstellt, kann die Lastverteilung variieren. Je nach Sichtweise
wird von individueller und aggregierter Last gesprochen. Da Peers untereinander bzgl.
ihrer Bandbreite und Verarbeitung sehr unterschiedlich sind, sollte die entstehende
Last möglichst gerecht verteilt werden.
Super-Peers bilden einen Kommunikationsengpass und sollten daher über eine entsprechende Bandbreite verfügen. Die Last erhöht sich mit zunehmendem Nachrichtenversand, der sich in Form von Suchanfragen und Kontrollnachrichten ausdrückt. Die
Anzahl an gerouteten Nachrichten hängt weiterhin von der Größe des Clusters eines
Super-Peers, der Popularität der dort angebotenen Ressourcen und der Replikation
von Super-Peers und Daten ab. Da die Entwicklungen einiger Faktoren gegensätzlich
sind, existiert keine Allgemeinlösung für das Problem der Lastverteilung. Folgende Zusammenhänge verdeutlichen die Auswirkung auf die Last der einzelnen Super-Peers.
Mit der steigender Clustergröße können viele Anfragen innerhalb eines Clusters beantwortet werden. Nachrichten müssen somit seltener zwischen dem Super-Peers geroutet werden. Das Fluten des Netzwerkes wird also verringert. Jedoch steigt mit
der Clustergröße die Verwaltung innerhalb eines Clusters, die Indextabellen müssen
gepflegt werden und viele Anfragen parallel verarbeitet werden. Mit hoher Clustergröße sinkt die Anzahl der Super-Peers, womit das Netzwerk anfälliger für Angriffe
ist. Die Neuordnung eines großen Clusters nimmt ebenfalls mehr Zeit ein. Clustergrößen sind abhängig von der Anzahl maximal zugelassener eingehender Verbindungen
10
2.2. Super-Peer-Architekturen
eines Super-Peers. Diese Anzahl eingehender Verbindungen wird in der Regel vom Betriebssystem vorgegeben. Allgemein kommt der Replikation eines Super-Peers bei steigender Clustergröße größere Bedeutung hinzu. Mit sinkender Clustergröße steigt wegen erhöhter ausgehender Suchanfragen der Kommunikationsaufwand zwischen den
Super-Peers. Die Kommunikation geschieht dezentral z.B. durch Nachrichten an alle
Teilnehmer (engl. Broadcast) einer bestimmten Tiefe und verursachen mehr Nachrichten als die zentrale Ordnung innerhalb eines Clusters. Die Anzahl maximaler eingehender und ausgehender Verbindungen eines Super-Peers kann sich unterscheiden
und ebenfalls die Clustergröße beeinflussen. Verbindungseinschränkungen entstehen
durch unterschiedliche Sende- und Empfangsleistungen (Bsp.: DSL) wie auch durch
betriebsystemabhängige maximale Verbindungsanzahlen (Bsp.: Socketanzahl). Populäre Ressourcen eines Clusters bestimmen unabhängig von den Eigenschaften eines
Super-Peers und der Clustergröße die Lastverteilung.
2.2.6. Bewertung
Super-Peer-Architekturen bilden eine Mischung aus zentralen und dezentralen Architekturen und vereinen damit einige Vorteile dieser. Je nach Ausrichtung und Einsatz
müssen jedoch viele Variablen der Architektur angepasst werden. Einige variable Eigenschaften werden nun abschließend benannt:
Clustergröße Die Clustergröße ist entscheidend für das Ausmaß zentraler und dezentraler Eigenschaften. Die Clustergröße bestimmt die Anzahl der Super-Peers
und somit auch die Angreifbarkeit des Netzwerkes. Ausfälle besitzen unterschiedliche organisatorische Maßnahmen.
k-Redundanz Die Größe der virtuellen Super-Peers bewirkt eine Lastverteilung mit
zusätzlichem Organisationsaufwand. Redundante Super-Peers verringern zudem die Angreifbarkeit.
Caching Caching von Anfragen wie auch Ressourcen stellen erhöhte Anforderungen
an Super-Peers in der Speicherkapazität und beim Nachrichtenversand zwecks
Konsistenzerhaltung. Das Ausmaß des Cachings sollte somit dem daraus resultierenden Nutzen entsprechen.
dezentrale Wahl der Teilarchitektur Die Aufteilung der Clustergrößen und somit
auch die Anzahl der dadurch entstehenden Super-Peers bestimmt die Größe
der dezentralen Teilarchitektur. Die effiziente Suche innerhalb dieser Teilarchitektur ist ausschlaggebend für die Effizienz der gesamten Suche und wird in
dem folgenden Kapitel genauer behandelt.
11
2. Organisations-orientierte Super-Peer-Architekturen
Bestehende gemischte Ansätze
Der in Abschnitt 3 gegebene Überblick über bestehende Suchverfahren umfasst eine Auswahl an bestehenden Verfahren, die dem Entwurf eines Suchverfahrens für
organisations-orientierte Super-Peer-Architekturen dienen können. Da sich einerseits
Kombinationen aller dezentralisierten und zentralisierten Ansätze für eine gemischte
P2P-Architektur einsetzen lassen und andererseits die Anzahl der bestehenden Suchverfahren für Super-Peer-Netzwerke gering ist, überwiegt der Anteil der reinen und
hybriden P2P-Systeme. An dieser Stelle soll nun auf die existierenden und in dem
Überblick aufgenommenen gemischten Ansätze verwiesen werden.
Wahrscheinlich wegen der hohen Popularität und der geringen Komplexität wurden
die Verfahren Gnutella und Chord als Basis des dezentralisierten Anteils der gemischten Systeme bevorzugt. TaChord sowie das Verfahren von Mizrak u.a. basieren auf
der Ringtopologie, die in Chord beschrieben wird. GUESS, Ultrapeer und Fasttrack
(Abschnitt 3.2.1) verwenden das Gnutella-Protokoll. brocade (Abschnitt 3.3.3) stellt
eine Erweiterung des Tapestry-Verfahrens dar. Lediglich SUPS (Abschnitt 3.2.8) lässt
sich keinem bestehenden reinen P2P-System zuordnen.
2.3. Organisationen
In der Systemtheorie werden Systeme als eine Ansammlung von Elementen und deren
Eigenschaften, die durch Wechselbeziehungen miteinander verbunden sind, definiert
[HF56]. Unter der Struktur eines Systems versteht man die Ordnung der Systemelemente und der zwischen ihnen wirksamen Wechselwirkungen [Mat02]. Diese Wechselwirkungen treten bei wachsenden Systemen verstärkt in zunehmend autonomen
Teilsystemen auf, die jedoch miteinander interagieren. Zur Reduktion der Komplexität lassen sich diese Teilsysteme hierarchisch gliedern.
Die in der Soziologie beschriebene soziale Vernetzung der modernen Gesellschaft
drückt sich in dem Small-World-Phänomen aus. Dieses Phänomen beschreibt die
überraschend kurze Bekanntschaftskette aller Menschen der Welt (Die Welt ist ein
Dorf.). Als eine Schlussfolgerung dieses Phänomens erzeugten Albert-László Barabási und Réka Albert [BA99] ein System mit hierarchischer Struktur, das gerade diese
moderne Gesellschaftsvernetzung ausdrückt.
Die meisten bekannten ’Systeme’ sind hierarchisch gegliedert, wie Vereine, Berufswelt
und Gemeinden. Sie unterscheiden sich häufig nur in der Anzahl und Bedeutung der
Hierarchien und deren Kommunikation untereinander. Neben einer hierarchischen
Ordnung können jedoch zusätzliche Beziehungen existieren, die keiner hierarchischen
Ordnung genügen, so dass sich in einer allgemeinen Betrachtung nur durch Einschränkung der Sichtweisen feste Strukturen erkennen lassen.
12
2.3. Organisationen
Um etwas detaillierter zu werden, wird im Verlauf der Arbeit meist auf das folgende
Beispiel Bezug genommen. Es lässt sich jedoch mit wenig Aufwand eine Überführung
auf andere Systeme herleiten.
2.3.1. Das betrachtete System
Die Erstellung und Organisation von Softwareprodukten verläuft in der Praxis hierarchisch. In Unternehmen wie auch in freien Entwicklergemeinden (Sourceforge3 ,
Savannah4 ), existieren Organisationseinheiten mit unterschiedlichen Aufgaben und
Verantwortungs- bzw. Zuständigkeitsbereichen. Um nicht auf die Überprüfung bestehender Strukturen in diesen Einrichtungen einzugehen und eine unnötige Komplexität
dessen zu veranschaulichen, wird ein vereinfachtes, jedoch hinreichend charakteristisches System verwendet, das aus den Systemelementen Organisation, Projekt, Gruppe
und Mitarbeiter besteht. Weiterhin zeichnet sich das System durch eine lose Koppelung aus, wie sie in Systemen wie Sourceforge existiert. Es existieren keine festen
’Arbeitszeiten’ und keine vertragliche Bindung der Mitarbeiter. Die Fluktuation der
Mitarbeiter ist groß und somit unterzieht sich das System einem stetigen Wandel mit
hoher Dynamik.
Anwendungsdomänen als spezifisches Overlay
Die Ausprägung des gerade beschriebenen Systems hängt direkt von der umfassenden
Anwendungsdomäne ab. Im Laufe der weiteren Arbeit werden exemplarisch nur wenige strukturelle Einheiten betrachtet, die Organisationen, die Projekte, die Gruppen
und die Mitarbeiter/Mitglieder.
Organisation Eine Organisation stellt das abstrakteste Element des Systems dar.
Organisationen bilden die Wurzel der Hierarchie. Sie können zusammengefügt werden, indem eine neue Hierarchiestufe eingeführt wird, die übergeordnet ist. Hierauf
wird jedoch nicht eingegangen. Weiterhin kann ein System aus Elementen bestehen,
die nicht eindeutig in einer Hierarchie zusammengefasst werden können, da eine abstraktere Ebene, die diese Elemente verbindet, nicht modelliert wird. Organisationen
verwalten Projekte und können neue initieren. Ihnen kommt hiermit im Wesentlichen
eine organisatorische Aufgabe zu. Verwaltungstätigkeiten können von Mitarbeitern
geleistet werden, die keinem Projekt und keiner Gruppe zugeordnet werden können.
Weiterhin kann es Gruppen ohne Projektzugehörigkeit geben, die direkt Aufgaben
einer Organisation bearbeiten, z.B. eine beratende Gruppe von Mitarbeitern zwecks
Umstrukturierung.
3
4
http://www.sourceforge.net,zuletztbesuchtam19.09.2005
http://savannah.gnu.org/,zuletztbesuchtam19.09.2005
13
2. Organisations-orientierte Super-Peer-Architekturen
Projekt Ein Projekt besitzt häufig einen thematischen und zeitlichen Bezug und
kann je nach Umfang in Gruppen und Mitarbeitern eingeteilt werden. Ein Projektleiter kann statt einer Gruppe direkt dem Projekt angehören.
Gruppe Gruppen erfüllen innerhalb von Projekten Teilaufgaben wie auch innerhalb
von Organisationen beratende Tätigkeiten. Je nach Komplexität der Anforderungen
können mehrere Gruppen parallel existieren. Von Teilgruppen wird in diesem Modell
zwecks Eingrenzung der Komplexität nicht ausgegangen.
Mitarbeiter Die ausführende Instanz bilden die Mitarbeiter, die in allen höheren
Ebenen angeordnet sein können.
Beziehungen Um die einzelnen Elemente untereinander in Beziehung zu setzen,
existieren Beziehungen innerhalb einer Hierarchiestufe wie auch außerhalb dieser. Bischofs und Steffens [BS05] geben folgende Beispiele.
Eine Organisation (O) regelt und verwaltet Projekte (P), Gruppen (G) und Mitarbeiter (S).
O regelt P,G,S
Ein Projekt bzw. eine Organisation besitzt unterschiedliche Gruppen.
O,P besitzt G
Mitarbeiter, Gruppen und Projekte können miteinander kooperieren, indem z.B. freie
Mitarbeiter nur kurzzeitig in einer Gruppe aushelfen.
P,G,S kooperiert P,G,S
Beziehungen sind stark systemabhängig und können übergreifend lediglich durch ein
3-Tupel beschrieben werden, das aus einem Ursprung, einer Beziehungsfunktion sowie einem Ziel besteht. Beziehungen R eines Systems S können über eine Menge E
aller Elemente durch eine Beziehungsfunktion δ definiert werden. Ein System ist somit definiert als
S = (E, R, δ)
wobei für jede Beziehungsfunktion δ einer Beziehung r gilt
δ : r → {{e1 , e2 } |e1 6= e2 ; e1 , e2 ∈ E ∧ r ∈ R}.
14
2.3. Organisationen
2.3.2. Overlay-Strukturen
Zur Erstellung eines wie oben beschriebenen interaktiven und kooperativen Systems
bedarf es einer geeigneten Kommunikationsstruktur. Die lose Kopplung und das dynamische Verhalten des Systems ähneln sehr dem in Abschnitt 2.1 vorgestellten P2PSystem, das als Kommunikations- und Ordnungsplattform verwendet wird. Zur Unterstützung der Hierarchien wie auch der Nutzung positiver effizienter Verhaltensweisen der Super-Peer-Architekturen (siehe 2.2) wird eine gemischte P2P-Architektur
vorgezogen.
Die Abbildung 2.3 verdeutlicht drei Ebenen, die aufeinander aufbauen (Overlay).
Ausgehend von der physikalischen Ebene folgt die virtuelle und schließlich die organisatorische Ebene.
Elemente der physikalischen Ebene sind einzelne Hostrechner, die über physikalische
Leitungen miteinander verbunden sind. Verbindungen zwischen diesen Hostrechnern
veranschaulichen den Datenfluss.
Die mittlere Ebene wird als virtuelle Ebene bezeichnet, da sie nicht mehr auf physikalischen Verbindungen beruht. Elemente in dieser Ebene werden als Peers und
Super-Peer bezeichnet. Verbindungen bestehen innerhalb und außerhalb eines Clusters. Peers müssen bei einem Super-Peer registriert werden, um dem Netzwerk anzugehören. Super-Peers untereinander pflegen Kontakte, um einerseits die Cluster
zu verbinden und andererseits Suchanfragen in verschiedene Cluster zu delegieren.
Peers entsprechen nicht notwendigerweise einer physikalischen Recheneinheit (Hostrechner). Es können sich mehrere Peers auf einem Hostrechner befinden. Verbindungen der virtuellen Ebene drücken lediglich aus, dass es einen Pfad (zwischen Peer
und Super-Peer) im physikalischen Netzwerk geben muss. Die Anzahl der Zwischenstationen (Hops) kann beliebig sein im Gegensatz zur physikalischen Ebene, in der
Verbindungen eine direkte physikalische Nachbarschaft ausdrückt. Die Verbindungen
besitzen somit eine höherwertige Semantik.
Die obere Ebene stellt den anfangs beschriebenen Zusammenhang der organisatorischen Elemente dar. Auch hier müssen Elemente der organisatorischen Ebene nicht
ein-eindeutig auf die Elemente der virtuellen Ebene abgebildet werden.
Da es sich in der Abbildung um Overlaystrukturen handelt, müssen diese aufeinander abgebildet werden. Die Abbildung der virtuellen Ebene auf die physikalische
Ebene ist in der Literatur bereits umfangreich beschrieben (siehe Kapitel 3). Die
Aufgabe besteht darin, neben einer einfachen Überlagerung der Schichten, die Lokalität und die Topologie der Ebenen geeignet zu überlagern. Anschaulich gesehen kann
die Überlagerung zweier benachbarter Peers auf zwei weit entfernte Hostrechner hohe
Performanzverluste nach sich ziehen. Die Dauer der Nachrichtenübertragung (Latenzzeit) steigt mit jeder Zwischenstation auf der physikalischen Ebene. Die Abbildung
der organisatorischen Ebene auf die virtuelle Ebene stellt ein ähnliches Problem dar.
15
2. Organisations-orientierte Super-Peer-Architekturen
Bild 2.3.. Abstraktionsebenen in einer organisations-orientierten Super-PeerArchitektur [BS05]
16
2.3. Organisationen
Kommunikation innerhalb der organisatorischen Ebene ist teilweise durch den hierarchischen Aufbau dieser eingeschränkt, so dass Knoten höherer hierarchischer Ebenen
mehr Nachrichten verarbeiten müssen als Knoten, die in einer niedrigeren Ebene angesiedelt sind. Knoten, die einer höheren Belastung ausgesetzt sind, sollten damit auf
leistungsfähigere Knoten der physikalischen Ebene abgebildet werden.
Abbildung 2.4 und 2.5 verdeutlichen den Zusammenhang zwischen der virtuellen und
der organisatorischen Ebene aus einer anderen Sicht. In Abbildung 2.4 ist eine aus
Abschnitt 2.2 bekannte einfache Super-Peer-Architektur zu sehen, die in Abbildung
2.5 aus der organisatorischen Sicht betrachtet wird. Dieser Vergleich veranschaulicht
insbesondere den Zusammenhang zwischen den Super-Peers und den höheren Organisationselementen.
M
P
P
M
P
P
P
M
S
S
P
P
O
P
P
M
G
P
P
M
M
S
P
G
P
P
P
M
G
S
P
Super-Peer
Peer
Verbindung
M
M
M
P
G
O Organisation
P Projekt
G Gruppe
M Mitglied
Assoziation
Bild 2.4.. Super-Peer Overlay. Verbindun-Bild 2.5.. Organisatorisches Overlay. Vergen repräsentieren Registrierungen zwi-bindungen stellen organisatorische Bezieschen Peers und Super-Peers.
hungen dar.
17
3. Such- und Routingverfahren
3.1. Einführung
Wie in Kapitel 2 beschrieben, können P2P-Systeme in drei Kategorien eingeteilt werden - unstrukturiert, hybrid und strukturiert. Die Suche in P2P-Systemen beinhaltet
Aspekte wie das Routing von Nachrichten, die Menge der empfangenen und sendenden Knoten, die Art der Nachrichten, die lokale Verarbeitung und die Speicherung
von Verweisen und deren Pflege [TR03b], auf die in den vorgestellten Verfahren jeweils eingegangen wird.
In dem Fortschreiten der Entwicklung neuer Suchverfahren kommt der Struktur eines
Architekturstiles (siehe Abschnitt 2.1.2) eine erhöhte Bedeutung zu, so dass die Effizienz dieser Verfahren häufig mit komplexen Strukturierungsmaßnahmen einhergeht.
Diese Maßnahmen werden durch das dynamische Verhalten der P2P-Systeme erfüllt,
so dass topologische Veränderungen Zusatzinformationen verursachen, die teilweise
propagiert werden müssen, um eine konsistente Struktur zu gewährleisten.
3.1.1. Gliederung des Kapitels
Es existieren unterschiedliche Ansätze zur Strukturierung des Netzwerkes, die bestehende Informationen über den Aufbau nutzen oder mittels Heuristiken eine möglichst
optimale Routingstrategie verfolgen. Die Strukturierung der anfolgenden Such- und
Routingverfahren kann je nach Intention unterschiedlich ausfallen. Die dieser Arbeit
zugrunde liegende Strukturierung ist zeit-und zielorientiert und wurde von Wang
und Li [WL03] adaptiert. Sie gliedert sich grob in drei Generationen, die unterschiedliche Schwerpunkte setzen. Zusätzlich wird eine Historie der Entwicklungen ersichtlich. Erweiterungen zu bestehenden Verfahren werden diesen zugeordnet, um das
Verständnis und den Bezug zu steigern. Die grobe zeitliche Einteilung wird hierbei
nur unwesentlich beeinträchtigt. Der Umfang der Beschreibungen spiegelt schließlich
deren Bedeutung wider. Zusätzlich zu der textuellen Beschreibung wird in Abschnitt
3.5 ein grafischer Überblick gegeben.
Die ersten Verfahren basieren auf unstrukturierten P2P-Systemen und kommen ohne
Nachbarschaftsinformationen aus. Gnutella in der ursprünglichen Version und Freenet sind Vertreter dieser Generation. Beide Ansätze basieren auf dem Fluten des
Netzwerkes, um Suchergebnisse zu erzielen. Sie unterscheiden sich im Vorgehen der
Suche und in der Platzierung der anzubietenden Ressourcen. In Gnutella wird das
18
3.1. Einführung
Netzwerk mittels einer Breitensuche geflutet und Knoten speichern ihre Ressourcen
selbst. In Freenet hingegen wird eine Tiefensuche verwendet und auf eine freie Verteilung der zu speichernden Ressourcen gesetzt. Da diese Verfahren die ersten Vertreter
ihrer Art sind und viele Optimierungsansätze hinsichtlich der Suchperformanz und
der verursachten Netzwerklast existieren, wurde eine Vielzahl an Weiterentwicklungen publiziert, die den Schwächen meist auf Kosten erhöhten Verwaltungsaufwandes
entgegenwirken. Zur Weiterleitung von Nachrichten kann durch ein Zufallsprinzip
(Random Walks, Abschnitt 3.2.3) oder wie in APS (Advanced Probalistic Search,
Abschnitt 3.2.4) durch Rückschlüsse auf vergangene Anfragen ähnlichen Inhaltes gewählt werden. Um die Trefferquoten bei möglichst geringen Nachrichtenversand aufrecht zu erhalten, werden in Local-Index (Abschnitt 3.2.5) und Routing-Index (Abschnitt 3.2.6) Nachbarn indexiert, was jedoch zu einem ansteigenden Verwaltungsaufwand führt. Zur Wahrung der Konsistenz dieser Informationen werden regelmässig
Nachrichten produziert, die nur indirekt der Suche dienen.
Um Verfahren möglichst skalierbar und performant zu gestalten, entstanden Verfahren, die auf verteilten Hashtabellen aufsetzten (Chord in 3.3.1, CAN in 3.3.2, Tapestry in 3.3.3). Diese gewährleisten eine gute Verteilung der Informationen, können
jedoch nur Punktanfragen1 verarbeiten. Ungenaue Suchanfragen können nicht auf
identifizierende eindeutige Hashwerte abgebildet werden. Erweiterungen, meist zur
Minimierung des Nachrichtenversandes verursachen eine erhöhte Komplexität der Algorithmen und des Verwaltungsaufwandes.
Ungefähr zur gleichen Zeit entstanden Verfahren mit ähnlichen Zielen, jedoch einem
unterschiedlichen Ansatz. Diese Verfahren verknüpfen den dezentralen Charakter eines P2P-Systems mit zentralen Eigenschaften (SUPS in 3.2.8, GUESS in 3.2.1, Agile
und SHARK in 3.3.4 und in 3.3.5). Das Netzwerk lässt sich in zwei Knotenarten unterschiedlicher Funktionalität einteilen. Diesen Verfahren ist gemein, dass einer Menge
an charakteristischen Knoten eine Serverrolle zukommt. Hierdurch entstehen je nach
Intention Gruppen, die durch diese speziellen Knoten an das Netzwerk angebunden
werden. Die zeitlich am nahesten entwickelten Verfahren legen besonderen Wert auf
die Sicherheit und Fehlertoleranz von Ressourcen [MNR02; NW03].
Angefangen mit den Verfahren der ersten Generation, wie sie in den Anwendungen
Napster und Kazaa verwendet wurden, folgen Beschreibungen der strukturerhaltenden Algorithmen der zweiten Generation, wie Chord (siehe 3.3.1), CAN (siehe 3.3.2)
und zwei Vertreter, Viceroy und Distance Halving, der dritten Generation. Zusammenfassend werden alle Verfahren im Anschluss gegenübergestellt.
1
Objekte, die eindeutig durch einen Bezeichner identifiziert werden, können nur über diesen gefunden werden
19
3. Such- und Routingverfahren
3.1.2. Verwendete Begriffe
Da in Overlays intensiv Gebrauch von den unten aufgeführten Begriffen gemacht
wird, werden diese nun vorgestellt. In den anstehenden Kapiteln wird jedoch, so weit
wie möglich und sinnvoll, der deutsche Begriff verwendet.
Overlay / Überlagerung Wird synonym mit dem Begriff Overlay-Netzwerk verwendet. Es handelt sich hierbei um ein Netzwerk, das einem darunterliegenden
Netzwerk aufgelegt wird. So ist ein P2P-Netzwerk ein Overlay zu dem Netzwerk der physikalischen Rechner.
Topologie Eine Topologie bezeichnet die Struktur eines Netzwerkes. Bekannte Strukturen sind stern- oder ringförmig, gitterartig oder zufällig.
Node / Knoten Ein Knoten stellt einen Teilnehmer eines Overlays dar. Mehrere
Knoten können auf demselben Hostrechner plaziert werden.
NodeId / Knotenschlüssel Knoten werden durch eindeutige Schlüssel repräsentiert,
die aus einem identifier space / ID-Raum (Wertebereich) entnommen werden.
Key / Schlüssel Ein eindeutiger Schlüssel dient der Abbildung von Objekten, die
von Knoten verwaltet werden können. Er wird häufig aus demselben ID-Raum
entnommen, wie auch die Knoten, um Beziehungen zwischen Knoten und Ressourcen herzustellen.
Routingtabelle Jeder Knoten besitzt eine Routingtabelle, die Verweise auf andere
Knoten enthält und mittels derer Nachrichten weitergeleitet werden.
3.2. Verfahren der 1.ten Generation
Die erste Generation von Overlays zeichnet sich durch eine Menge von verbundenen
Knoten aus, die keiner Ordnung genügen. Beitretende Knoten werden an einer beliebigen Stelle des Netzwerkes hinzugefügt, so dass eine nicht vorhersagbare OverlayTopologie entsteht. Diese erste Generation wird nach Tsoumakos [TR03b] in blinde
und informierte Verfahren eingeteilt. Blinde Verfahren pflegen keinerlei Informationen bzgl. der Lage von Ressourcen. Informierte Verfahren dagegen pflegen zentrale
oder verteilte Indextabellen, die Informationen über einen Teilbereich des Overlays
beinhalten und zusammen einen kompletten Index erstellen. Zentrale Indextabellen
erinnern an das Client-Server-Prinzip, bei dem alle Klienten sich an einem Server anund abmelden und deren Metainformationen über bereitgestellte Ressourcen übermitteln. Knoten, die nur einen Teil des Netzwerkes indexieren, z.B. die Nachbarschaft,
bilden einen dezentralen Index über das gesamte Sytem.
20
3.2. Verfahren der 1.ten Generation
3.2.1. Breitensuche - Breath-first traversal BFS
Die Suche in einem baumartigen und graphbasierten Netzwerk wird als Breitensuche
bezeichnet, wenn der initiierende Knoten erst alle Kindsknoten durchwandert und
diese dem gleichen Prinzip folgen. Es wird somit erst die Breite und dann sukzessiv
die Tiefe durchsucht. Da Graphen im Gegensatz zu ’Bäumen’nicht notwendigerweise
zyklenfrei sind, muss eine zusätzliche Erkennung oder Vermeidung vollzogen werden.
Die Breitensuche (Breadth-first traversal) wurde im dezentralen Gnutella-Netzwerk2
zur Verbreitung von Nachrichten verwendet. Gnutella gilt als eines der ersten freien
verteilten Suchprotokolle für P2P-Systeme und wurde von Justin Frankel ins Leben
gerufen. Jeder Peer fungiert in einem P2P-System als Client und Server und wird in
diesem Kontext als Servant bezeichnet. Servanten sind untereinander mit nur wenigen
ihrer Art verbunden. Eintretende Knoten kontaktieren das Netzwerk über sog. wellknown hosts 3 , die über externe Quellen bereitgestellt werden. Die Kommunikation
untereinander wird durch wenige sog. Deskriptoren geführt.
Ping Der Ping-Deskriptor wird zur aktiven Ermittlung von weiteren Servanten verwendet. Servanten präsentieren sich hiermit im Netzwerk. Eine Ping-Nachricht kann
weitergeleitet werden, mit der Absicht Informationen über benachbarte Servanten zu
erhalten [LCP+ 04].
Pong Als Antwort auf einen Ping-Deskriptor wird der Pong-Deskriptor verwendet,
der die Menge an zur Verfügung gestellten Daten und die Adressen der Servanten, jedoch nicht die charakterisierenden Metadaten der Ressorucen selbst an den fragenden
Servanten übermittelt.
Query Die Suche nach bestimmten Ressourcen wird in Form eines Query-Deskriptors
an Servanten versendet, der einen Namen(-steil) enthalten kann. Die Interpretation
des Suchstrings variiert und kann vom Entwickler stark beeinflusst werden4 .
QueryHit Als Antwort auf eine Query generiert der empfangende Servant einen
QueryHit-Deskriptor mit den Informationen bzgl. seiner bereitgestellten Daten und
der zur Verfügung stehenden Geschwindigkeit.
2
Gnutella Protokoll Spezifikationen unter http://rfc-gnutella.sourceforge.net/ einzusehen.
Zuletzt besucht am 25.05.05
3
Kontaktinformationen zum Eintreten in das Netzwerk werden nicht im Protokoll berücksichtigt.
Es existieren verschiedene Möglichkeiten, wie das Abrufen von Addressen der well-known hosts
über Webseiten (http://gnutellahosts.com)
4
siehe http://rfc-gnutella.sourceforge.net/src/rfc-0_6-draft.html zuletzt besucht am
25.05.2005
21
3. Such- und Routingverfahren
Get Zielknoten können mittels des Get-Deskriptors eine Verbindung zum Anbieter
erstellen und den Transfer starten, falls dieser es ermöglicht.
Push Push-Deskriptoren werden verwendet, um Firewall-Restriktionen zu umgehen,
die keine direkte Verbindung zulassen. Der anbietende Servant wird veranlasst, eine
Verbindung zum Suchenden aufzubauen und somit den Transfer zu ermöglichen. Falls
beide Servanten durch eine Firewall geschützt sind, ist kein Austausch möglich.
Bye Das Austreten aus dem Netzwerk kann durch den Bye-Deskriptor signalisiert
werden (in Gnutella v0.6 optional). Hierbei werden bestehende Verbindungen geschlossen.
Nachrichten werden an alle dem Sender bekannten Servanten geschickt, die diese wiederum weitersenden. Somit fluten sie das gesamte Netzwerk (Message Flooding). Um
Zyklen zu vermeiden, werden alle Nachrichten mit einer Lebensdauer versehen. Diese
Lebensdauer kann sich in der Anzahl an maximal überschreitenden Hops (HTL:hopto-live) und in einer zeitlichen Begrenzung (TTL:time-to-live) ausdrücken, wonach
sie beendet wird. Servanten, die der Suchanfrage genügen, treten direkt mit dem
Suchenden in Verbindung.
Erweiterungen
Modifizierte Breitensuche (Modified-BFS) Eine Reduzierung des Nachrichtenaufkommens wurde mit dem Algorithmus Modified-BFS (publiziert in [KGZY02])
ermöglicht, indem nicht alle Nachbarknoten angesprochen werden, sondern nur eine
zufällig bestimmte Menge an Nachbarn kontaktiert wird. Da keine Kriterien für die
Auswahl der Nachbarn herangezogen werden, vermindert sich mit der Anzahl ausgewählter Nachbarn ebenfalls die Trefferquote unter Berücksichtung der Hops und der
Zeit.
Intelligente Breitensuche (Intelligent-BFS) Kalogeraki u.a. stellen in [KGZY02]
ein Suchverfahren vor, in dem die Weiterleitung von Erfolgsschätzungen beeinflusst
wird. Schätzungen basieren auf einem Profil- und Bewertungsmechanismus, durch den
sie entscheiden, in welche Richtung ein Broadcast gesendet wird. Die während der Suche gefundenen Antworten speichert der suchende Peer in tabellarischer Form ab, die
jeweils Anfrage und Zielknoten enthält. Die Least-Recently-Used Strategie wird zur
Wahrung einer festen Tabellengröße verwendet. Aus den fortwährend gespeicherten
Informationen ergibt sich ein (unvollständiges) Profil für alle bisherigen Zielknoten,
das bei anstehenden Anfragen herangezogen werden kann. Die Auswahl der Knoten,
die zur Weiterleitung bestimmt werden, wird durch eine definierte maximale Anzahl
22
3.2. Verfahren der 1.ten Generation
und durch Vergleichskriterien (Ranking) beeinflusst. Als Vergleichskriterium wird das
Cosinus-Maß [Fer03] vorgeschlagen, das aus dem Information Retrieval bekannt ist
und Dokumente anhand ihrer Ähnlichkeit spezifiziert.
Gerichtete Breitensuche (Directed-BFS) In [BY01] wird am Anfang einer Suche anhand von bisher erstellten Statistiken direkt Kontakt zu ’vielversprechenden’
Knoten erstellt. Diese Knoten verfahren dann nach der bisherigen Breitensuche. Statistiken beinhalten Merkmale, die folgende Heuristiken begründen:
Eine hohe Anzahl gelieferter Resultate in vorherigen Anfragen erhöht die Wahrscheinlichkeit einer erneuten hohen Trefferquote.
Die Anzahl der durschnittlichen Hops bis zum Erreichen eines Knotens, der
Resultate in der Vergangenheit liefern konnte, deutet auf die Entfernung der
gesuchten Ressourcen hin. Je geringer diese ist, desto weniger Nachrichten wurden verschickt.
Knoten, die bisher viele Nachrichten weitergeleitet haben, sind stabil und verfügen wahrscheinlich über eine bessere Netzanbindung.
Die Nachrichtenwarteschlange eines Knotens beeinflusst die Latenzzeit und
kann zusätzlich Informationen über seine Auslastung geben.
Fortlaufende Breitensuche (Consecutive-BFS) Die Breitensuche (BFS) produziert mit zunehmender Suchtiefe ein exponentiell wachsendes Nachrichtenaufkommen.
Da keine Rückmeldung zum Ausgangsknoten existiert, wird die Suche auch bei Erfolg nicht unterbrochen. Ein Verfahren, das in der Künstlichen Intelligenz und in der
Spieltheorie verwendet wird, reduziert das Nachrichtenaufkommen durch Iterationen.
Eine, dem System zugrunde liegende Anzahl an Verfahrensregeln (Policy), definiert,
welche Iterationen bei der Suche verwendet werden. So kann die Suchtiefe pro Durchgang erhöht werden, ohne dass unnötig Nachrichten weitergeleitet werden (Expanding
Ring).
[BY01] und [YGM02] beschreiben dieses Verfahren als Iterative Deepening. Ausgehend von einer systemweiten Policy, die die Iterationen a,b und c (a<b<c) und eine
Warteperiode W vorsieht, wird die Suche anfangs mit einer Tiefe a verschickt. Nach
erfolgloser Suche in der tiefsten Ebene (sog. Frontier) wird die Nachricht für die Zeit
W dort temporär gespeichert und anschließend gelöscht. Falls die Suchtiefe (nächste
Iteration) vom Suchenden erhöht wird, so sendet dieser eine Resend -Nachricht aus,
die schließlich an der Grenze der vorherigen Iteration ankommt. Falls die Wartezeit
noch nicht abgelaufen ist, sendet dieser Knoten die ursprünglich gespeicherte Nachricht um b − a Ebenen weiter. Ohne sie zu bearbeiten, leiten die Knoten, die eine
Resend-Nachricht erhalten, diese weiter.
23
3. Such- und Routingverfahren
Bei einem Verzweigungsgrad (sog. branching factor) b und der Tiefe der Suchlösung
d ist die Zeitkomplexität O(bd). Im Vergleich zur einfachen Tiefensuche ist hier die
Suchtiefe der Lösung entscheidend.
Ultrapeer Das bestehende Gnutella-Protokoll wurde von den Gnutella-Entwicklern
in dem Ultrapeer Proposal v1.0 [SR01] um eine zunehmende Strukturierung erweitert.
Der Ansatz entspricht den in Abschnitt 2.2 vorgestellten Super-Peer-Netzwerken und
kann als zusätzliches Overlay zu dem ursprünglichen Gnutella-Protokoll angesehen
werden. Ein Ultrapeer übernimmt die Funktion eines Gateways zum Gnutellanetzwerk. Die Wahl eines Ultrapeers ist selbstorganisierend und muss folgende Bedingungen erfüllen:
Ultrapeers dürfen nicht durch eine Firewall geschützt sein, da ansonsten keine
eingehenden Verbindungen akzeptiert werden können.
Das Betriebssystem muss eine hohe Anzahl an Socketverbindungen bereitstellen.
Sie sollten eine hohe Bandbreite aufweisen, da sie in ihrer Funktion sonst als
Engpass für Servanten werden, die den Gateway verwenden.
Die Zeit, in der sie sich ohne Unterbrechung im Netzwerk befinden (Uptime)
muss ausreichend hoch sein, um erhöhte Kosten zur Benennung eines nachfolgenden Ultrapeers zu sparen und Indexinformationen aufbauen zu können.
Verarbeitungsgeschwindigkeit ankommender Anfragen und Speicherung großer
Indextabellen zeichnen Ultrapeers aus.
Servanten, die nicht den Anforderungen eines Ultrapeers bzw. Super-Peers genügen,
bauen Verbindungen zu einem oder mehreren Ultrapeers auf. Verbindungen unter
Servanten existieren nicht, so dass sich Cluster von Servanten bilden, die ihre Anfragen an einen Ultrapeer senden. Dieser verweist, gestützt durch Indextabellen, auf
einen Zielservanten oder routet die Nachricht an weitere Ultrapeers, die nach dem
gleichen Prinzip folgen.
Als Routingstrategie ist das Query Routing Protocol (QRP) 5 entstanden, das in diesem Zusammenhang nicht näher erläutert wird.
Servanten, die keine Information über bestehende Ultrapeers besitzen, können nach
dem bisherigen Verfahren ihre Suche als Broadcast propagieren. Sie ignorieren damit
das zusätzliche Overlay.
5
Spezifikation unter http://rfc-gnutella.sourceforge.net/src/qrp.html zuletzt besucht am
25.05.05
24
3.2. Verfahren der 1.ten Generation
GUESS - Gnutella Ultrapeer Extension for Scalable Searches GUESS ist ein
Suchmechanismus, der ohne blinde Weiterleitung von Nachrichten auskommt und
als Erweiterung des bestehenden Gnutella-Suchverfahrens entwickelt wird. Es wurde
in der Version v0.01 im Jahre 2002 von den Entwicklern des Gnutella-Protokolls
vorgestellt und bisher nicht in allen Details implementiert. Die Beschreibung ähnelt
der zuvor Erwähnten. Da jedoch kein expliziter Zusammenhang der beiden Verfahren
erkannt wurde, wird auf GUESS an dieser Stelle separat eingegangen.
Ein unstrukturiertes Gnutella-Netzwerk wird strukturiert, indem sog. Ultrapeers
(Super-Knoten) und Klientenknoten eingeführt werden [SR02]. Ultrapeers können für
Peers als Proxy zum Gnutella-Netzwerk angesehen werden. Die hierdurch entstehende Struktur ermöglicht skalierbare Suchanfragen. Super-Knoten erhalten von ihren
Klientenknoten Anfragen und leiten diese an bekannte Super-Knoten weiter. Der empfangende Super-Knoten bzw. der dahinter liegende Klientenknoten dient als Server
und der sendende Super-Knoten als Klient. Der ursprüngliche Sender wird somit von
seinem Ultrapeer gekapselt - im Gegensatz zur vorherigen Ultrapeer-Beschreibung.
Ultrapeers sind in der Anzahl gleichzeitig zu verschickender Nachrichten beschränkt,
um die Netzwerklast gering zu halten.
Gia Gia6 wurde von Chawathe, Ratnasamy u.a. [Yat03] entworfen, um die Skalierbarkeit des Gnutella-Systems zu verbessern. Die Anfragenverteilung im System hängt
von der zur Verfügung stehenden Kapazität eines Knotens ab. Je höher die Kapazität
ist, desto mehr Verbindungen können zu anderen Knoten eingegangen werden. Die
Kapazität bezeichnet die bearbeiteten Anfragen pro Zeiteinheit. Durch einen Level of
Satisfaction wird der aktuelle Verbindungsgrad beschrieben, der somit eine Grenze
für eingehende Verbindungen definiert. Statt die Suche durch ein Fluten des Netzwerkes zu realisieren, werden Walker (Verfahren siehe ”Random Walks” in Abschnitt
3.2.3) eingesetzt. Inspiriert durch die Vorarbeit von Adamic u.a. [ALPH01] wird die
Weiterleitung im Random-Walker-Verfahren durch die Kapazität der Nachbarknoten
entschieden. Mit der Kapazität steigt der Verbindungsgrad eines Nachbarn. Dieser
speichert für alle direkten Nachbarn Informationen über bereitgestellte Ressourcen
und besitzt somit mehr Informationen, die schließlich die Wahrscheinlichkeit eines
Suchtreffers erhöhen.
Interessen-basierte Algorithmen Sripanidkulchai, Barbosa u.a. untersuchten interessen-basierte Verfahren zur Weiterleitung von Nachrichten, um die Suchperformanz
zu erhöhen. Knoten besitzen ein gemeinsames Interesse, wenn sie im Besitz gleicher
Ressourcen sind. Drei interessen-basierte Algorithmen werden im Folgenden kurz
vorgestellt.
6
Gia steht für gianduia und stellt die allgemeine Bezeichnung des Haselnussbrotaufstrichs Nutella
dar (Crema Gianduia)
25
3. Such- und Routingverfahren
Shortcut-Based Algorithm Sripanidkulchai u.a. stellen in [SMZ03] einen Algorithmus
vor, der aktuelle Anfragen aufgrund einer Historie verarbeitet. Sie vertreten den Ansatz, dass Knoten, die in der Vergangenheit erfolgreich einem anfragenden Knoten
antworten konnten, es mit hoher Wahrscheinlichkeit in der Zukunft ebenfalls können.
Knoten, die ein ähnliches Interesse verfolgen, erstellen gegenseitig Shortcuts, die der
Lokalisierung dienen.
Basic Community Algorithm I Barbosa u.a. beschreiben in [BCAA04] eine Graphstruktur, die Interessen abbildet. Ecken repräsentieren Knoten; Kanten zwischen zwei
Ecken stellen gemeinsame Interessen dar. Ein Knoten wählt zufällig eine feste Anzahl
an eigenen Ressourcen aus, die auf Übereinstimmung mit bestehenden Knoten hin
untersucht werden. Die Anzahl der gleich-interessierten Knoten ist ebenfalls begrenzt,
so dass danach keine weiteren Knoten befragt werden. Die gefundenen Knoten verfahren nach demselben Prinzip. Durch die zufällige Auswahl der Ressourcen entstehen
verschiedene Interessengruppen.
Basic Community Algorithm II In einem abgewandelten Algorithmus von Barbosa
u.a. [BCAA04] werden je nach Ausmaß der Übereinstimmungen die Kanten in dem
Graphen gewichtet. Das Gewicht drückt innerhalb einer Interessensgruppe die unterschiedlich ausgeprägte Verbundenheit unter den Knoten aus. Im Gegensatz zum
vorherigen Ansatz wird hier auf eine Rekursion verzichtet. Gefundene Knoten werden
somit nicht der gleichen Prozedur unterworfen.
Fasttrack Das FastTrack-Protokoll wurde von Niklas Zennström und Janus Friis
initiiert. Es erweitert das bestehende Gnutella-Protokoll um sog. Supernodes, die die
Skalierbarkeit des Netzwerkes deutlich erhöhen. Es handelt sich um ein Super-PeerNetzwerk, in dem die Super-Knoten als Indexknoten dienen, die die in Abschnitt
2.2 beschriebenen Eigenschaften besitzen sollten. Die Kommunikation innerhalb des
Netzwerkes teilt sich in zwei Bereiche, der Kommunikation zwischen Super-Knoten
und allgemeinen Knoten und der Kommunikation zwischen den Super-Knoten. Da
eine undokumentierte Verschlüsselung der Kommunikation besteht, konnten die ursprünglichen Kommunikationselemente nicht vollständig ermittelt werden, speziell
die Kommuniaktion zwischen den Super-Knoten. Eine Nachahmung des Protokolls
ist in dem Projekt giFT-FastTrack [Har04] entstanden. Als bekanntester Vertreter
des FastTrack-Protokolls ist KaZaA7 zu nennen.
3.2.2. Tiefensuche (Depth-first traversal DFS)
Ausgehend von einem Baum oder Graph wird die Suche von einem Knoten initiiert
und statt in die Breite, also an alle Nachbarknoten, in die Tiefe fortgesetzt. In einem
7
http://www.kazaa.com/us/index.htm, zuletzt besucht am 17.10.2005
26
3.2. Verfahren der 1.ten Generation
Baum wird jeweils der direkte Kindsknoten angesprochen, der in der Ebene am weitesten links angeordnet ist und noch nicht besucht wurde. Dieser Vorgang wiederholt
sich, bis ein Blatt erreicht ist. Dann beginnt ein Backtrackingprozess, der rekursiv den
Pfad zum Ursprung verfolgt, bis die erste Verzweigung gefunden ist. Diese wird wiederum bis zum Blattknoten verfolgt. Mittels dieses Algorithmus wird der komplette
Baum durchsucht, erst tiefenorientiert, dann breitenorientiert.
Anders als in einem Baum kann ein Graph Zyklen enthalten, so dass nicht unbedingt
ein Blatt gefunden wird. Zyklen müssen erkannt werden, häufig durch eine Historie,
um an geeigneter Stelle den Backtrackingprozess zu starten.
Ein Vertreter der Tiefensuche stellt das P2P-System Freenet dar, das im Folgenden
vorgestellt wird.
Freenet
Das von Ian Clarke (1999) in [CSWH01] vorgestellte P2P-System Freenet erlaubt es,
Daten anonym bereitzustellen, indem die angebotenen Ressourcen nicht lokal gespeichert werden, sondern in sog. Data Stores auf beliebigen anderen Knoten gelagert
werden. Hierzu wird ein Hashwert für jede Ressource erzeugt. Knoten sind dezentral angeordnet und in ihrer Funktionsweise identisch. Anfragen und Bereitstellen
(Uploads) werden durch einen Hop-to-live (HTL) in ihrer Reichweite begrenzt, damit das Netzwerk nicht komplett geflutet wird. Anfragen sollen bei der Weiterleitung
an den Knoten vermittelt werden, der dem Ziel am nächsten liegt. Ein weiterleitender
Knoten wartet auf die Antwort, bevor dieser einen neuen Nachbarn zur Weiterleitung
bestimmt, so dass statt einer Breitensuche eine Tiefensuche verwendet wird [BY01].
Erster Ansatz Der erste Routingalgorithmus entschied anhand von Indextabellen,
in welche Richtung die Nachricht weitergeleitet wird. Der Index wird anhand von
Rückmeldungen über geroutetete Nachrichten erstellt. Eine Nachricht, die das gewünschte Ziel erreicht hat, veranlasst den Zielknoten, eine positive Rückmeldung
an alle Vorgänger bis zum ursprünglichen Sender zu versenden. Diese Nachricht wird
zum Indexaufbau genutzt. Ähnliche Anfragen werden in dieselbe Richtung verschickt,
so dass sich Knoten allmählich auf einen Bereich spezialisieren.
NextGeneration-Routing Eine Erweiterung des bestehenden Routingmechanismus
hinsichtlich der Performanz ist das zusätzliche Abspeichern der Antwortzeit, der bisherigen Trefferquote und der Zeit zur Erstellung einer ersten Verbindung zu einem
Knoten. Mit diesen zusätzlichen Informationen soll das Weiterleiten der Nachrichten
optimiert werden.
27
3. Such- und Routingverfahren
3.2.3. Random Walks
Suchanfragen, hier Walker, werden durch eine zufällige Anzahl an Addressaten begrenzt. Diese verfahren bei der Weiterleitung nach dem gleichen Prinzip, so dass das
Netzwerk auf undeterministische Weise durchsucht wird. Walker terminieren nach
einer vorgegebenen Zeit (TTL - time-to-live ) oder beenden die Suche erfolgreich.
Die Erfüllung der Suche wird durch eine regelmässige Kontaktaufnahme mit dem Suchenden überprüft. Falls genügend Ergebnisse durch weitere Walker erzielt worden
sind, kann eine weitere Suche somit beendet und ein unnötiges Nachrichtenaufkommen reduziert werden. In dem ursprünglichen Algorithmus ist ein Walker vorgesehen,
womit sich die Suchzeit verlängert. Diese wird durch weitere Walker verkürzt, wobei
das Nachrichtenaufkommen damit ansteigt.
In einer Analyse von [LCC+ 02] wurde gezeigt, dass die Skalierbarkeit des Systems im
Vergleich zum einfachen Fluten des Netzwerkes gesteigert werden konnte. Von den
Autoren wurden folgende Bedingungen für eine skalierbare Suche in unstrukturierten Umgebungen aufgestellt, die in dem vorgestellten Verfahren eingehalten werden
können:
Adaptives Beenden von Suchanfragen auch vor Ablauf der TTL verringert unnötige Netzwerklast.
Nachrichtenduplikate sollten minimiert werden, indem Knoten nur einmal besucht werden.
Zusätzliche Suchschritte sollen die Anzahl der besuchten Knoten nicht signifikant erhöhen.
3.2.4. APS - Adaptive Probabilistic Search
Tsoumakos und Roussopoulos stellen in [TR03a] eine informierte Suchmethode für
unstrukturierte Netzwerke vor. Peers kennen lediglich die Adressen ihrer Nachbarn.
Suchanfragen werden durch Walker repräsentiert, die einen Teil des Netzwerkes durchsuchen und bei erstem Erfolg ihre Suche beenden. Sie sind begrenzt, so dass nicht alle
verfügbaren Nachbarn angesprochen werden. Nachrichten verfallen nach Überschreitung einer angegebenen maximalen Suchtiefe (TTL). Sie werden bei Empfang kurzzeitig gespeichert (soft-state). Jeder Knoten besitzt einen lokalen Index, in dem pro
angefragtem Objekt bzw. weitergeleiteter Suche für jeden Nachbarn eine Wahrscheinlichkeit für die erfolgreiche Suche in der Zukunft gespeichert wird. Falls verschiedene
Walker denselben Knoten erreichen, dient der soft state dazu, den letzteren mit einem
Misserfolg zu beenden, da dieser ansonsten dem ersten folgen würde.
28
3.2. Verfahren der 1.ten Generation
Die Wartung der gespeicherten Indexeinträge geschieht nach zwei unterschiedlichen
Ansätzen. Im optimistischen Ansatz wird davon ausgegangen, dass eine Suche erfolgreich endet. Nur im gegensätzlichen Fall verfasst der zuletzt besuchte Knoten eine
update-Nachricht, die den Suchpfad in umgekehrter Richtung verfolgt. Dieser Knoten
und seine Vorgänger erniedrigen ihre zuvor getroffene Auswahlwahrscheinlichkeit, so
dass zukünftige Suchen mit gleichem Suchkriterium einen anderen Weg einschlagen.
Erfolgreiche Suchen werden nicht berücksichtigt. Der pessimistische Ansatz beruht
auf der Annahme, dass vorwiegend Misserfolge eintreten. Somit wird nur bei Erfolg
eine Update-Nachricht versendet, die alle vorherigen Knoten veranlasst, ihre diesbezügliche Wahrscheinlichkeit zu erhöhen. Bei Misserfolg wird nicht reagiert. Falls
weniger als die Hälfte der ausgesandten Walker zum Erfolg führen, ist die Verarbeitungszeit im pessimistischen Fall geringer.
Dieses Suchverfahren zeichnet sich durch eine Lernfähigkeit aus, die bei wiederholten
Anfragen zunehmend effizienter zum Ziel führt. Im Worst-Case werden 2 ∗ k ∗ T T L
Nachrichten pro Anfrage verschickt (k enspricht der Anzahl an Walkern). Die Menge der zu verwaltenden Informationen von r bisher gesuchten Ressourcen bei einer
Anzahl von n Nachbarn betragen O(r × n).
Erweiterungen
Die Verfasser des Suchverfahrens stellen zwei Erweiterungen vor. Die kontinuierliche
Überwachung der Erfolgsrate dient dem s-APS (wechselndes-APS), die kostengünstigere Alternative zur Indexwartung während der Laufzeit zu wählen. Eine zusätzliche
Gewichtung nach der Entfernung der Trefferknoten wirkt sich positiv auf die Anzahl
der zu kontaktierenden Knoten aus. Nähere Replikate können im ω-APS (gewichtetesAPS) dem Entfernteren somit vorgezogen werden, anstatt bei gleicher Wahrscheinlichkeit zweier Nachbarn zufällig zu entscheiden.
Tsoumakos und Roussopoulos stellen mit AGNO (An Adaptive Group Communication Scheme for Unstructed P2P Networks) [TR05] eine Möglichkeit der Gruppenkommunikation vor. Gruppen werden implizit durch gemeinsame Interessen gebildet,
die durch sog. Backpointer (rückwärtiger Verweis) beim Weiterleiten von Nachrichten entstehen. Dynamische Strukturen werden erkannt, indem die Lernfähigkeit des
APS-Verfahren genutzt wird. Somit kann nach einer gewissen Lernphase die Anzahl
an versendeten Nachrichten reduziert werden und die Suche zielgerichteter ablaufen.
Außerdem wird davon ausgegangen, dass Peers, die ein bestimmtes Interesse bisher
bekundet haben, dieses auch weiterhin pflegen und über relevante Neuerungen informiert werden wollen.
29
3. Such- und Routingverfahren
3.2.5. Local Indices
Yang und Garcia-Molina schlagen in [BY01] vor, dass jeder Knoten einen lokalen Index über die Informationen seiner Nachbarn bis zu einem Radius r pflegt. Der Radius
entspricht hierbei der Anzahl an Hops. Eine systemweite Richtlinie (policy) bestimmt,
welche Knoten abhängig von ihrem Radius zum anfragenden Knoten Nachrichten verarbeiten, weiterleiten und verwerfen. Eine policy besteht aus einer Menge von Zahlen,
die die Tiefe einer Nachricht darstellen und ausschlaggebend dafür sind, welcher Knoten eine Nachricht verarbeitet, d.h. mit dem lokalen Index vergleicht. Die anderen
Knoten leiten die Suchanfrage lediglich an alle direkten Nachbarn weiter. Der letzte
Eintrag der policy bestimmt den Knoten, der die Nachricht verfallen lässt. In einer
Policy P = 1, 5 verarbeiten die Knoten der ersten und fünften Tiefe die Nachricht,
indem sie ihren Index überprüfen. Alle dazwischenliegenden Knoten leiten diese lediglich weiter. Die Knoten der Tiefe fünf beenden die Suche, da die Policy diese Tiefe
als letzte Zahl angibt.
Falls der Indexradius r beträgt, so sollte nach [TR03c] der Abstand zweier aufeinander
folgender Tiefen in der policy 2∗r+1 sein, da die dazwischenliegenden Knoten jeweils
indexiert werden und somit bei einer Verarbeitung nur die Latenzzeit erhöhen.
3.2.6. Routing Index - RI
Ein Routing Index ist eine Datenstruktur, anhand der als Suchergebnis eine sortierte
Liste von direkten Nachbarn geliefert wird. Die Sortierung gibt Auskunft über die
Güte des damit verbundenen Pfades zu den naheliegenden Ressourcen. Ressourcen
werden Kategorien zugeordnet, wobei eine Ressource mehreren Kategorien gleichzeitg
angehören kann. Jeder Knoten verwaltet einen lokalen Index und einen Routing Index, der für die Weiterleitung der Anfragen dient. Der lokale Index gibt Auskunft
über alle dem Knoten angehörigen Ressourcen; der Routing Index speichert Informationen über Ressourcen der anderen Knoten im Netzwerk. Es werden in [CGM02]
drei Routing Indizes (RI) unterschieden, der compound RI (CRI), der hop-count RI
und der exponential RI, die im Folgenden vorgestellt werden.
compound RI Jeder Knoten hält neben dem lokalen Index Informationen über die
kategorienbezogene Anzahl aller Ressourcen eines Pfades. Die Abbildung 3.1 veranschaulicht ein Netzwerk mit fünf Knoten und den dazugehörigen Indextabellen, die
in einen lokalen Index (dunkel) und einen Routing Index (hell) unterteilt sind. Der
Routing Index beinhaltet alle direkten Nachbarknoten, stellt jedoch die Anzahl aller
Ressourcen eines weiterführenden Pfades in Zusammenhang mit den ausgewählten
Kategorien. Der Knoten A ist direkt mit Knoten C benachbart und führt diesen somit in dem Routing Index auf. Die Anzahl der Ressourcen in diesem Routing Index
30
3.2. Verfahren der 1.ten Generation
entspricht jedoch der Anzahl an Ressourcen der Knoten C und allen Weiterführenden,
also auch D und E.
#
K1
K2
K3
B
18
3
3
3
A
76
31
49
20
24<12+32+4
Dokumente können
mehreren
Kategorien
angehören
B
#
K1
K2
K3
D
24
12
32
4
C
54
18
16
11
G=2
18>3+3+3
Weitere Dokumente
gehören anderen
Kategorien an
G=2
C
G=8,75
D
G=1
A
#
K1
K2
K3
A
12
3
9
0
B
18
3
3
3
C
64
28
40
20
#
K1
K2
K3
C
24
12
4
8
A
30
6
12
3
D
24
12
32
4
E
16
4
4
8
Lokaler Index
E
#
K1
K2
K3
E
16
4
4
8
C
78
18
16
11
G = 28/64 * 20/64 * 64 = 8,75
Bild 3.1.. Ausschnitt des Netzwerkes mit jeweiligen Indextabellen. Anfrage nach
Ressource aus Kategorie K1 und K3 an Knoten A versandt. Auswahlroute fett gekennzeichnet mit Gütewert als Auswahlkriterium. Berechnung des Gütewertes G von
Knoten C.
Falls der Knoten A eine Suchanfrage nach Ressourcen erhält, die den Kategorien K1
und K3 zugeordnet werden, so wird zuerst der lokale Index betrachtet und dann für
jeden direkten Nachbarn eine Pfadgüte berechnet, um nicht das gesamte Netzwerk
zu fluten. Die Güte berechnet sich nach folgender Formel:
G = #N umberOf Documents ∗
Q
CRI(si )
i #N umberOf Documents
Der Pfad mit der höchsten Güte (A-C-D) wird dann verfolgt. Dieser Algorithmus
terminiert, wenn die gewünschte Trefferanzahl erreicht wurde bzw. es keine weiteren
Nachbarn mehr gibt.
Die Entfernung der aggregierten Ressourcen ist in diesem Algorithmus nicht ersichtlich. Der compound Routing Index stellt lediglich die Anzahl der gewünschten Ressourcen in dem betrachteten Pfad zur Verfügung und berechnet anhand dessen die
Pfadgüte. Bei einer geringen geforderten Trefferanzahl ist somit die Entfernung wichtiger als die Menge, die schließlich in der Güteberechnung betrachtet wird. Ein weiteres
durchaus größeres Problem ergibt sich in der Wartung der Indexdaten. Compound
31
3. Such- und Routingverfahren
Index indexiert alle in einem Pfad folgenden Knoten. Die Daten- und Topologieänderungen verursachen daher eine enorme Netzwerklast, da alle Knoten eines möglichen
Pfades benachrichtigt werden müssen.
hop-count RI Der hop-count RI vermindert die Wartungsprobleme, in dem eine
künstliche Indexierungsgrenze (sog. horizon) angegeben wird. Es wird somit nur bis
zu einer festen Entfernung indexiert. Der Speicheraufwand erhöht sich jedoch, da
für jeden Radius (1-hop, 2-hop, ..) ein aggregierter Index erstellt wird nach dem
Prinzip des compound RI, jedoch mit dem Radius als Grenze. Es müssen also mehrere
Indexlisten gespeichert werden.
exponential RI Der exponential RI verringert den Speicheraufwand des hop-count
RI auf Kosten von ungenauer Vorhersagen. Eine detaillierte Beschreibung des Algorithmus wurde von den Autoren nicht geliefert. Nach [CGM02] werden die Kosten
eines regulären Baumes 8 auf den hop-count RI angewandt.
3.2.7. DLRP - Distributed Resource Location Protocol
Statt alle existierenden Replikate einer Ressource zu finden bzw. alle Knoten mit entsprechenden Verweisen zu kontaktieren, werden in dem Suchprotokoll von Menascé
und Kanchanapalli [MK02] nur einzelne Nachbarn befragt und die Weiterleitung
durch eine Suchtiefe begrenzt. Jeder Knoten besitzt ein lokales Verzeichnis über eigene Ressourcen und einen Verzeichniscache über fremde Inhalte. Weiterhin ist die
direkte Nachbarschaft namentlich bekannt, so dass Nachrichten adressiert werden
können.
Ein suchender Knoten, sog. source, sendet die Anfrage mit einer gewissen Wahrscheinlichkeit an seine Nachbarn, die diese mit ihren lokalen und fremden Informationen
vergleichen. Falls sie nicht Besitzer dieser Ressource sind und auch keinen Verweis
in ihrem Cache enthalten, so wird die Nachricht bis zu einer vorgegebenen Suchtiefe
nach gleichem Prinzip weiterverschickt, wobei die Wahrscheinlichkeit in Abhängigkeit der Suchtiefe in einer Richtlinie variiert werden kann (broadcast policy). Die
weitergeleitete Nachricht enthält alle Adressen der bisher untersuchten Knoten. Diese Zusatzinformation wird verwendet, um den Verzeichniscache aller Knoten eines
Suchpfades mit neuen Inhalten zu versehen. Methoden zur Ersetzung bestehender
und zur Invalidation nicht mehr existierender Einträge sind nicht im Protokoll vorgesehen.
8
Ein Baum, bei dem alle Knoten den gleichen Grad D haben, wird als regulärer Baum bezeichnet.
Die maximale Kardinalität der Kantenmenge eines Weges in einem Baum wird als Tiefe des
Baumes bezeichnet.[Hor00]
32
3.3. Verfahren der 2.ten Generation
3.2.8. SUPS - Scalable Unstructured P2P System
SUPS wird als ein Super-Peer-System vorgeschlagen, dass Vorteile wie die zentralisierte Suche und die Anonymität verbindet. Besonderer Wert wird auf die Topologie des
unstrukturierten Netzteiles gelegt, also den Super-Peer-Beziehungen untereinander.
Pyun und Reeves gehen in [PR04] davon aus, dass die wichtigste Anforderung an ein
unstrukturiertes P2P-System ein geringer Durchmesser9 ist. Eine gute Lastverteilung
könnte durch einen regulären Graphen geleistet werden, da alle Knoten die gleiche
Anzahl an ausgehenden Verbindungen besitzen. Zufallsgraphen10 werden von Erdös
und Rényi [ER59] erzeugt, indem Paare von Ecken zufällig ausgewählt werden und
mit einer gleichen Wahrscheinlichkeit verbunden werden, so dass alle Ecken nahezu
die gleiche Anzahl an Kanten besitzen. Weiterhin zeigen sie, dass hierbei ein geringer
Durchmesser entsteht, der für die Topologieerstellung von P2P-Systemen gewünscht
ist.
Da jedoch P2P-Systeme einer starken Dynamik unterliegen, wurde von Pyun und
Reeves ein Prozess vorgeschlagen, der die Topologieänderungen berücksichtigt (Random δ -Process). Als minimalen Verbindungsgrad in dem Netzwerk bezeichnen die
Autoren δ. Bei dem Eintreten eines Knotens werden alle bestehenden Knoten auf
ihre Konnektivität hin untersucht. Die Knoten mit einem Grad geringer als δ werden
mit dem Knoten verbunden, der den geringsten Grad aufweist. Die Auswahl erfolgt
zufällig. Dieser Prozess wird solange wiederholt, bis der Grad aller Knoten nahezu
gleich ist. δ, als Ausdruck der Konnektivität, erhöht sich dabei mit steigender Anzahl
an Knoten.
Die Einhaltung eines geringen Durchmessers birgt jedoch eine hohe Anzahl an Topologieänderungen, falls Knoten das Netzwerk betreten oder verlassen. Weiterhin
muss jeder Knoten die Anzahl aller bestehenden Knoten regelmässig schätzen, um
die entsprechende Konnektivität zu gewährleisten.
3.3. Verfahren der 2.ten Generation
Verfahren der zweiten Generation basieren überwiegend auf verteilten Hashtabellen
(sog. distributed hash-table (DHT)). Die gleichverteilende Eigenschaft der Hashtabellen wirkt sich auf Skalierbarkeit und Lastverteilung der Nachrichten positiv aus.
Ressourcen und Knotenadressen werden meist auf denselben Wertebereich abgebildet und somit wird eine Beziehung zwischen Knoten und Ressourcen ermöglicht, die
9
Der Durchmesser eines Graphen entspricht der maximalen Distanz zweier beliebiger Knoten. Die
Distanz zwischen zwei Knoten ist die minimale Anzahl Kanten, die durchlaufen werden muss,
um von einem Knoten aus den anderen zu erreichen
10
Ein Zufallsgraph ist ein Graph, in dem die Anzahl an Ecken, Kanten und Verbindungen nach
einem Zufallsprinzip gewählt werden.
33
3. Such- und Routingverfahren
sich darin ausdrücken kann, dass Knoten einen Bereich an Ressourcen verwalten.
Suchgarantien können ausgestellt werden, da theoretisch alle Ressourcen mit meist
logarithmischem Aufwand gefunden werden.
3.3.1. CHORD
Das Chord-Protokoll [SMK+ 01] wurde von Ion Stoica 2001 publiziert und zählt zu
den bekannten DHT-Verfahren. Das Protokoll spezifiziert, auf welche Art und Weise
Schlüssel lokalisiert werden können und wie Knoten das System betreten und verlassen. Chord ist ein Vertreter der DHT-Verfahren und basiert somit auf der Verteilung
der Knoten mittels einer verteilten Hash-Tabelle. Knoten werden durch einen Ring
eindeutig repräsentiert und verwalten Bereiche von Schlüsseln. Schlüssel werden ebenfalls durch eine Hash-Funktion auf den Ring abgebildet, indem sie Knoten zugeordnet
werden.
Der Ring umfasst somit alle Knoten, die aktuell im System enthalten sind. Er besteht
jedoch in der Regel aus einer wesentlich größeren Menge an Ringplätzen, als Knoten
vorhanden sind. Die Größe des Ringes entspricht einer Zweier-Potenz mit Exponent
m, die alle Knoten eindeutig abbilden kann. Das Wählen einer Zweier-Potenz ist in
den Nachbarschaftsbeziehungen der Knoten begründet, die mit der Entfernung der
Nachbarn abnimmt. Die Knoten auf dem Ring sind durch Nachbarschaftsbeziehungen
miteinander verbunden. Jeder Knoten hat mehrere Nachfolger und einen Vorgänger.
Routing
In [SMK+ 01] werden zwei Routingverfahren vorgestellt, das einfache Routing und das
skalierbare Routing. In der einfachen Variante wird eine Nachricht immer an den ersten bzw. einzigen Nachfolger auf dem Ring weitergeleitet. Die Laufzeit des einfachen
Routing ist daher proportional zu Knotenanzahl und bringt keine Vorteile gegenüber
Verfahren der ersten Generation. In der zweiten Variante, dem skalierbaren Routing,
besitzt jeder Knoten eine sog. Finger-Tabelle, die Auskunft über die Nachbarschaft
gibt. Eine Finger-Tabelle enthält m Nachbarschaftseinträge, die die Nachfolgeknoten
auf dem Ring beinhalten. Die Entfernung der Nachbarn auf dem Ring nimmt exponentiell zu, um einen größeren Folgebereich zu adressieren. Somit ist der i-te Eintrag
der Finger-Tabelle der 2i−1 Nachbar auf dem Ring in Uhrzeigerrichtung. Neben der
Fingertabelle besitzt jeder Knoten noch einen Zeiger auf seinen Vorgängerknoten.
Im Folgenden werden der Aufbau und die Basisfunktionen des Chord-Protokolls
anhand eines durchgängigen Beispiels erklärt. Zu den Basisoperationen der DHTVerfahren zählen das Betreten, das Verlassen und das Suchen.
Gegeben sei ein Präsenzsystem mit einer maximalen Aufnahme von acht Knoten. Somit wird m=3 gewählt und es entsteht ein Ring mit anfangs acht leeren Plätzen. Zum
34
3.3. Verfahren der 2.ten Generation
Zeitpunkt tx ergibt sich die in Abb. 3.2 gezeigte Situation mit der Fingertabelle des
Knotens 192.168.0.17. Als Knoten-Hashfunktion wird eine xmod8-Funktion verwenKnoten 192.168.0.6
Knoten 192.168.0.17
0
1
Start Inter- Nachvall
folger
=
5
7
+1
2
2²
6
5
3
4
2
3
5
[2,3)
[3,5)
2
4
[5,1)
6
Finger-Tabelle
Knoten 192.168.0.12
Bild 3.2.. Chord-Ring mit drei Knoten und m=3
det, die nur den Teil des Subnetzes (Klasse C) betrachtet. In der Fingertabelle des
Knotens 192.168.0.17 sind, gemäss der Größe des Ringes(2m ), drei Einträge enthalten,
die den 20 , 21 und 22 Nachfolger enthalten. Zusätzlich hierzu wird ein Intervall für
jeden Eintrag angegeben, der je nach Auftreten i 2i Knoten enthält. Weiterhin wird
der Nachfolger noch notiert. Das Intervall gibt Auskunft darüber, welche Knoten der
i-te Eintrag wiederum kennt. Somit ist also der komplette Ring adressierbar(m=3:
2i−1 + 2i−1 ). Als Vorgänger wird der Knoten 192.168.0.6 gespeichert, da er für den
Platz 0 auf dem Ring zuständig ist.
Da Ressourcen ebenfalls durch eine Hashfunktion auf den Ring abgebildet werden,
gehen wir nun davon aus, dass für eine Ressource R1 der Wert 7 berechnet wurde.
Die Verwaltung der Ressourcenschlüssel verläuft gegen den Uhrzeigersinn und somit
wird dieser Schlüssel von Knoten 192.168.0.17 verwaltet (siehe Abb.3.3). Falls nun
nach dieser Ressource gesucht wird, kann der Wert und somit der Knoten berechnet
werden. Angenommen, der Knoten 192.168.0.12 sucht diese Ressource (Knoten 7), so
wird durch den dritten Intervalleintrag in der Finger-Tabelle festgestellt, dass Knoten
0 Informationen über den Knoten 1 hat. Es wird die Nachricht also an Knoten 0
weitergeleitet, der letztendlich durch den ersten Eintrag seiner Finger-Tabelle die
Nachricht an Knoten 1 weiterleiten kann. Dieser tritt abschließend direkt mit dem
fragenden Knoten in Kontakt.
35
3. Such- und Routingverfahren
Knoten 192.168.0.6
Knoten 192.168.0.17
R1
0
1
=
5
7
+1
2
2²
6
5
3
4
Finger-Tabelle
Start
Knoten 192.168.0.12
5
6
0
Inter- Nachvall
folger
[5,6)
6
[6,0)
6
[0,3)
1
Bild 3.3.. Aufbau des Chord-Ringes wie in Abb. 3.2. Knoten 192.168.0.12 sucht
Ressource R1, die von Knoten 192.168.0.17 verwaltet wird. Verweis über dritten
Eintrag der gezeigten Fingertabelle.
Topologie
Das Ein- und Austreten neuer Knoten in das System basiert auf den gleichen Schritten, die für das Suchen einer Ressource notwendig sind. Wenn ein neuer Knoten
das System betritt, wird seine Position im Ring berechnet und der Teil der FingerTabelle des vorangehenden Knotens übernommen und entsprechend der Position in
der Finger-Tabelle abgeändert. Dieser Knoten verwaltet nun einen Teilbereich des
Vorangegangenen, der hingegen einen Verwaltungsbereich abgibt. Der entsprechende
Vorgang tritt beim ordnungsgemässen Verlassen des Systems ein. Der vorherige Knoten übernimmt einen Teil der Fingertabelle und erweitert seinen Verwaltungsbereich.
Um dem unbeabsichtigen bzw. fehlerhaften Austreten vorzubeugen, versendet jeder
Knoten in regelmäßigen Abständen Ping-Anfragen an seinen Nachfolger und handelt
entsprechend.
Bewertung
Chord zeichnet sich wie alle bestehenden DHT-Verfahren durch eine gute Lastverteilung aus, da diese den Hashfunktionen zugrunde liegt. Eine weitere Stärke ist die
Skalierbarkeit, da die Routingkosten bei Zunahme der zu verwaltenden Knoten logarithmisch ansteigen. Dies wird durch die Anzahl der zu versendenden Nachrichten
bei der Suche und dem Einfügen gewährleistet. Die Komplexität der Suche beträgt
36
3.3. Verfahren der 2.ten Generation
O(log N ) und die des Betretens und Verlassens O(log N 2 ). Da gleiche Ressourcen von
demselben Knoten verwaltet werden, ergibt sich theoretisch eine maximale Trefferquote. Die Hashfunktion muss jedoch so konzipiert sein, dass der Hashschlüssel gleichen
Ressourcen auch dieselben Werte zuweist. Eine ungeeignete Hashfunktion könnte anhand des Namens einer Ressource einen Hashwert vergeben und würde sich somit
vom gesuchten Inhalt loslösen. Da mittels Hashfunktionen nur sog. Punktsuchen vollzogen werden können, ist es schwierig, nach einer Menge von ähnlichen Ressourcen zu
suchen. Ungenaue Suchanfragen werden daher in der Regel keine zufriedenstellenden
Ergebnisse liefern.
Erweiterungen
Da Chord eines der ersten DHT-Verfahren darstellt, existieren verschiedene weitergehende Ansätze, die bestimmte Eigenschaften herausstellen und diese erweitern. Einige
dieser Ansätze werden nun vorgestellt.
Dabek u.a. reduzieren in [DLS+ 04] die Zeit für das Finden von Knoten um die Hälfte unter der Annahme, dass alle Knoten im Netzwerk miteinander kooperieren und
die durchschnittliche Routingkomplexität O(log N) ist. Bisher wurde bei der Suche
nach einem Knoten in Chord iterativ vorgegangen, d.h. die Einträge in der Fingertabelle eines Knoten werden durchlaufen und jeweils eine Rückmeldung gegeben. Die
Erweiterung sieht hier eine rekursive Form der Weiterleitung vor, indem angesprochene Knoten wiederum in ihrer Fingertabelle die passenden Einträge suchen und die
Nachricht weiterleiten. Der letztendlich gefundene Knoten tritt dann direkt mit dem
Initiator in Verbindung.
Gummadi u.a. gehen in [GGG+ 03] der Frage nach, in wieweit sich DHT‘s an die
darunter liegende Internet-Topologie anpassen lassen, um die Latenzzeiten zu minimieren. Hierbei werden die Routingeinträge hinsichtlich ihrer Round-Trip-Time
(RTT)11 optimiert (Proximity Neighbor Selection). Aus einer Nachbarschaftsmenge
wird anschließend der Knoten mit der geringsten RTT ausgewählt (Proximity Route
Selection).
Koorde Karger und Kaashoek [KK03] erarbeiteten ein Netzwerk, namens Koorde,
das einen geringeren Ausgrad als bei Chord gewährleistet. Der Grad misst die eingehenden (Eingrad) und ausgehenden (Ausgrad) Verweise eines Knotens. Somit können
11
Round-Trip-Time ist die Zeit, die benötigt wird, eine Nachricht zu einem Peer zu schicken und
die Antwort zu erhalten.
37
3. Such- und Routingverfahren
bei einem Grad g und d Schritten genau g d Knoten erreicht werden. Die Autoren ermöglichen durch Koorde den logarithmischen Grad bei logarithmischem Durchmesser,
den Chord bietet, zu reduzieren. Durch eine Kombination von einem Ring-Graphen,
wie in Chord verwendet, und einem DeBrujin-Graphen wird konstanter Grad ermöglicht. Ein DeBruijn-Graph12 hat einen Grad von 2 bei einem Durchmesser log(n).
In einem Koorde-Netzwerk besitzt jeder Knoten vier Zeiger, zwei DeBrujin-Kanten
und jeweils einen Vorgänger und Nachfolger auf der Ring-Topologie. Die Komplexität
der Suche und der Topologieänderungen, sowie der Durchmesser entsprechen denen
bei Chord. Lediglich der Ausgrad, d.h. die ausgehenden Verweise eines Knotens sind
konstant vier.
miChord Kathryn Chen, Loai Naamani und Karim Yehia [CNY03] definieren Metriken, anhand derer entschieden werden kann, wo eine Ressource abzulegen ist. Die
Suche danach bleibt hiervon unberührt. Sie geschieht nach dem beschriebenen Verfahren in Chord. Lediglich der die Ressource verwaltende Knoten besitzt einen Verweis
auf die Ressource, die sich irgendwo im Netzwerk befinden kann. Knoten verwenden
Metriken, um sich für Ressourcen bestimmter Art zu ”bewerben”. Die Metriken sind
dynamisch und können von einer Anwendungsschicht beeinflusst werden. Diese hat
damit Einfluss auf die kriterienspezifische Platzierung von Ressourcen. Eine Lastverteilung könnte somit beeinflusst werden.
TaChord - topology-aware Chord system with super-peers TaChord zeigt Ansätze zur Unterstützung topologischer Aspekte bei der Suche und dem Weiterleiten
von Nachrichten. Außerdem setzen die Autoren von [DSX04] auf den Einsatz von
Super-Peers aus den in Abschnitt 2.2 beschriebenen Gründen.
Optimierungen basieren auf zusätzlichen Speicherstrukturen der einzelnen Knoten.
Neben einer Fingertabelle verwenden Knoten eine Routingtabelle, die physikalisch
benachbarte Knotenadressen bereitstellt. Super-Knoten verfügen zudem über die Informationen über ihre Cluster und einen Cache, der vergangene Suchanfragen enthält.
Die Verwendung einer Routingtabelle verringert die Latenzzeit durch Bezugnahme
auf die physikalische Entfernung eines Knotens und der Cache dient der Effizienzsteigerung durch Direktverweise.
Sucht nun ein Knoten eine Ressource und den damit verbundenen Zielknoten, so
wird durch die Fingertabelle der Nachfolger bestimmt. Weiterhin wird mittels der
Routingtabelle ein naheliegender Knoten gesucht, dessen Bezeichner in der Nähe des
Zielknotens liegt. Falls ein Super-Knoten kontaktiert wird, so existieren noch die Möglichkeiten der Überprüfung der Cacheeinträge und der Knotenbezeichner des Clusters.
12
Ein n dimensionaler de Bruijn-Graph zur Basis 2 besteht aus 2n Knoten und 2( n + 1) Kanten.
38
3.3. Verfahren der 2.ten Generation
Die Entfernung der potentiellen Kontaktknoten zum Zielknoten ist schließlich ausschlaggebend für die Wahl. Weiterhin wird gezeigt, dass eine redundante Haltung
von Super-Peers durch unterschiedliche Cacheeinträge Effizienzvorteile hinsichtlich
der Weiterleitung hervorbringt. Wartung und topologische Veränderungen werden
nicht berücksichtigt.
Mizrak u.a. stellen ein Verfahren vor, dass sich die Heterogenität der Knoten zunutze macht und damit Suchanfragen in konstanter Zeit ermöglicht [MCKS03]. In dem
gemischten Ansatz werden einfache Knoten von Super-Knoten getrennt. Alle Knoten
und Ressourcen werden mittels verteilter Hashtabellen auf einem Ring platziert, wobei einfache Knoten einem großen äußeren Ring zugeordnet und Super-Knoten einem
kleineren inneren Ring zugewiesen werden. Jeder Knoten des inneren Ringes ist für
einen Bereich des äußeren zuständig, das den in 2.2 vorgestellten Clustern entspricht.
Statt einer Fingertabelle benötigen die einfachen Knoten lediglich die Adresse ihres Super-Knotens. Abbildung 3.4 veranschaulicht den Aufbau und die Route einer
Suchanfrage. Ein suchender Knoten schickt die Anfrage an seinen Super-Knoten, der
anhand des Bezeichners des Zielknotens den zuständigen Super-Knoten kontaktiert.
Dieser übermittelt daraufhin die Adresse des Zielknotens direkt an den Suchenden.
Die Kosten einer Suchanfrage sind konstant, da im schlechtesten Fall zwei SuperKnoten kontaktiert werden müssen.
Bild 3.4.. Systemarchitektur nach Mizrak et. al.
39
3. Such- und Routingverfahren
Symphony [MBR03] wurde durch das Modell einer ”kleinen Welt”13 von Kleinberg
[Kle00] inspiriert. Das Modell besteht aus einem zwei-dimensionalen Gitter, in dem
jeder Knoten vier Verweise auf seine direkten Nachbarn pflegt und zusätzlich auf einen
entfernten Knoten verweist, der zufällig gewählt wird. Eine Nachricht kann hierbei
in O(log 2 n) Schritten an jeden Knoten versendet werden. Dieses Prinzip wurde in
Symphony auf ein ring-förmiges DHT-Protokoll erweitert.
Coral Coral [FM03] ist ein DHT-Vertreter mit einem Unterschied in der Zuweisung
von Schlüsseln zu Objekten. Während in DHT‘s injektive Abbildungen von Objekten
zu Schlüsseln entstehen, können in DSHT‘s Schlüssel auf mehrere Objekte verweisen
(Distributed Sloppy Hash Table - DSHT).
Naheliegende Knoten werden in Clustern gruppiert. Eine Hierarchie aus drei Ebenen
beschreibt die Granularität der Entfernung (Region, Kontinent und Welt). Folgende
Ebenen existieren:
1. Ebene bestehend aus mehreren Clustern, die Regionen darstellen, mit Durchmesser von 30 Millisekunden
2. Ebene bestehend aus mehreren Clustern, die Kontinente darstellen, mit Durchmesser von 100 Millisekunden
3. Ebene bestehend aus einem Cluster, das allumfassend ist, mit unendlichem
Durchmesser
Jedes Cluster stellt einen Chord-Ring dar. Der Einsatz von DSHT‘s erlaubt das Auftreten eines Knoten mit gleichem Schlüssel in genau einem Cluster jeder Ebene, so
dass Lokalitätsbeziehungen angestellt werden können. Über die Allgemeinheit wird
die Suche in einem Kontinent bis schließlich in einer Region verfeinert.
Hieras [XMH03], ein DHT-Vertreter, verfolgt ein ähnliches Prinzip wie Coral mit
dem Unterschied, dass ausgehend von der aktuellen Region die Suche auf den Kontinent und schließlich auf die Allgemeinheit erweitert wird. Zu beachten ist hierbei, dass
in der Ausgangsebene mehrere Chordringe parallel existieren und somit der anfangs
befragte Ring wesentlich kleiner ist als beim umgekehrten Verfahren Coral. Weiterhin
werden Cluster nicht mittels Entfernungen eingeteilt, die durch die Latenzzeit einer
Antwort entstehen.
13
Das Phänomen der kleinen Welt (eng. small world) wurde von Milgram erstmals beschrieben und
wird hier nicht näher betrachtet. Weiteres dazu unter [Mil67]
40
3.3. Verfahren der 2.ten Generation
3.3.2. CAN
Das Konzept des Scalable Content-Addressable Network (CAN) wurde von [RFH+ 01]
am AT&T Center for Internet Research at ICSI (ACIRI) 14 2001 entworfen. Es werden wie bei Chord Hashfunktionen zur Abbildung von Knoten und Ressourcen verwendet, jedoch basiert es auf einem geometrischen Ansatz. Der Wertebereich dieser
Abbildung stellt ein d-dimensionales Kartesisches Koordinatensystem dar, in dem
die Punkte abgebildet werden. Ein Punkt repräsentiert einen Knoten des Systems
und wird in CAN mittels eines d-dimensionalen Bereiches abgebildet. Ähnlich dem
Verfahren eines k-d-Suchbaumes [Ben75] erhält jeder Knoten eine Zone zugewiesen,
der den generierten Hashkoordinaten entspricht. Der Wertebereich ist zu jedem Zeitpunkt komplett durch existierende Knoten verwaltet. Jeder Knoten hat somit 2*d
(Dimension) Nachbarn. Das Einfügen neuer Knoten verursacht immer eine Teilung
bestehender Zonen, wodurch ein hierarchischer Suchraum entsteht (siehe Abb. 3.5a).
0/1
1/1
0/1
1/1
K3
K3
K2
K2
K4
K4
K1
K1
0/0
1/0
K1
K5
1/0
K1
K2
K3
0/0
K4
K2
K3
K4
K5
Bild 3.5.. a) Aufbau eines CAN bestehend aus vier Knoten b) Hinzufügen von
Knoten K5
Routing
Um in einem CAN nach Ressourcen zu suchen, ist es notwendig, einen beliebigen
bestehenden Knoten zu kennen, von dem aus die Suchanfrage weitergeroutet wird.
14
http://www.icsi.berkeley.edu/index.html
41
3. Such- und Routingverfahren
Anhand der gesuchten Koordinaten kann ein bestehender Knoten die Suchanfrage
zielgerichtet an einen seiner Nachbarn weiterleiten, der wiederum nach dem gleichen
Prinzip verfährt, bis letztendlich der gesuchte Knoten gefunden ist. Die richtige Richtung und somit der entsprechende Nachbar kann mittels einfacher Vektorberechnung
der eigenen und gesuchten Koordinaten ermittelt werden.
Topologie
Das Eintreten eines neuen Knotens geschieht auf die gleiche Art und Weise. Die
Hashwerte des neuen Knotens werden berechnet und der bisherige Knoten gesucht,
der für die Verwaltung des Punktes zuständig ist. Wenn dieser Knoten gefunden
wurde, wird der von ihm verwaltete Bereich in zwei gleich große Teilbereiche unterteilt.
Die Änderungen bzgl. der Nachbarschaft müssen in angrenzenden Knoten aktualisiert
werden (siehe Abb.3.5b).
Das Verlassen bewirkt die Freigabe der zugehörigen Zone. Es tritt eine Verschmelzung
zweier Bereiche ein, wobei der Nachbar mit dem bisher kleinsten Zuständigkeitsbereich den nun nicht mehr zugewiesenen überschrieben bekommt. Um auch das unbeabsichtigte Entfernen eines Knotens zu registrieren, wird die Anwesenheit der Nachbarn
in regelmässigen Abständen überprüft und entsprechend gehandelt. Da nicht in allen Fällen eine Verschmelzung zweier Bereiche möglich ist, kann es u.U. vorkommen,
dass mehrere angrenzende, jedoch unzusammenhängende Bereiche verwaltet werden
müssen. In Abb. 3.5b) kann nach Austreten des Knotens K3 die hinterlassene Zone
nicht mit einer Angrenzenden verschmolzen werden.
Bewertung
Die beschriebene Architektur zeichnet sich insbesondere durch Selbstorganisation,
Skalierbarkeit und Fehlertoleranz aus. Knoten werden mit Hilfe von Hashfunktionen und Nachbarschaftsinformationen im multidimensionalen Raum positioniert. Die
Komplexität der Verwaltung von Routinginformationen ist proportional zur Dimensionierung, da jeder Knoten genau 2*d Nachbarn hat. Mit steigender Anzahl an Knoten werden demnach im Einzelfall nicht mehr Routinginformationen gespeichert. Die
mittlere Pfadlänge eines Routingvorganges steigt hierbei jedoch mit der Komplexität
O(n1/d ), da die Hierarchietiefe ausgeweitet wird. Um die Konsistenz der Nachbarschaftsinformationen zu erhalten, wird in regelmässigen Abständen die Nachbarschaft
überprüft, so dass das System fehlertolerant gegenüber unvermitteltem Austreten ist.
Wie auch bei Chord können jedoch keine ungenauen Suchanfragen effizient beantwortet werden.
42
3.3. Verfahren der 2.ten Generation
Erweiterungen
In [RFH+ 01] werden neben der Beschreibung des einfachen CAN noch Erweiterungsvorschläge, wie Änderungen der Dimensionen und Einführung sogenannter Realitäten,
beschrieben. Darauf bezogene Erweiterungen entstammen nicht den ursprünglichen
Autoren des CAN.
Dimensionen Da die mittlere Pfadlänge beim Routingvorgang von der Anzahl der
Knoten und der Anzahl der Dimensionen abhängig ist, kann diese durch Hinzunahme
von weiteren Dimensionen verringert werden. Jedoch erhöht sich somit auch die Anzahl der Routinginformaionen, die jeder Knoten in den Routingtabllen beinhaltet, da
die Nachbarschaftsmenge ebenfalls proportional zur Anzahl der Dimensionen ist. Ein
weiterer Vorteil ist die Steigerung der Fehlertoleranz, da die Anzahl der Routingwege
sich erhöht.
Realitäten Ein zweiter Vorschlag behandelt die Einführung von Realitäten, die jeweils unabhängige Koordinatensysteme mit verschiedener Aufteilung darstellen. Somit ist jeder Knoten für eine Zone pro Realität verantwortlich. Mit diesem Ansatz
verkürzt sich die Pfadlänge einer Nachricht und steigert die Fehlertoleranz auf Kosten
der Verwaltung mehrerer Routingtabellen.
Zusätzliche Informationen der benachbarten Knoten bzgl. der Netzwerkanbindung
können das Routing von Nachrichten performanter gestalten. Wenn jeder Knoten
die Round-Trip-Time (RTT) seiner Nachbarn in regelmässigen Abständen misst, so
kann das Weiterleiten einer Nachricht beschleunigt werden, indem bei Alternativen
der Nachbar mit der niedrigeren RTT gewählt wird.
eCAN - expressway content-adressable network Xu und Xang [XZ02] steigern die
Routingperfomanz auf O(logN ), indem sie den kompletten Wertebereich auf verschiedenen Ebenen unterschiedlicher Granularitätsstufen abbilden. Jeder Knoten besitzt
pro Ebene vier Nachbarn. Ausgehend von dem ursprünglichen CAN besitzt ein Knoten vier direkte Nachbarn (1 Ebene). Diese vier Nachbarn können wiederum als ein
zusammenhängender Bereich angesehen werden, der bis zu vier Nachbarn besitzt. Die
dritte Ebene wird gleichermaßen erstellt.
Somit wird eine Hierarchie auf das Koordinatensystem abgebildet, die direkte Sprünge zu entfernteren Zellen durch unterschiedliche Ebenen ermöglicht (expressway,
Schnellstraße). Die hierarchische Einteilung ermöglicht ein logarithmisches Routing,
jedoch auf Kosten ansteigender Verwaltung der Routingtabellen.
43
3. Such- und Routingverfahren
pSearch Eine Verknüpfung des eCAN mit Methoden des Information Retrieval (IR),
speziell Bewertungsverfahren, wurde in pSearch [TXM03] beschrieben, auf die jedoch
an dieser Stelle lediglich verwiesen wird.
3.3.3. Tapestry
Die Routinginfrastruktur Tapestry wurde von [ZKJ01] an der Universität von Kalifornien entwickelt. Basierend auf der verteilten Suchtechnik von Plaxton, Rajamaran
und Richa [PRR97], die auf einem statischen Netzwerk beruht, wurden einige Erweiterungen entwickelt, wie die Unterstützung von dynamischen Netzwerkstrukturen, die
für P2P-Systeme unerlässlich sind. Die Unterstützung von Ortsinformationen stellt
einen wesentlichen Unterschied zu Chord (siehe 3.3.1) und CAN (siehe 3.3.2) dar. Mittels dieser Informationen können Latenzzeiten bzgl. der darunterliegenden Topologie
berücksichtigt werden.
Ähnlich den vorangegangenen Verfahren werden Knoten und Ressourcen durch ID‘s
repräsentiert, die aus einem Wertebereich durch eine Hashfunktion abgebildet werden.
Routinginformationen liegen den einzelnen Knoten in Form von Nachbarschaftslisten
(Neighbor Map) vor. Diese Listen stellen eine n×m-Matrix dar, in der die Anzahl der
Zeilen der Zahlenbasis und die Spaltenanzahl den Ziffern der ID‘s entspricht. Nachbarschaftsgrade werden durch Übereinstimmung von Ziffernfolgen in den Knoten-ID‘s
bestimmt. Somit hat die Nachbarschaftsliste in einem Tapestry-Netzwerk, in dem
10.000 Knoten verwaltet werden können, die als Zahl zur Basis 10 dargestellt werden,
genau zehn Zeilen und vier Spalten (siehe Abb. 3.6). In den Spalten (j∈0..m) werden Lokalisierungsinformationen derart abgespeichert, dass jeweils j Ziffern mit der
eigenen Knoten-ID übereinstimmen. Daher werden zunehmend Informationen über
die eigene Nachbarschaft gespeichert. Zusätzlich enthält jeder Knoten eine Liste von
ihn referenzierenden Knoten (sog. Backpointer), die der Aktualisierung von Nachbarschaftslisten dienen.
Routing
Nachrichten werden anhand der Nachbarschaftsliste an den numerisch naheliegendsten Knoten weitergeleitet. Da nicht für jeden Eintrag in der Liste ein Knoten existieren muss, können Nachrichten somit nicht eindeutig weitergeleitet werden. Das
Surrogate Routing beseitigt dieses Problem, indem dann der Knoten verwendet wird,
der in den signifikaten Ziffern eine maximale Übereinstimmung enthält. Der Zielknoten wird hierbei durch maximal O(log N) Zwischenstationen gefunden.
44
3.3. Verfahren der 2.ten Generation
Max. Knoten = 10.000
i=
0
1
Basis = 10
2
3
4
5
6
7
8
9
j=0
0xxx
1xxx
2xxx
3xxx
4xxx
5xxx
6xxx
7xxx
8xxx
9xxx
1
2
3
40xx
41xx
42xx
43xx
44xx
45xx
46xx
47xx
48xx
49xx
450x
451x
452x
453x
454x
455x
456x
457x
458x
459x
4560
4561
4562
4563
4564
4565
4566
4567
4568
4569
Bild 3.6.. Nachbarschaftsliste des Knotens mit der ID=4567
Topologie
Ein eintretender Knoten generiert seine Knoten-ID und verschickt eine Nachricht an
genau diesen Knoten, der bisher nicht existierte. Diese Nachricht wird mittels Surrogate Routing an einen numerisch nahen bestehenden Knoten weitergeleitet, von dem
die Nachbarschaftsliste kopiert wird. Der bestehende und der eintretende Knoten passen daraufhin ihre Nachbarschaftslisten an. Über Backpointer können Referenzen gefunden werden, die eventuell nun wegen neuer Nachbarschaftsverhältnisse angepasst
werden. Das Verlassen des Systems geschieht ebenfalls über die Benachrichtigung der
Backpointer. Die Konsistenz der Topologie wird durch regelmässiges Überprüfen der
referenzierten Knoten gewahrt.
Bewertung
Die Komplexität der Suche nach bestehenden Knoten ist mit den vorangegangen
Verfahren zu vergleichen und liegt bei O(log N). Der Umfang der Nachbarschaftsinformationen hängt lediglich von der Zahlenbasis der ID‘s und der maximalen Knotenanzahl ab und bleibt somit konstant. Das System besitzt hiermit jedoch eine statische
Obergrenze.
45
3. Such- und Routingverfahren
Systeme mit starken Topologieschwankungen verursachen eine hohe Anzahl an Nachrichten zur Pflege der Nachbarschaftsbeziehungen und sind damit nur bedingt geeignet. Der große Vorteil zu Chord und CAN liegt in der Unterstützung von topologischen Eigenschaften. Die Einbeziehung von Lokalitätsinformationen verringert die
Anzahl an physikalischen Hops, da diese zunehmend den logischen entsprechen.
Erweiterungen
brocade Die Erweiterung des Tapestry-Netzwerkes von Zhao u.a [ZDH+ 02] sieht
eine zusätzliche Overlay-Ebene vor. Knoten in dieser Ebene werden Landmarken
(Super-Knoten) genannt. Sie sind untereinander verbunden und zeichnen sich durch
hohe Bandbreite, Rechenleistung und Ressourcenanzahl aus. Super-Knoten verwalten
eine sog. cover set von hierarisch untergeordneten Knoten. Die Verbindung zwischen
den Super-Knoten geschieht auf einem zusätzlichen Overlay. Da Super-Knoten angesichts der natürlichen Netzwerktopologie als Gateways angesehen werden können, verwenden die Autoren folgende Kommunikationsarten. Es wird zwischen interdomainund intradomain-Routing unterschieden. Die intradomain-Verbindungen beziehen
sich auf Kommunikation innerhalb eines cover set‘s, die interdomain-Verbindung auf
die Verbindungen zwischen den Super-Knoten.
Knoten, die eine Suchanfrage erhalten, können auf drei vorgestellten Wegen einen
Super-Knoten kontaktieren.
Naiver Ansatz Nachrichten werden, wie in Tapestry vorgesehen versendet und falls
diese zukünftig einen Super-Knoten kontaktieren, kann dieser sie auf dem neu
erzeugten Overlay weiterrouten (interdomain).
Indirekter Ansatz Alle IP-Pakete werden von den Super-Knoten mitgelesen und anhand der Tapestry spezifischen Informationen des IP-Paketes kann eine Nachricht zum interdomain-Versand ausgewählt werden.
Direkter Ansatz Zuständige Super-Knoten müssen den Knoten der cover-set‘s bekannt sein und gepflegt werden. Über einen Verlauf von bisherigen Nachrichten
kann jeder Knoten entscheiden, in welchem Overlay die Nachricht weitergeleitet werden soll. Falls eine derartige Suchanfrage temporär gespeichert wurde,
so kann sie auf dieselbe Art weitergeleitet werden. Ansonsten wird sie an den
Super-Knoten delegiert.
Die Autoren favorisieren durch eine Evaluation den dritten Ansatz.
46
3.3. Verfahren der 2.ten Generation
3.3.4. AGILE - Adaptive, Group-of-Interest-based Lookup Engine
AGILE wurde von Jan Mischke und Burkhard Stiller an der ETH Zürich entwickelt und in [MS03a] beschrieben. Es wird ein Overlay-Netzwerk erstellt, das eine
gruppen-basierte Suche ermöglicht. Gruppen werden hier als Group-of-Interest (GoI)
beschrieben.
Durch eine Hashfunktion werden Ressourcen und Knoten wie in bisherigen DHTVerfahren auf denselben Wertebereich abgebildet. Knoten werden in Requester (Klient) und Provider (Server) je nach aktueller Funktion eingeteilt. Ein Provider-Knoten
ist derjenige, dessen Knoten-ID am nahesten an der gesuchten Ressourcen-ID liegt.
Dieser verwaltet die Ressource, wie in Abschnitt 3.3.1 beschrieben. Ressourcen und
Knoten werden in Gruppen eingeteilt, indem der Schlüssel ziffernweise interpretiert
wird. So können die ersten Ziffern eine grobe Kategorie beschreiben und die darauffolgenden diese verfeinern. Es entsteht somit eine zusätzliche Hierarchie über dem
ID-Raum, die eine Granularität verdeutlichen kann.
Als Beispiel soll das in [MS03a] Vorgestellte verwendet werden. Anlässlich der starken Verbreitung von Musikdateien durch P2P-Systeme werden drei Hierarchien aufgestellt, der Medien-Typ, das Musikgenre und der Musiktitel (siehe Abb. 3.7a). Jeder
der drei Hierachien besitzt eine Hashfunktion zur Abbildung auf einen eindeutigen
Schlüssel. Die Such-ID setzt sich dann aus den drei Schlüsseln der Hierarchien zusammen. Der Wertebereich umfasst in AGILE 128 bit, wobei Medientyp und Musikgenre
einen 32 bit ID-Raum und der Musiktitel einen 64-bit ID-Raum adressieren können.
Eine Suchanfrage könnte also wie folgt aussehen : 12345678.12345678.12345678ADBCDEF.
Die Suche geschieht ziffernweise ähnlich wie bei Tapestry (siehe Abschnitt 3.3.3).
In einer Routingtabelle (siehe Abb. 3.7b) wird erst der richtige Medientyp ausfindig
gemacht, dann in einer weiteren Routingtabelle das Musikgenre und schließlich in der
letzten Routingtabelle der Musiktitel. Eine gewisse Fehlertoleranz ergibt sich durch
die erhöhte Anzahl der Routingtabellen, da jede eigenständig sinnvolle Suchergebnisse
liefern kann und nicht notwendigerweise alle herangezogen werden müssen.
Das Betreten und Verlassen bewirkt wie in vorangegangenen Verfahren eine Suche
des Knotens im ID-Raum mit anschließender Aktualisierung der Routingtabellen aller
Nachbarn.
Knoten, die mehreren Gruppen angehören, haben dementsprechend mehr Verwaltungsaufwand, da sich ihre Routingtabellen vergrößern bzw. vervielfachen.
3.3.5. SHARK - Symmetric Hierarchy Adaption for Routing of Keywords
SHARK wurde ebenfalls von den Autoren Jan Mischke und Burkhard Stiller entwickelt und basiert auf dem vorherigen Ansatz. Ein wesentlicher Unterschied ist die
47
3. Such- und Routingverfahren
Bild 3.7.. a)Suchbaum und b)Routing-Tabelle(n) eines Knotens
Differenzierung in mehrere Dimensionen. Neben einer semantischen Dimension, in der
Typ, Genre und Name aggregiert werden können, existiert in dem in [MS03b] vorgestellten Beispiel zusätzlich eine zeitliche Dimension, die sich in Jahr, Monat, Tag
verfeinern lässt. In Abb. 3.8 wird diese Mehrdimensionalierung auf weitere Ebenen
angewandt.
Bild 3.8.. Multidimensionale Hierarchie in SHARK
48
3.3. Verfahren der 2.ten Generation
3.3.6. Kademlia
Kademlia ist ein P2P-System zur Speicherung und Wiederauffindung von Ressourcen
[MM02]. Wie bei Chord (siehe Abschnitt 3.3.1) werden Knoten und Ressourcen auf
einen Wertebereich abgebildet. Knoten verwalten numerisch ähnelnde binäre Schlüssel (oder sogar die dazugehörigen Ressourcen). Jeder Knoten speichert Informationen
über andere Knoten und deren Ressourcen, um eine effizientere Suche zu ermöglichen.
Für jedes Bit des Wertebereiches (160 bit Bezeichner) werden Informationen über andere Knoten gespeichert (k-buckets). Somit existieren 160 Listen mit jeweils maximal
k Einträgen. Da höherwertige Bits eine größere Anzahl an Knoten repräsentieren, werden mehr Informationen über numerisch naheliegende Knoten gespeichert, als über
Entferntere.
Bei einer Suchanfrage wird ein Schlüssel berechnet, der die Lage des Knotens beschreibt, an dem sich die gesuchte Ressource befindet. Die Berechnung dieser Entfernung liegt der XOR-Metrik zugrunde. Zwei Werte werden bitweise verglichen, so
dass bei Übereinstimmung eine 0 und bei Unterscheidung eine 1 für das jeweilige Bit
ensteht. Der entstandene Wert ergibt die numerische Differenz und ist für die Weiterleitung entscheidend. Dieser Vorgang wiederholt sich solange, bis der Zielknoten
erreicht ist.
Durch die Speicherung der k-buckets pro Bit entsteht ein logarithmischer Aufwand
für das Suchen und das Einfügen von Knoten. Der Nachrichtenversand geschieht
asynchron, so dass mehrere Knoten gleichzeitig kontaktiert werden können und die
Geschwindigkeit nur bedingt von der Verarbeitungsgeschwindigkeit einzelner abhängig ist.
Der Kademlia-Algorithmus wird in populären Produkten wie EDonkey2000 und EMule zur serverlosen Suche verwendet[Mon05]. Diese Produkte bieten die serverlose Kademliasuche und eine server-basierte Suche parallel an.
3.3.7. YAPPERS - Yet Another Peer-to-PEeR System
Das Verfahren von Ganesan u.a. [GSGM03] verknüpft die Ansätze des Netzwerkflutens und der verteilten Hashtabellen. Jeder Knoten besitzt eine verteilte Hashtabelle,
wie in Abschnitt 3.3.1 vorgestellt, die die Nachbarschaftsinformationen bis zu einem
festen Grad enthält. Über diese DHT‘s wird die Suche auf das gesamte Netzwerk
angewandt. Der gesamte Wertebereich ist in eine feste Anzahl sog. buckets eingeteilt.
Buckets können Kategorien, Eigenschaften etc. darstellen, die von Knoten verwaltet
werden und Anfragen bzgl. dieser zulassen.
Um das Fluten des Netzwerkes zu unterdrücken, werden Nachbarschaftsinformationen gepflegt. Nachbarn, die innerhalb von h Knotensprüngen (hops) erreicht werden
können, werden in einer Direkten Nachbarschaft zusammengefasst, Knoten mit einem
49
3. Such- und Routingverfahren
Abstand von 2 ∗ h + 1 zu einer Erweiterten Nachbarschaft. Alle Knoten mit einem
Radius von h + 1 werden Grenze genannt. Anfragen, die nicht die direkten Nachbarn
betreffen, werden an eine feste Anzahl an Grenzknoten weitergeleitet, die wiederum
ihre direkten Nachbarschaftsknoten kennen. Die erweiterte Nachbarschaft umfasst
also die direkte Nachbarschaft, die Grenzknoten und dessen direkte Nachbarschaft.
3.3.8. CANDy - (Content Addressable Network DirectorY
Suchverfahren, die allgemein auf verteilten Hashtabellen (DHT) aufbauen, zeichnen
sich durch eine gute Suchperformanz aus, die jedoch nur möglich ist, wenn die Suchanfrage eindeutig spezifiziert wird. Ressourcen und Knoten werden durch Hashfunktionen in Form von numerischen Bezeichnern repräsentiert und können daher nicht für
ungenaue Anfragen herangezogen werden.
Bauer u.a. stellen in [BHPW04] ein Rahmenwerk vor, das die Effizienz der DHT‘s
und die Möglichkeit ungenauer Anfragen verbindet. Ressourcen und Knoten werden,
wie in bisherigen Verfahren, durch eine Hashfunktion abgebildet und entsprechend
zugeordnet. Eigenschaften, die den Ressourcen zugrunde liegen, werden zusätzlich
in Name-Wert Paaren gespeichert, indem eine zweite Hashfunktion den Namen und
zugehörigen Wert auf eine propID abbildet. Eine zusätzliche Datenstruktur regelt
die Beziehung zwischen Name und Wert. So kann ein Name vom Datentyp ’String’
sein und durch eine Menge von Worten beschrieben werden [BHPW04]. Der durch
die zweite Hashfunktion generierte Wert bezeichnet einen Knoten, der alle entsprechenden Bezeichner der Ressourcen kennt, die der Eigenschaft genügen. Über einen
weiteren Schritt wird dann der Knoten mit der gesuchten Ressource gesucht.
Dieses zweistufige Verfahren kann die Anzahl an gefundenen Ressourcen stark erhöhen, falls kaum charakteristische Eigenschaften oder eine Vielzahl an Eigenschaften
untersucht werden. Falls für jede Eigenschaft eine separate Anfrage erstellt wird, können keine logischen Operatoren auf diese Eigenschaften angewandt werden und die
Treffermenge eingrenzen. Um diesen Schwächen entgegenzuwirken, wird die gesamte
Anfrage bei der Suche nach den einzelnen Eigenschaften mitgeschickt. Jeder Knoten,
der ein Teilergebnis (Eigenschaft) erzielt, kann dieses mit den bisherigen Ergebnissen
über logische Mengenoperatoren einschränken. Das zwischenzeitliche Resultat wird
bei weiteren Teilanfragen weitergereicht und erst nach Abschluss der letzten Anfrage
an den ursprünglichen Sender gesandt.
3.3.9. Kelips
In Kelips [GBL+ 03] werden Knoten und Ressourcen durch eine Hashfunktion abgebildet und in Gruppen unterteilt. Die Anzahl der k Gruppen (Affinitätsgruppen) ist
50
3.3. Verfahren der 2.ten Generation
√
proportional mit der Anzahl n bestehender Knoten ( n). Jede Gruppe enthält eine
gleiche Anzahl an Knoten wegen einer konsistenten Hashverteilung.
Ein Knoten besitzt Information über seine Nachbarschaft in Form eines sog. Softstate.
Ein Softstate besteht aus einer Gruppensicht, einer Kontaktliste und indexierten
Daten (Datentupel), die im Folgenden kurz vorgestellt werden:
Gruppensicht Über eine Teilmenge der Knoten, die der eigenen Gruppe angehören,
werden Informationen wie die Round-Trip-Time (RTT)(siehe Abschnitt 3.3.1)
und die Onlinedauer gespeichert.
Kontaktliste Eine feste Anzahl an Knoteninformationen fremder Gruppen ermöglicht die Kontaktierung dieser.
Datentupel Die Datentupel bestehen aus (gruppenübergreifenden) Knotenadressen
und angehörigen Ressourcen, die bei zwischenzeitlicher Kenntnisnahme indexiert werden.
Jeder Eintrag wird periodisch auf Aktualität überprüft. Das Ergebnis wird mittels
eines epidemischen Verbreitungsprotokolls [RMH98] verbreitet, wobei die Round-TripTime als Indikator für die Verbreitung herangezogen wird. Naheliegende Knoten werden bevorzugt, so dass diese weniger Updateanfragen stellen müssen und Netzwerklast vermindern.
Replikate bestehender Ressourcen können die Verfügbarkeit erhöhen, dürfen jedoch
nur in der ursprünglichen Gruppe gespeichert werden.
Die Suche nach einer Ressource mit gegebenen Namen geschieht mit der Zeit- und
Nachrichtenkomplexität O(1). Es wird der Hashwert des gegebenen Namens und somit der Gruppe ermittelt. Der bekannte Knoten dieser Gruppe mit geringster Entfernung (RTT) wird angefragt und liefert über seinen Softstate (Datentupel) die Adresse
eines Knotens mit der gesuchten Ressource.
3.3.10. SkipNet
SkipNet ist ein skalierbares Overlay-Netzwerk, das besonderen Wert auf die Lokalitätseigenschaften der Daten legt. Ressourcen können auf vordefinierten Knoten, wie
auch zur Lastverteilung mittels Hashfunktionen, verteilt gespeichert werden. Statt
das Overlay-Netzwerk mittels DHT‘s zu strukturieren, verfolgen die Autoren von
[HJS+ 03] den Ansatz sog. Skip-Listen [Pug90]. Nach [HJS+ 03] ist eine Skip-Liste
eine sortierte verbundene Liste, in der einige Knoten um Verweise auf entferntere
Knoten erweitert werden.
Die SkipNet-Architektur besteht aus mehreren doppelt verketteten Ringen, die hierarchisch unterteilt werden können. Die Wurzel (Ebene L=0) stellt einen Ring mit
51
3. Such- und Routingverfahren
allen Knoten dar. Nachbarn der Listen der Ebenen L=i haben eine ursprüngliche
Entfernung in der Wurzelliste von 2i . Somit besteht jede Ebene i auch aus genau
2i Ringen. Jeder Knoten verwaltet eine Routingtabelle bezüglich der n bestehenden
Knoten mit 2 ∗ log(n) Einträgen. Diese Tabelle besteht aus allen direkten Nachbarn
aller Ebenen oder anders aus allen linken und rechten Knoten, die 2i Sprünge entfernt sind (i ∈ L). Abbildung 3.9 verdeutlicht den Zusammenhang der Ebenen und
Nachbarschaftbeziehungen. Jeder Knoten erhält neben seinem Namen eine zufällige
binäre eindeutige Darstellung, die in der Abbildung als Ringbezeichner erscheint. Zusätzlich kann der Knoten mit einem eindeutigen Namen versehen werden, wie einer
URL (z.B. name.domain.net). Hiermit existieren zwei Adressräume, der numerische
und Domänen spezifische Adressraum.
Ringbezeichner
000
A
001
B
A
00
010
C
E
D
C
100
011
01
E
G
B
101
F
10
A
G
H
C
111
110
L=3
H
11
D
Ebene
F
L=2
D
E
0
G
B
A
B
C
G
L=1
F
D
E
Wurzel
F
H
1
L=0
H
Bild 3.9.. Hierarchische Darstellung der Routinginformationen jedes im Netzwerk
bestehenden Knotens. Knoten C (dunkelgrau) mit diesen Informationen (hellgrau)
sind hervorgehoben. Ringe sind binär bezeichnet.
Die Suche nach einer bestimmten Ressource kann auf zwei unterschiedlichen Wegen
geschehen, über den binären Bezeichner und über den Namen eines Knotens. Beide
Varianten können nach obigen Prinzip hierarchisch durchsucht werden und benötigen
O(log(n)) Schritte.
Die in den DHT-Verfahren vorgestellten Hashfunktionen garantieren eine Lastverteilung der Knoten in dem Adressraum. Diese Lastverteilung kann in SkipNet innerhalb
von Domänen erreicht werden, indem eine Hashfunktion auf alle Ressourcen innerhalb dieser Domäne angewandt wird. So werden die Lokalitätsinformationen bis zum
Erreichen dieser Domäne bewahrt; innerhalb dieser werden die Daten durch Anwendung einer Hashfunktion auf alle Knoten gleichverteilt.
52
3.4. Verfahren der 3.ten Generation
3.4. Verfahren der 3.ten Generation
Schwerpunkte dieser Generation sind die Fehlertoleranz und Sicherheit. Da es sich
hierbei um ein Randgebiet der Untersuchungen dieser Arbeit handelt, werden lediglich die Ansätze zweier Verfahren vorgestellt.
3.4.1. Viceroy
Viceroy stellt ein P2P-Netzwerk dar, das von Dahlia Malkhi, Moni Naor und David
Ratajczak im Jahre 2001 entwickelt wurde und auf einem Butterfly-Graphen beruht
[MNR02]. Es zeichnet sich durch einen konstanten Ein- und Ausgrad und einen logarithmischen Durchmesser aus. Der Eingrad misst die Verweise auf den Knoten selbst
und der Ausgrad die Verweise auf andere Knoten. Peers werden auf Knoten eines
sogenannten Butterfly-Graphen gelegt.
Der Aufbau von Viceroy ist relativ komplex und wird daher nur im Ansatz beschrieben. Ein in das Netzwerk eintretender Peer erhält eine zufällige Position innerhalb der
bestehenden Ebenen. Alle Peers befinden sich in einem doppelt verketteten Ring, der
den Zusammenhalt gewährt, jedoch nicht zur Suche verwendet wird. Weiterhin besteht pro Ebene eine doppelt verkettete Liste, die die Position im Butterfly-Graphen
bestimmt. Abschließend verweist jeder Peer auf zwei Vorgänger und zwei Nachfolger. Durch das Prinzip der mehrfachen Auswahl einer zufälligen Position auf dem
Butterfly-Graphen wird die Position übernommen, von der aus der linke und rechte
Nachbar annähernd gleich weit entfernt sind.
3.4.2. Distance Halving
Distance Halving [NW03] wurde von Moni Naor (Viceroy) und Udi Wieder 2003 als
Nachfolger von Viceroy vorgeschlagen. Es ist weniger komplex als Viceroy und besitzt
ähnliche Eigenschaften. Der Ein- und Ausgrad ist nahezu konstant, der Durchmesser
und die Suche logarithmisch. Ein kontinuierlicher Graph wird diskretisiert, wobei die
Distanz zweier Knoten hierbei halbiert wird. Auf die Beschreibung der Diskretisierung
wird an dieser Stelle verzichtet, da die zum Verständnis benötigten mathematischen
Grundlagen einer zusätzlichen Erklärung bedürfen.
3.5. Überblick und Auswahl
Die zur Suche sowie zur Weiterleitung von Nachrichten soeben dargestellten Verfahren zeigen neben einer grundsätzlich ähnlichen Intention bezüglich der Performanzbemühungen, starke Unterschiede in ihrer Gestaltung auf. Ein Ziel der in den nächsten Abschnitten angehenden Beschreibung eines Simulators, ist die Schaffung einer
53
3. Such- und Routingverfahren
Grundlage, mittels derer ein Großteil aller beschriebenen Verfahren simuliert werden
kann. Auch angesichts der Komplexität einiger Verfahren kann lediglich diese Basis
geschaffen werden.
Signifikante Unterschiede, die in einer Simulation zu berücksichtigen sind, werden im
anfolgenden Abschnitt aufgezeigt. In der Literatur [LCP+ 04; TR03b; Tso03; RV03]
werden unterschiedliche Bemühungen eingegangen, eine Kategorisierung von Suchund Routingverfahren zu schaffen. Diese Kategorisierungsbemühungen sind bereits
teilweise der Strukturierung des vorangegegangenen Kapitels zu entnehmen, werden
jedoch zusammenfassend noch einmal gegenübergestellt. Das Kapitel endet mit der
Auswahl der in dieser Arbeit zu untersuchenden Verfahren.
3.5.1. Überblick
Der nun folgende grafische Überblick gibt einen Einblick in die zeitliche Entwicklung sowie der Abhängigkeiten der Suchverfahren untereinander. Abbildung 3.10 charakterisiert die Verfahren anhand ihrer ersten Veröffentlichung (horizontal) und der
eingestuften Generation (vertikal). Beziehungen repräsentieren direkte Bezüge, die
in Form einer Weiterentwicklung zu verstehen sind. Weitere indirekte Bezüge sind
zwecks Überschaubarkeit ausgelassen worden.
Viceroy
Kademlia
brocade
Tapestry
Plaxton
Pastry
AGILE SHARK
Kelips
Broose
YAPPERS
SkipNet
CAN
pSearch
Generationen
eCAN
CANDy
miChord
Gummadi
Hieras
Coral
Symphony
Mizrak
Chord
FreeNet
..
1999
Koorde
Random-Walks
DLRP
Local-Indices
Routing-Indices
Fasttrack
Gnutella
1997
Distance Halving
2000
C-BFS
2001
TaChord
Dabek
D-BFS
Ultrapeer/
GUESS
M-BFS
Gia
I-BFS
APS
2002
2003
SUPS
AGNO
2004
2005
Bild 3.10.. Zeitlicher Überblick über die Entstehung der beschriebenen Suchverfahren. Die vertikale Achse zeigt hierbei den Verlauf der Generationen auf. Ursprünge
der Verfahren sind durch Pfeile gekennzeichnet.
54
3.5. Überblick und Auswahl
Um eine spätere Auswahl an zu simulierenden Suchverfahren zu vereinfachen, sind in
der Tabelle 3.1 speziell darauf ausgerichtete Kriterien veranschaulicht, die weiterhin
als Überblick dieses Kapitels dienen. Alle beschriebenen Verfahren lassen sich grob
anhand einiger ausgewählter Eigenschaften charakterisieren. Die Charakterisierung
geschieht teilweise textuell wie auch durch die Verwendung des -Symbols. Zweitere
stellt den Grad der Ausprägung der Eigenschaft dar. Es werden ein bis drei Symbole
hierbei verwendet. Es bestehen häufig Abhängigkeiten zwischen der Komplexität und
der Performanz eines Verfahrens, so dass diese Eigenschaften zusammenfassend zu
betrachten sind. Verweise auf Beschreibungen der Verfahren deuten darauf hin, dass
Erweiterungen existieren, die unterschiedliche Eigenschaften besitzen und somit nicht
einzustufen sind.
In der Tabelle 3.1 wurden folgende Eigenschaften mitaufgenommen:
Architekturstil /Struktur Die Unterscheidung anhand eines Architekturstiles wird
an zwei Kriterien vorgenommen. So werden die in einer Architektur verwendeten Elementtypen zusammenfassend betrachtet (P2P, Super-Peer) und die
topologische Struktur beschrieben. Weitere Eigenschaften eines Architekturstiles werden ausgelassen.
Suchprinzip Das grundlegende Prinzip der Weiterleitung von Nachrichten eines Suchverfahrens wird als Suchprinzip aufgefasst. Aufgrund der jeweiligen spezifischen
Erweiterungen in den Suchverfahren, lässt sich keine detaillierte und übersichtliche Einordnung finden.
Komplexität Verfahren unterscheiden sich in ihrer algorithmischen Komplexität. Dieses Kriterium dient somit als Kriterium, mit welchem Aufwand ein Verfahren
umgesetzt werden kann.
Performanz Die Ziele vieler Verfahren variieren, so dass die Performanz der Verfahren unter Berücksichtung der Ziele zu untersuchen ist. Ziele können hierbei
eine minimierte aggregierte sowie individuelle Netzwerklast, die Trefferquote
von Suchanfragen wie auch die Unterstützung ungenauer Anfragen sein. Die
hier gewählte Einstufung umfasst diese Kriterien. Eine nähere Betrachtung im
Einzelfall ist bei der Auswahl unumgänglich.
55
3. Such- und Routingverfahren
Verfahren/
Architekturstil
SuchKom- Performanz
Algorithmen
Struktur
prinzip
plexität
Gnutella
P2P
zufällig
Fluten
M-BFS
P2P
zufällig
Fluten
I-BFS
P2P
zufällig
Fluten
D-BFS
P2P
zufällig
Fluten
C-BFS
P2P
zufällig
Fluten
Ultrapeer
SP
zufällig
Fluten
GUESS
SP
zufällig
Fluten
Gia
P2P
zufällig
Fluten
3.2.1
3.2.1
FastTrack
SP
zufällig
Fluten
Freenet
P2P
zufällig
Fluten
Random Walks
P2P
zufällig
Fluten
APS
P2P
zufällig
Fluten
3.2.4
3.2.4
Local Indices
P2P
zufällig
Index
Routing Index
P2P
zufällig
Index
3.2.6
3.2.6
DLRP
P2P
zufällig
Fluten
SUPS
SP
zufällig
Fluten
Chord
P2P
Ring
DHT
Koorde
P2P
Ring
DHT
miCHord
P2P
Ring
DHT
TaChord
SP
Ring
DHT
Mizrak
SP
Ring
DHT
Symphonie
P2P
Ring
DHT
Coral
P2P
Ring
DHT
Hieras
P2P
Ring
DHT
CAN
P2P
multi-dim
DHT
eCAN
P2P
multi-dim
DHT
pSearch
P2P
multi-dim
DHT
Tapestry
P2P
Gitter
DHT
brocade
P2P
Gitter
DHT
Pastry
P2P
Gitter
DHT
AGILE
P2P
Hierarchisch
DHT
SHARK
P2P
Hierarchisch
DHT
Kademlia
P2P,SP
XOR
DHT
YAPPERS
P2P
zufällig
DHT, Fluten
CANDy
P2P
zufällig
DHT
Kelips
P2P
Gruppen
DHT
SkipNet
P2P
Listen
DHT
Viceroy
P2P
Butterfly, Ring
DHT
Distance Halving
P2P
DH-Graph
DHT
Tabelle 3.1.. Einordnung der Suchverfahren anhand von Architekturstil, Suchgrundsatz, Komplexität und Performanz.
56
3.5. Überblick und Auswahl
3.5.2. Auswahl der zu simulierenden Verfahren
Die Simulation von Suchverfahren innerhalb dieser Arbeit stellt nur einen Teilbereich
dar. Sie veranschaulicht die Nutzung des entworfenen Simulators. Aufgrund der Komplexität einiger Verfahren wird nun eine Auswahl getroffen. Es werden zwei Verfahren
ausgewählt, die starke Unterschiede aufweisen.
Als erstes Verfahren wird ein einfaches blindes Suchverfahren der ersten Generation
simuliert, das unabhängig von einer Topologie eingesetzt werden kann und ungenaue
Suchanfragen zulässt. Das in Abschnitt 3.2.3 vorgestellte Random-Walks-Verfahren
erfüllt diese Eigenschaften.
Die zweite Wahl fällt auf ein strukturiertes DHT-Suchverfahren der zweiten Generation. Der Chord-basierte Ansatz von Mizrak et. al. (Abschnitt 3.3.1) erscheint als
geeignet, um ein effizienten Suchalgorithmus für Super-Peer-Architekturen zu implementieren.
Die separate Simulation sowie Kombination beider Verfahren wird in Kapitel 7 in
Form von Experimenten beschrieben. Die Kombination soll Suchanfragen mit ungenauen Kriterien erfüllen, die in bisherigen DHT-Verfahren ausgeschlossen wurde.
57
4. Anforderungsdefinition
Die Anforderungsdefinition umfasst neben einer einführenden Beschreibung der Ausgangssituation eine Charakterisierung der zu simulierenden Elementtypen in einer
Rollenanalyse sowie alle gestellten Anforderungen. Auf die Beschreibung von Anwendungsfällen wird verzichtet, da keine Akteure innerhalb der Simulation auftreten.
Diese werden zusammenfassend als textuelle Sucheingabe formuliert.
4.1. Ausgangssituation
Kommunikation ist die Grundlage neuer Wissensaquisitation. Gespräche führen zu
einem Wissensaustausch und ermöglichen somit eine Weiterentwicklung der teilnehmenden Partner. Wissen, das in Form von Informationen angeboten wird, kann jedoch nur über vorhandene Kommunikationsstrukturen weitergegeben werden. Diese
Kommunikationsstrukturen können in unterschiedlichen Formen auftreten, die sich
in dem Grad der Strukturiertheit unterscheiden lassen. In dieser Arbeit soll lediglich
eine dezentrale Struktur untersucht werden. Die Akteure sind gleichberechtigt und
nur während ihrer Anwesenheit ansprechbar.
Jeder Informationsträger ist für die Bereitstellung sowie ’Wartung’ seiner Informationen selbst zuständig. Verbindungen untereinander existieren über unterschiedlichste
Beziehungen. Wie in der Realität der menschlichen Kommunikation können Teilinformationen vielen Quellen entstammen, die häufig in einer bestimmten, teils transitiven,
Relation zur Informationsquelle stehen.
Eine technische Umsetzung dieser Strukturen kann durch eine P2P-Architektur entstehen, in der alle Teilnehmer gleichberechtigt sind und Beziehungen zueinander eingehen können. Peers können Teilinformationen als Metainformationen enthalten und
somit eine indirekte Kommunikation ermöglichen.
Die Suche nach Informationen ist eine notwendige Voraussetzung sowohl zum Wissenserwerb als auch zur Wissenserweiterung und ist daher von entscheidender Bedeutung.
Für eine P2P-Architektur wurden bisher viele Ansätze für mögliche Kommunikationswege und -strukturen entworfen, die unterschiedliche Ziele verfolgen. Um diese
Ansätze miteinander vergleichen zu können, muss eine Basis geschaffen werden, mittels derer ein Vergleich ermöglicht wird. Viele bisherige Simulatoren unterstützen nur
einen Teil der bestehenden Suchverfahren oder sind zu generisch, so dass der Aufwand,
diese zu testen, zu groß ist. Der Zwiespalt zwischen angestrebter Allgemeingültigkeit
58
4.2. Rollenanalyse
und ausreichendem Detaillierungsgrad ist jedoch so groß, dass Einschränkungen hinsichtlich einiger dieser gegensätzlichen Ziele getroffen werden müssen. Eine Einschränkung wird an dieser Stelle im Hinblick auf die Dynamik getroffen, so dass nur ein
fester Zustand des P2P-Systems untersucht wird. Somit entfallen viele Aspekte, die
von anderen Simulatoren ebenfalls modelliert werden müssen. Hierzu zählt das Fehlverhalten, das Ein- und Austreten von Teilnehmern, das sich auf die Verfügbarkeit
der Informationen auswirkt.
Dieser nun vorhandene temporäre Zustand des zu untersuchenden Systems gewährleistet eine vereinfachte Evaluation von Suchverfahren und soll in allen weiteren Beschreibungen als Annahme dienen.
4.2. Rollenanalyse
Die Simulation eines P2P-Netzwerkes wie auch die der organisations-orientierten
Ebene umfasst unterschiedliche Elementtypen, die durch einen Architekturstil definiert werden. Der virtuellen Ebene liegt eine P2P-Architektur oder ein Super-PeerArchitektur zugrunde, die folgende Elementtypen definiert.
Cluster-Peers pflegen eine Nachbarschaft mit übergeordneten Super-Peers. Sie bieten Informationen zum Austausch an(häufig in Form von Ressourcen). Während ihres Daseins können weitergeleitete Nachrichten gespeichert werden, um
spätere Nachrichten effizienter und zielgerichteter weiterzuleiten.
Super-Peers stellen eine besondere Form von Peers dar. Neben den beschrieben Eigenschaften können sie zusätzlich Metadaten über Cluster-Peers speichern. Eine
Nachbarschaft wird zu weiteren Super-Peers eingegangen. Weiterhin besitzen
sie eine Beziehung zu bei ihnen registrierten Cluster-Peers.
Die organisatorische Ebene kann als Anwendungsebene oder semantisches domänenspezifisches Overlay angesehen werden, das sich der virtuellen Ebene als
Kommunikationsplattform bedient. Innerhalb dieser Ebene existieren vier hierarchisch gruppierte Elementtypen, die sich durch nicht-funktionale Eigenschaften wie Verfügbarkeit und Rechenkapazität unterscheiden. Es existieren in der
betrachteten Domäne Organisationen, Projekte, Gruppen und Mitglieder (siehe Abschnitt 2.3). Weitere Domänen werden nicht betrachtet, können jedoch
analog modelliert werden.
59
4. Anforderungsdefinition
4.3. Funktionale Anforderungen
Der Schwerpunkt der zu errichtenden Funktionalität liegt auf der einfachen Entwicklung neuer Suchverfahren. In diesem Zusammenhang sind einige Anforderungen entstanden, die eine weitere Unterstützung während der Entwicklung bieten.
Topologien sowie die element-spezifischen Daten drücken einen temporären Zustand
des Systems aus. Zur Evaluation unterschiedlicher Zustände muss eine Variation
der Größen und der Daten einer Topologie als erneute Eingabe unterstützt
werden.
Suchanfragen unterschiedlicher Komplexität sollen unterstützt werden. Neben eindeutigen sollen daher auch mehrdeutige Suchanfragen als Eingabe verarbeitet
werden.
Simulationsebenen Eine separate Simulation des P2P-Overlays und des domänen
spezifischen Overlays wie auch deren Verknüpfung mittels geeigneter MappingAlgorithmen muss gewährleistet werden.
Suchverfahren sollen möglichst einfach integriert werden. Integrations- wie auch
funktionale Hürden sollen hiermit vermieden werden. Die Basisfunktionalität
der Verfahren soll durch wenige einfache Schnittstellen schnell umzusetzen sein.
Darstellungen der Ergebnisse sollen während der Ausführung wie auch zusammenfassend nach dieser grafisch veranschaulicht werden. Weiterhin ist für den Konsolenbetrieb eine textuelle Auswertung vorgesehen, die dem Servereinsatz dient.
Weiterverarbeitung der gelieferten Rohdaten erhöht die Nutzbarkeit. Die Ausgabe
dieser Daten soll einem standardisierten Format entsprechen, dass zur späteren
Tabellenkalkulation genutzt werden kann.
4.4. Technische Anforderungen
Der zu erstellende Simulator soll folgenden technischen Anforderungen genügen:
Zuverlässigkeit Die Simulation soll bei Verwendung korrekter Eingabedaten reibungslos ablaufen.
Benutzbarkeit/Ergonomie Ein möglichst intuitiver Umgang soll durch eine geeignete Darstellung der Konfigurationsmöglichkeiten innerhalb einer grafischen Benutzungsoberfläche ermöglicht werden. Die Konsistenz zwischen der grafischen
Darstellung und den entsprechenden Konfigurationsdateien muss gewährleistet
sein, um Fehlinterpretationen auszuschließen.
60
4.5. Konzeptionelle Anforderungen
Robustheit Einstellungen bezüglich eines Experimentes, die zu einem Fehlverhalten
führen, sollen möglichst überprüft und bei falscher Eingabe vor dem Start einer
Simulation dem Benutzer angezeigt werden. Die Einstiegshürde in die Simulation von Suchverfahren sinkt mit Zunahme der Robustheit.
Skalierbarkeit Topologien einer Größenordnung von mehreren tausend Knoten sollen
simuliert werden können. Die Anzahl an gestellten Anfragen muss in einem
variablen Ausmaß ermöglicht werden, so dass sowohl eine einzelne wie auch
eine Vielzahl dieser verarbeitet werden können.
Lizenz Zur späteren Weiterenwicklung soll eine Open-Source-Lizenz gewählt werden.
Gerade im Hinblick auf der Verwendung anderer Bibliotheken, die genutzt oder
erweitert werden, muss auf eine geeignete Lizenz geachtet werden. Der Simulator muss als voll-funktionstüchtige Anwendung die Open-Source-Richtlinien
einhalten.
4.5. Konzeptionelle Anforderungen
Modularität Ein modularer Aufbau des Simulators soll die Wartbarkeit und die Erweiterung vereinfachen. Gerade neu zu entwickelnde Suchverfahren sollen über
feste Schnittstellen leicht integrierbar sein. Allgemeine Voraussetzungen, wie
die Verwendung von Nachrichtenhistorien und Caches sollen die Entwicklung
neuer Verfahren beschleunigen. Das Routing von Nachrichten soll dem Entwickler abgenommen werden. Lediglich notwendige Daten wie der Empfänger sollen
für eine garantierte Auslieferung ausreichen.
Validation und Verifikation kann über geeignete Ausgaben erleichtert werden. Die
manuelle Verfolgung der Prozessgeschehnisse soll anhand dieser Ausgaben ermöglicht werden.
Metriken zur späteren Analyse der Suchverfahren dienen der Vergleichbarkeit dieser.
Die Erarbeitung unterschiedlicher aussagekäftiger Metriken, sowie die Integration in den Simulator, stellen eine Kernaufgabe der Simulation dar. In ihrer
Menge sollen Aussagen über die Effizienz, der Netzwerkauslastung sowie weitere
der abschließenden Auswahl eines Suchverfahrens für organisations-orientierte
Suchverfahren getroffen werden können.
Plattformunabhängigkeit Die Ausführung des Simulators soll nicht auf bestimmte Betriebssysteme beschränkt sein. Die Auswahl einer plattformunabhängigen
Programmiersprache erscheint hierbei sinnvoll. Die weite Verbreitung und Verwendung der Sprache Java innerhalb des Simulationskontextes erscheint als
geeignet, da zusätzlich eine Vielzahl an Visualierungsanwendungen für diese
Sprache bereitstehen.
61
4. Anforderungsdefinition
Standards Angesichts der Existenz diverser Standards für Topologieformate, soll im
Zuge der Wiederverwendbarkeit ein bestehendes Format zur Eingabe verwendet
werden.
4.6. Strukturelle Anforderungen
In der Abbildung 4.1 sind die wichtigsten Konzepte des Simulators dargelegt. Die
Verwendung des Simulators soll weitestgehend von strukturellen Gegebenheiten der
Topologie wie auch von dem Verhalten der zu simulierenden Elemente abstrahiert
werden. Die Kernaufgabe des Simulators besteht in der Simulation gewählter Metriken zur Weiterleitung von Nachrichten. Die der Weiterleitung innewohnende Logik
soll gekapselt werden, so dass ein austauschbares Verhalten in Form von zugeführten Suchverfahren ermöglicht wird. Beziehungen der Elemente untereinander werden
ebenso gekapselt und allein durch die zugeführte Topologie bestimmt. Der Simulationsprozess wird initiiert bzw. getrieben von der Aussendung neuer Suchanfragen.
Initiatoren der Suchanfragen können in diesem Zusammenhang als Akteure betrachtet werden. Die Darstellung als Akteur dient jedoch lediglich dem Verständnis des
Prozessvorganges, da keine direkten Akteure vorhanden sind.
Simulationselemente erscheinen in Form der in Abschnitt 4.2 angesprochenen Rollen.
Grundlegende Funktionalität soll zentral definiert werden, so dass eine Erweiterung
auf andere Anwendungskontexte vereinfacht wird.
Gruppe
Mitglied
Projekt
1
Organisation
Simulationselement
1..* 1..*
Super-Peer
Cluster-Peer
Topologie
sendet Nachrichten
initiert Suche
definieren Verhalten
definiert Struktur
1
1..*
1..*
1
1
Suchender
Suchverfahren
Bild 4.1.. Fachliches Klassenmodell des Simulators. Simulationselemente treten in
Form der Elementtypen eines Architekturstils auf. Die Struktur der Topologie, sowie
das Verhalten und die initialen Suchanfragen werden ausgelagert und dem Simulationselement zugeführt.
62
5. Beschreibung der Simulation
Das Kapitel Simulation stellt die Einführung der relevanten Begrifflichkeiten und
Simulationsarten innerhalb einer Simulation dar. Es wird das Vorgehensmodell während der Studie beschrieben, sowie die Ablaufgestaltung und die Ereignisbehandlung.
Die Modellierung der Eingaben und Ausgaben schließt daraufhin die Beschreibung
der Simulation ab.
5.1. Einführung
Um das Verhalten real existierender Systeme zu untersuchen, gibt es neben der Simulation dieser ebenfalls die Möglichkeit einer direkten Implementierung. Nach Law
und Kelton [LK99] sind die meisten realen Systeme zu komplex, als dass ein realistisches Modell analytisch bewertet werden kann. Außerdem begründet sich die in dieser
Arbeit getätigte Simulation darin, dass ein derartiges System nicht real existiert und
die Erstellung angesichts des Umfanges nicht in vorgegebener Zeit realisierbar wäre.
5.1.1. Grundlegendes
Eine Simulation kann als die Repräsentation eines (Teil-)Systems in realistischer Form
beschrieben werden. Sie stellt eine Imitation von Abläufen eines realen Vorganges bzw.
Systems dar [Ban98]. Die Qualität dieser Simulation hängt dabei von der Kenntnis
der relevanten Eigenschaften dieses Systems und der realitätsgetreuen Modellierung
ab.
In dem Bereich der Simulation existieren einige wichtige Begriffe, die im Folgenden
kurz beschrieben werden. Ein wesentlicher Begriff stellt hierbei das System dar. Nach
Forrester [Pag91] besteht ein System aus einer Menge an Entitäten, die in einer Beziehung zueinander stehen und zu einem bestimmten Zweck miteinander interagieren.
Die Entitäten repräsentieren die zu beobachtenden Objekte im System. Attribute
definieren Zustände einer Entität (lokale Attribute) wie auch des Systems (globale
Attribute). Sie beschreiben somit den jeweiligen Zustand. Ein Modell stellt ein reales System in einer abstrakten, meist vereinfachten Art dar. Es werden analytische
Modelle und Simulationsmodelle unterschieden. Analytische Modelle bestehen in der
Regel aus Differenzialgleichungen zur Abbildung der realen Situation. Sie sind jedoch
63
5. Beschreibung der Simulation
in ihrer Komplexität und ihrer analytischen Lösungsmöglichkeit beschränkt . Simulationsmodelle hingegen ermöglichen die Simulation komplexer Situationen, indem
Zustandsveränderungen beobachtet werden.
Simulationen lassen sich nach [AB05] aus unterschiedlichen Perspektiven betrachten.
Die statische Simulation beschreibt ein System genau zu einem festen Zeitpunkt im
Unterschied zur dynamischen Simulation, die Zeitintervalle bzw. mehrere Zeitpunkte
betrachtet. Eine deterministische Simulation ergibt zu gegebenen Eingaben immer
die gleichen Ausgaben. Die Verarbeitung unterliegt keinen Zufallsvariablen im Gegensatz zur stochastischen Simulation.
Je nach Einflussbereich der beeinflussenden Variablen werden endogene und exogene
Simulationen unterschieden. Exogene Simulationen werden im Vergleich zu seinem
Pendant durch außenstehende Variablen mitbestimmt. Endogene Ereignisse sind von
internen Faktoren abhängig und treten häufig als Konsequenz eines vorherigen Ereignisses auf. Die letzte Sichtweise differenziert das zeitliche Verhalten der Simulationen
und soll näher betrachtet werden.
Zeitpunkte werden entweder diskret oder kontinuierlich betrachtet. Die Menge der Zustandsänderungen sind in der diskreten Simulation endlich begrenzt und somit nur zu
bestimmten diskreten Zeitpunkten möglich. Die kontinuierliche Simulation hingegen
lässt eine unendliche Anzahl an Zustandsveränderungen zu, da Zeitabschnitte unendlich verfeinert werden können. Eine Kombination dieser Sichtweisen für Teilbereiche
der Simulation wird als hybrid bezeichnet.
Es existieren vier unterschiedliche Ansätze zur Modellierung der zeitdiskreten Simulation: der ereignis-, transaktions-, prozess- und aktivitätsorientierte Ansatz. Während bei der ereignis- und transaktionsorientierte Modellierung ”[..]primär die Materialflüsse durch Bedienstationen und die dabei zurückzulegenden Wege betrachtet werden[..]”[Pag91] steht der Bearbeitungsvorgang der einzelnen Bedienstationen bei der prozess- und aktivitätsorientierten Modellierung im Vordergrund. Der
transaktions- und aktivitätsorientierte Ansatz gelten in der Literatur [Pag91] als Alternative mit geringerer Bedeutung und werden daher hier vernachlässigt.
In der ereignisorientierten Simulation betrifft das Eintreten von internen und externen
Ereignissen die Entitäten und verändert deren Zustand. Zu bestimmten Zeitpunkten
werden alle eingetretenen Ereignisse abgehandelt und mit der Simulation fortgefahren. Die Aktivität, also der Vorgang während der Abarbeitung, tritt hierbei in den
Hintergrund. Anders wird bei der prozessorientierten Simulation verfahren. Alle eine
Entität betreffenden Aktionen und Attribute werden in einem Prozess gekapselt, der
unterschiedliche Zustände einnehmen kann. Der Ablauf entspricht dann der Prozessinteraktion mit Hilfe eines Schedulers, der für die Aktivierung sorgt. Der Schwerpunkt
liegt hierbei auf den Aktionen und kann als maschinenorientiert bezeichnet werden
[Pag91]. Weiterhin eignet sich dieser Ansatz für die Modellierung komplexer Vorgänge.
64
5.1. Einführung
Die Entscheidung für die Wahl eines Modellierungsstiles hängt von der Art der natürlichen Abbildung des zu simulierenden Verhaltens ab. Der dieser Arbeit zugrunde
liegende Stil ist ereignis-orientiert und zeit-diskret. Die folgenden Abschnitte erläutern dieses genauer.
5.1.2. Validation und Verifikation
Eine Simulation einer realen Gegebenheit ist nur aussagekräftig, wenn diese in den zu
untersuchenden wie auch beeinflussenden Faktoren übereinstimmt. Eine Validation
dessen ist für die Aussagekraft der Simulation unabdingbar, muss jedoch im Einzelfall
überprüft werden. Diese Überprüfung gilt als stetige Aufgabe während des Entwurfs.
Hilfsmaßnahmen, wie ausreichende Tests, Darstellungs- und Visualisierungsfunktionen können neben einer vorherigen Analyse des realen Ablaufes die Qualität einer
Simulation erhöhen. Garantien über einen realitätsgetreuen Ablauf sind angesichts
der zugrunde liegenden Entscheidung für eine simlative Analyse kaum zu geben. Die
Verifikation während der Entwicklung kann hingegen durch Tests der entsprechenden
Implementierungen ermöglicht werden.
5.1.3. Sichtweisen dieser Simulation
Die vorgenommene Simulation wird anhand der obigen Einführung kurz eingeordnet.
Das Verhalten während der Simulation wird durch das Eingabemodell (siehe 5.3)
wesentlich mitbestimmt. Zum Vergleich verschiedener Suchverfahren wird eine vorliegende Eingabe in Form von festen Topologien der einzelnen Ebenen und vordefinierten Suchanfragen herangezogen. Soweit die einzelnen Suchverfahren determinstisch
arbeiten, erfolgt die Simulation insgesamt determinstisch. Stochastische Eingaben
sind für den Vergleich nicht vorgesehen. Die Zeit wird diskretisiert, da einerseits
eine analytische Darstellung so komplex erscheint und damit nicht in Erwägung gezogen wurde und andererseits relative zeitliche Aussagen zur Bewertung und dem
anschließenden Vorschlag (siehe 8.1) ausreichen. Die Simulation läuft zeitdiskret und
ereignisorientiert. Der Bearbeitungsvorgang in den einzelnen Entitäten ist von geringerem Interesse. Die Simulation des Nachrichtenverkehrs dagegen wird in mehreren
Metriken verwendet und gibt letztendlich die Entscheidung für die Modellierung der
Ereignisse. Hierbei sind exogene Ereignisse durch das Eingabemodell bestimmt. Die
Analyse wird also durch die endogenen Ereignisse bestimmt.
5.1.4. Gliederung der Simulation
Die Simulation umfasst verschiedene Bereiche, die in den folgenden Abschnitten erläutert werden. Begonnen wird mit der Vorstellung des Simulationsmodells. Das dort
65
5. Beschreibung der Simulation
Bild 5.1.. Vorgehensmodell der Simulationsstudie
beschriebene Vorgehensmodell wird mit einer Messmethode kombiniert. Desweiteren
folgt eine Beschreibung des Simulationszyklus und der zu betrachtenden Ereignisse.
Das Ein-/Ausgabemodell im darauffolgenden Abschnitt umfasst die Konfiguration
der Simulation, den Aufbau der Topologien und der Suchanfragen. Den Abschluss
bildet der Ausgabebericht, der zur späteren Analyse dient.
Der Entwurf und die entsprechende Implementation des Simulators werden beschrieben. Hierbei werden der Bezug zum Simulationsmodell verdeutlicht und die verwendeten Konzepte der Softwareentwicklung angesprochen.
Die untersuchten Experimente (im dort genannten Sinne) umfassen neben der Konfiguration die untersuchten Suchverfahren. Hierbei wird auf die in den Abschnitten 3
und 3.5 vorgestellten Suchverfahren eingegangen. Implementierungen dieser werden
ebenfalls behandelt.
Der Abschluss erfolgt in der Analyse der vorgenommenen Experimente.
5.2. Simulationsmodell
Jede Simulationsstudie kann in eine Abfolge unterschiedlicher Schritte eingeteilt werden. Diese Abfolge wird in dem in Abbildung 5.1 dargestellten und an [Ban99] angelehnten Vorgehensmodell beschrieben. Der erste Schritt einer Simulationstudie ist die
Problembeschreibung. Die Problembeschreibung zeigt den Grund für eine Simulation
auf und sorgt für gegenseitiges Verständnis zwischen Problemsteller und Problemlöser. Sie ist in der Anforderungsdefinition (Kapitel 4) zu finden. Nach der Schaffung
66
5.2. Simulationsmodell
dieser Grundlage werden Ziele definiert, die mittels einer Simulation untersucht und
gemessen werden (Abschnitt 5.2.1). Ausgehend von diesen Zielen wird ein konzeptuelles Modell der Realität erstellt. Ein konzeptuelles Modell beschreibt die funktionalen
Zusammenhänge der Komponenten eines Systems untereinander. Dieses Modell wird
unter Berücksichtung der angestrebten Ziele vereinfacht, indem Elemente und Eigenschaften ohne bzw. mit vertretbarem Einfluß auf die Untersuchung der Performanzeigenschaften vernachlässigt werden. Um das Modell ausführen zu können, wird daher
aus dem konzeptuellen Modell ein operatives Modell (Abschnitt 6) erstellt. Die Verifikation sichert die korrekte Überführung, wobei die Validation im Anschluß die Intention der Simulation überprüft, so dass nicht von der ursprünglichen Problemstellung
abgewichen wird. Nach der Erstellung eines operationalen Modells werden Experimente (Abschnitt 7) erstellt, die auf die verschiedenen Eingabeparameter (Abschnitt
5.3) und den zu untersuchenden Zielen beruhen (Abschnitt 5.2.1). Die (wiederholte)
Ausführung der Simulation mit anschließender Analyse (Abschnitt 7.3) erzeugt die
Rohdaten, die im darauffolgenden Schritt zu einem Vergleich aufbereitet werden (Abschnitt 5.3.5). Durch die unterschiedlichen Simulationen der Suchverfahren wird als
abschließendes Ergebnis ein Vorschlag eines geeigneten Verfahrens für die anfängliche
Problemstellung gegeben (Abschnitt 8.1).
5.2.1. Messen nach der GQM-Methode
Ein zielgerichteter Ansatz bei der Verfolgung der gewünschten Resultate ist die GQMMethode. Dieser von Basili u.a. [VRBR94] entwickelte Top-Down-Ansatz stellt ein
allgemeines Vorgehensmodell bei der Messplanung dar, das in dieser Arbeit mit dem
beschriebenen Vorgehensmodell kombiniert wird.
Die Goal-Question-Metric (GQM) Methode leitet zielgerichtet von einem Ausgangsproblem die gewünschten Ziele (Goal) ab, die als konzeptionelle Stufe bezeichnet werden. Die Einhaltung und der Fortschritt der Ziele werden in der operativen Stufe über
Fragen beantwortet (Question). Zur Messung der qualitativen wie auch quantitativen
Ausprägung der untersuchten Veränderungen werden Metriken in der quantitativen
Stufe definiert (Metric). Anhand dieser Metriken werden Antworten auf die gestellten
Fragen gegeben, die letztendlich Rückschluß auf das Erreichen der angestrebten Ziele
zulassen.
Eine Kombination der beiden Verfahren wird daher verwendet, da das eingangs
beschriebene Vorgehensmodell den Aufbau einer allgemeinen Simulationsstudie beschreibt, die durch die GQM-Methode konkretisiert wird. Die Zielfindung beider Verfahren begründet sich in der vorhergehenden Problemstellung. Die Validationsphase
wird in der GQM-Methode durch direkten Rückschluß auf die Beantwortung der Fragen abgebildet. Die erforderliche Analyse geschieht in der GQM-Methode anhand der
gewählten Metriken. Abschließend beeinflusst die Erstellung der Metriken die Erstellung des operationalen Modells, da diese im Entwurf berücksichtigt werden können.
67
5. Beschreibung der Simulation
Die Abbildung 5.2.1 zeigt die Elemente der Messplanung mittels GQM auf. Im Anschluß wird auf die verwendeten Metriken eingegangen.
Bewertung von S uchverfahren
für S uper-P eer-Architekturen
Optimierung des
Nachrichtenverkehrs
durch Kombination einer
semantisch höheren Ebene
Wie hoch is t
die Erfolgs rate?
Wie viele Hops werden
pro Antwort benötigt?
Wie viele Anworten
werden erzielt?
AQR
QS R
Wie hoch is t
die S ys tembelas tung?
AP M
AQR: Ans wer query relation
HP Q
VMS
VME
OMS
OME
VMS : Virtual mes s age count
AP M: Ans wer per mes s age
QS R: Query s ucces s rate
Wie hoch is t
die Einzelbelas tung?
OMS : Organis ational mes s age count
VME: Virtual mes s age count per element
HP Q: Hops per mes s age
OME: Organis ational mes s age count per element
Bild 5.2.. Messplanung nach der GQM-Methode
Die Simulationsstudie basiert auf zwei Zielen. Es sollen Suchverfahren für Super-PeerArchitekturen anhand unterschiedlicher Kriterien verglichen werden. Hierzu muss die
Möglichkeit geschaffen werden, eine maximale Anzahl an Suchverfahren - wie in Abschnitt 3 beschrieben - zu modellieren. Organisatorische Elemente, wie Mitglieder
und Projekte, geben Zusatzinformationen bei der Suche nach Ressourcen, die in bisherigen Suchverfahren nicht genutzt werden. Das zweite Ziel soll die Auswirkungen
der Verwendung dieser Informationen auf bestehenden Suchverfahren darstellen.
In dem mittleren Bereich der Abbildung 5.2.1 sind einige Fragen dargestellt, die
Antworten hinsichtlich der Ziele liefern. Die Fragen beziehen sich auf die nichtfunktionalen Eigenschaften Erfolgsrate, Antwortverhalten und Auslastung der Systemkomponenten.
Der untere Bereich der Abbildung veranschaulicht die verwendeten zeitabhängigen
Metriken. Das Verständnis dieser Metriken wird in den Kapiteln 7 und B vorausgesetzt und daher hier detailliert beschrieben.
68
5.2. Simulationsmodell
AQR Das Verhältnis der gestellten Anfragen zu den ermittelten Antworten. Diese
Metrik stellt alle Anfragen zum einem bestimmten Zeitpunkt den bisherigen
Antworten gegenüber.
QSR Die Erfolgsrate der gestellten Anfragen. Jede mindestens einmal beantwortete Anfrage erhöht die Erfolgsrate, die an den aktuell im System befindlichen
Anfragen gemessen wird. So liefert diese Metrik die Prozentzahl aller bisher
beantworteten Anfragen.
APM Das Verhältnis der erzielten Antworten zu den gestellten Anfragen. Eine Anfrage nach mehrfach vorhandenen Ressourcen kann mehrere Antworten erzielen.
Die Anzahl der ermittelten Antworten wird pro Anfrage gemessen.
HPQ Die Pfadlänge einer erfolgreichen Suche. Eine beantwortete Anfrage kann unterschiedlich viele Zwischenstationen durchlaufen (Hops). Diese Metrik gibt Auskunft über die Dauer einer Antwort.
VMS Die Anzahl virtueller Nachrichten im System. Suchanfragen verursachen eine
unterschiedliche Netzbelastung. Um diese aggregierte Last zu messen, werden
alle im System befindlichen Nachrichten zum aktuellen Zeitpunkt aufaddiert.
VME Die Anzahl virtueller Nachrichten pro Element. Um Engpässe einzelner Simulationselemente festzustellen, wird die individuelle Netzbelastung gemessen.
OMS Die Anzahl organisatorischer Nachrichten im System. Diese Metrik misst die
aggregierte Netzlast des organisatorischen Overlays.
OME Die Anzahl organisatorischer Nachrichten pro Element. Sie wird als individuelle Belastung der organisatoischen Simulationselemente gemessen.
69
5. Beschreibung der Simulation
5.2.2. Simulationszyklus
Der Ablauf der Simulation ist neben einer Initialisierung durch einige Zustände definiert. Insgesamt wird zwischen einer Makro- und einer Mikrosimulationszeit unterschieden. Die Makrosimulationszeit verdeutlicht die reale Zeitabfolge, wohingegen
die Mikrosimulationszeit eine sequentielle Emulation paralleler Vorgänge ermöglicht.
Mikrosimulationsschritte erfolgen somit in Nullzeit, die der Nachbildung paralleler
Vorgänge dienen und keine reale Zeit benötigen .
Die in Abschnitt 5.3 beschriebene Eingabe wird eingangs initialisiert. Der Konfiguration wird die angestrebte Simulationszeit entnommen und zum Starten der
Simulation auf ’0’ gesetzt. Jedes Simulationsmodell besitzt einen sog. Treiber,
der für die Erzeugung von Ereignissen
zum Fortlaufen der Simulation zuständig ist. Der Treiber liegt in Form eines
externen Nachrichtengenerators vor, der
den Eingaben entsprechend Nachrichten
verschickt bzw. in die entsprechenden
Eingangswarteschlangen der zu simulierenden Entitätene einreiht. Falls zur aktuellen Zeit keine Nachricht vorgesehen
ist, wird mit der sequentiellen Verarbeitung der Eingangswarteschlangen aller Entitäten fortgefahren. Gegebenheiten der Nachrichtenparameter wie auch
die Beschaffenheit der Nachbarschaft bestimmen, ob eine Nachricht weitergeleitet wird. Eine Weiterleitung der Nachricht verursacht mögliche ParametereinBild 5.3.. Simulationszyklus
stellungen dieser und die Einlagerung
der modifizierten Nachricht in die Eingangswarteschlange des/der Adressaten. Der
Simulationszyklus wird beendet, indem die Simulationszeit inkrementiert wird. Falls
das Simulationsende erreicht ist terminiert die Simulation. Ansonsten wird mit der
Überprüfung auf externe Ereignisse fortgefahren.
70
5.2. Simulationsmodell
5.2.3. Ereignisbehandlung
Die Ereignisbehandlung drückt in der Simulation die Dynamik der Geschehnisse aus.
Diese entsteht durch die nachrichten-basierte Kommunikation der interagierenden
Entitäten. Jede Entität besitzt daher einen Eingangspuffer für Nachrichten. Der Ausgangspuffer wurde zu Gunsten einer direkten Übertragung ausgelassen. Der allgemeine Fall sieht einen Empfang mit entsprechender Verarbeitung und anschließender
Versendung vor. Lediglich der Treiber der Simulation empfängt keine Nachrichten,
da sie keine Entität widerspiegelt, sondern ein künstliches Konstrukt ist, das real
nicht existiert. Dieser erzeugt aus einer externen Quelle Nachrichten und stellt sie
den eigentlichen Sendern zu.
Um das Verhalten innerhalb eines Netzwerkes zu simulieren, wird das zugrunde liegende Basisverhalten in Nachrichten gekapselt. Es existieren häufig folgende Nachrichtentypen, um die Kommunikation in einem Netzwerk abzubilden:
Betreten (join): Ein Knoten verfasst zum Betreten des Netzwerkes eine Nachricht an einen anderen Knoten
Verlassen (leave): Ein Knoten verlässt das Netzwerk und sendet eine Abschiedsnachricht.
Aktualisierung (update): Eine Aktualisierung der Nachbarschaft sowie eine Aktualisierung des Datenbestandes werden in Form einer Nachricht versandt.
Suche (search): Suchanfragen werden innerhalb einer Nachricht formuliert und
versendet.
Um das eigentliche Simulationsziel zu erreichen, sind bei der Simulation einige Kompromisse einzugehen. Ausgegangen wird von einer festen sich nicht ändernden Topologie, statischen Suchanfragen und unveränderbarem Ressourcenbestand. Die Simulation beschränkt sich somit auf die Suche und das Weiterleiten innerhalb eines statischen Netzwerkes. Eine zusätzliche Netzwerkbelastung, die durch die Pflege strukturerhaltender Maßnahmen (viele Update-Nachrichten) entstehen kann, wird in der
Simulation nicht berücksichtigt.
Das in Abbildung 5.4 dargestellte Aktivitätsdiagramm verdeutlicht die Nachrichtenbehandlung der Entitäten. Durch die Übermittlung von Ereignissen in Form von
Nachrichten kann die Simulation leicht um das bisher nicht simulierte Verhalten erweitert werden, indem neue Nachrichtentypen und damit verbundene Operationen
definiert werden.
Die Einlagerung einer Nachricht in den Eingangspuffer einer Entität bewirkt die
Verarbeitung der Nachricht. Hierbei wird jedoch lediglich überprüft, ob die Verarbeitung des Nachrichteninhaltes (hier: Suchangaben) interpretiert und verarbeitet
71
5. Beschreibung der Simulation
werden sollen. Falls der Inhalt interpretiert wird, so werden die Anweisungen verfolgt
(hier: Überprüfung des lokalen Datenbestands auf Übereinstimmung). Bei Übereinstimmung wird eine Antwort generiert und versendet. Falls kein Treffer erzielt wurde,
so kann die Nachricht weitergeleitet oder der Suchprozess beendet werden (z.B. TTL,
HTL).
Bild 5.4.. Nachrichtenbehandlung einer Entität
72
5.3. Ein-/Ausgabemodell
5.3. Ein-/Ausgabemodell
Der entwickelte Simulator benötigt verschiedene Eingangsparameter. Der Entwurf
ist auf die möglichst einfache Wiederverwendung und Anpassung der zu erstellenden
Experimente ausgelegt. Um dies zu gewährleisten, sind neben der Konfiguration des
Simulators ebenfalls die topologischen Strukturen der einzelnen zu simulierenden Ebenen und die den Simulationsprozess treibenden Anfragen extern gehalten. Ohne die
Kenntnis über den Aufbau des Simulators wird somit eine Nutzung und Erstellung
von Experimenten ermöglicht.
In Abbildung 5.5 ist das Ein-/Ausgabemodell des Simulators zu sehen, das die angesprochenden drei Eingangsparameter enthält. Die Ausgabe erfolgt als Bericht des
simulierten Experimentes mit sowohl textueller wie auch grafischer Auswertung anhand der in Abschnitt 5.2.1 vorgestellten Metriken.
Von entscheidender Bedeutung ist die externe Erstellung und Manipulation der Suchverfahren, die die Entwicklung neuer Suchverfahren vereinfacht. Die Entwicklung
dieser Verfahren wird detailliert in Abschnitt 6 dargestellt.
Bild 5.5.. Ein-/Ausgabe Modell des Simulators
Die folgenden vier Abschnitte verdeutlichen den Aufbau der einzelnen Eingangsparameter. Anschließend wird auf die Struktur des Ausgabeberichtes eingegangen.
5.3.1. Konfiguration
In einer Konfigurationsdatei werden alle Einstellungen getätigt, die zum Ablauf einer
Simulation notwendig sind. Sie stellt somit einen bestimmten Zustand des Systems
73
5. Beschreibung der Simulation
dar, von dem aus die Simulation gestartet wird. Unterschiedliche Konfigurationen
können dann als Experiment zusammengefasst werden. Die Reproduzierbarkeit einzelner Konfigurationen wird durch statische Topologien der einzelnen Ebenen mit deren
Verknüpfung untereinander und den ebenfalls statischen Suchanfragen gewährleistet.
Neben diesen Parametern beeinflussen die Angabe der zu simulierenden Ebenen und
die Simulationsdauer die Simulation. Um den angestrebten Vergleich diverser Suchverfahren zu gewährleisten, wird das jeweils zu testende Suchverfahren angegeben.
Einen Einblick in die wesentlichen Konfigurationselemente gibt das Listing 5.1.
Allgemeine Einstellungen zum Experiment (experiment) werden zu Beginn angegeben. Hierzu zählen u.a. die Laufzeit der Simulation, der Trace-Zeitraum und die
Formatierung des Ausgabeberichtes. Zu den speziellen Elementen (model) zählen
Topologie- und Verbindungseinstellungen sowie eine Auswahl der zu betrachtenden
Metriken. Erweiterungen (extensions) können z.B. Einstellung zu Topologiegeneratoren oder Visualisierungskomponenten sein.
Listing 5.1. Konfiguration eines Experimentes
<? xml version = " 1.0 " encoding = " UTF -8 " ? >
2 < simulation xmlns:xsi = " http: // www . w3 . org /2001/ XMLSchema instance " >
3
< experiment name = " Easim1 " >
4
< lifecycle time = " 25 " / >
5
< debug start = " 0 " stop = " 0 " / >
6
< trace start = " 0 " stop = " 5 " / >
7
< output dir = " output " >
8
< styles >
9
< style name = " report " class = " desmoj . core . report
. HTMLReportOutput " / >
10
...
11
</ styles >
12
</ output >
13
</ experiment >
14
< model >
15
< topologies >
16
< topology model = " true " layer = " organisational "
file = " input / topologies / organisational / sample
-5000. xml " / >
17
< topology model = " true " layer = " virtual " file = "
input / topologies / virtual / sample -5000. xml " / >
18
< topology model = " false " layer = " physical " file = "
input / topologies / physical / sample -5000. xml " / >
19
</ topologies >
20
< mappings >
1
74
5.3. Ein-/Ausgabemodell
< mapping layer1 = " organisational " layer2 = " virtual "
class = " easim . layers . mapping .
O r gV i r t M ap p i n g_Default " >
22
< parameters / >
23
</ mapping >
24
...
25
</ mappings >
26
< query file = " input / queries / sample -20000. xml " / >
27
< strategies >
28
< strategy element = " host " class = " easim . strategy .
Ho st Str at egy _Default " >
29
< parameters >
30
< parameter name = " max depth " type = " java . lang
. Integer " value = " 2 " / >
31
< parameter name = " max answer per message "
type = " java . lang . Integer " value = " 1 " / >
32
</ parameters >
33
< description > descr </ description >
34
</ strategy >
35
...
36
</ strategies >
37
< metrics >
38
< metric name = " QUERY_SUCCESS_RATE " value = " true " / >
39
...
40
</ metrics >
41
</ model >
42
< extensions >
43
...
44
</ extensions >
45 </ simulation >
21
5.3.2. Topologie
Komponenten eines Netzwerkes, die untereinander kommunizieren, genügen einer
Struktur, die Aufschluss über die Konnektivität der einzelnen Elemente gibt. Diese Struktur der Verbindungen untereinander wird als Topologie vezeichnet.
Zur Simulation der in 5.2 vorgestellten Ebenen, wird pro Ebene eine eigene Topologie verwendet. Eine allgemeine Topologie kann mit den Basiselementen Knoten und
Kante beschrieben werden. Ein Knoten stellt ein aktiv bzw. passiv kommunikatives
Element des Systems dar. Eine Kante repräsentiert die (un-)gerichtete Verbindung
zweier Knoten, die eine Kommunikation ermöglicht.
75
5. Beschreibung der Simulation
In dem zu erstellenden Simulator werden Topologien verwendet, die neben den elementaren Basiselementen Attribute zur genaueren Spezifizierung dieser Elemente enthalten. Um die Wiederverwendung der erstellten Topologien zu gewährleisten, wird
das XML-Datenformat GraphML [BEH+ 01] verwendet. GraphML unterstützt neben
der reinen Struktur der Graphen ebenfalls anwendungsspezifische Daten, die neben
der wachsenden Popularität als Entscheidungskriterium für die Wahl dieses Formates
gedient haben.
Zur sinnvollen Simulation der einzelnen Ebenen werden realistische Strukturen der
Topologien vorausgesetzt. Da die effiziente und korrekte Erstellung einer InternetTopologie problematisch ist [ZCB96; YJB02], wird auf bestehende Topologie-Generatoren zurückgegriffen, die unterschiedliche Ansätze bei der Erstellung verfolgen. Die
generierten Topologien werden dann in das Graph-Format GraphML übertragen und
mit anwendungsspezifischen Daten erweitert.
Das Listing 5.2 verdeutlicht den Zusammenhang der Strukturinformationen einer
Topologie mit den anwendungsspezifischen Zusatzinformationen. Peers werden als
Knoten (node) mit einer eindeutigen ID repräsentiert. Kanten (edge) verdeutlichen
die strukturelle Verbindung der Knoten untereinander. Die anwendungsspezifischen
Daten, wie Ressourcen, werden den Peers in einem data-Element zugeordnet. Der
Aufbau der Datenelemente wird über das Schlüsselwort key im oberen Bereich des
Listings definiert. Da gerichtete, wie auch ungerichtete Verbindungen existieren können, definiert das Schlüsselwort edgedefault die Richtung der jeweiligen Kanten.
Listing 5.2. Beispieltopologie der virtuellen Ebene
<? xml version = " 1.0 " encoding = " UTF -8 " ? >
2 < graphml xmlns = " http: // graphml . graphdrawing . org / xmlns "
3
xmlns:xsi = " http: // www . w3 . org /2001/ XMLSchema - instance "
xsi:schemaLocation = " http: // graphml . graphdrawing . org
/ xmlns http: // graphml . graphdrawing . org / xmlns /1.0/
graphml . xsd " >
4
< key attr . name = " ressourceName " attr . type = " string " for =
" node " id = " ressource " >
5
< desc > node ressource names </ desc >
6
< default > no default specified </ default >
7
</ key >
8
..
9
< graph edgedefault = " undirected " >
10
< node id = " 0 " >
11
< data key = " type " > superpeer </ data >
12
</ node >
13
< node id = " 0 _0 " >
14
< data key = " type " > clusterpeer </ data >
1
76
5.3. Ein-/Ausgabemodell
< data key = " ressource " > dateiname_npwc ,
dateiname_htjt </ data >
</ node >
< node id = " 0 _1 " >
< data key = " type " > clusterpeer </ data >
< data key = " ressource " > dateiname_grvj ,
dateiname_ltpc , dateiname_nvwf </ data >
</ node >
15
16
17
18
19
20
21
...
< edge source = " 0 " target = " 8 " >
< data key = " delay " > 100 </ data >
</ edge >
< edge source = " 0 " target = " 4 " >
< data key = " delay " > 50 </ data >
</ edge >
22
23
24
25
26
27
28
...
</ graph >
30 </ graphml >
29
Verbindung der Ebenen
Bei kooperierenden Simulationen mehrerer Ebenen, die jeweils unterschiedliche topologische Beziehungen aufweisen, muss eine Verbindungsmöglichkeit gegeben werden.
Diese Verbindungslogik kann ebenfalls als Eingabe betrachtet werden, da sie maßgeblich an dem Simulationsverlauf mitwirkt. Sie wird in Form eines Verweises auf einen
bestehenden Algorithmus in der Konfiguration ausgewählt. Wie in 2.3 beschrieben,
können beispielhaft mehrere organisatorische Elemente auf demselben Peer angeordnet sein, jedoch auch eine 1:1 Beziehung existieren. Um diese Zuweisung variabel zu
halten, ist eine entsprechende Logik als Eingabe in algorithmischer Form vorgesehen.
Topologie-Generatoren
Topologische Strukturen beeinflussen maßgeblich den Verlauf einer Suchanfrage in
einem Netzwerk. Um möglichst realitätsnahe Strukturen in die Untersuchung von
P2P-Architekturen einzubeziehen werden in dieser Arbeit Topoloiegeneratoren verwendet. Weiterhin stellt die Erstellung realer Topologien ein eigenes Forschungsgebiet
dar, auf das in dieser Arbeit nicht eingegangen wird.
In der Literatur werden häufig zwei Generatoren angesprochen. Die stellen verschiedene Modelle bereit und bieten Konvertierungsmöglichkeiten sowie Importmöglichkeiten zu anderen Formaten. Das Geogia Tech Internetwork Topology Model (GT-ITM)
77
5. Beschreibung der Simulation
[ZCB96] setzt sich zum Ziel reale Lokalitäts- und Hierarchiebeziehungen abzubilden
und bildet die Struktur mit nötigen Metainformationen in einem Graphmodell ab.
Zur Erstellung der Strukturen, wie sie im Internet erscheinen, jedoch auch in anderen Domänen existieren, wird ebenfalls häufig der Boston university Representative
Internet Topology gEnerator (BRITE) [MLMB01] verwendet. BRITE verfolgt einen
allgemeineren Ansatz, der eine hohe Anzahl an Strukturen unterstützt. Zusammenfassend sind diese Generatoren sowohl für die Abbildung physikalischer Strukturen
als auch zur Erstellung abstrakterer Ebenen zu verwenden. Tsoumakos und Roussopoulos verwenden in der Analyse von Suchmethoden in P2P-Netzwerken GT-ITM
[Tso03; TR03c] (siehe auch 3.2.4). Chen Dongfeng, Yang Shoubao und Peng Xiaoyan verwenden hingegen in TaChord [DSX04](siehe auch 3.3.1) zur Erstellung eines
hierarchischen Chord-Ringes den Generator BRITE.
In dieser Arbeit entstammen die in dem GraphML-Format beschriebenen Topologien dem GT-ITM Topologiegenerator. Wegen der einfacheren Handhabung und der
leichten Erweiterbarkeit von GraphML wurde eine Konvertierung durchgeführt.
5.3.3. Such- und Routingstrategien
Schwerpunkt dieser Arbeit sind Such- und Routingstrategien. Um eine möglichst
einfache und flexible Simulation dieser zu schaffen, werden Suchstrategien als Eingabe betrachtet. Suchverfahren, wie auch Konfiguration, Topologien und Suchanfragen
werden dem Simulator während der Laufzeit hinzugefügt (siehe Abb. 5.5). Die unterschiedlichen Eingaben können weitestgehend miteinander kombiniert werden, so dass
als Beispiel dieselbe Topologie von unterschiedlichen Suchstrategien genutzt wird.
5.3.4. Suchanfragen
Suchanfragen können dem Simulator vordefiniert als Eingabe bereitgestellt werden.
Da zum Vergleich verschiedener Suchverfahren die Voraussetzungen übereinstimmen
müssen, werden sowohl Suchanfragen wie auch die Topologie des Netzwerkes extern
als Eingabe gehalten.
Die notwendigen Elemente zur Formulierung einer Suche sind die Zeit (time), der
Suchende (initiator, type) und eine Beschreibung der Kriterien, die jetzt erläutert
werden.
time Die Zeit (time) stellt den Beginn einer gestellten Suchanfrage dar. Diese wird
durch die Ablaufsteuerung registriert und bei Eintreten des entsprechenden Simulationsschrittes gestartet.
78
5.3. Ein-/Ausgabemodell
initiator Suchanfragen werden von suchenden Elementen (initiator) initiiert, die
allen Ebenen entstammen können. Das jeweilige Element erhält zur gewählten Zeit
die Nachricht und stellt somit den ersten Empfänger dar.
type Da Elemente unterschiedlicher Ebenen namentlich nicht eindeutig unterscheidbar sein müssen, ist die Angabe eines speziellen Elementtypen (type) anzugeben, der
die Eindeutigkeit ermöglicht.
item Jede Anfrage enthält einen Eintrag (item) zur Suchspezifizierung. Abhängig
von der durchsuchten Ebene, existieren unterschiedliche Eintragsbeschreibungen.
organisatorisch: Organisatorische Suchanfragen beinhalten drei Variablen, mittels derer exakte wie auch ungenaue Suchanfragen durchgeführt werden können.
Alle Elemente dieser Ebene gehen Beziehungen zu anderen Elementen ein. Eine
Beziehung ist ein 3-Tupel bestehend aus Ursprung, Beziehungsname und
Ziel (siehe Abschnitt 2.3).
virtuell: In der virtuellen Ebene wird die Suche lediglich durch ein frei definiertes
Suchkriterium beschrieben.
Die Interpretation der Suchkriterien obliegt einzig den verwendeten Suchstrategien,
so dass eine möglichst hohe Flexibilität gewährleistet ist.
Das Listing 5.3 verdeutlicht den Aufbau der zu tätigenden Suchanfragen.
Listing 5.3. Spezifizierung der Suchanfragen als Eingabebeispiel
<? xml version = " 1.0 " encoding = " UTF -8 " ? >
< queries xmlns:xsi = " http: // www . w3 . org /2001/ XMLSchema instance " x s i : n o N a m e s p a c eS c h e m a L o ca t i o n = " query . xsd " >
3
< query time = " 0 " initiator = " 1 _3_3_2 #1 " type = " member " >
4
< item source = " * " relation = " gro_mem " target = " 0 _0_1_5
#1 " / >
5
</ query >
6
< query time = " 0 " initiator = " 1 _3_3_2 #1 " type = " member " >
7
< item source = " 0 _0_1_5 #1 " relation = " mem_gro " target = "
*"/>
8
</ query >
9
..
10
< query time = " 0 " initiator = " 1 _3_3_2 #1 " type = " member " >
11
< item source = " 0 _0_1_5 #1 " relation = " mem_mem " target = "
0 _0_1_5 #1 " / >
12
</ query >
1
2
79
5. Beschreibung der Simulation
< query time = " 0 " initiator = " Peer_29 #1 " type = " superpeer " >
< item criteria = " Peer_31 #1 " / >
15
</ query >
16 </ queries >
13
14
5.3.5. Ausgabebericht
Der Ausgabebericht wird nach jeder Simulation einer Konfiguration erstellt und enthält neben den Konfigurationseinstellungen auch die statistischen Angaben über den
Verlauf. Je nach gewählter Metrik variiert der Umfang dieser Meldungen. Neben dem
Ausgabebericht werden weitere Dokumente erstellt, die zusätzlichen Aufschluß über
den Ablauf des Experimentes geben. Es existieren daneben Informationen über den
zeitlichen Ablauf der Nachrichteninitialisierungen und - weiterleitungen (sog. trace),
sowie Fehlermeldungen und Debugmeldungen. Ebenfalls ist es möglich, neben den
automatisch generierten Meldungen, manuelle Ausgaben in den Suchstrategien zu
formulieren.
Zur Weiterverarbeitung der gelieferten Rohdaten, die durch die verwendeten Metriken
einer Simulation entstehen, wird eine csv1 -Datei erstellt, die in gängigen Tabellenkalkulationen verarbeitet werden kann.
1
csv: comma separated values
80
6. Entwurf und Implementierung
In diesem Abschnitt wird auf den Entwurf des Simulators sowie die damit verbundene
Implementierung eingegangen. Der Grobentwurf veranschaulicht die Verbindung der
Super-Peer-Architektur mit dem Aufbau organisatorischer Strukturen. Der anschließende Feinentwurf, mit abschließender Implementationsbeschreibung rundet dieses
Kapitel ab.
6.1. Grobentwurf
Für die Modellierung eines P2P-Systems mit der Erweiterung domänenspezifischer
organisatorischer Elemente werden zwei unterschiedliche Ansätze vorgestellt und
schließlich der Eingesetzte genauer beschrieben.
Der erste Ansatz beschreibt die Beziehung mittels Metadaten, um die ein Peer erweitert wird. So könnte ein Peer neben seinen bisherigen Ressourcen weitere der Suche
bereitstellen, die Aufschluss über die organisatorische Funktion und die vorhandenen Relationen geben. Diese Metadaten werden entweder durch eine Änderung des
P2P-Protokolls oder der Suchverfahren berücksichtigt.
Im zweiten Ansatz wird der virtuellen P2P-Ebene eine Ebene übergeordnet, die die
organisatorischen Elemente mit ihren Beziehungen beinhaltet. Die Verbindung der
beiden Ebenen wird durch einen Vermittler (Mediator) geleistet.
Der folgende Entwurf basiert auf dem zweiten Ansatz, da er intuitiver, strukturierter
und dynamischer ist. Die organisatorische Ebene beschreibt semantisch höherwertige Beziehungen als die virtuelle Ebene. Die Viefalt (organisatorischer) Elemente in
anderen Domänen kann variieren und eigenständig mittels Suchverfahren simuliert
werden. Organisatorische Elemente können unterschiedlichen Suchstrategien genügen.
Die Einführung einer separaten Ebene erscheint daher sinnvoll. Die zur Verknüpfung
der beiden Ebenen notwendige Verbindung ist je nach realen Gegebenheiten unterschiedlich und wird daher extern definiert, so dass es in erstellten Experimenten variert werden kann. Weiterhin ist die Simulation ohne Verbindung einer angrenzenden
Ebene möglich, so dass Ebenen unabhängig voneinander simuliert werden können.
Der erste Ansatz kann über das gewählte Datenformat der Topologien leicht verfolgt
werden, indem den Peers lediglich spezielle Metadaten übergeben werden müssen.
Dieser wird jedoch aus beschriebenen Gründen nicht näher vorgestellt.
81
6. Entwurf und Implementierung
6.1.1. Architektur
Zur Identifizierung der Architektur des Simulators werden kurz einige Architekturmuster [BMR+ 96] vorgestellt, die der Verständlichkeit dienen. Es wird auf das Schichtenmodell, Intorspektion und das Forwarder-Receiver-Pattern eingegangen.
Die Anordnung von aufeinander aufbauenden Ebenen/Schichten wird in der Literatur häufig als Schichtenmodell bzw. ’Layers-Pattern’ beschrieben. Einzelne Ebenen
operieren losgelöst voneinander und kooperieren über eine feste Schnittstelle. Ebenen sind in der Regel anhand ihres Abstraktionsgrades angeordnet, so dass abstraktere Ebenen mit weniger abstrakten kommunizieren, die wiederum nach demselben
Prinzip verfahren. Als Veranschaulichung eines Schichtenmodells dient das in der Literatur ausführlich beschriebene ISO-OSI-Referenzmodell1 . Eine Einschränkung des
Schichtenmodells besagt, dass eine Ebene jeweils nur mit einer direkt angrenzenden kommunizieren darf. Dieses eingeschränkte Schichtenmodell liegt dem Simulator
zugrunde, so dass die organisatorische Ebene lediglich mit der virtuellen Schicht interagiert, nicht jedoch die physikalische Ebene kontaktieren darf.
Im Zuge der Entwicklung adaptiver Systeme existieren weitere Architekturmuster in
Verwendung, die im Entwurf des Simulators berücksichtigt wurden. Um die Konfigurierbarkeit (im weiteren Sinne) zu erhöhen, werden neben den Einstellungen in einer
Konfigurationsdatei, alle Suchverfahren, Mappingverfahren sowie Topologiegeneratoren mit deren Visualisierung mittels Introspektion zur Laufzeit geladen. Introspektion
(ebenfalls als Reflektion bekannt) ermöglicht es, Informationen über den Aufbau von
Klassen während der Laufzeit einzuholen und diese zu integrieren. Die beschriebene Funktionalität wird dem Simulator dann über feste Schnittstellen bereitgestellt.
Durch die Auslagerung wesentlicher logischer Funktionen entsteht ein minimaler Kern
an Basisfunktionalität. Die Einbindung sowie die Schnittstellen werden im Abschnitt
6.2 besprochen.
Zur Verbergung von Kommunikationsprotokollen dient ein Dispatcher bzw. ’ForwarderReceiver-Pattern’, welches die Übermittlung der Nachrichten übernimmt. Die Aufgabe der Nachrichtenübermittlung wird als Basisfunktionalität bereitgestellt, die von
den Ebenen in Anspruch genommen werden muss.
Durch die Verwendung der beschriebenen Muster soll ein möglichst generischer und
strukturierter Aufbau geschaffen werden.
6.2. Feinentwurf
Der Feinentwurf beschreibt den Aufbau des Simulators sowie die Integration eines bestehenden Rahmenwerkes und einer Anwendung zur grafischen Darstellung der Statis1
http://www.iso.org/, zuletzt besucht am 14.08.2005
82
6.2. Feinentwurf
tiken. Zur zeitdiskreten Simulation wird das DESMO-J Rahmenwerk [PLC00; Cla01]
verwendet, das von der Univeristät Hamburg entwickelt wurde. Es dient der Entwicklung von objekt-orientierten Simulationsmodellen und stellt viele der in Abschnitt 5.1
beschriebenen Konstrukte bereit. Die grafische Darstellung der Statistiken wird von
einer Klassenbibliothek namens JFreeChart [Gil05] getätigt. JFreeChart unterstützt
neben den genutzten Zeitreihendarstellungen und Balkendiagrammen viele weitere
Visualisierungsmöglichkeiten, die zur weiteren Entwicklung des Simulators herangezogen werden können.
6.2.1. Abgrenzung von bestehenden Rahmenwerken zur Simulation
Angesichts der unterschiedlichsten Suchverfahren für P2P-Netzwerke existieren einige
Simulatoren, die häufig sehr spezielle Schwerpunkte setzen. Im Folgenden werden
einige dieser kurz vorgestellt. Je nach Forschungsintensität wurden Simulatoren für
einzelne Protokolle entworfen. Chord, FreeNet, Gnutella und Pastry stellen eigene
Simulatoren bereit, die zur Simulation dieser Verfahren entwickelt wurden.
Für das Verfahren Chord entstand in dem Ursprungsprojekt IRIS 2 ein Simulator
namens p2psim3 . Dieser Simulator unterstützt neben der Simulation von Chord einige
weitere angelehnte Verfahren. Weitere Verfahren wie Kademlia, Kelips und Tapestry
werden ebenfalls unterstützt.
Für FreeNet wurden bisher zwei Simulatoren entwickelt - Serapis und Aurora. Serapis wurde zur Untersuchung unterschiedlichen Cacheverhaltens entworfen. Beide
Simulatoren werden der Freenet-Distribution beigelegt.4
Zahlreiche Evaluationen beziehen sich auf das Gnutella-Netzwerk. Die Tauschbörse Limewire5 verwendet zur Simulation des Gnutella-Protokolls den Simulator Gnu(tella)Sim6 , der für die Simulation von Gnutella-Netzwerken und weiteren unstrukturierten
Netzwerkes konzipiert wurde.
Das auf der Basis von Plaxtons Suchalgorithmus (siehe Abschnitt 3.3.3) aufbauende
Verfahren Pastry verwendet ebenfalls einen eigenen Simulator namens FreePastry7 .
Neben den protokoll-spezifischen Simulatoren existieren weitere, die unterschiedliche
Protokolle unterstützen, wie auch jegliche Restriktionen bzgl. dieser auslassen. Der
Simulator 3LS abstrahiert von speziellen Protokollen und gibt dem Entwickler die
Möglichkeit, neue Protokolle zu simulieren. Hierzu ist ein Schichtenmodell vorgesehen, dass drei Schichten unterscheidet - die Benutzerebene, die Protokollebene und
2
http://project-iris.net/papers/, zuletzt besucht am 14.08.2005
http://pdos.csail.mit.edu/p2psim/, zuletzt besucht am 14.08.2005
4
http://www.freenet.sourceforge.net, zuletzt besucht am 14.08.2005
5
http//www.limewire.com, zuletzt besucht am 14.08.2005
6
http://www.cc.gatech.edu/computing/compass/gnutella/, zuletzt besucht am 14.08.2005
7
http://freepastry.rice.edu/FreePastry/, zuletzt besucht am 14.08.2005
3
83
6. Entwurf und Implementierung
die Netzwerkebene. Das Projekt Anthill [BMM02] stellt ein Rahmenwerk dar, das
den Schwerpunkt auf den Entwurf, die Implementation und Evaluation von P2PAnwendungen setzt. Ein Prototyp basiert auf der JXTA-Technologie8 , die sich zum
Ziel setzt, eine Standardisierung von Peer-to-Peer-Anwendungen durch frei zugängliche Protokolle zu ermöglichen. Der Peer-to-Peer Simulator (Peersim) [Jes05] stellt
ebenfalls keine Einschränkungen an zu simulierende Protokolle. Entstanden ist dieser
Simulator in dem Projekt BISON9 , das komplexe adaptive Systeme untersucht und
hiermit einen geeigneten Simulator bereitstellt.
Mit der intensiven Erforschung von P2P-Systemen der letzten Jahre geht eine hohe
Anzahl an Simulatoren einher, so dass nur eine kleine Auswahl dieser angesprochen
werden konnte. Bei der Recherche fällt auf, dass unterschiedliche Ziele untersucht
werden und somit eine Vielzahl an Simulatoren nicht in direkter Konkurrenz zueinander stehen. Trotz dieser Spezialisierungen ist die Tendenz zu erkennen, allgemeine
P2P-Simulatoren zu entwickeln, wie es in den Projekten Anthill und Peersim bereits
geschehen ist. Ähnlich den letztgenannten beiden Simulatoren wird in der vorliegenden Arbeit der Abstraktionsgrad der Modellierung erweitert und die Möglichkeit gegeben, auf diesem Abstraktionsniveau das Routing von Nachrichten zu untersuchen.
Die Simulationsmöglichkeiten sollen jedoch weiter gefasst werden als in bisherigen
Anwendungen. Von besonderem Interesse ist hierbei die Simulation einzelner wie
auch zusammenhängender Ebenen und deren selektive Ausblendung. Die einfache
Darstellung der Ebenen in einem Schichtenmodell erlaubt das Hinzufügen weiterer
Schichten, wie es in dieser Arbeit in der ’organisatorischen’ Ebene vollzogen wird. Der
Protokollaustausch wird in Form von austauschbaren Logikbausteinen zur Suche gewährleistet, die in dortiger Form leicht in bestehende Anwendungen portiert werden
kann. Eine Modellierung unterschiedlicher Architekturstile ist zusätzlich über die Definition der Elementtypen möglich, so dass neben reinen P2P-Architekuren ebenfalls
Super-Peer- und Client-Server-Architekturen simuliert werden können. Möglichkeiten
innerhalb eines Experimentes verschiedene Suchstrategien zu kombinieren, ist ebenfalls eine Neuerung gegenüber bisherigen Simulatoren. Neben einer häufig genutzten
textuellen Ausgabe, die in weiteren Schritten durch externe Anwendungen visualisiert werden müssen, erfolgt hier eine Darstellung während der Laufzeit. Auf weitere
nicht-funktionale Eigenschaften wie Erweiterbarkeit, Nutzbarkeit, Konfigurierbarkeit
und Flexibilität wird wie in anderen Simulatoren besonderen Wert gelegt.
6.2.2. Strukturelle Sicht
Die strukturelle Sichtweise gibt einen Einblick in die Paketstruktur, die Klassenstruktur und die Integration externer Algorithmen.
8
9
http://www.jxta.org, zuletzt besucht am 14.08.2005
http://www.cs.unibo.it/bison/, zuletzt besucht am 14.08.2005
84
6.2. Feinentwurf
Paketstruktur
Die Abbildung 6.1 verdeutlicht den Aufbau des Simulators in sieben Pakete. Im
Folgenden wird auf die Funktionalität der einzelnen Pakete eingegangen und im Anschluss werden die Klassen in Abbildung 6.2 detailliert beschrieben.
Bild 6.1.. Paketaufbau des Simlators
core Die Basis des Simulators stellt das Paket core dar, das für die Initiierung, den
Simulationszyklus sowie die Nachrichtenhandhabung zuständig ist.
layers Alle zu simulierenden Ebenen mit ihren Elementen, sowie ihre Verknüpfung
sind in dem Paket layers enthalten.
extension Nicht zur direkten Ausführung der Simulation benötigte Klassen werden
in dem Paket extension gesammelt. Hierzu zählen insbesondere Klassen zur
Erstellung der Topologien und der Suchanfragen.
statistic Statistische Auswertungen, die in der Benutzeroberfläche visualisiert und
in den Ausgabebericht einfließen, sind in dem Paket statistic gesammelt. Die
hier definierten Metriken werden im Simulationszyklus aktiviert.
85
6. Entwurf und Implementierung
configuration Die Konfiguration des Simulators geschieht an zentraler Stelle in der
Klasse Configurator, die für die Bereitstellung der Parameter zuständig ist.
strategy Simulationelemente werden durch die in dem Paket strategy bereitgestellten
Suchstrategien um ihre logische Funktionalität erweitert.
gui Neben der textbasierten Simulation sind die Klassen zur grafischen Visualisierung
in dem Paket gui enthalten.
util Das Paket util stellt Klassen zur Erstellung von neuen Topologien und Anfragen
bereit. Weiterhin sind einige Hilfsklassen für die grafische Benutzeroberfläche
enthalten.
Klassenstruktur
Der beschriebene Aufbau enthält keine Beziehungen zwischen den Paketen. Diese
werden in einer kompakten Form in dem folgendem Klassendiagramm 6.2 dargestellt.
Es zeigt alle wichtigen Klassen und Beziehungen des Simulators. Aufgrund der Komplexität wurden unwesentliche Beziehungen außer Acht gelassen.
Als Entitäten werden alle Simulationselemente und Nachrichten modelliert. Die folgende Beschreibung dient der Erläuterung des Klassendiagramms in Abbildung 6.2.
Simulationselemente Simulationselemente sind für jede Ebene spezifisch und treten
als physikalische, virtuelle und organisatorische Elemente mit entsprechenden
Verfeinerungen auf. Trotz ihrer spezifischen Funktion weisen sie signifikante
Übereinstimmungen auf. Jedes Element besitzt eine Basisfunktionalität, die
die topologischen Aktivitäten wie das Eintreten und Verlassen des Netzwerkes
und die Weiterleitung von Nachrichten implementieren [VL03; Tso03; LCP+ 04].
Diese Funktionen werden durch die Klassen PhysicalElement, VirtualElement und OrganisationalElement bereitgestellt oder vorgeschrieben. Die
Oberklasse SimulationElement hebt die Gemeinsamkeit, dass alle Simulationselemente Suchstrategien verwenden, hervor.
Nachrichten Nachrichten werden von den Simulationselementen anhand einer Strategie verarbeitet und untereinander weiterversendet. Anfragen stellen eine gesonderte Nachricht dar, die wiederum anhand ihrer Ebenenzugehörigkeit unterteilt werden. In einer abstrakten Ebene initiierte Nachrichten können innerhalb
dieser oder einer Abstraktionsebene tiefer versendet werden. In dem zweiten
Fall wird eine, der konkreteren Ebene entsprechende, Nachricht erstellt, die
die abstraktere Nachricht kapselt. Durch die Kapselung wird die ursprüngliche
Nachricht mitverschickt und kann bei Eintreten in eine höhere Ebene wieder
verarbeitet werden.
86
6.2. Feinentwurf
Strategie Jedes Simulationselement verwendet eine bestimmte ihrer Zugehörigkeit
entsprechende Strategie. Je nach Vielfalt unterschiedlicher Funktionen der Elemente einer Ebene können diese verschiedene Suchstrategien verwenden. Diese
Zuordnung ermöglicht das Anwenden unterschiedlicher Strategien innerhalb einer Ebene, so dass u.U. ein Projektelement eine andere Strategie als ein Gruppenelement verwenden kann.
Topologie Topologien aller Ebenen werden einheitlich verarbeitet und erst abschließend den Ebenen zugeordnet. Sie enthalten neben ihren Graph-basierten Eigenschaften (Knoten, Kante) zusätzliche Metadaten, die erst bei der Zuordnung
eines Overlays berücksichtigt werden. So wird die Möglichkeit geschaffen, eine
Topologie für unterschiedliche Overlays zu verwenden, da nur die spezifischen interpretiert werden. Die Erstellung einer Topologie geschieht statisch zu Beginn
Bild 6.2.. Die wichtigsten Klassen und Beziehungen innerhalb des Simulators
87
6. Entwurf und Implementierung
der Simulation und verändert sich währenddessen nicht. Um eine Erweiterung
hinsichtlich der Dynamik möglichst einfach zu gestalten, sind definierte Schnittstellen zum Eintreten sowie Austreten des Netzwerkes geschaffen, die initial
verwendet werden. Über einen in dieser Arbeit nicht vorgesehenen Dienst kann
somit mit geringem Aufwand eine topologische Dynamik während der Laufzeit
erreicht werden.
Mapping Zwei angrenzende Ebenen werden über einen Algorithmus miteinander verbunden, indem Elemente beider Ebenen Referenzen aufeinander erhalten. Diese
Algorithmen werden extern zugeführt und zählen somit zur Konfiguration des
Simulators.
Simulationszyklus Die Klasse SimulationCycle stellt ein externes Ereignis während der Simulation dar. Innerhalb eines jeden Zyklus wird bei geplanent anstehenden Anfragen die Klasse MessageGenerator aufgerufen, die zur Versendung dieser initialen Nachricht zuständig ist. Weiterhin werden Simulationselemente mit eingehenden neuen Nachrichten zur Verarbeitung dieser aktiviert.
Weiterversendete Nachrichten werden erst bei Beginn des nächsten Zyklus von
den Empfängern verarbeitet, die daraufhin als Versender agieren können. Der
Abschluß ist durch die Aktualisierung aller aktivierten Statistiken gekennzeichnet.
Generatoren Generatoren dienen der Erstellung neuer Topologien und Anfragen und
gehören daher nicht direkt zur Simulation. Sie erstellen lediglich die Eingabedaten.
Integration der Suchstrategien
Bei der Simulation wird der Schwerpunkt auf das Verhalten der Simulationselemente
und des Systems bei Variation verschiedener Suchstrategien gelegt. Suchstrategien
stellen die Dynamik des Systems dar, indem sie für die Versendung von Nachrichten
zuständig sind. Um den Austausch dieser zu ermöglichen, wird jegliche Logik bzgl. der
Weiterleitung in ihnen gekapselt. Simulationselemente werden somit als Datenobjekte
modelliert. Mittels des Besucher-Entwurfsmuster s [GHJV95] werden Simulationselemente und Strategien miteinander verbunden. Elemente werden daher - anders als
der intuitive Ansatz - passiv dargestellt. Sie können in einem Simulationsschritt einen
Nachrichtenempfänger wie auch Nachrichtensender darstellen. Dabei werden sie selbst
nicht direkt aktiv, sondern delegieren die Verarbeitung an eine Suchstrategie. Wie in
der Abbildung 6.3 ersichtlich wird, delegieren sie eine eintreffende Nachricht mittels
der ’accept’-Methode an eine Strategie, welche die von den Simulationselementen bereitgestellten Daten verarbeitet. Suchstrategien sind statisch erstellte Objekte, die
keinen Zustand besitzen. Sie fungieren als Dienstleister, die von den Simulationselementen in Anspruch genommen werden können. Zur einfachen Erweiterung werden
88
6.2. Feinentwurf
alle verwendeten Suchstrategien von der abstrakten Klasse AbstractStrategy abgeleitet, die die Implementierung der Methoden search() und inform(), sowie getDefaultValues() und getDescription() vorschreibt. Die letzteren beiden Methoden dienen lediglich der grafischen Verwendung im Simulator mittels Introspektion.
Bild 6.3.. Darstellung der Integration von Suchstrategien
Im Anhang A wird der Aufbau der Suchverfahren detailliert beschrieben. Darauffolgende Beispiele zeigen die Implementierung einiger der in Abschnitt 3 beschriebenen
Suchverfahren.
Integration spezifischer Ebenenzuordnungen
Ähnlich der Integration von Suchstrategien werden selbstdefinierte Algorithmen zur
Zuordnung der Ebenen verwendet. Statt eines ’Besucher-Entwurfsmusters’ wird als
Schnittstelle das Interface Mapping verwendet, das entsprechend implementiert werden kann. Zwei zu verbindende Ebenen stehen in ihrer Menge an Elementen zur Verfügung. Sie stellen Methoden zur Registrierung zur bereit. Konfiguriert werden die
Implementierungen über die in Abschnitt 5.3.1 beschriebene Konfigurationsdatei.
6.2.3. Verhaltenssicht
Simulationselemente stellen im Kontext einer Simulation Entitäten dar. Anders als
die intuitive Abbildung der Realität es vermuten lässt, wird in dieser Arbeit das Verhalten der Entitäten in Strategien ausgelagert. Strategien beinhalten das Verhalten
einer Elementtyps des modellierten Architekturstils, so dass nicht jedes Element eine
89
6. Entwurf und Implementierung
eigene Strategie verwendet, sondern alle Elemente gleichen Typs dieselbe Strategie
nutzen. Dies kann jedoch nur funktionieren, wenn Strategien zustandslos sind, wie
es durch das angewandte Besucher-Entwurfsmuster geschehen ist. Zustände werden
hier durch die Daten einer Entität gewahrt.
6.2.4. Ablaufsicht
Um die Interna des Simulators näher zu verstehen, werden der Initialisierungsablauf
und die Nachrichtenverarbeitung detailliert angesprochen. Abschließend wird auf die
Validation einer Simulation eingegangen.
Initialisierungsprozess
Der Initialisierungsprozess übernimmt die Initialisierung des Simulators und das
Bootstrapping-Verfahren (siehe Abschnitt 2). Da in den Experimenten immer von
einer statischen Topologie ausgegangen wird, stellt das Bootstrapping den finalen
Topologie-Zustand dar. Die Erweiterung des dynamischen Verhalten wird über Methoden des Eintretens wie auch Austretens realisiert, die während der Erstellung
genutzt werden. Das Sequenzdiagramm 6.4 demonstriert den Ablauf, wobei die Instanz der Klasse SimlatorModel den Start auslöst. Der Configurator wird beauftragt, die Konfiguration einzulesen, aus der die zu erstellenden Topologien und deren Verknüpfung entnommen wird. Die Initialisierung der gewünschten Metriken zur
statistischen Auswertung bilden den nächsten Schritt. Abschließend wird der Simulationszyklus gestartet, indem der MessageGenerator und der Simulationcycle in
die Warteschlange der Ablaufsteuerung eingereiht werden.
Bild 6.4.. Initialisierungsprozess des Simulators
90
6.2. Feinentwurf
Nachrichtenversand
Wie anfangs beschrieben stellen Simulationselemente Datenobjekte dar, die Methoden zur Bearbeitung bereitstellen. Das Sequenzdiagramm 6.5 verdeutlicht den Ablauf
des Nachrichtenversandes und -empfanges über zwei Simulationsschritte. Im ersten
Simulationsschritt lagert die Strategy des sendenden Elementes die zur Weiterleitung
bestimmten Nachricht bei dem Empfängerelement ein. Nach Ablauf aller Einlagerungen wird zum Zeitpunkt t=0.5 die Klasse SimulationCycle aufgerufen, die für jedes Simulationselement, dass mindestens eine neue Nachricht zu verarbeiten hat, ein
Ereignis ausgelöst. Aus Performanzgründen musste dieser Weg gewählt werden, da
sonst für jede neue Nachricht ein eigenes Ereignis ausgelöst wird. Weiterhin werden
alle verwendeten Metriken berechnet.
Nach Abarbeitung aller in diesem Simulationsschritt getätigten Aufgaben, ruft die
Ablaufsteuerung zum Zeitpunkt t=1.0 die Methode eventRoutine aller eingetroffenen Ereignisse auf, die dann die Ausführung der accept()-Methode der ereignisbezogenen Elemente bewirkt. Da Elemente keine Logik beeinhalten, rufen sie ihre
zugewiesene Strategie zur endgültigen Verarbeitung auf. Die Wiederholung dieser
Weiterleitungen hängt von den gewählten Strategien ab, da diese durch anfängliche
Parametrisierung die Suchtiefe u.ä. festlegen. Sind Beendigungskriterien der Strategien erfüllt und erfolgen keine dem System neu hinzugefügten Nachrichten, so kehrt
das System in seinen ursprünglichen inaktiven Zustand zurück.
6.2.5. Validation
Die Schwierigkeit der Validation einer Abbildung der realen Gegebenheiten wurde
in Abschnitt 5.1.2 angesprochen. Als zur Verfügung stehende Mittel werden die Ausgabedokumente, sowie eine grafische Visualisierung der verwendeten Topologien angeboten. Der Verlauf während des Weiterleitens von Nachrichten wird automatisch
generiert und kann manuell erweitert werden. Die Sichtweise von Ausschnitten dieses Dokumentes wird von dem Rahmenwerk ’Desmo-J’ bereitgestellt und ist in dem
Simulator integriert. Um sich einen Einblick in den Aufbau der gewählten Topologien zu verschaffen, können diese durch eine grafische Darstellungsfunktion betrachtet
werden.
91
6. Entwurf und Implementierung
Bild 6.5.. Ablauf des Nachrichtenversandes von einem Simulationselement zu einem
Empfänger
92
6.3. Implementierung
6.3. Implementierung
Der kurzen Beschreibung der Entwicklungsumgebung folgt die Darstellung der Implementation des vorangegangenen Entwurfes aus Benutzersicht. Die wichtigsten Funktionen zum Umgang mit der grafischen Version des Simulators werden aufgezeigt.
6.3.1. Entwicklungsumgebung
Zur Einhaltung der Plattformunabhängigkeit wurde Java in der Version 1.42 als Programmiersprache gewählt. Die Implementierung des beschriebenen Entwurfs erfolgt
mit Hilfe der Entwicklungsumgebung IntelliJ IDEA10 in der Version 4.5. Die verwendeten Bibliotheken zur grafischen Visualisierung der Metriken (JFreeChart) und
das Rahmenwerk Desmo-J basieren ebenfalls auf Java, so dass keine weitere Programmiersprache erforderlich ist und sich die Integration der Bibliotheken möglichst
vereinfacht gestaltet.
Als Buildmanagement-Werkzeug wurde Apache Ant11 in der Version 1.6 verwendet.
Eine detaillierte Beschreibung des Umgangs erfolgt im Anhang C.
6.3.2. Benutzerschnittstelle
Der Simulator kann in zwei verschiedene Arten betrieben werden. Es ist die Verwendung mit grafischer Oberfläche wie auch ohne vorgesehen. Der Ausgabebericht bleibt
hiervon unberührt. Jegliche Konfiguration basiert auf den Konfigurationsdateien und
kann manuell oder über die grafische Benutzungsoberfläche bearbeitet werden. Die
manuelle Konfiguration wurde in den wichtigsten Punkten unter 5.3.1 behandelt. Im
Folgenden wird auf die grafische Verwendung des Simulators eingegangen.
Konfiguration
Die Abbildungen 6.6 und 6.7 veranschaulichen einen Teil der Einstellungsmöglichkeiten. Unterschieden wird hierbei von Einstellungen bzgl. des Experimentes, der zu
simulierenden Overlays, den verwendeten Strategien und aktivierten Metriken. Über
eine Werkzeugleiste kann jederzeit eine bestehende Simulation gestartet und beeinflusst werden. Die Statusleiste verdeutlicht den Fortgang der Simulation anhand diskreter und realer Zeitschritte. Der aktuelle Stand innerhalb des Experimentes ist über
die Laufleiste ersichtlich.
10
11
http://www.jetbrains.com/idea/, zuletzt besucht am 20.10.2005
http://ant.apache.org/, zuletzt besucht am 20.10.2005
93
6. Entwurf und Implementierung
Bild 6.6.. Konfiguration der zu simulierenden Overlays
Bild 6.7.. Konfiguration der zu simulierenden Strategien
Die Einstellungen zu den Strategien erfolgen dynamisch zur Laufzeit mittels Introspektion (siehe 6.1). Somit ist die Möglichkeit geschaffen, ohne den Eingriff in die
Oberflächengestaltung neue Strategien zu entwickeln und sie über die Oberfläche zu
konfigurieren.
Werkzeuge
Dem Simulator sind einfache Werkzeuge hinzugefügt. Hierzu zählen Generatoren zu
den Topologien und Anfragen, die je nach Implementierung parametrisiert werden
können. Die Abbildung 6.8 veranschaulicht die Generierung einer virtuellen Topologie.
Als Eingabe wird eine Topologie für die Verbindung der Super-Peers verwendet, die
durch den Topologie-Generator gt-item geliefert wird. Die Größe der Cluster, sowie
die Verteilung von Ressourcen und die Größe sind als weitere Parameter anzugeben.
Zur visuellen Überprüfung der erstellten Topologien ist deren Visualisierung als
Graph in einem weiteren Werkzeug enthalten. Es kann hierbei jedoch lediglich von
einer subjektiven Überprüfung gesprochen werden, da der visuelle Überblick bei wenigen hundert Knoten nicht mehr gegeben ist. Zur Verbesserung der Übersichtlichkeit
ist eine Einschränkung der Knoten anhand ihres Grades vorzunehmen.
Start eines Experimentes
Nachdem alle gewünschten Einstellungen vorgenommen worden sind, kann die Simulation über die Werkzeugleiste gestartet werden. Der in dem Feinentwurf 6.2 beschriebene Initialisierungprozess bereitet hierbei die Simulation vor. Zur aktuellen
94
6.3. Implementierung
Bild 6.8.. Topologiegenerator zur Erzeugung einer virtuellen Topologie
Überwachung des Experimentes erscheint der in Abbildung 6.9 gezeigte Überwachungsbildschirm, der sich je nach gewählten Metriken voneinander unterscheiden
kann. Das Ende des Experimentes wird entweder durch eine vorgegebene Laufzeit
oder durch eine vorzeitige Beendigung erreicht. Die erzeugten Grafiken lassen sich
durch ein Kontextmenü abspeichern, drucken und in der Darstellung ändern.
Der Ausgabebericht
Der erzeugte Ausgabebericht kann über die Werkzeugleiste aufgerufen werden. Die
erzeugte Dokumente lassen sich dort je nach voreingestelltem Format darstellen. In
der Darstellung 6.10 ist eine HTML-Ausgabe erzeugt worden, die textuell die Experimentparameter und die statischen Werte anzeigt. Die schrittweise Darstellung der
Simulation (Beispiel in Abb.. 6.11) gibt Aufschluss über den detaillierten Ablauf der
Simulation. In dieser Auflistung sind alle Ereignisse dokumentiert, die sich während
der Simulation ereignet haben.
95
6. Entwurf und Implementierung
Bild 6.9.. Aktuelle Betrachung der Messergebnisse aller gewählten Metriken während der Laufzeit
Bild 6.10.. Ausgabebericht mit Darstellung der Experimenteinstellungen
und Ergebnisse
96
Bild 6.11.. Zeitliche Auflistung aller
während der Simulation eingetretenden Ereignisse
7. Experimente
Diese Kapitel soll den Einsatz des Simulators anhand von drei Experimenten verdeutlichen. Eine anschließende Bewertung und Validation rundet dieses Kapitel ab.
7.1. Abgrenzung eines Experimentes
Experimente können unterschiedlicher Art sein, so dass eine genauere Abgrenzung an
dieser Stelle unabdingbar ist. Um einen möglichst hohen Grad an Reproduzierbarkeit
zu erlangen, wird in dieser Arbeit nur von kontrollierten Experimenten ausgegangen,
die nach Prechelt [Pre01] als ”[..]Studie, bei der alle voraussichtlich für das Ergebnis relevanten Umstände (Variablen) konstant gehalten werden (Kontrolle), mit Ausnahme
von einem oder wenigen, die den Gegenstand der Untersuchung bilden (Experimentvariablen).[..]”.
7.2. Beschreibung der Experimente
Zur Demonstration der Verwendung des Simulators werden nun drei Experimente geführt, die die Overlays separat wie auch kombiniert simulieren. Die Implementation
der Verfahren ist dem Anhang A.3, A.4 und A.5 zu entnehmen. Jede vorgenommene
Konfiguration der Experimente sowie deren Beschreibung und Ergebnis ist im Anhang B zu finden. Da sich die folgenden Vergleiche auf die einzelnen Ergebnisse der
Konfigurationen beziehen, sollten diese vorher studiert werden. Weiterhin wird das
Verständnis der in Abschnitt 5.2.1 beschriebenen Metriken vorausgesetzt.
1. Das erste Experiment VRW-VC stellt das Random-Walks-Verfahren (Abschnitt 3.2.3) in drei Konfigurationen einem Chord-basierten Ansatz (Abschnitt
3.3.1) in zwei Konfigurationen gegenüber. Hierbei wird die virtuelle Ebene alleine simuliert.
2. In dem zweiten Experiment ORW-OIBFS werden innerhalb des organisatorischen Overlays das Random-Walks-Verfahren (ORW) mit einem verwandten
(OIBFS) verglichen, das jedoch organisatorische Beziehungen in höherem Ausmaß interpretiert.
97
7. Experimente
3. Das abschließende Experiment OIBFS-VC gibt Auskunft über die Kombinationsmöglichkeiten beider Overlays zur Unterstützung ungenauer Suchanfragen.
Hierbei werden die Verfahren VC und OIBFS kombiniert.
Die Bewertung im Anschluss bereitet die Rohdaten der Experimente exemplarisch
auf und zeigt einen Weg auf, Experimente mit Hilfe des vorgestellten Simulators
durchzuführen.
7.3. Analyse der Experimente
Um ein geeignetes Verfahren für organisations-orientierte Super-Peer-Architekturen
zu simulieren, wurden die Experimente (siehe Kapitel B) durchgeführt und werden nun hier analysiert. Die als Vergleichskriterium verwendeten Grafiken dienen
als Zusatz zu den Ausgabeberichten, da sie Rundungswerte gegenüberstellen und
hieraus Tendenzen ersichtlich machen. Die Relation der gegenübergestellten Daten
kann in ihrem Grad durchaus abweichen. Die nun vorgestellten Vergleiche resultieren
in der Verknüpfung zweier Verfahren (Experiment OIBFS-VC), die für die Suche in
organisations-orientierten Super-Peer-Architekturen verwendet werden können. Hierzu siehe ebenfalls Abschnitt 8.1.
7.3.1. Vergleich VRW-VC
Die Abbildungen 7.1 und 7.2 verdeutlicht die Auswirkungen unterschiedlicher Parametereinstellungen des Random-Walks Verfahren VRW sowie den Vergleich mit
einem parameterlosen Chord-basierten Ansatz VC. Die beiden dortigen Grafiken beziehen sich auf die Suche nach einem eindeutigen Kriterium sowie auf die Suche nach
mehrdeutigen Kriterien. Sie dienen jedoch lediglich der Hinführung zu den späteren
Experimenten und werden daher nur kurz angesprochen.
VRW1 und VRW2 sowie VRW4 und VRW5 zeigen Ähnlichkeiten in der Anzahl an
versendeten Nachrichten. Die jeweils erste Konfiguration VRW1 und VRW4 (Walkeranzahl=1)verursachen im Durchschnitt lediglich 40% bzw. 46% der Nachrichten des
entsprechenden Pendants VRW2 und VRW5 (Walkeranzahl=3). Da jeder empfangene Peer bis zu drei Walker aussenden darf, entsteht ein exponentielles Anwachsen
des Nachrichtenaufkommens, das durch die Metrik VMS in den Abbildungen B.2.1,
B.2.2 und B.2.4, B.2.5 zu sehen ist. Dieses exponentielle Anwachsen wird jedoch
nach wenigen Schritten durch eine Historie verringert, so dass im Durchschnitt nach
Ablauf der Simulation bei einer Verdreifachung der max. Walkeraussendungen (pro
Element) nur eine Verdopplung der Nachrichtenanzahl. Ausserdem werden in VRW2
und VRW5 die Antworten in vierfacher Geschwindigkeit gefunden (siehe QSR der
jeweiligen Abbildungen).
98
7.3. Analyse der Experimente
300
250
200
150
100
50
0
Dauer
HTL
Walker
QSR
APM
HPQ
VMS
VME
VRW1
250
200
1
0,75241
1,40627
49,3025
11,508
0,01151
VRW2
250
200
3
0,93952
2,21418
37,28749
VRW3
250
10
3
0,76512
0,76512
7,02881
6,76
0,00676
VC1
250
0,95441
0,95441
7,08177
0,568
0,000568
28,7
0,0287
Bild 7.1.. Gegenüberstellung der Verfahren VRW und VC. Suche nach eindeutigen
Peernamen.
Die Verfahren VRW3 und VC1 sowie VRW6 und VC2 sind zu vergleichen, da
realistische Suchtiefenbeschränkungen in die Konfiguration aufgenommen wurden
(HTL<10). Signifikante Unterschiede entstehen durch die logarithmische Suchdauer des Chord-basierten Verfahren gegenüber dem exponentiellen Nachrichtenaufkommen der Random-Walks basierten Verfahren (siehe ∆ VMS in 7.1 und 7.2). Somit
entstehen klare Unterschiede zugunsten VC1 und VC2, die in den einzelnen Ausgabeberichten (siehe B.2.3,B.2.7 und B.2.6,B.2.8) am deutlichsten werden.
300
250
200
150
100
50
0
Dauer
HTL
Walker
QSR
APM
HPQ
VMS
VME
VRW4
250
200
1
0,84565
3,59059
42,54255
7,676
0,00768
VRW5
250
200
3
0,94507
4,63514
20,99885
16,216
0,01622
VRW6
250
10
3
0,79025
2,1309
7,7687
7,324
0,007324
VC2
250
0,94934
0,94934
8,42996
0,588
0,000588
Bild 7.2.. Gegenüberstellung der Verfahren VRW und VC. Suche nach (mehrfach
vorhandenen) Ressourcen.
99
7. Experimente
7.3.2. Vergleich ORW-OIBFS
Die Gegenüberstellung der Verfahren ORW (Abschnitt B.3.1) und IBFS (Abschnitt
B.3.2) zeigt klare Vorteile des zweiten Verfahrens auf. Beide Verfahren basieren auf
einer Breitensuche. Die in dem zweiten Verfahren implementierte einfache Logik bzgl.
des Aufbaus der organisatorischen Ebene resultiert in einer hohen Nachrichtenabnahme gegenüber dem ersteren ’blinden’ Verfahren (∆OMS in Abbildung 7.3). Desweiteren ist zu erkennen, dass Dauer einer Nachrichtenversendung (∆HPQ) und die damit
verbundene Zeit zur Erfüllung aller Anfragen (∆QSR) steigt.
250
200
150
100
50
0
Dauer
QSR
APM
HPQ
VRW1
120
0,45637
0,45637
30,57263
223,70833
OMS
0,22371
OME
OIBFS
120
0,9177
3,42608
6,6558
9,94167
0,00994
Bild 7.3.. Gegenüberstellung der Verfahren ORW und OIBFS
7.3.3. Vergleich OIBFS-VC
Die Auswirkungen der unterschiedlichen Abbildungen der Ebenen in den Experimenten OIBFS-VC1 und OIBFS-VC1 sind durch die durchschnittlichen zu verarbeitenden Nachrichten der virtuellen Elemente und der benötigten Zeit zu erkennen.
Dem Experiment OIBFS-VC1 liegt eine zufällige Gleichverteilung aller Elemente einer Organisation über die Cluster der virtuellen Ebene zugrunde. Die Nachrichten
werden anhand der vereinfachten Chord-Protokolls über das gesamte Netzwerk geleitet, so dass die Höchstbelastung eines einzelnen Peers um fast die Hälfte reduziert werden konnte (siehe MVE in Abbildungen B.4.1 und B.4.2). Die Kosten dafür schlagen
jedoch in einer um ein Drittel höheren aggregierten Netzlast des ersteren Experimentes zu Buche, da keine Lokalitätseigenschaften berücksichtigt wurden (siehe ∆VMS
in Abbildung 7.4). Das Auslassen dieser Eigenschaften verursacht zudem eine längere
Laufzeit, die anhand der Durchschnittwerte ∆QSR, ∆APM und ∆HPQ ersichtlich
100
7.3. Analyse der Experimente
80
70
60
50
40
30
20
10
0
APM
HPQ
VMS
VME
OMS
OME
OIBFS-VC1
50
0,66
1,54286
4,19256
70,12
0,07012
17,96
0,01796
OIBFS-VC2
Dauer
50
0,72571
QSR
1,78857
4,45923
46,84
0,04684
17,96
0,01796
Bild 7.4.. Gegenüberstellung der Verfahren OIBFS-VC1 und OIBFS-VC2
werden. Ebenso ist eine erhöhte Anzahl des maximalen Nachrichtenaufkommens der
organisatorischen Elemente zu verzeichnen. Eine plausible Begründung liegt in den
kürzeren Laufzeiten der Nachrichten, die die Wege zwischen den Peers verkürzen und
so zu einem verfrühten Rückmelden innerhalb der organisatorischen Ebene führt. Die
weiteren getroffenen Metriken tragen einer Unterscheidung nicht bei.
Zusammenfassend ergeben beide Verfahren wesentliche Vorteile gegenüber den vorherigen Experimenten, die jedoch in der Komplexität dieser begründet sind. Beide
Verfahren garantieren eine logarithmische Suchkomplexität über die Menge der SuperPeers S und dem Durchmesser des hierarchischen Netzwerkes von O(logS*d), wobei
die zweite Variante durch Hinzunahme einer erweiterten Logik bezüglich der Suchinterpretation wie folgt optimiert werden kann.
Eine Suche (∗, ry , ex ), die durch ein organisatorisches Element ez initiert wurde, könnte statt einer schrittweisen Annäherung direkt durch die Metadaten des Super-Peers
an ex geleitet werden, da dieser über Metadaten der gesamten inner-organisatorischen
Elemente verfügt. Die Wahrscheinlichkeit, dass die dem Elemente ex naheliegenden
Elemente die Suche erfolgreich beenden können, ist bei einer hierarchischen Vernetzung höher als bei weit Entfernten.
7.3.4. Validation der Ergebnisse
Wie bereits in Abschnitt 5.1.2 angepsrochen wurde, ist eine Validation der Experimente schwierig. In jedem Experiment werden Annahmen getroffen, die voneinander
abweichen können. Den folgenden Vergleichen aus der Literatur liegen meist eine
unterschiedliche Struktur und Größe der Topologien sowie andere Suchanfragen zugrunde.
101
7. Experimente
Zwei der simulierten Verfahren werden nun mit den Ergebnissen in der Literatur
verglichen. Das Random-Walks-Verfahren, welches in den Experimenten VRW-VC
(Abschnitt B.2) und ORW-OIBFS (Abschnitt B.3), wird als erstes untersucht. Die
zweite Beschreibung geht auf das Chord-basierte Verfahren VC (Abschnitt B.2) ein.
Das Verfahren Random-Walks (Abschnitt 3.2.3) kann in zwei Alternativen eingesetzt
werden. Entweder werden initial eine feste Anzahl an Walkern definiert, die dann das
Netzwerk durchlaufen oder es werden bei jeder Weiterleitung neue Walker ausgesendet, so dass die Anzahl mit der Pfadlänge steigt.
Hier wurde die zweite Alternative betrachtet, die ohne Optimierung ein exponentiell steigendes Nachrichtenaufkommen mit steigender Pfadtiefe verursacht. Als Optimierung wurde eine Historie verwendet, so dass keine Knoten mehrfach besucht
werden und ein Backtracking-Algorithmus verwendet, der bei einer hohen Lebensdauer das komplette Netzwerk durchkämmt. Ein Vergleich mit den in der Literatur
[LCC+ 02; TR03c] vorgenommenen Simulationen erweist sich als äußerst schwierig, da
gerade bei Suchverfahren der ersten Generation viele Optimierungen vorgenommen
werden können, die einen Vergleich erschweren. Intuitiv verständlich ist, dass eine
Erhöhung der Anzahl an ausgesendeten Walker die Erfolgsrate und das Nachrichtenaufkommen erhöht.
Mizrak et.al [MCKS03] (Abschnitt 3.3.1) stellten ein Chord-basiertes Suchverfahren
für Super-Peer-Architekturen vor, in dem die Super-Peer auf einem Chord-Ring platziert werden. Die Autoren simulieren ungefähr 10000 Peers, die zwischen 55 und 125
Ressourcen besitzen. Die Topologie verändert sich während der Simulation durch beabsichtigtes Ein- und Austreten sowie durch unbeabsichtige Ausfälle. Die Ergebnisse
sind auf Speicherverbrauch, Skalierbarkeit und Nachrichtendurchsatz ausgerichtet.
Das in der hier vorliegenden Arbeit durchgeführte Experiment untersucht andere Eigenschaften wie Pfadlänge einer Nachricht, Nachrichtenaufkommen und Erfolgsrate.
Daher wird nun ein Vergleich zu dem ursprünglichen Chord-Verfahren gezogen.
Die Suchdauer (in hops) nach einer Ressource mittels des Chord-Verfahren steigt logarithmisch mit der Anzahl der vorhandenen Peers. Genau diese Zeit wird maximal
für die Suche innerhalb des Super-Peer-Ringes in dem hier vorgestellten Verfahren
verwendet. Zusätzlich dazu kommen maximal zwei Nachrichten für das Weiterleiten
innerhalb des Ursprungsclusters und des Zielclusters hinzu, falls Ursprung und Ziel
’einfache Peers’ sind.
Somit muss das Experiment VRW-VC folgende Daten liefern:
Die Suche nach einer existierenden Ressource ist immer erfolgreich (siehe QSR
in Abb. B.2.7 und B.2.8).
Es dürfen maximal log2 (S) + 2 Nachrichten versendet werden, wobei S die
Anzahl der Super-Peers ausdrückt. Da in den Experimenten jeweils 256 SuperPeers simuliert werden, darf die maximale Anzahl an Hops zehn Schritte nicht
überschreiten (siehe HPQ in Abb. B.2.7 und B.2.8).
102
8. Schlussfolgerung und Ausblick
In dem abschließenden Kapitel wird ein Vorschlag gegeben, wie sich Suchverfahren in
organisations-orientierten Super-Peer-Architekturen gestalten können. Hierbei wird
auf zwei Varianten eingegangen, die situationsbedingt Vor-und Nachteile aufweisen.
Im Anschluss daran erfolgt in einem Fazit eine Beurteilung der Möglichkeiten wie
auch Schwächen des erstellten Simulators. Die Arbeit endet mit einem Ausblick, in
wieweit die Entwicklung fortgesetzt werden kann und welche offenen Fragen noch
bestehen.
8.1. Vorschlag eines organisations-orientierten Suchverfahrens
für Super-Peer-Architekturen
Prinzipiell lassen sich alle Verfahren der virtuellen Ebene mit denen der organisatorischen verbinden. Zur Entwicklung und Kombination von Verfahren ist der im Laufe
der Arbeit beschriebene Simulator erstellt worden. Im Folgenden wird ein mögliches
Verfahren vorgestellt, das durch die in Abschnitt 7 beschriebenen Experimente entstanden ist. Dem Vorschlag liegt ein Chord- basiertes Suchverfahren der virtuellen
Ebene zugrunde, das an Mizrak u.a. (siehe Abschnitt 3.3.1) angelehnt ist. Die darauf
aufbauende organisatorische Suche ermöglicht neben exakten Suchanfragen ebenfalls
ungenaue Anfragen, die mittels bisheriger DHT-Verfahren nicht lösbar waren.
8.1.1. Aufbau der virtuellen Ebene
Der virtuellen Ebene liegt eine Super-Peer-Architektur zugrunde. Die dortigen SuperPeers pflegen ein Cluster, dessen Peers gewissen Bedingungen genügen müssen. Alle
in einem Cluster befindlichen Peers, sowie deren Super-Peer werden mittels einer
Hash-Funktion auf genau denselben Wert abgebildet. Als Funktionsparameter wird
der jeweilige Name des Peers herangezogen. Auf den Topologieaufbau sowie die dynamischen Veränderungen wird später eingegangen. Mit einer diesen Anforderungen
entsprechenden Topologie wird die Suchtiefe nach einem Peernamen stärker eingeschränkt, als es in der ursprünglichen Version der Chord-Protokolls möglich war. Die
Suchtiefe, die in der betrachteten diskreten Sichtweise der Suchzeit entspricht, ist
von logarithmischer Komplexität. Jedoch wird nicht die Anzahl aller Peers N zur
Berechnung herangezogen, sondern lediglich die Anzahl der Super-Peers S benötigt.
Die Suche nach einem Peernamen entspricht somit O(log(S)), S ∈ N .
103
8. Schlussfolgerung und Ausblick
Eine Anfrage erreicht nach maximal dlog(S) + 2e Schritten den entsprechenden ZielPeer und benötigt dann noch einen Schritt für die direkte Antwort zum Initiator.
Die logarithmische Suchzeit begründet sich durch den Einsatz eines Chord-Ringes.
Die weiteren zwei Suchschritte entstehen dadurch, dass ein ’einfacher Peer’ seinen
Super-Peer kontaktieren muss und der Ziel-Peer ebenfalls ein ’einfacher Peer’ ist.
8.1.2. Aufbau der organisatorischen Ebene
Die organisatorische Ebene wird vereinfacht als hierarchisch angesehen. Elemente unterschiedlicher (hierarchischer) Ebenen stehen in (gerichteten) Beziehungen, wobei
der Name einer Beziehung die semantische Bedeutung ausdrückt. Innerhalb dieser
Hierarchie können sowohl ungenaue als auch exakte Anfragen formuliert werden. Die
Anfragenformulierung beschränkt sich jedoch auf das 3-Tupel der Verbindungen (siehe Abschnitt 2.3). Anfragen werden durch die Angabe eines 3-Tupels
(E1 , mem mem, E1 ), E1 ∈ M ember oder (E1 , pro pro, E1 ), E1 ∈ P roject exakt formuliert.
Ungenaue Anfragen entsprechen einem 3-Tupel mit Sternchen-Operator wie folgt
(E1 , mem gro, ∗), E1 ∈ M ember oder (∗, pro gro, E1 ), E1 ∈ Group.
Aufbauend auf diesen Basisanfragen lassen sich durch Verknüpfung komplexere Suchen formulieren. Die Suchtiefe einfacher Anfragen hängt von dem Durchmesser des
hierarchischen Netzwerkes ab. Der ’Worst-Case’ tritt bei einer Suche eines Gruppenmitglieds nach einer Gruppe einer anderen Organisation unter Angabe eines Mitglieds
dieser ein ((∗, grom em, Ex )). Die Anfrage wird über die zuständige Organisation zur
Zielorganisation hinunter zu dem Gruppenmitglied Ex geleitet.
8.1.3. Verbindung der virtuellen und organisatorischen Ebene
Es werden nun zwei Varianten vorgestellt, die beiden Ebenen miteinander zu verbinden. In beiden Fällen werden die Elemente der Ebenen mit gleichen Eigenschaften bzgl. der Hochverfügbarkeit und Netzanbindung aufeinander abgebildet. In den
Experimenten werden Organisationen und Super-Peers ähnliche Eigenschaften zugeschrieben, da sie einen Kommunikationsengpass darstellen. So entspricht die Anzahl
der Organisationen denen der vorhandenen Super-Peers. Ebenso könnten Projekte
als weiterer Engpass angesehen werden, so dass die Anzahl an Super-Peers hiermit
steigen würde. Die Abbildung der weiteren Elemente auf Peers eines Clusters variiert
jedoch.
Variante 1
Alle weiteren organisatorischen Elemente treten im Netzwerk als einfache Peers auf.
Peers, die ein organisatorisches Element Ex darstellen, gehören dem Cluster eines
104
8.1. Vorschlag eines organisations-orientierten Suchverfahrens für
Super-Peer-Architekturen
Super-Peers Sy an, wobei eine Abbildungsfunktion h definiert wird, die ein organisatorisches Element eindeutig auf eine Super-Peer-ID abbildet und schließlich einem
beliebigen Peer Pz dieses Super-Peers zugeordnet wird (Ex − > Sy − > Pz ). Durch
eine Gleichverteilung der Abbildungfunktion stimmt die Größe der einzelnen Cluster
nahezu überein. Abbildung 8.1 veranschaulicht in einem Ausschnitt die gleichverteilten Verknüpfungen.
or
g
O0
or
P00
g_
o
pr
org_org
org
_p
ro
p
G010
O
h(
h(
0
01
1
g ro
ro _
O2
h
)=
0
P
(S
)=
h(
)
0
SP
p ro
gr o
CP0_0
G011
em
_m
gro
_m
em
CP1_5
SP1
SP0
CP0_1
CP2_3
SP2
SP3
CP3_4
Cluster SP0
_gr
o
CP1_9
)
0
rg
P01
M0110
M
o
g_
or
g
or
_o
r
O3
g_
or
g
O1
CP2_2
M0111
h(M0111)=
h(SP1)
h(G011)=h
h(P01
(SP2)
P3)
) =h ( S
CP3_7
Chord-Ring
Bild 8.1.. Ausschnitt der Ebenenverknüpfung, die durch die gleichverteilte Verbindungsfunktion h entstehen
Variante 2
In dieser Variante wird auf eine Gleichverteilung zu Gunsten der Lokalitätseigenschaften verzichtet. Jeder Teilast einer Hierarchie beginnend bei einer Organisation wird
auf einen Super-Peer und dessen Cluster abgebildet. Durch die hohe Lokalität werden Suchen innerhalb einer Organisation auch innerhalb eines Clusters geroutet. Im
Falle größerer Organisationen (wenige Organisationselemente) kann die Anzahl an
Super-Peers steigen, in dem Projekte ebenfalls auf Super-Peers abgebildet werden.
Bei obiger Suche würde dann ein fester Teilbereich des P2P-Netzwerkes durchsucht.
Die verursachte Last weitet sich nicht auf andere Bereiche des Netzwerkes aus. Abbil-
105
8. Schlussfolgerung und Ausblick
dung 8.2 veranschaulicht die Verknüpfungen mit bleibenden Lokalitätseigenschaften.
O1
0
)
Cluster SP0
)
M3110
P2
)
)=h
(SP
2
M0110
G011
em
_m
gro
gro
_m
em
h(SP2)
gro
(S
)=
h
10
31
CP1_5
CP1_9
CP0_0
CP0_1 SP1
CP0_2
SP0
SP2 CP2_3
CP2_2
SP3
CP2_5
CP3_4
CP3_7
h(
M
)
(SP
pro
_
3 11
0
)=h
G311
P01
h(G
(SP
0
P0)
)=h(S
)=h
h (O
_g
ro
h(P31)=
00
h(G010
h (P
G010
P31
pro
ro
_g
pro
h(SP0)
P00
pro
h(M0110)=
g
or
_p
ro
O2
org_org
org
_
org
h(O3)=h(SP2)
or
g_
or
g
rg
_o
org
O0
ro
_p
O3
g
or
g_
or
Chord-Ring
Bild 8.2.. Ausschnitt der Ebenenverknüpfung, die durch die Organisationen abbildende Verbindungsfunktion h entstehen
8.2. Zusammenfassung und Fazit
Motiviert durch eine organisations-orientierte Domäne wurde im Rahmen dieser Arbeit ein Überblick über bestehende Suchverfahren in Peer-to-Peer (P2P) Architekturen geschaffen, der Aufschluss über die Funktionsweise der Verfahren sowie deren
Gemeinsamkeiten und Unterschiede gibt. Dieser Überblick diente der Entwicklung
eines generischen Simulators, der keine Einschränkungen bezüglich der zu untersuchenden Verfahren stellt. Neben der Simulation von P2P-Architekturen sollte nun
ein organisations-orientierte Overlay zusätzlich berücksichtigt werden, um als abschließendes Ergebnis dieser Arbeit ein Suchverfahren für organisations-orientierte
Super-Peer-Architekturen vorzuschlagen.
Die vorgestellte Arbeit unterteilt sich demnach in verschiedene Teilaufgaben, die direkt voneinander abhängig sind, so dass der auf eigenen Simulationen beruhende
106
8.3. Anknüpfungspunkte und Ausblick
Vorschlag eines domänen-spezifischen Suchverfahrens die Erfüllung der vorangegangenen Teilaufgaben bedingt. Die resultierenden Ziele dieser Arbeit werden nun kurz
zusammengefasst.
Angesichts der starken Entwicklung von Suchverfahren für P2P-Architekturen, existiert eine Vielzahl an Verfahren, die jedoch bisher nicht zusammenfassend betrachtet
wurden. Der hier gegebene Überblick von ca. 40 Verfahren mit jeweiligen Verfeinerungen stellt einen umfassenden Einblick in die Entwicklung der vergangenen Jahre
dar.
Simulatoren für P2P-Architekturen sind keine Neuerung. Viele der bisherigen Simulatoren entstanden durch die Entwicklung neuer Suchverfahren, um diese auf ihre
Eigenschaften hin zu untersuchen. Hierbei wurden spezielle Annahmen getätigt, die
den generellen Einsatz ausschließen. Weitere Simulatoren entstanden, die entweder
spezielle Eigenschaften untersuchen und dahingehend ausgelegt sind oder den Einsatz
erschwierigen, da keine Dokumentation erstellt wurde. Die grafische Visualisierung
sowie die Bereitstellung von Exportmöglichkeiten der gelieferten Rohdaten wurden
fast ausnahmslos vernachlässigt.
Der in dieser Arbeit entwickelte Simulator eaSim wurde ganzheitlich entworfen. Die
nicht benötigte Funktionaltität des Ein- und Austretens von Peers kann durch die
Implementierung vorgegebener Schnittstellen erstellt werden. Durch die allgemeine
Modellierung lassen sich verschiedene Architekturstile simulieren. Die domänenspezifische Simulation ist optional, so dass ein Einsatzgebiet hierdurch nicht beschränkt
wird. Die Arbeit wird erleichtert, indem Suchalgorithmen per Introspektion durch
eine intuitive Oberfläche verwendet werden und diese den Fortgang der Simulation
durch eine grafische zeitabhängige Darstellung der gewählten Metriken visualisiert.
Der Vorschlag eines organisations-orientierten Suchverfahrens ist an das DHT-Suchverfahren von Mizrak et.al. (Abschnitt 3.3.1) angelehnt. Verfahren, die verteilte Hashtabellen verwenden, lassen keine ungenauen Suchanfragen zu, da hierüber kein eindeutiger Hash-Wert berechnet werden kann. Das vorgeschlagene Verfahren umgeht
diese Einschränkung durch die Hinzunahme eines anderen Verfahrens innerhalb des
organisatorischen Overlays, das ungenaue Suchanfragen interpretieren kann.
Zusammenfassend ermöglicht die vorliegende Arbeit in Verbindung mit dem erstellten
Softwareprodukt die Simulation unterschiedlichen Verhaltens von Architekturelementen (hier Peers).
8.3. Anknüpfungspunkte und Ausblick
Im Laufe einer Entwicklung und dem damit verbundenen tieferen Einblick in den
Untersuchungsbereich ergeben sich neue Fragen, die es zu klären gilt. Somit ergeben
sich auch hier weitergehende Ansätze.
107
8. Schlussfolgerung und Ausblick
Komplexe Zusammenhänge werden häufig aus Zeit- und Kostengründen simuliert.
Der, meiner Ansicht nach, wichtigste Aspekt dieser Simulationen, ist die Aussagekraft
dieser. Simulationen bedingen einer Verifikation und Validation, die sich jedoch häufig
als recht schwierig erweist. Systeme, die in der Realität noch nicht existieren, können
keine Informationen über den realen Ablauf liefern, so dass lediglich Hypothesen
überprüft werden können. Die automatische Überprüfung von Verhaltenshypothesen
wie auch von dem realen Verhalten eines Systems könnte dem Simulator durch eine
geeignete Datenstruktur beigefügt werden, so dass im Anschluss einer Simulation eine
automatische Überprüfung stattfände.
Für Simulationen mit wenigen Elementen wäre eine grafische Visualisierung der zurückgelegten Wege einzelner Nachrichten denkbar. Diese könnte in Form eines pulsierenden Netzwerkes ablaufen, das zur Laufzeit Aufschluss über Veränderungen aufzeigt.
Das Desmo-J Rahmenwerk hält eine Reihe an Konstrukten vor, die genutzt werden
können. Die Nutzung erwies sich als überaus positiv und soll an dieser Stelle weiterempfohlen werden. Durch Profiler-Test ergab sich jedoch eine erhöhte CPU-Zeit des
Schedulers, da sich die interne Struktur der Warteschlangen sehr allgemein, jedoch
für diese Arbeit weniger effizient erwies. Eine effizientere Arbeitsweise des Schedulers
könnte die Simulationsgeschwindigkeit beträchtlich erhöhen und ließe sich durch den
modularen Aufbau von Desmo-J mit wenig Aufwand vollziehen.
Der interne objekt-orientierte Aufbau aller Entitäten (Peers und Nachrichten) während der Simulation vereinfacht die Handhabung, birgt jedoch auch Performanzeinbußen. Simulationen von mehr als 50000 Elementen und regem Nachrichtenverkehr
sind angesichts der entstehenden Speicherlast nicht durchzuführen. Eine Verschlankung der Datenstruktur würde dieses Problem verringern.
108
Literaturverzeichnis
[AB05] Adelsberger, Heimo H. und Dr. M. Bick: Simulation - Begriffe und Modellierung. http://vawi74.wi-inf.uni-essen.de/ss05sim/
05Simulation_SS05.pdf, Letzter Zugriff 7.07.2005, 2005. Vorlesungsskript der Universität Duisburg-Essen.
[ALPH01] Adamic, Lada A., Rajan M. Lukose, Amit R. Puniyani und
Bernardo A. Huberman: Search in Power-Law Networks. CoRR,
cs.NI/0103016, 2001.
[BA99] Barabási, Albert-László und Réka Albert: Emergence of scaling
in random networks. In: Science 286, Seiten 509–512, 1999.
[Ban98] Banks, Jerry: Handbook of Simulation. Wiley-Interscience, 1998.
[Ban99] Banks, Jerry: Introduction to simulation. In: Winter Simulation Conference, Seiten 7–13, 1999.
[BCAA04] Barbosa, Marcelo Werneck, Melissa Morgado Costa, Jussara M. Almeida und Virg&#237;lio A. F. Almeida: Using locality
of reference to improve performance of peer-to-peer applications. SIGSOFT Softw. Eng. Notes, 29(1):216–227, 2004.
[BEH+ 01] Brandes, Ulrik, Markus Eiglsperger, Ivan Herman, Michael
Himsolt und M. Scott Marshall: GraphML Progress Report. In:
Graph Drawing, Seiten 501–512, 2001.
[Ben75] Bentley, J. L.: Multidimensional binary search trees used for associative searching. In: Communications of the ACM, Seiten 509–517, 1975.
Volume 18.
[BH04] Bischofs, L. und W. Hasselbring: A Hierarchical Super Peer Network for Distributed Software Development. In: Dustdar, S., H.C.
Gall und A. de Lucia (Herausgeber): Proceedings of the Workshop
on Cooperative Support for Distributed Software Engineering Processes
(CSSE 2004), Seiten 99–106, Linz, Austria, 9 2004. Austrian Computer
Society.
109
Literaturverzeichnis
[BHPW04] Bauer, Daniel, Paul Hurley, Roman Pletka und Marcel
Waldvogel: Bringing Efficient Advanced Queries to Distributed Hash
Tables, Mai 2004.
[BHW05] Bischofs, Ludger, Wilhelm Hasselbring und Timo Warns:
Handbuch der Software-Architektur, Kapitel Peer-to-Peer-Architekturen.
dpunkt Verlag, 2005. voraussichtliches Erscheinungsdatum Dez. 2005.
[BMM02] Babaoglu, Özalp, Hein Meling und Alberto Montresor: Anthill: A Framework for the Development of Agent-Based Peer-to-Peer Systems. In: ICDCS, Seiten 15–22, 2002.
[BMR+ 96] Buschmann, Frank, Regine Meunier, Hans Rohnert, Peter
Sommerlad und Michael Stad: Pattern-Oriented Software Architecture — A System of Patterns. John Wiley Press, 1996.
[BS05] Bischofs, Ludger und Ulrike Steffens: Organisation-oriented
Super-Peer Networks for Digital Libraries. In: Agosti, Maristella, Hans-Jörg Schek und Can Türker (Herausgeber): Peer-to-Peer,
Grid, and Service-Orientation in Digital Library Architectures: 6th Thematic Workshop of the EU Network of Excellence DELOS, S. Margherita
di Pula, Cagliari, Italy, 24-25 June, 2004. Revised Selected Papers, Band
3664 / 2005 der Reihe Lecture Notes in Computer Science, Seiten 45–62.
Springer, 2005.
[BY01] Beverly
Yang,
Hector
Garcia-Molina:
Efficient
Search
in
Peer-to-Peer
Networks.
Technischer
Bericht,
Computer
Science
Department,
Stanford
University,
http://www.cs.utexas.edu/users/browne/CS395Tf2002/Papers/GarciaMolina-showDoc.pdf, 2001.
[CGM02] Crespo, Arturo und Hector Garcia-Molina: Routing indices
for peer-to-peer systems. Technischer Bericht, Stanford University,
http://www-db.stanford.edu/crespo/publications/crespoa ri.pdf, 2002.
[Cla01] Claassen, Sönke: Entwicklung anwendungsspezifischer Modellkomponenten für Produktionssysteme im Rahmen eines Simulationsframeworks.
Diplomarbeit, Universität Hamburg, 2001.
[CNY03] Chen, Kathryn, Loai Naamani und Karim Yehia: miChord: Decoupling Object Lookup from Placement in DHT-Based Overlays, 2003.
[CSWH01] Clarke, Ian, Oskar Sandberg, Brandon Wiley und Theodore W. Hong: Freenet: A Distributed Anonymous Information Storage
110
Literaturverzeichnis
and Retrieval System. Lecture Notes in Computer Science, 2009:46+,
2001.
[DLS+ 04] Dabek, Frank, Jinyang Li, Emil Sit, James Robertson,
M. Frans Kaashoek und Robert Morris: Designing a DHT for
Low Latency and High Throughput. In: NSDI, Seiten 85–98, 2004.
[DSX04] Dongfeng, Chen, Yang Shoubao und Peng Xiaoyan: TaChord:
a Chord System Using Topology-Aware Routing and Super Peers, 2004.
Department of Computer Science, University Science and Technology of
China.
[ER59] Erdos, P. und A. Renyi: On random graphs, 1959. Publ. Math. Debrecen, 6:290–297.
[Fer03] Ferber, Reginald: Information Retrieval: Suchmodelle und DataMining-Verfahren für Textsammlungen und das Web. dpunkt Verlag,
März 2003.
[FM03] Freedman, Michael J. und David Mazières: Sloppy Hashing and
Self-Organizing Clusters. In: IPTPS, Seiten 45–55, 2003.
[GBL+ 03] Gupta, Indranil, Ken Birman, Prakash Linga, Al Demers und
Robbert van Renesse: Kelips: Building an Efficient and Stable P2P
DHT Through Increased Memory and Background Overhead. In: Proceedings of the 2nd International Workshop on Peer-to-Peer Systems (IPTPS ’03), 2003.
[GGG+ 03] Gummadi, P. Krishna, Ramakrishna Gummadi, Steven D. Gribble, Sylvia Ratnasamy, Scott Shenker und Ion Stoica: The
impact of DHT routing geometry on resilience and proximity. In: SIGCOMM, Seiten 381–394, 2003.
[GHJV95] Gamma, Erich, Richard Helm, Ralph Johnson und John Vlissides: Design Patterns : Elements of Reusable Object-Oriented Software.
Addison Wesley, March 1995.
[Gil05] Gilbert, David: The JFreeChart Class Library. http://www.jfree.
org/jfreechart/jfreechart-1.0.0-rc1-install.pdf, Letzter Zugriff 7.07.2005, 2005.
[GS93] Garlan, David und Mary Shaw: An Introduction to Software Architecture. In: Ambriola, V. und G. Tortora (Herausgeber): Advances
in Software Engineering and Knowledge Engineering, Seiten 1–39, Singapore, 1993. World Scientific Publishing Company.
111
Literaturverzeichnis
[GSG02] Gummadi, P. Krishna, Stefan Saroiu und Steven D. Gribble: A
measurement study of Napster and Gnutella as examples of peer-to-peer
file sharing systems. Computer Communication Review, 32(1):82, 2002.
[GSGM03] Ganesan, P., Q. Sun und H. Garcia-Molina: YAPPERS: A Peerto-Peer Lookup Service Over Arbitrary Topology, 2003.
[Har04] Hargreaves, Tom: giFT-FastTrack.
http://gift-fasttrack.
berlios.de/, Letzter Zugriff 7.07.2005, 2004.
[HF56] Hall, A. D. und R. E. Fagen: Definition of System. General Systems
1, 1956.
[HJS+ 03] Harvey, Nicholas, Michael B. Jones, Stefan Saroiu, Marvin
Theimer und Alec Wolman: Skipnet: A scalable overlay network with
practical locality properties. In: In proceedings of the 4th USENIX Symposium on Internet Technologies and Systems (USITS ’03), Seattle, WA,
March 2003.
[Hor00] Horstmann, O.: Finite-Elemente-Gitter für das Küsteningenieurwesen
auf der Basis hierarchischer Gebietsmodelle. Dissertation, BTU Cottbus,
2000. ISBN 3-934934-01-3.
[Jes05] Jesi, Gian Paolo: PeerSim: build a new protocol for the peersim simulation framework. http://peersim.sourceforge.net/tutorial1/
tutorial1.pdf, Letzter Zugriff 7.07.2005, 2005.
[Jos03] Joseph, Sam: An Extendible Open Source P2P Simulator. P2P Journal,
Seiten 1–15, November 2003.
[KAD+ 04] Karbhari, Pradnya, Mostafa H. Ammar, Amogh Dhamdhere,
Himanshu Raj, George F. Riley und Ellen W. Zegura: Bootstrapping in Gnutella: A Measurement Study. In: PAM, Seiten 22–32,
2004.
[KGZY02] Kalogeraki, Vana, Dimitrios Gunopulos und D. ZeinalipourYazti: A Local Search Mechanism for Peer-to-Peer Networks. In: Proceedings of the Eleventh International Conference on Information and
Knowledge Management (CIKM), Seiten 300–307, 2002. http://www.
cs.ucr.edu/~vana/kalogeraki-cikm02.pdf.
[KK03] Kaashoek, M. Frans und David R. Karger: Koorde: A simple
degree-optimal distributed hash table. In: Proceedings of the 2nd International Workshop on Peer-to-Peer Systems (IPTPS ’03), 2003.
112
Literaturverzeichnis
[Kle00] Kleinberg, Jon: The Small-World Phenomenon: An Algorithmic Perspective. In: Proceedings of the 32nd ACM Symposium on Theory of
Computing, 2000.
[LCC+ 02] Lv, Qin, Pei Cao, Edith Cohen, Kai Li und Scott Shenker:
Search and replication in unstructured peer-to-peer networks. In: ICS,
Seiten 84–95, 2002.
[LCP+ 04] Lua, Eng Keong, Jon Crowcroft, Marcelo Pias, Ravi Sharma und Steven Lim: A Survey and Comparison of Peer-to-Peer Overlay Network Schemes. Technischer Bericht, IEEE COMMUNICATIONS
SURVEY AND TUTORIAL, 2004.
[LK99] Law, Averill M. und David M. Kelton: Simulation Modeling and
Analysis. McGraw-Hill Higher Education, 1999.
[Mat02] Matthies, Michael: Einführung in die Systemwissenschaft, 2002. Vorlesungsskript Uni Kassel WS 2002 / 2003.
[MBR03] Manku, G., M. Bawa und P. Raghavan: Symphony: Distributed hashing in a small world. In: 4th USENIX Symposium on Internet Technologies and Systems, 2003.
[MCKS03] Mizrak, Alper Tugay, Yuchung Cheng, Vineet Kumar und
Stefan Savage: Structured Superpeers: Leveraging Heterogeneity to
Provide Constant-Time Lookup. In: Proceedings of the Third IEEE Workshop on Internet Applications (WIAPP’03), Seiten 104–111, San Jose,
California, 2003.
[Mil67] Milgram, S.: The small world problem. In: Psychology Today, (2):60–
67, 1967.
[MK02] Menasc&#233;, Daniel A. und Lavanya Kanchanapalli: Probabilistic scalable P2P resource location services. SIGMETRICS Perform.
Eval. Rev., 30(2):48–58, 2002.
[MLMB01] Medina, Alberto, Anukool Lakhina, Ibrahim Matta und
John W. Byers: BRITE: An Approach to Universal Topology Generation. In: MASCOTS, Seiten 346–, 2001.
[MM02] Maymounkov, P. und D. Mazieres: Kademlia: A peer-to-peer information system based on the XOR metric, 2002.
[MNR02] Malkhi, Dahlia, Moni Naor und David Ratajczak: Viceroy: a
scalable and dynamic emulation of the butterfly. In: PODC, Seiten 183–
192, 2002.
113
Literaturverzeichnis
[Mon05] Monk: EMule - Network Guide. http://www.emule-project.net/
home/perl/help.cgi?l=1&rm=show_topic&topic_id=232, Letzter Zugriff 7.07.2005, 2005. EMule - Network Guide.
[MS03a] Mischke, Jan und Burkhard Stiller: Peer-to-Peer Overlay Network
Management through AGILE. In: Integrated Network Management, Seiten 337–350, 2003.
[MS03b] Mischke, Jan und Burkhard Stiller: Rich and Scalable Peer-toPeer Search with SHARK. In: Active Middleware Services, Seiten 112–
121, 2003.
[NW03] Naor, Moni und Udi Wieder: Novel architectures for P2P applications: the continuous-discrete approach. In: SPAA, Seiten 50–59, 2003.
[Pag91] Page, Bernd: Diskrete Simulation, Eine Einführung mit Modula-2.
Springer-Verlag, 1991.
[PLC00] Page, Bernd, Tim Lechner und Sönke Claassen: Objektorientierte
Simulation in Java. Libri Books on Demand, 2000.
[PR04] Pyun, Young June und Douglas S. Reeves: Constructing a Balanced, (log(N)/loglog(N))-Diameter Super-Peer Topology for Scalable P2P
Systems. In: Peer-to-Peer Computing, Seiten 210–218, 2004.
[Pre01] Prechelt, Lutz: Kontrollierte Experimente in der Softwaretechnik.
Springer Verlag, 2001.
[PRR97] Plaxton, C. Greg, Rajmohan Rajaraman und Andrea W. Richa: Accessing Nearby Copies of Replicated Objects in a Distributed Environment. In: ACM Symposium on Parallel Algorithms and Architectures,
Seiten 311–320, 1997.
[Pug90] Pugh, William: Skip Lists: A Probabilistic Alternative to Balanced
Trees. Commun. ACM, 33(6):668–676, 1990.
[RFH+ 01] Ratnasamy, Sylvia, Paul Francis, Mark Handley, Richard M.
Karp und Scott Shenker: A scalable content-addressable network. In:
SIGCOMM, Seiten 161–172, 2001.
[RMH98] Renesse, Robbert Van, Yaron Minsky und Mark Hayden: A
Gossip-Style Failure Detection Service. In: Proceedings of the IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing, 1998.
114
Literaturverzeichnis
[RV03] Reynolds, Patrick und Amin Vahdat: Efficient Peer-to-Peer Keyword Searching. In: Middleware, Seiten 21–40, 2003.
[Sch01] Schollmeier, Rüdiger: A Definition of Peer-to-Peer Networking for
the Classification of Peer-to-Peer Architectures and Applications. In:
Peer-to-Peer Computing, Seiten 101–102, 2001.
[Shi00] Shirky, Clay: What is P2P... And What Isn’t? http://www.openp2p.
com/pub/a/p2p/2000/11/24/shirky1-whatisp2p.html, zuletzt besucht am 17.10.2005, 2000.
[SM04] Schindelhauer, Christian und Peter Mahlmann: Algorithmen für
Peer-to-Peer-Netzwerke. Vorlesungsskript der Fakultät EIM, Institut für
Informatik Universität Paderborn, 2004. Version 4.4.1.
[SMK+ 01] Stoica, Ion, Robert Morris, David R. Karger, M. Frans Kaashoek und Hari Balakrishnan: Chord: A scalable peer-to-peer lookup
service for internet applications. In: SIGCOMM, Seiten 149–160, 2001.
[SMZ03] Sripanidkulchai, K., B. Maggs und H. Zhang: Efficient Content
Location Using Interest-Based Locality in Peer-toPeer Systems, 2003.
[SR01] Singla, Anurag und Christopher Rohrs: Ultrapeers: Another Step
Towards Gnutella Scalability. http://rfc-gnutella.sourceforge.
net/Proposals/Ultrapeer/Ultrapeers.htm, Letzter Zugriff 7.07.2005,
2001. Working Draft.
[SR02] Singla, Anurag und Christopher Rohrs: Ultrapeers:Another Step
Towards Gnutella Scalability. http://rfc-gnutella.sourceforge.
net/src/Ultrapeers_1.0.html, 2002. Version 1.0.
[SW03] Steinmetz, R. und K. Wehrle: Peer-to-Peer-Networking und - Computing. Informatik-Spektrum, 27(1):51-54, Februar 2004, 2003.
[TD03] Ting, Nyik San und Ralph Deters: 3LS – A Peer-to-Peer Network
Simulator. In: P2P ’03: Proceedings of the 3rd International Conference
on Peer-to-Peer Computing, Seiten 212–213. IEEE Computer Society
Press, 2003.
[TR03a] Tsoumakos, Dimitrios und Nick Roussopoulos: Adaptive probabilistic search for peer-to-peer networks. Technischer Bericht, University of Maryland, http://www.cs.umd.edu/dtsouma/objects/P2P2003.pdf,
2003.
[TR03b] Tsoumakos, Dimitrios und Nick Roussopoulos: A Comparison of
Peer-to-Peer Search Methods. In: WebDB, Seiten 61–66, 2003.
115
Literaturverzeichnis
[TR03c] Tsoumakos, Dimitrios und Nick Roussopoulos: A Comparison of
Peer-to-Peer Search Methods. In: WebDB, Seiten 61–66, 2003.
[TR05] Tsoumakos, Dimitrios und Nick Roussopoulos: AGNO: An Adaptive Group Communication Scheme for Unstructured P2P Networks. In:
Euro-Par, Seiten 1183–1193, 2005.
[Tso03] Tsoumakos, Dimitrios: Analysis and Comparison of P2P Search Methods, 2003.
[TXM03] Tang, Chunqiang, Zhichen Xu und Mallik Mahalingam: pSearch:
information retrieval in structured overlays. Computer Communication
Review, 33(1):89–94, 2003.
[VL03] Vuong, Son T. und Juan Li: ECSP: An Efficient Cluster Based P2P
Architecture. In: International Conference on Internet Computing, Seiten
860–865, 2003.
[VRBR94] Victor R. Basili, Gianluigi Caldiera und H. Dieter Rombach:
Goal Question Metric Paradigm. In: Encyclopedia of Software Engineering, Seiten 528–532. John Wiley & Sons, 1994.
[WL03] Wang, Chonggang und Bo Li: Peer-to-peer overlay networks: A survey. Technischer Bericht, Department of Computer Science, HKUST,
2003.
[XMH03] Xu, Zhiyong, Rui Min und Yiming Hu: HIERAS: A DHT Based
Hierarchical P2P Routing Algorithm. In: ICPP, Seiten 187–, 2003.
[XZ02] Xu, Zhichen und Zheng Zhang: Building low-maintenance expressways for p2p systems. Technischer Bericht HPL-2002-41, HP Laboratories Palo Alto, 2002.
[Yat03] Yatin, Yatin Chawathe: Making Gnutella-like P2P Systems Scalable,
2003.
[YGM02] Yang, Beverly und Hector Garcia-Molina: Improving Search in
Peer-to-Peer Systems. In: Proceedings of the 22nd International Conference on Distributed Computing Systems (ICDCS), 2002.
[YGM03] Yang, Beverly und Hector Garcia-Molina: Designing a SuperPeer Network. In: ICDE, Seiten 49–, 2003.
[YJB02] Yook, Soon-Hyung, Hawoong Jeong und Albert-Laszlo Barabasi: Modeling the Internet’s large-scale topology. PNAS, 99(21):13382–
13386, 2002.
116
Literaturverzeichnis
[ZCB96] Zegura, Ellen W., Kenneth L. Calvert und Samrat Bhattacharjee: How to Model an Internetwork. In: INFOCOM, Seiten 594–
602, 1996.
[ZDH+ 02] Zhao, Ben Y., Yitao Duan, Ling Huang, Anthony D. Joseph
und John Kubiatowicz: Brocade: Landmark Routing on Overlay Networks. In: IPTPS ’01: Revised Papers from the First International Workshop on Peer-to-Peer Systems, Seiten 34–44, London, UK, 2002. SpringerVerlag.
[ZKJ01] Zhao, B. Y., J. D. Kubiatowicz und A. D. Joseph: Tapestry: An
Infrastructure for Fault-tolerant Wide-area Location and Routing. Technischer Bericht UCB/CSD-01-1141, UC Berkeley, April 2001.
117
A. Suchstrategien
Suchstrategien stellen einen Schwerpunkt innerhalb des Simulators dar. Um bestehende Suchstrategien zu verwenden und zu konfigurieren, sowie neue zu erstellen wird
im Folgenden detailliert auf den Aufbau dieser eingegangen und anschließend anhand
eines Beispiels verdeutlicht.
A.1. Aufbau einer Suchstrategie
Um eine neue Suchstrategie zu entwicklen müssen einige Voraussetzungen erfüllt werden. Jede Suchstrategie bildet eine Instanz der abstrakten Klasse easim.strategy.AbstractStrategy (Listing A.1). Hierbei müssen die vier beschriebenen abstrakten Methoden implementiert werden. Die ersten beiden Methoden getDescription() und
getDefaultValues() werden zur Darstellung der Strategie in der grafischen Version des Simulators verwendet. Besonderse Achtsamkeit ist bei der Implementierung
der Methode getDefaultValues() geboten, da hier die Reihenfolge und die korrekte Typisierung der initialen Parameter mit denen des parametrisierten Konstruktors
übereinstimmen muss. Ein parameterloser Konstruktor ist zudem zu implementieren,
um mittels Introspektion die genannten Methoden aufzurufen. In dem Listing A.2
werden die beiden zuletzt beschriebenen Vorraussetzungen am Beispiel deutlich.
Von entscheidender Bedeutung für die Verwendung der Strategien ist die Methoden
search(). Zu jedem Zeitpunkt während der Simulation, zu dem ein Element eine neue
Nachricht erhält werden diese Methoden in der abgebildeten Reihenfolge aufgerufen.
Jegliche logische Funktionalität ist somit in dieser Methode enthalten.
1
package easim . strategy ;
2
3
public abstract class AbstractStrategy {
4
5
6
7
8
9
10
/* *
* Description of this strategy algorithm
*
* @return mapping description
*/
public abstract String getDescription () ;
11
12
118
/* *
A. Suchstrategien
* Getter for all default values . </ br >
* The order of defined public fields must be the same
as in the returned array
* @return default values for specified public fields
*/
public abstract Object [] getDefaultValues () ;
13
14
15
16
17
18
/* *
* This method contains the implementation of a search
algorithm , </ br >
* which will be assigned to an simulation element .
Because elements needs </ br >
* specific data , for each element an implementation
should be written .
*
* @param element Element to seach
* @param msg
Message with search criteriy etc .
* @return success of searching local
*/
public abstract boolean search ( SimulationElement
element , Message msg ) ;
19
20
21
22
23
24
25
26
27
28
29
}
Listing A.1. Aufbau einer abstrakten Suchstrategie
A.2. Beispiel einer Suchstrategie
Das in dem Listing A.2 dargestellte Listing verdeutlicht den Rumpf einer Beispielstrategie ohne Suchalgorithmus. Zubeachten sind die globalen Felder global var1
und global var2. Globale Felder (ausgedrückt durch das Schlüsselwort ’public’) entsprechen in ihrer Reihenfolge und Typisierung genau denen des parametrisierten
Konstruktors und Rückgabewertes der Methode getDefaultValues(). In der aktuellen Version des Simulators werden als Typen lediglich java.lang.String und
java.lang.Integer unterstützt. Primitive Typen wie int und short sind mittels Introspektion nicht zu erfassen und können daher nicht verwendet werden.
119
A. Suchstrategien
1
package easim . strategy ;
2
3
public class O r g a n i s a t i o n al S t r a t e g y _S a m p l e extends
AbstractStrategy {
4
public Integer global_var1 ;
public Integer global_var2 ;
5
6
7
private int local_var1 ;
8
9
/* *
* Default constructor for retrieving the default values
of declared fields
*/
public O r g a n i s a t i o n a l S t r a t e g y _ R a n d o m W a l k s () {}
10
11
12
13
14
public O r g a n i s a t i o n a l S t r a t e g y _ R a n d o m W a l k s ( Integer var1 ,
Integer var2 ) {
this . global_var1 = var1 ;
this . global_var2 = var2 ;
15
16
17
18
local_var1 = 1;
19
}
20
21
public String getDescription () {
return " This message will be displayed in the
strategy settings panel . " ;
}
22
23
24
25
public Object [] getDefaultValues () {
return new Object []{ new Integer (1) , new Integer (8) };
};
26
27
28
29
public boolean search ( SimulationElement element , Query
msg ) {
..
}
30
31
32
33
}
Listing A.2. Beispiel einer Suchstrategie
120
A. Suchstrategien
A.3. Beispiel ORW
Der in A.3 dargestellte Algorithmus beschreibt aus Platzgründen lediglich die wichtigsten Konstrukte der Suchmethode ORW, die in dem Experiment ORW-OIBFS
(Abschnitt B.3.1) verwendet wurde.
..
2 public void search ( SimulationElement element , Query query )
{
3
O rg an i sa t io na l El em e nt myElement = ( OrganisationalElement )
element ;
4
Orga nisation alQuery myQuery = ( OrganisationalQuery ) query ;
1
5
// for later backtracking
myQuery . getHistory () . addElementToHistory ( element ) ;
6
7
8
// only messages with with same id or new initial messages
are forwared
// a copy of a already forwarded message will not forwarded
again
if (! myElement . h as A l r ea d yForwardedMsg ( myQuery .
getI nitialM essageI d () )
|| ( myElement . h a s A lr e a d y ForwardedMsg ( myQuery .
getI nitialM essageI d () )
&& myElement . h a sA l r e ad y F orwardedMsg ( myQuery . getId () ) ) ) {
9
10
11
12
13
14
// remember this message
myElement . rem em ber Fo rwa rdedMsg ( myQuery . getId () ) ;
myElement . rem em ber Fo rwa rdedMsg ( myQuery .
getI nitialM essageI d () ) ;
15
16
17
18
// test on query matching and sends an answer
boolean answered = canAnswerMessage ( myElement , myQuery ) ;
19
20
21
if ((! answered || query . getAnswerSize () < maxAnswers )
&& ! query . maxHopsReached ( maxDepth . intValue () ) ) {
forward ( myElement , myQuery ) ;
} else {
// stop forwarding
}
} else {
// message was already forwarded before
}
22
23
24
25
26
27
28
29
30
31
}
121
A. Suchstrategien
32
..
Listing A.3. Beispiel einer Suchstrategie für organisatorische Elemente basierend
auf dem Verfahren Random-Walks mit Backtracking
A.4. Beispiel VC
Folgender Algorithmus beschreibt die wichtigsten Konstrukte der Suchstrategie VC
in Experiment ORW-VC (Abschnitt B.2.7).
..
public void search ( SimulationElement element , Query query )
{
3
SuperPeer myElement = ( SuperPeer ) element ;
4
VirtualQuery myQuery = ( VirtualQuery ) query ;
1
2
5
6
7
// ringsize for calculating difference between self and
target
int ringsize = Configurator . model . superPeers . length ;
8
9
10
// get the search criteria and the type
String searchType = myQuery . getSearchType () ;
11
12
String searchCriteria = myQuery . getSearchCriteria () ;
13
14
15
16
// my name and hash id
String myName = element . getName () ;
int myhashId = Integer . parseInt ( myName . substring (5 , myName
. length () - 2) ) ;
17
18
19
// target name and hash id
int targetHashId = ge tM appedSup er PeerId ( searchCriteria ) ;
20
21
22
// calculate difference on ring
int difference = getDifference ( myHashId , targetHashId ,
ringSize ) ;
23
24
25
26
122
// get the maximal 2 - exponent smaller than difference
int targetFingerId = getTargetFingerId ( difference ) ;
A. Suchstrategien
// get the target instance
if ( targetFingerId != 0) {
29
// target is a super - peer
30
SuperPeer target = getTargetFinger ( myElement ,
targetFingerId ) ;
31
// forward the message
32
sendMessage ( myElement , target , myQuery ) ;
33
} else {
34
if ( myElement . getElementData ( " organisationalName " ) .
contains ( searchCriteria ) ) {
35
// the target is the super - peer itself
36
// send to the upper layer
37
sendUp ( element , query ) ;
38
} else {
39
// the target is a known cluster - peer
40
destination = myElement . getMetadata () . getHostingPeer (
searchCriteria ) ;
41
// forward the message
42
sendMessage ( element , destination , query ) ;
43
}
44
}
45 ..
46 }
27
28
Listing A.4. Beispiel einer Suchstrategie für Super-Peers basierend auf dem ChordVerfahren
A.5. Beispiel OIBFS
Die Suchstrategie OIBFS des Experimentes ORW-OIBFS (Abschnitt B.3.2) ist in
Listing A.5 dargestellt.
public void search ( SimulationElement element , Query query )
{
2
O rg an i sa t io na l El e me nt myElement = ( OrganisationalElement )
element ;
3
Orga nisatio nalQuery myQuery = ( OrganisationalQuery ) query ;
1
4
5
if (! myQuery . getHistory () . historyContainsElement ( myElement
)) {
123
A. Suchstrategien
6
myQuery . getHistory () . addElementToHistory ( myElement ) ;
7
8
self = element . getName () ;
9
10
// set flags for searched element types
interpretQuery ( myQuery ) ;
11
12
13
// test whether this element is searched
boolean isDestination = sendAnswer ( myElement , myQuery ) ;
14
15
16
if (! isDestination ) {
// forward to a subset of all known neighbors bases on
their known relationship
forward ( myElement , myQuery ) ;
}
17
18
19
20
}
21
22
}
Listing A.5. Beispiel einer Suchstrategie für organisatorische Elemente basierend auf
einem Hierarchischen Verfahren mit Interpretation der vorhandenen Beziehungen
124
B. Experimente
Die in der Arbeit angesprochenen Experimente und Konfigurationen werden im Folgenden beschrieben. Zum Verständnis der Ausgaben sollten die in Abschnitt 5.2.1
dargestellten Metriken gelesen werden.
B.1. Aufbau der Beschreibungen
Den Konfigurationen der Experimente sind die jeweiligen Experimentvariablen zu
entnehmen. Weiterhin wird in textueller Form auf die Struktur (Topologie), das Verhalten (Suchverfahren) und den Treiber (Suchanfragen) eingegangen.
Zielsetzung Jeder methodisch aufgebaute Versuch beginnt mit einer Zielsetzung und
Erwartung, die an das Experiment gestellt wird. Hypothesen über den Ausgang
werden hierbei vernachlässigt.
Strukturbeschreibung durch die verwendete Topologie Da es sich um zu simulierende Netzwerke handelt, werden die Topologien als konstante Variablen modelliert. Die Detailliertheit der Beschreibungen wird gering gehalten, da die
Verwendung identischer Topologien im Vordergrund steht.
Verhaltensbeschreibung durch Ausprägung der Suchverfahren Der Vergleichbarkeit angemessen, werden nur geringe Änderungen in aufeinanderfolgenden Konfigurationen getätigt. Dieser Abschnitt ist für die Unterscheidung der Experimentvariablen verantwortlich.
Treiber in Form von Suchanfragen Die Initiierung der Simulation entsteht durch
die versendeten Suchanfragen. Diese werden nur in den ersten Simulationszyklen der Simulation gestellt. Eine fortwährende (realistische) Aussendung ist
nicht vorgesehen. Allgemein unterscheiden sich Anfragen anhand ihrer exakten
oder ungenauen Kriterien.
Rohdaten als Ausgabe Die Visualisierung der Simulation ist nur in der grafischen
Ansicht dargestellt. Die textuelle Ausgabe des Berichtes wird nur zur Berechnung der späteren Bewertung herangezogen, da dieser exakte Werte zu entnehmen sind.
125
B. Experimente
B.2. Experiment VRW-VC
B.2.1. Konfiguration VRW1“
”
Dieses Experiment1 ist darauf ausgelegt, die nötige Suchtiefe bei einer optimalen
Erfolgsrate und minimalen Netzlast zu ermitteln, wobei das Verfahren Random-Walks
(siehe Abschnitt 3.2.3) betrachtet wird. Es wird die virtuelle Ebene simuliert.
Topologie
Das betrachtete Netzwerk umfasst 1000 Knoten, bestehend aus 100 Super-Peers und
900 Peers, die jeweils gleichverteilt in Clustern den Super-Peers zugeordnet sind. Als
zur Suche bereitstehende Daten existieren lediglich die eindeutigen Namen der Peers,
die eine eindeutige Suche ermöglichen.
Suchverfahren
Jeder Typ des gewählten Architekturstils verfügt über eine eigene Suchstrategie.
Super-Peers verwenden das Verfahren Random-Walks. Die Aussendung der Walker,
sowie die maximale Tiefe einer Suchnachricht und deren Höchstgrenze an Antworten
beeinflussen als Parameter die Suche. Einfache Peers, die einem Cluster angehören,
werden lediglich durch die Parameter Suchtiefe und Antwortbegrenzung parametrisiert. Die Tabelle B.1 veranschaulicht die relevanten Parameter.
Tabelle B.1.. Parametereinstellungen zum Experiment VRW1
Parameter / Knotentyp
Super-Peer Peer
Maximale Tiefe
200
200
Maximale Anzahl an Walker
1
Höchstgrenze an Antworten
5
5
Suchanfragen
Suchanfragen beziehen sich auf Peernamen. Ressourcen werden in diesem Experiment
nicht berücksichtigt. Jeder Peername ist eindeutig. In den ersten zehn Simulationsschritten werden pro Zyklus durchschnittlich zwei Anfragen gestellt. Die Initiatoren
werden zufällig aus der Menge der Super-Peers wie auch Peers ermittelt.
1
Eine detaillierte Beschreibung des Experimentes ist der Konfigurationsdatei ’/input/config exp1.xml’ des Simulators zu entnehmen. Die Ausführung erfolgt mittels des ant-Aufrufes
’ant exp1’
126
B. Experimente
Bild B.1.. Ausgabe Experiment 1: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage (APM) d)
Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im System (VMS) f) Virtuelle
Nachrichten pro Element (VME)
127
B. Experimente
B.2.2. Konfiguration VRW2“
”
Dieses Experiment2 ist darauf ausgelegt, die Auswirkungen einer Erhöhung der Aussendung an Nachrichten auf die Erfolgsrate zu beobachten, wobei das Verfahren
Random-Walks (siehe Abschnitt 3.2.3) betrachtet wird. Es wird die virtuelle Ebene unabhängig simuliert.
Topologie
Die verwendete Topologie entspricht der in dem Experiment B.2.1 Beschriebenen.
Suchverfahren
Die Beschreibung entspricht dem vorangegangenen Experiment. Die Tabelle B.2 veranschaulicht die relevanten Parameter.
Tabelle B.2.. Parametereinstellungen zum Experiment VRW2
Parameter / Knotentyp
Super-Peer Peer
Maximale Tiefe
200
200
Maximale Anzahl an Walker
3
Höchstgrenze an Antworten
5
5
Suchanfragen
Es werden die gleichen Suchanfragen wie zuvor verwendet.
2
Eine detaillierte Beschreibung des Experimentes ist der Konfigurationsdatei ’/input/exp/config exp2.xml’ des Simulators zu entnehmen. Die Ausführung erfolgt mittels des ant-Aufrufes
’ant exp2’
128
B. Experimente
Bild B.2.. Ausgabe Experiment 2: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage (APM) d)
Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im System (VMS) f) Virtuelle
Nachrichten pro Element (VME)
129
B. Experimente
B.2.3. Konfiguration VRW3“
”
Dieses Experiment3 ist darauf ausgelegt, das Suchverhalten bei realen Suchtiefen4 zu
untersuchen, wobei das Verfahren Random-Walks (siehe Abschnitt 3.2.3) betrachtet
wird. Es wird die virtuelle Ebene unabhängig simuliert.
Topologie
Die verwendete Topologie entspricht der in dem Experiment B.2.1 Beschriebenen.
Suchverfahren
Die Beschreibung entspricht dem vorangegangenen Experiment. Die Tabelle B.3 veranschaulicht die relevanten Parameter.
Tabelle B.3.. Parametereinstellungen zum Experiment VRW3
Parameter / Knotentyp
Super-Peer Peer
Maximale Tiefe
10
10
Maximale Anzahl an Walker
3
Höchstgrenze an Antworten
5
5
Suchanfragen
Es werden die gleichen Suchanfragen wie zuvor verwendet.
3
Eine detaillierte Beschreibung des Experimentes ist der Konfigurationsdatei ’/input/config exp3.xml’ des Simulators zu entnehmen. Die Ausführung erfolgt mittels des ant-Aufrufes
’ant exp3’
4
Gängige Suchtiefen in verwendeten Sucherverfahren liegen zwischen fünf und zehn
130
B. Experimente
Bild B.3.. Ausgabe Experiment 3: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage (APM) d)
Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im System (VMS) f) Virtuelle
Nachrichten pro Element (VME)
131
B. Experimente
B.2.4. Konfiguration VRW4“
”
Dieses Experiment5 ist darauf ausgelegt, das Suchverhalten bei unterschiedlichen Ergebnissen zu beobachten, wobei das Verfahren Random-Walks (siehe Abschnitt 3.2.3)
betrachtet wird. Es wird die virtuelle Ebene unabhängig simuliert.
Topologie
Die Topologie drückt die vorher beschriebene Struktur aus. Peers stellen Ressourcen bereit, die durch zugehörige Super-Peers indexiert werden und somit der Suche
zugänglich sind. Aus einer Menge von 10000 unterschiedlichen Ressourcen werden
jedem Peer 5 bis 100 unterschiedliche Ressourcen zugeteilt.
Suchverfahren
Die Beschreibung entspricht dem vorangegangenen Experiment. Die Tabelle B.4 veranschaulicht die relevanten Parameter.
Tabelle B.4.. Parametereinstellungen zum Experiment VRW4
Parameter / Knotentyp
Super-Peer Peer
Maximale Tiefe
200
200
Maximale Anzahl an Walker
1
Höchstgrenze an Antworten
5
5
Suchanfragen
Die Suche erstreckt sich, wie eingangs beschrieben, über die gesamte Topologie. Als
Suchkriterien werden vorhandene Ressourcen verwendet, die über die Topologie mehrfach existieren können.
5
Eine detaillierte Beschreibung des Experimentes ist der Konfigurationsdatei ’/input/config exp4.xml’ des Simulators zu entnehmen. Die Ausführung erfolgt mittels des ant-Aufrufes
’ant exp4’
132
B. Experimente
Bild B.4.. Ausgabe Experiment 4: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage (APM) d)
Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im System (VMS) f) Virtuelle
Nachrichten pro Element (VME)
133
B. Experimente
B.2.5. Konfiguration VRW5“
”
Dieses Experiment6 ist darauf ausgelegt, die Auswirkungen einer Erhöhung der Aussendung an Nachrichten auf die Erfolgsrate zu beobachten, wobei das Verfahren
Random-Walks (siehe Abschnitt 3.2.3) betrachtet wird. Es wird die virtuelle Ebene unabhängig simuliert.
Topologie
Die verwendete Topologie entspricht der in dem Experiment 2 Beschriebenen.
Suchverfahren
Die Beschreibung entspricht dem vorangegangenen Experiment. Die Tabelle B.5 veranschaulicht die relevanten Parameter.
Tabelle B.5.. Parametereinstellungen zum Experiment VRW5
Parameter / Knotentyp
Super-Peer Peer
Maximale Tiefe
200
200
Maximale Anzahl an Walker
3
Höchstgrenze an Antworten
5
5
Suchanfragen
Es werden die gleichen Suchanfragen wie zuvor verwendet.
6
Eine detaillierte Beschreibung des Experimentes ist der Konfigurationsdatei ’/input/config exp5.xml’ des Simulators zu entnehmen. Die Ausführung erfolgt mittels des ant-Aufrufes
’ant exp5’
134
B. Experimente
Bild B.5.. Ausgabe Experiment 5: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage (APM) d)
Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im System (VMS) f) Virtuelle
Nachrichten pro Element (VME)
135
B. Experimente
B.2.6. Konfiguration VRW6“
”
Dieses Experiment7 ist darauf ausgelegt, das Suchverhalten bei realen Suchtiefen8 zu
untersuchen, wobei das Verfahren Random-Walks (siehe Abschnitt 3.2.3) betrachtet
wird. Es wird die virtuelle Ebene unabhängig simuliert.
Topologie
Die verwendete Topologie entspricht der in dem Experiment 5 Beschriebenen.
Suchverfahren
Die Beschreibung entspricht dem vorangegangenen Experiment. Die Tabelle B.6 veranschaulicht die relevanten Parameter.
Tabelle B.6.. Parametereinstellungen zum Experiment VRW6
Parameter / Knotentyp
Super-Peer Peer
Maximale Tiefe
10
10
Maximale Anzahl an Walker
3
Höchstgrenze an Antworten
5
5
Suchanfragen
Es werden die gleichen Suchanfragen wie zuvor verwendet.
7
Eine detaillierte Beschreibung des Experimentes ist der Konfigurationsdatei ’/input/config exp6.xml’ des Simulators zu entnehmen. Die Ausführung erfolgt mittels des ant-Aufrufes
’ant exp6’
8
Gängige Suchtiefen in verwendeten Sucherverfahren liegen zwischen fünf und zehn
136
B. Experimente
Bild B.6.. Ausgabe Experiment 6: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage (APM) d)
Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im System (VMS) f) Virtuelle
Nachrichten pro Element (VME)
137
B. Experimente
B.2.7. Konfiguration VC1“
”
Dieses Experiment9 veranschaulicht die Suche mittels des Chord-Routing-Verfahrens
(siehe Abschnitt 3.3.1). Als Suchanfragen werden Ressourcen betrachtet. Es wird die
virtuelle Ebene unabhängig simuliert.
Topologie
Die der Simulation zugrunde liegende Topologie besteht aus 256 Super-Peer und
744 einfachen Peers, die in Clustern angeordnet sind. Alle Super-Peers sind auf einem Chord-Ring angeordnet. Super-Peers indexieren Informationen der registrierten
Peers. Ressourcen, die den Peers eines Clusters X bekannt sind, genügen einer modulo Funktion, die alle Ressourcen als eindeutigen ganzzahligen Wert interpretiert und
auf den Chord-Ring gleichverteilt. Ressourcen mit dem Wert 500 (500 modulo 256 =
244) werden somit im Cluster des Super-Peers ’244’ gesucht.
Suchverfahren
Jeder Typ des gewählten Architekturstils verfügt über eine eigene Suchstrategie.
Super-Peers verwenden das Verfahren Chord und stellen keine weiteren Parameter
bereit, wohingegen Peers eines Clusters lediglich die Suchtiefe und die Antwortbegrenzung berücksichtigen. Die Tabelle B.7 veranschaulicht die relevanten Parameter.
Tabelle B.7.. Parametereinstellungen zum Experiment VC1
Parameter / Knotentyp
Super-Peer Peer
Maximale Tiefe
200
Höchstgrenze an Antworten
5
5
Suchanfragen
Die Suchanfragen werden wie in den vorherigen Verfahren gestellt, wobei in diesem
Experiment nur nach Ressourcen gesucht wird.
9
Eine detaillierte Beschreibung des Experimentes ist der Konfigurationsdatei ’/input/config exp7.xml’ des Simulators zu entnehmen. Die Ausführung erfolgt mittels des ant-Aufrufes
’ant exp7’
138
B. Experimente
Bild B.7.. Ausgabe Experiment 7: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage (APM) d)
Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im System (VMS) f) Virtuelle
Nachrichten pro Element (VME)
139
B. Experimente
B.2.8. Konfiguration VC2“
”
Dieses Experiment10 veranschaulicht die Suche mittels des Chord-Routing-Verfahrens
(siehe Abschnitt 3.3.1). Als Suchanfragen werden Peernamen betrachtet, die im System eindeutig sind. Es wird die virtuelle Ebene unabhängig simuliert.
Topologie
Die verwendete Topologie entspricht der zuvor Untersuchten.
Suchverfahren
Es werden die gleichen Suchverfahren wie im vorherigen Experiment verwendet.
Suchanfragen
Suchanfragen entsprechen den vorherigen Experimenten, wobei hier lediglich Peernamen als Kriterium verwendet werden.
10
Eine detaillierte Beschreibung des Experimentes ist der Konfigurationsdatei ’/input/config exp8.xml’ des Simulators zu entnehmen. Die Ausführung erfolgt mittels des ant-Aufrufes
’ant exp8’
140
B. Experimente
Bild B.8.. Ausgabe Experiment 8: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage (APM) d)
Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im System (VMS) f) Virtuelle
Nachrichten pro Element (VME)
141
B. Experimente
B.3. Experiment ORW-OIBFS
B.3.1. Konfiguration ORW“
”
Als Strategie des folgenden Experimentes11 der organisatorischen Ebene ist, wie zuvor,
das Random-Walks-Verfahren verwendet worden. Ziel ist es hierbei ein möglichst einfaches Verfahren mit geringer Netzwerklast zu erstellen, indem eine unterschiedliche
Anzahl an Walkern verwendet wird.
Topologie
Die Topologie unterliegt einer hierarchischen Struktur, in der vier Elementtypen existieren. Es bestehen vier ungerichtete Verbindungstypen zwischen den Elementen, die
die unterschiedlichen Hierarchiestufen miteinander verbinden.
Suchverfahren
Als Suchverfahren wird für alle Elemente das in den vorangegangenen Experimenten dargestellte Random-Walks Verfahren eingesetzt. Die Anzahl an auszusendenden
Nachrichten unterscheidet sich jedoch bei den Elementen der organisatorischen Ebene.
Organisationen senden (siehe Tabelle B.8) bis zu fünf Walker aus, um eine möglichst
schnelle Abdeckung des Suchraumes zu ermöglichen.
Tabelle B.8.. Parametereinstellungen zum Experiment ORW
Parameter / Knotentyp
Organisation Projekt Gruppe Mitglied
Anzahl Walker
5
1
1
1
Maximale Tiefe
120
120
120
120
Höchstgrenze an Antworten
5
5
5
5
Suchanfragen
Suchanfragen werden in den ersten zehn Simulationsschritten erstellt. Pro Simulationsschritt werden durchschnittlich zwei Anfragen an zufällig ermittelten Elementen
initiiert. Als Suchkriterien werden ausschließlich Namen organisatorischer Elemente
verwendet.
11
Eine detaillierte Beschreibung des Experimentes ist der Konfigurationsdatei ’/input/config exp9.xml’ des Simulators zu entnehmen. Die Ausführung erfolgt mittels des ant-Aufrufes
’ant exp9’
142
B. Experimente
Bild B.9.. Ausgabe Experiment 9: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage (APM) d)
Schritte pro Antwort (HPQ) e) Organisatorische Nachrichten im System (OMS) f)
Organisatorische Nachrichten pro Element (OME)
143
B. Experimente
B.3.2. Konfiguration OIBFS“
”
Dieses Experiment12 veranschaulicht die Suche mittels hierarchischer Metainformationen. Die Suche kann entweder durch exakte Angabe eines gesuchten organisatorischen
Elementes wie auch durch eine ungenaue Spezifizierung mittels der in Abschnitt 2.3
und 5.3 beschrieben Suche beschrieben werden. In diesem Experiment wird die organisatorische Ebene unabhängig simuliert.
Topologie
Die verwendete Topologie verdeutlicht einen einfachen hierarchischen Aufbau, in dem
Verbindungen zu den jeweils anliegenden Ebenen unterschiedlicher Tiefe bestehen.
Angesichts der vier unterschiedlichen Ebenen existieren vier Verbindungenstypen, die
in einer gerichteten Sichtweise auf acht Verbindungstypen ansteigen. Zudem hat jedes
Mitglied eine implizit vorhandene selbst-reflexive Beziehung, die nicht in der Topologie modelliert wird, jedoch in den Suchverfahren herangezogen werden kann.
Suchverfahren
Das simulierte Suchverfahren liegt allen Elementen zugrunde. Entscheidungen basieren auf den vorhandenen Beziehungen und gewährleisten eine optimale Suchtiefe, die
dem Durchmesser des Netzwerkes entspricht. Der Aussendungsgrad einer Nachricht
steigt auf ein Maximum, falls keine relevanten direkten und transitiven Beziehungen
ersten Grades bestehen.
Suchanfragen
Es treten in den ersten zehn Simulationsschritten durchschnittlich zwei Suchanfragen pro Schritt auf. Sie bestehen aus einer zufälligen Anzahl an exakten wie auch
unscharfen Formulierungen.
12
Eine detaillierte Beschreibung des Experimentes ist der Konfigurationsdatei ’/input/config exp10.xml’ des Simulators zu entnehmen. Die Ausführung erfolgt mittels des ant-Aufrufes
’ant exp10’
144
B. Experimente
Bild B.10.. Ausgabe Experiment 10: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage (APM) d)
Schritte pro Antwort (HPQ) e) Organisatorische Nachrichten im System (OMS) f)
Organisatorische Nachrichten pro Element (OME)
145
B. Experimente
B.4. Experiment OIBFS-VC
B.4.1. Konfiguration OIBFS-VC1“
”
Die in den Experimenten B.2.8 und B.3.2 dargestellten Experimente berücksichtigen
jeweils nur eine Ebene. Das anfolgende Experiment13 verbindet diese beiden Simulationen, indem eine Verbindung der Elemente vorgenommen wird. Das Experiment
verfolgt das Ziel, unscharfe Suchanfragen der organisatorischen Ebene mittels des
Chord-Routingprotokolls der virtuellen Ebene zu erfüllen.
Topologie
Die verwendeten Topologien entsprechen den Experimenten B.2.8 und B.3.2. Sie werden verbunden, indem alle Organisationen auf Super-Peers abgebildet werden. Die
weiteren organisatorischen Elemente werden auf einfache Peers abgebildet. Die Zuordnung wird durch eine Abbildungsfunktion gleichverteilt, so dass alle Cluster nahezu
die gleiche Größe besitzen. Lokalitätsbeziehungen zwischen organisatorischen Elementen werden nicht berücksichtigt. Genauere Informationen sind dem Abschnitt 8.1 zu
entnehmen. Dieses Experiment simuliert 1000 Elemente der jeweiligen Ebene mit
acht Organisationen.
Suchverfahren
Die verwendeten Suchverfahren der einzelnen Elemente entsprechen den vorangegangenen Experimenten. Super-Peers verfügen zudem über die Berechnung der
Abbildungsfunktion, mittles derer organisatorische Namen auf einen Super-PeerBezeichner abgebildet werden können.
Suchanfragen
Es werden sieben teils ungenaue organisatorische Anfragen in den ersten Simulationszyklen gestellt.
13
Eine detaillierte Beschreibung des Experimentes ist der Konfigurationsdatei ’/input/config exp12.xml’ des Simulators zu entnehmen. Die Ausführung erfolgt mittels des ant-Aufrufes
’ant exp12’
146
B. Experimente
Bild B.11.. Ausgabe Experiment 12: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage (APM) d)
Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im System (VMS) f) Virtuelle
Nachrichten pro Element (VME) g) Organisatorische Nachrichten im System (OMS)
h) Organisatorische Nachrichten pro Element (OME)
147
B. Experimente
B.4.2. Konfiguration OIBFS-VC2“
”
Das folgende Experiment14 entspricht dem Vorangegangenen mit der Ausnahme, dass
statt einer möglichst guten Gleichverteilung Lokalitätsbeziehungen der organisatorischen Elemente berücksicht werden.
Topologie
Lokalitätseigenschaften bleiben erhalten, indem neben der Abbildung der Organisationen auf Super-Peers alle weiteren Elemente einer Organisation dem Cluster des
entsprechenden Super-Peers zugeordnet werden.
Suchverfahren
Die Suchverfahren unterscheiden sich zum vorherigen Experiment nur durch eine
geänderte Abbildungsfunktion.
Suchanfragen
Die gleichen Suchanfragen wie zuvor werden verwendet.
14
Eine detaillierte Beschreibung des Experimentes ist der Konfigurationsdatei ’/input/config exp13.xml’ des Simulators zu entnehmen. Die Ausführung erfolgt mittels des ant-Aufrufes
’ant exp13’
148
B. Experimente
Bild B.12.. Ausgabe Experiment 13: a) Anfragen-Antworten Verhältnis (QAR) b)
Erfolgsrate der Anfragen (QSR) c) Anzahl an Antworten pro Anfrage (APM) d)
Schritte pro Antwort (HPQ) e) Virtuelle Nachrichten im System (VMS) f) Virtuelle
Nachrichten pro Element (VME) g) Organisatorische Nachrichten im System (OMS)
h) Organisatorische Nachrichten pro Element (OME)
149
C. Buildmanagement
Dem Simulator liegen mehrere Bibliotheken zugrunde, die mittels eines Ant1 -Skriptes
erstellt und manipuliert werden können. Der grobe Aufbau sowie die daraus resultierende Verzeichnisstruktur nun kurz beschrieben.
C.1. Aufbau und Umgang
Die verwendete build-Datei ist in Listing C.1 in ihren wichtigsten Einstellungen zu
sehen. Zum Starten einer Simulation existieren zwei Varianten. Die grafische Oberfläsche wird mittels ant startGui gestartet, wohingegen eine textuelle Simulation
mittels ant start direkt begonnen wird. Als Parameter wird die zu verwendende
Konfigurationsdatei und das Zielverzeichnis angegeben.
Die Erstellung neuer Strategien erfolgt durch die im Feinentwurf 6.2 beschriebene Vorkehrungen. Diese Strategie kann dann in das Verzeichnis src/easim/strategy/ abgelegt werden und durch den Aufruf ant easim-strategy in die Bibliothek bin/easimstrategy.jar aufgenommen werden, die zum Start des Simulators verwendet wird.
Die in dem Abschnitt 7 dargestellten Experimente können direkt über das Ant-Skript
nachvollzogen werden (ant expX).
Listing C.1. Aufbau der build.xml
< project basedir = " . " default = " usage " >
..
3
<! -- Building libraries -- >
1
2
4
5
6
7
1
< target name = " easim - all " depends = " easim - core , easim strategy , easim - mapping , easim - extension " description
= " compile and deploy all source files " / >
< target name = " easim - core " depends = " compile - core , deploy core " description = " compile and deploy all core source
files " / >
< target name = " easim - strategy " depends = " compile_strategy ,
deploy_strategy " description = " compile and deploy all
strategy source files " / >
http://ant.apache.org
150
C. Buildmanagement
8
9
10
< target name = " easim - mapping " depends = " compile_mapping ,
deploy_mapping " description = " compile and deploy all
mapping source files " / >
< target name = " easim - extension " depends = "
compile_extension , deploy_extension " description = "
compile and deploy all extension source files " / >
< target name = " easim - desmoj " depends = " compile_desmoj ,
deploy_desmoj " description = " compile and deploy all
desmoj source files " / >
11
12
<! -- Starting simulator -- >
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
< target name = " startGui " depends = " easim - all , easim - desmoj
" description = " Starts the simulator with gui " >
< java jar = " £{ easim . deploy . dest }/£{ easim . core . deploy .
file } " classpathref = " glob alCla sspat hAndD eploy "
fork = " true " >
< jvmarg line = " - Xmx384m " / >
< sysproperty key = " easim . config " value = " bin / input
/ config . xml " / >
< sysproperty key = " easim . output " value = " bin /
output " / >
</ java >
</ target >
< target name = " start " depends = " easim - all , easim - desmoj "
description = " Starts the simulator on the console " >
< java classname = " easim . core . SimulatorModel "
classpathref = " g lob alCla sspat hAndD eploy " fork = "
true " >
< jvmarg line = " - Xmx384m " / >
< sysproperty key = " easim . output " value = " bin /
output / " / >
< sysproperty key = " easim . config " value = " bin / input
/ config . xml " / >
</ java >
</ target >
28
29
<! -- Experiment settings -- >
30
31
32
< target name = " exp1 " depends = " easim - all , easim - desmoj "
description = " starts the 1 st experiment " >
< mkdir dir = " bin / output / exp1 / " / >
151
C. Buildmanagement
33
34
35
36
37
38
39
40
< java jar = " £{ easim . deploy . dest }/£{ easim . core . deploy .
file } " classpathref = " glo balCla sspat hAndD eploy "
fork = " true " >
< jvmarg line = " - Xmx384m " / >
< sysproperty key = " easim . config " value = " bin / input
/ exp / config_exp1 . xml " / >
< sysproperty key = " easim . output " value = " bin /
output / exp1 " / >
</ java >
</ target >
..
</ project >
C.2. Verzeichnisstruktur
Die Verzeichnisstruktur ist in Abbildung C.1 zu sehen. Die Verzeichnisse src, input und lib werden durch das Ant-Skript in das bin-Verzeichnis kopiert und dort
verwendet.
/easim
/bin
/input
/lib
/output
/easim-core.jar
/easim-desmoj.jar
/easim-extension.jar
/easim-mapping.jar
/easim-strategy.jar
/src
/input
/lib
/build.xml
Bild C.1.. Verzeichnisstruktur des Simulators
152
D. Danksagung
Nach meinem nunmehr sechs-jährigen Studium möchte ich an dieser Stelle einigen
Menschen für die Unterstützung in dieser Zeit danken. Mein besonderer Dank gilt
meinen Eltern, ohne die das Studium wahrscheinlich nicht möglich gewesen wäre und
meiner Freundin, die mir während dieser Zeit stets zur Seite stand.
Weiterhin möchte ich mich für die gute Betreuung und Atmosphäre der letzten sechs
Monate bei Herrn Dipl.-Inform. Ludger Bischofs und Herrn Prof. Dr. Wilhelm Hasselbring bedanken.
Abschließend gebührt Stefan Brüggemann für die kritische Betrachtung dieser Arbeit
ein besonderer Dank.
153