Algorithmen für Peer-to-Peer-Netzwerke

Algorithmen für Peer-to-Peer-Netzwerke
Vorlesungsskript
1.-13. Vorlesung
Version 4.4.1
Sommersemester 2004
Christian Schindelhauer
Peter Mahlmann
Heinz Nixdorf Institut
Fakultät EIM, Institut für Informatik
Universität Paderborn
1. Oktober 2004
Inhaltsverzeichnis
Abbildungsverzeichnis
VII
Tabellenverzeichnis
1
2
3
Organisation
1.1 Inhalte der Veranstaltung .
1.2 Organisation . . . . . . . .
1.2.1 Termine . . . . . .
1.2.2 Vorlesungsmaterial
1.2.3 Prüfung . . . . . .
1.2.4 Übungen . . . . .
1.3 Literatur und Links . . . .
1.4 Prüfungsfragen . . . . . .
IX
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
1
1
2
2
3
4
Peer-to-Peer-Netzwerke der ersten Generation
2.1 Was ist ein Peer-to-Peer-Netzwerk? . . . .
2.2 Napster . . . . . . . . . . . . . . . . . . .
2.2.1 Geschichte . . . . . . . . . . . . .
2.2.2 Aufbau . . . . . . . . . . . . . . .
2.2.3 Diskussion . . . . . . . . . . . . .
2.3 Gnutella in der Originalversion . . . . . . .
2.3.1 Aufbau . . . . . . . . . . . . . . .
2.3.2 Diskussion . . . . . . . . . . . . .
2.4 Kazaa, Gnutella (II), Morpheus . . . . . . .
2.5 Zusammenfassung . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
8
8
8
9
9
9
10
12
13
Skalierende Peer-to-Peer-Netzwerke
3.1 Warum manche Netzwerke nicht skalieren . . . . . . .
3.2 Distributed Hash-Table . . . . . . . . . . . . . . . . .
3.3 CAN — Content Addressable Network . . . . . . . .
3.3.1 Aufbau . . . . . . . . . . . . . . . . . . . . .
3.3.2 Die Balancierung der Zonen nach dem Aufbau
3.3.3 Die Join-Operation . . . . . . . . . . . . . . .
3.3.4 Entfernen eines Peers . . . . . . . . . . . . . .
3.3.5 Defragmentierung . . . . . . . . . . . . . . .
3.3.6 Ungleichungen der Wahrscheinlichkeitstheorie
3.3.7 Realitäten . . . . . . . . . . . . . . . . . . . .
3.4 CHORD: Konsistentes Hashing für P2P-Netzwerke . .
3.4.1 Die Datenstruktur von Chord . . . . . . . . . .
3.4.2 Suche in Chord . . . . . . . . . . . . . . . . .
3.4.3 Aufnehmen von Peers . . . . . . . . . . . . .
3.5 Koorde . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
16
18
18
18
21
21
21
22
26
26
26
29
29
30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
I
3.6
3.7
3.8
3.9
4
5
3.5.1 Der DeBrujin-Graph . . . . . . . . . . . . . . . . . . . . . . .
3.5.2 Die Topologie von Koorde . . . . . . . . . . . . . . . . . . . .
3.5.3 Eigenschaften von Koorde . . . . . . . . . . . . . . . . . . . .
Tapestry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1 Grundlegende Terminologie . . . . . . . . . . . . . . . . . . .
3.6.2 Nachbarschaftsmengen . . . . . . . . . . . . . . . . . . . . . .
3.6.3 Eigenschaften der Nachbarschaftsmengen und Routing . . . . .
3.6.4 Objekte und Routing . . . . . . . . . . . . . . . . . . . . . . .
3.6.5 Surrogate-Routing . . . . . . . . . . . . . . . . . . . . . . . .
3.6.6 Einfügen neuer Peers . . . . . . . . . . . . . . . . . . . . . . .
Pastry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.1 Die Zeigerstruktur . . . . . . . . . . . . . . . . . . . . . . . .
3.7.2 Einfügen von Peers . . . . . . . . . . . . . . . . . . . . . . . .
3.7.3 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.4 Experimentelle Resultate . . . . . . . . . . . . . . . . . . . . .
3.7.5 Pastry versus Tapestry . . . . . . . . . . . . . . . . . . . . . .
Viceroy — Ein Butterfly basiertes Peer-to-Peer-Netzwerk . . . . . . . .
3.8.1 Der Butterfly-Graph . . . . . . . . . . . . . . . . . . . . . . .
3.8.2 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.3 Einfügen eines Peers . . . . . . . . . . . . . . . . . . . . . . .
3.8.4 Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.5 Eigenschaften von ViceRoy . . . . . . . . . . . . . . . . . . .
3.8.6 Das Prinzip der mehrfachen Auswahl (principle multiple choice)
3.8.7 Resumee . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Distance Halving . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.1 Kontinuierliche Graphen . . . . . . . . . . . . . . . . . . . . .
3.9.2 Einfügen von Peers in Distance-Halving . . . . . . . . . . . . .
3.9.3 Lookup in Distance-Halving . . . . . . . . . . . . . . . . . . .
3.9.4 Resumee Distance-Halving . . . . . . . . . . . . . . . . . . . .
Epidemische Algorithmen und Datenaggregation
4.1 Epidemische Algorithmen . . . . . . . . . . . . . .
4.1.1 Replizierte Datenbanken . . . . . . . . . . .
4.1.2 Mathematische Modellierung von Epidemien
4.1.3 Epicast . . . . . . . . . . . . . . . . . . . .
4.1.4 Anruf-Model (Random Call) . . . . . . . . .
4.1.5 Ausbreitungsverhalten im Push-Modell . . .
4.1.6 Eine einfache Terminierungsstrategie . . . .
4.1.7 Shenkers Min-Counter-Algorithmus . . . . .
4.2 Datenaggregation . . . . . . . . . . . . . . . . . . .
4.2.1 Zählen . . . . . . . . . . . . . . . . . . . .
4.2.2 Der Average-Algorithmus . . . . . . . . . .
4.2.3 Experimentelle Resultate . . . . . . . . . . .
4.2.4 Weitere Aggregations-Funktionen . . . . . .
4.2.5 Resumee . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
32
33
35
35
35
35
36
38
38
41
41
43
44
48
50
50
51
52
53
53
54
55
56
56
56
57
58
59
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
61
61
62
63
63
65
73
73
75
75
76
77
79
79
Routing und Sicherheit
5.1 Sicherheit in Peer-to-Peer-Netzwerken . . . . . . . . . . . . .
5.1.1 Methoden der Kryptographie . . . . . . . . . . . . . .
5.1.2 Sicherheitsanforderungen in Peer-to-Peer-Netzwerken
5.1.3 Die Sybil Attacke . . . . . . . . . . . . . . . . . . . .
5.1.4 Der Sybil-Abwehransatz John Douceur . . . . . . . .
5.1.5 Das Problem der byzantinischen Generäle . . . . . . .
5.1.6 Ein Zensor-Resistentes Peer-to-Peer-Netzwerk . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
81
81
81
82
83
84
84
87
II
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.2
Routing in Peer-to-Peer-Netzwerken . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Techniken für CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 Routing-Techniken für CHORD: DHash++ . . . . . . . . . . . . . . . . . . . . .
Literaturverzeichnis
88
88
89
96
III
IV
Abbildungsverzeichnis
2.1
2.2
2.3
2.4
2.5
Funktionsweise von Napster . . . . . . . . . . . . .
Anbindung von neuen Knoten in Gnutella . . . . . .
Dateisuche in Gnutella . . . . . . . . . . . . . . . .
Das Gnutella-Netzerk (Schnappschuss 2000) [JAB01]
Eine hybride Netzwerkstruktur . . . . . . . . . . . .
3.1
3.2
3.3
3.4
Die Client-Server-Struktur von Napster entspricht einem Stern-Graph [JAB01] . . . . . . 15
Ein zufälliger Graph, der die Struktur von Gnutella symbolisieren soll . . . . . . . . . . . 16
Der Standardansatz einer Hash-Tabelle ist nicht geeignet als Peer-to-Peer-Netzwerk . . . 17
Bei der verteilten Hash-Tabelle wird jedem Peer (farbiger Kreis) ein Bereich zu geordnet.
Alle Daten (Rechtecke) die auf diesen Bereich abgebildet werden, werden entsprechen den
Peers zugeordnet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Nach dem Einfügen eines Peers sind nur die Zuordnungen der benachhbarten betroffen . . 18
Das Löschen eines Peers in der DHT betrifft nur die Bereiche der direkten Nachbarn . . . 18
Der Aufbau der Zonen in CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Iterierte Join-Operationen als Random Tree . . . . . . . . . . . . . . . . . . . . . . . . . 21
Verläßt ein Knoten das CAN-Netzwerk, übernimmt sein Nachbar das Gebiet . . . . . . . 22
Der einfache Fall der Defragmentierung in CAN . . . . . . . . . . . . . . . . . . . . . . 23
Der schwierige Fall der Defragmentierung in CAN . . . . . . . . . . . . . . . . . . . . . 23
Konsistentes Hashing in der Chord-Datenstruktur . . . . . . . . . . . . . . . . . . . . . . 27
Die Zeigerstruktur von Chord. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Der Suchalgorithmus für die Chord-Datenstruktur . . . . . . . . . . . . . . . . . . . . . 29
Schlüsselsuche im Chord P2P-Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Die Shuffle-Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Die Exchange-Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Die Shuffle-Exchange-Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Jeder String lässt sich durch m Shuffle- oder Shuffle-Exchange-Operationen in jeden beliebigen anderen überführen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Der DeBrujin-Graph für 8 Knoten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Der selbe DeBrujin-Graph. Die Knoten sind sortiert auf dem Ring aufgetragen. . . . . . . 32
Die Verbindungsstruktur der DeBrujin-Kanten auf dem Ring. . . . . . . . . . . . . . . . . 33
Der Eingrad der Knoten in Koorde ist mit hoher Wahrscheinlichkeit O(log n) . . . . . . . 34
Ein Grad-3-DeBrujin-Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Nachbarschaft des Peers 4227. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Publikation von Objekten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Routing im Tapestry Netzwerk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Beispiel einer Pastry-Routing-Tabelle [Aus einem Web-Dokument von Druschel und Rowstron,
das nicht zitiert werden soll] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Die Pastry-Zeigerstruktur im Knoten 001 für b = 2 und ` = 2 . . . . . . . . . . . . . . . 42
Pastry-insert.pdf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Nach dem Einfügen von Peer 11 werden nicht alle notwendigen Einträge aktualisiert . . . 44
Der Reparatur-Mechanismus für Pastry . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Pastry-Routing-Alg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
3.24
3.25
3.26
3.27
3.28
3.29
3.30
3.31
3.32
3.33
V
. . . .
. . . .
. . . .
. . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
11
11
12
13
3.34 Beim Einfügen eines Peers in Pastry, kann man die Latenzzeiten des Routing klein halten,
indem man latenznahe Knoten eines Levels bevorzugt [DR01b] . . . . . . . . . . . . . . .
3.35 Die Latenzzeiten der Level i-Sprünge steigen bei Pastry expontiell in i an [DR01b] . . . .
3.36 Durchschnittliche Anzahl von Hops beim Routing von Pastry mit steigender Knotenanzahl
(b = 4, ` = 16 und |M | = 32) [DR01b] . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.37 Verteilung der Hops beim Routing von Pastry mit steigender Knotenanzahl (b = 4, ` = 16,
|M | = 32 und n = 106 ) [DR01b] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.38 Pastry-latency.pdf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.39 Güte der Routing-Table von Pastry vor und nach dem Ausfall von 500 von 5.000 Peers und
nach Abschluss der Repeartur-Routine [DR01b] . . . . . . . . . . . . . . . . . . . . . . .
3.40 Der Butterfly-Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.41 Die Viceroy-Umsetzung eines Butterfly-Graphen aus [MNR02] . . . . . . . . . . . . . .
3.42 Der Suchalgorithmus für die Viceroy-Datenstruktur . . . . . . . . . . . . . . . . . . . . .
3.43 Links- und Rechts-Kanten des kontinuierlichen Graphen des Distance-Halving-Peer-toPeer-Netzwerks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.44 Durch die Diskretisierung eine kontinuierlichen Graphen ensteht das Distance-HalvingNetzwerkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.45 Der Suchalgorithmus für das Distance-Halving-Netzwerk . . . . . . . . . . . . . . . . .
3.46 Rekursiver Lookup-Aufruf von Distance-Halving falls der Start-Peer sich links vom ZielPeer befindet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.47 Rekursiver Lookup-Aufruf von Distance-Halving falls der Start-Peer sich rechts vom ZielPeer befindet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.48 Congestion-optimierter Suchalgorithmus für das Distance-Halving-Netzwerk . . . . . . .
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
Replizierte Datenbanken sollen den gleichen Datenbestand verteilt unterhalten ohne dass
Knoten und Kantenausfälle dies beeinträchtigen . . . . . . . . . . . . . . . . . . . . . . .
Informationsverbreitung im Push-Modell . . . . . . . . . . . . . . . . . . . . . . . . . .
Informationsverbreitung im Pull-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . .
Informationsverbreitung im Push&Pull-Modell . . . . . . . . . . . . . . . . . . . . . . .
Beispielhafte Informationsverbreitung im Push-Modell . . . . . . . . . . . . . . . . . . .
Wachstumsphasen im Push-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beispielhafte Informationsverbreitung im Pull-Modell . . . . . . . . . . . . . . . . . . .
Wachstumsphasen im Pull-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beispielhafte Informationsverbreitung im Push&Pull-Modell . . . . . . . . . . . . . . . .
Wachstumsphasen im Push&Pull-Modell . . . . . . . . . . . . . . . . . . . . . . . . . .
Häufigkeit der einzelnen Zustände des Min-Counter-Algorithmus . . . . . . . . . . . . .
Der Average-Algorithmus zur Daten-Aggregation . . . . . . . . . . . . . . . . . . . . . .
Experimentell Verifikation des Average-Aggregations-Algorithmus [JM04] . . . . . . . .
Zählen der Peers durch Datenaggregation in einem dynamischen Netzwerk [JM04] . . . .
Der übergelaufene General X gibt widersprüchliche Anweisungen . . . . . . . . . . . . .
Unauflösbare Verwirrung unter den Generälen . . . . . . . . . . . . . . . . . . . . . . . .
Der loyale General gibt konsistente Befehle . . . . . . . . . . . . . . . . . . . . . . . . .
Eine Mehrheitsentscheidung unter den drei Offizieren kann von dem Überläufer nicht gestört werden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 byz-loes-3.pdf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6 Struktur des Peer-to-Peer-Netzwerks von [FS02] . . . . . . . . . . . . . . . . . . . . . . .
5.7 Zwei Realitäten eines (zwei-dimensionalen) CAN-Peer-to-Peer-Netzwerks . . . . . . . .
5.8 Hop-Distanz-Verringerung durch Erhöhung der Dimension und der Anzahl der Realitäten
in CAN [RFH+ 01] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.9 Iterativer Lookup in Chord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.10 Rekursiver Lookup in Chord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.11 Vergleich von iterativen und rekursiven Lookup in Chord [DLS+ 04] . . . . . . . . . . . .
5.12 Wahl der Finger in Chord durch Proximity Neighbor Selection (PNS) [DLS+ 04] . . . . .
5.1
5.2
5.3
5.4
VI
47
47
48
49
49
50
51
53
54
56
57
58
58
58
59
62
63
64
64
66
68
69
71
71
72
74
76
78
78
85
85
86
86
86
87
89
90
91
91
92
93
5.13
5.14
5.15
5.16
5.17
Vergleich von PNS, PRS und deren Kombination in Chord [DLS+ 04] . . . . . . . .
(0, 1; 0, 5; 0, 9)-Perzentile eines solchen PNS-samples verschiedener Größ[DLS+ 04]
Routing Zeit eines PNS-16-samples im Vergleich zu PNS in Chord [DLS+ 04] . . . .
Kumulativer Performanz-Gewinn in DHash++ [DLS+ 04] . . . . . . . . . . . . . . .
Vergleich von STP und TCP in DHash++ [DLS+ 04] . . . . . . . . . . . . . . . . .
VII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
93
94
94
96
97
VIII
Tabellenverzeichnis
2.1
Nachrichtentypen in Gnutella
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1
Notation des Routing-Algorithmus von Pastry in Abbildung 3.33 . . . . . . . . . . . . . .
45
IX
X
Kapitel 1
Organisation
1.1
Inhalte der Veranstaltung
1. Vorlesung
Ein Peer-to-Peer-Netzwerk (P2P-Netzwerk) ist ein Kommunikationsnetzwerk, in dem die Teilnehmer so- 23.04.2004
wohl Client als auch Server-Aufgaben wahrnehmen. Hierfür stehen den Teilnehmer nur bidirektionale Verbindungen zur Verfügung, wobei zentrale Strukturen absichtlich vermieden werden. Bekannt und beliebt
sind solche Kommunikationsnetzwerke durch die Dateitauschbörsen im Internet geworden wie (seiner Zeit)
Napster und Gnutella.
Im Rahmen dieser Veranstaltung werden algorithmische Ansätze zur effizienten Realisierung solcher
Netzwerke vorgestellt und diskutiert.
Nach einem kurzen Überblick über die Einsatzmöglichkeiten von P2P-Netzwerken in der Praxis wenden wir uns ihm Hauptteil der Veranstaltung den algorithmischen Problemstellungen zu. Wir stellen hier
unter anderem die P2P-Netzwerke CAN, Chord, Pastry und Tapestry vor, die vollständig ohne zentrale
Strukturen auskommenund werden ihre Effizienz mathematisch untersuchen. Danach wenden wir uns der
Zuverlässigkeit und Sicherheit von P2P-Netzerken zu. Als Ausblick wird der Zusammenhang von P2PNetzwerken und mobilen Ad-Hoc-Netzerken diskutiert.
1.2
Organisation
Aktuelle Informationen zu dieser Veranstaltung befinden sich auf der Web-Seite:
http://wwwcs.upb.de/cs/ag-madh/WWW/Teaching/2004SS/AlgoP2P/
Für weitere organisatorische Fragen stehen Christian Schindelhauer ([email protected]) und Peter
Mahlmann ([email protected]) immer gerne zur Verfügung.
1.2.1
Termine
Die Vorlesung findet vom 23.04.2004 - 30.07.2004 jeden Freitag von 9-11 Uhr in Raum F0.530 statt. Die
Übungen vom 26.04.2004 - 26.07.2004 sind in drei Gruppen unterteilt.
• Übungsgruppe A, montags von 10-11 Uhr in Raum F0.530
• Übungsgruppe B, montags von 11-12 Uhr in Raum F0.530
• Übungsgruppe C, montags von 16-17 Uhr in Raum F0.530
1.2.2
Vorlesungsmaterial
Zu dieser Veranstaltung wird das folgende Material zur Verfügung gestellt.
1
• Die Webseite der Veranstaltung:
http://wwwcs.upb.de/cs/ag-madh/WWW/Teaching/2004SS/AlgoP2P/
mit allen Informationen und insbesondere diesem Skript
• Vorlesungsfolien im Powerpoint und PDF-Format
• Skript als PDF-Dokument
Neben den Übungsaufgaben ist das Skript die Grundlage zur Prüfung. Das Skript wird gegen Ende
der Vorlesung auf der Web-Seite zur Verfügung gestellt.
• Literaturhinweise
werden hier im Skript auf Seite 3 aufgeführt.
• Übungsaufgaben
Die Übungsaufgaben werden am Mittwoch jeder Woche auf der Web-Site zur Verfügung gestellt.
Die Übungsaufgaben sind ausdrücklich Bestandteil der Prüfung. Die Lösungen zur Übungsaufgabe
werden vom Veranstalter nicht zur Verfügung gestellt.
• Mögliche Prüfungsfragen werden im Skript veröffentlicht auf Seite 4.
• Übungsanmeldung und Anmeldung zum Vorrechnen geschieht durch das StudInfo{flex}-System
(entwickelt von der Fachgruppe Kastens). Es ist verfügbar über die URL:
https://studinfo.upb.de/cgi-bin/go?c=p2p_2004ss&m=account
• Anmeldung zur mündlichen Prüfung per EMail an Christian Schindelhauer ([email protected])
1.2.3
Prüfung
Wer nach der DPO 4 oder der neuen Lehramtsstudienordnung studiert, kann im Anschluss an dieser Veranstaltung eine benotete, mündliche, ca. 30-minütige Prüfung bei Christian Schindelhauer ablegen. Eine
Stunde vor dieser mündlichen Prüfung wird dem Teilnehmer eine der Aufgaben aus der Übung vorgelegt,
die er alleine ohne Hilfsmittel schriftlich bearbeiten muss und deren Lösung er in der mündlichen Prüfung vorstellt. Zusätzlich werden (natürlich) Fragen zur Vorlesung gestellt. Ein Katalog möglicher Fragen
findet sich in diesem Skript. Der schriftliche Teil der Prüfung kann durch erfolgreiche Teilnahme in der
Übung ersetzt werden. Die Teilnahme an der Übung war erfolgreich, wenn mindestens eine Aufgabe vor
den Teilnehmern richtig vorgerechnet wurde und diese Aufgabe mustergültig schriftlich bearbeitet wurde.
Die Teilnahme an der Übung wird dann entsprechend der Leistung benotet und diese Note fließt in die
Notengebung der mündlichen Prüfung ein.
Die Prüfungen finden in den beiden folgenden Woche statt.
• I. Prüfungszeitraum: 13.-17.09.2004 (10-17 Uhr)
• II. Prüfungszeitraum: 04.-08.10.2004 (10-17 Uhr). Das ist die Woche vor Vorlesungsbeginn des Wintersemesters.
Zusätzlich wird eine öffentliche mündliche Prüfung im Rahmen der letzten Vorlesung am Freitag, den
30.07, 9-11 Uhr in F0.530 durchgeführt.
Die Prüfungsanmeldung ist bis zum 30.07. per EMail an Peter Mahlmann ([email protected])
möglich. Weitere Prüfungen sind in Ausnahmefällen nach Vereinbarung möglich.
1.2.4
Übungen
Wie bereits beschrieben werden die Übungsaufgaben auf den Web-Seiten jeden Mittwoch zur Verfügung
gestellt. Die Besprechung der Lösung geschieht (in der Regel) am darauf folgenden Montag. Die Aufgabenstellungen werden gemäß der Ausrichtung dieser Veranstaltung hauptsächlich aus dem Gebiet der
verteilten Algorithmen und Wahrscheinlichkeitstheorie gewählt.
2
Die Gruppeneinteilung geschieht online über das StudInfo{flex}-System. Es gibt drei Übungsgruppen
mit einer maximalen Teilnehmerzahl von jeweils 30 Studenten1 .
1.3
Literatur und Links
Folgende Bücher, Artikel und Web-Seiten können zur vertiefenden Lektüre besonders empfohlen werden.
• O’Reilly Network: OpenP2P http://www.openp2p.com/
Diese praktisch orientierte Web-Site ist eine Fundgrupe für die aktuelle Entwicklung im Bereich von
Peer-to-Peer-Netzwerken. Diese Web-Site richtet sich and die breitere Öffentlichkeit und hat daher
wenig wissenschaftliches zu berichten . . . .
• CAN: A Scalable Content-Addressable Network von Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp und Scott Shenker [RFH+ 01] beschreibt einen der ersten Ansätze den Peer-toPeer-Netzwerke mit effizienten Datenstrukturen zu Leibe zu rücken. Dieser Artikel ist (fast vollständig) Bestandteil der Vorlesung und eignet sich hervorragen zu vertiefendem Studium.
• Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications von Ion Stoica, Robert
Morris, David Karger, M. Frans Kaashoek und Hari Balakrishnan [SMK+ 01] beschreibt erstmals ein
Peer-to-Peer-Netzwerk mit logarithmischen Zeitverhalten. Auch dieser Artikel wird fast vollständig
im Rahmen dieser Veranstaltung behandelt. Eine Lektüre kann nur empfohlen werden.
• Koorde: A simple degree-optimal distributed hash table, von David R. Karger und M. Frans
Kaashoek [KK03]. Das Peer-to-Peer-Netzwerk Koorde besticht durch seine einfache elegante Struktur. Auch der Artikel ist lesenswert.
• Tapestry: An Infrastructure for Fault-tolerant Wide-area Location and Routing von Ben Y.
Zhao, John Kubiatowicz, und Anthony D. Joseph [JZK02] gibt eine ausführliche Beschreibung des
Tapestry-Peer-to-Peer-Netzwerks wieder.
• Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems
von Peter Druschel und Antony Rowstron [DR01b] beschreibt ein Peer-to-Peer-Netzwerk, das wie
Tapestry auf Plaxtons Routing-Algorithmus aufbaut. Dennoch gehen hier die Leute von Microsoft
Research andere Wege als die von der UC Berkeley.
• Viceroy [MNR02] Dieses Peer-to-Peer-Netzwerk basiert auf dem Butterfly-Graphen und wird im
Rahmen dieser Vorlesung vorgestellt. Es war das erste Peer-to-Peer-Netzwerk mit konstanten Einund Ausgrad.
• Distance Halving [NW03] Dieser Ansatz von denselben Autoren konzentriert sich auf den Übergang
von kontinuierlichen Graph zu diskreten (Peer-to-Peer-) Netzwerken.
• Epidemic Algorithms [DGH+ 87] In diesem wichtigen Artikel wird der Begrich der epidemischen
Algorithmen zur Informationsverbreitung in replizierten Datenbanken eingeführt. Ein wegweisender
Artikel besonders für den Bereich der verteilten Datenbanken.
• Randomized Rumor Spreading [KSSV00] Dieser Artikel analysiert das Ausbreitungsverhalen im
Anrufmodell (random call model) von Gerüchten (epidemischen Algorithmen). Insbesondere wird
hier ein sehr effizienter Terminierungsmechanismus vorgestellt.
• Fortsetzung folgt . . .
1 Am
04.05.2004 waren 90 Studenten zu dieser Veranstaltung angemeldet
3
1.4
Prüfungsfragen
Die folgenden Fragen können in der Prüfung vorkommen. Daneben kommen Fragen zur Übung vor.
1. Vorlesung, 23.04.2004, P2P-Netzwerke der 1. Generation
• Was ist ein Peer-to-Peer-Netzwerk?
• Was ist Napster und wie funktioniert es?
• Was ist Gnutella und wie funktioniert es?
• Diskutieren Sie die Vorteile und Nachteile von Gnutella im Vergleich zu Napster.
• Was sind hybride Peer-to-Peer-Netzwerke und in wie fern sind sie besser als die dezentrale
Peer-to-Peer-Netzwerke?
• Vergleichen Sie die Netzwerkstrukturen der Peer-to-Peer-Netzwerke der ersten Generation
2. Vorlesung, 23.04.2004, DHT, CAN
• Warum skaliert Naster nicht?
• Warum skaliert Gnutella nicht?
• Warum eignen sich eine Hash-Tabelle nicht direkt als geeignetes Peer-to-Peer-Netzwerk?
• Was ist eine Distributed Hash-Table (DHT)?
• Wie werden Peers und Daten in CAN eingefügt?
3. Vorlesung, 07.05. 2004, CAN
• Wie werden Peers in CAN eingefügt?
• Erläutern Sie das Probelm der Fragmentierung.
• Welchen Einfluß hat die Anzahl der Dimensionen auf CAN?
• Was versteht man unter Realtitäten in CAN?
• Vergleichen Sie die Vor- und Nachteil von Realitäten und Dimensionen in CAN.
• Wie kann man die Latenzzeit in CAN optimieren?
4. Vorlesung, 17.05. 2004, Chord, Chernoff
• Was besagt die Markoff-Ungleichung?
• Was besagt die Chebyshev-Ungleichung?
• Warum ist die Chernoff-Schranke so ein nützliches Werkzeug?
• Beweisen Sie die Gültigkeit der Chernoff-Schranke.
5. Vorlesung, 21.05.2004, Chernoff, Chord
• Was ist Chord?
• Wieviele Finger hat Chord? Wozu dienen Sie?
• Wie effizient ist der Lookup in Chord?
• Wie hoch ist der Eingrad und der Ausgrad in Chord?
• Wie nimmt man Peers in Chord auf?
• Wie lange dauert die Peer-Aufnahme in Chrod?
6. Vorlesung, 28.05.2004, Koorde
• Beschreiben Sie die Struktur von Koorde.
• Welche Eigenschaften hat Koorde?
4
• Was ist ein DeBrujin-Graph?
• Welche Eigenschaften hat ein DeBrujin-Graph?
• Erläutern Sie den k-DeBrujin-Graphen.
7. Vorlesung, 04.06.2004, Tapestry
• Was versteht man unter Nachbarschaftsmengen und welche Eigenschaften besitzen diese?
• Wie funktioniert Routing im Tapestry Netzwerk?
• Wie können neue Peers in ein Tapestry Netzwerk eingefügt werden?
• Welchen Zweck erfüllt der Acknowledged Multicast Algorithmus?
• Wie kann ein neuer Peer seine Routing-Tabelle aufbauen, damit diese die Lokalitäts-Eigenschaft
erfüllt?
• Was sind die Aufgaben von Root-Sets und Storage-Servern?
8. Vorlesung, 11.06.2004, Pastry
• Erläutern Sie die Unterschiede zwischen Pastry und Tapestry.
• Welche Zeiger hat Pastry?
• Was bedeuten die Einträge in der Routing-Tabelle?
• Wie fügt man Peers in Pastry ein?
• Wann müssen die Routing-Einträge repariert werde und wie geschieht dies?
• Erläutern Sie das Routing in Pastry.
• Welche Formen der Lokalität kennt Pastry?
• Diskutieren Sie die experimentellen Resultate im Zusammenhang mit Pastry.
9. Vorlesung, 14.06.2004, ViceRoy, Distance-Halving
• Erläutern Sie die Motivation für das Viceroy-Netzwerk.
• Wie ist Viceroy aufgebaut?
• Warum ist das Butterfly-Netzwerk besonders gut für Routing geeignet?
• Wie kann man log n berechnen, wenn n die Anzahl der Knoten in Viceroy bezeichnet?
• Wie fügt man einen neuen Peer in Viceroy ein?
• Wie funktioniert der Lookup in Viceroy?
• Wie effizient sind diese Operationen?
• Beschreiben Sie das Prinzip der mehrfachen Auswahl.
• Zeigen Sie, dass mit dem Prinzip der mehrfachen Auswahl der Eingrad in Peer-to-Peer-Netzwerken
erheblich reduziert werden kann.
• Was sind kontinuierliche Graphen?
• Erläutern Sie Distance-Halving!
• Wie funktioniert der Lookup in Distance-Halving?
• Welcher Mechanismus kann Congestion Distance-Halving reduzieren?
10. Vorlesung, 21.06.2004, Epidemische Informationsverbreitung
• Was sind Replizierte Datenbanken? Wie kann man sie unterhalten?
• Erläutern Sie das Anruf-Modell. Was ist Push und Pull und Push&Pull?
• Beschreiben Sie das Ausbreitungsverhalten von Push, Pull und Push&Pull.
5
• Beschreiben Sie Terminierungsstrategien für epidemische Algorithmen. Wie kann man die
Nachrichtenanzahl klein halten?
11. Vorlesung, 02.07.2004, Epidemische Informationsverbreitung
• Wie kann man die Anzahl der Teilnehmer eines Peer-to-Peer-Netzwerks bestimmen?
• Welche Funktionen kann man durch Datenaggregation bestimmen?
12. Vorlesung, 09.07.2004, Sicherheit in Peer-to-Peer-Netzwerken
• Nennen Sie allgemeine Methoden der Kryptographie.
• Welche Sicherheitsanforderungen haben Peer-to-Peer-Netzwerke?
• Beschreiben Sie eine Sybil-Attacke.
• Kann man Sybil-Attacken abwehren?
• Erklären Sie das Problem der Byzantinischen Generäle.
• Wie kann man das Problem der Byzantinischen Generäle lösen?
• Wie kann man ein Zensur-resistentes Peer-to-Peer-Netzwerk aufbauen?
13. Vorlesung, 12.07.2004, DHash++
• Welche Techniken verwendet CAN zur Latenz-Optimierung eingesetzt?
• Welche speziellen Techniken werden bei DHash++ zur Optimierung des Routing eingesetzt?
• Was versteht man unter Datenlayout?
• Erklären Sie den rekursiven und iterativen Lookup in DHash++.
• Wie kann man die nächste Nachbarwahl in DHash++ organisieren?
• Was sind Erasure Resilient Codes?
6
Kapitel 2
Peer-to-Peer-Netzwerke der ersten
Generation
2.1
Was ist ein Peer-to-Peer-Netzwerk?
Das englische Wort Peer (sprich „Pier“) bezeichnet einen Ebenbürtigen, Gleichrangigen (aber auch ein
Mitglied des Hochadels) 1 . Laut dem Online-Wörterbuch von Merriam-Webster geht diese Word über das
Mittelenglisch ethymologisch zurück auf das lateinische Wort par, welches auch im Deutschen als gleich
verwendet wird. Demnach ist ein Peer-to-Peer-Netzwerk wortwörtlich ein Netzwerk, das Gleichrangige
mit anderen Gleichrangigen direkt verbindet.
Diese Umschreibung würde aber allgemein für Rechner des Internets gelten. Schließlich unterscheiden
die Internet Protocol (IP) Adressen nicht zwischen besonder bevorrechteten und weniger bevorrechteten
Adressen, so dass man mit Fug und Recht das Internet selbst aus Peer-to-Peer-Netzwerk bezeichnen könnte.
Ursprünglich mag das Internet auch so funktioniert haben. Aber mit der Zeit haben sich bestimmte Dienste,
wie zum Beispiel Web-Server oder Mail-Server, immer weiter zu zentralisierten Client-Server-Strukturen
herausgebildet.
Bei einer Client-Server-Netzwerk-Struktur kontrolliert ein besonders bevorrechtigteter Knoten, genannt
der Server, die anderen Teilnehmer, die Clients genannt werden. Ein gutes Beispiel ist ein Web-Server, dieser speichert Web-Seiten, die von den Web-Clients abgerufen werden können. Hierzu melden sich diese
mittels einer TCP (Transmission Control Protocol) bei dem Web-Server an, wonach dieser die Web-Seiten
diesen Client zusendet. Verweigert der Server einen Web-Client den Zugriff, so ist dieser machtlos. Andererseits sind die Web-Seiten auch nicht mehr abrufbar, falls der Web-Server ausgefallen ist.
Wenn man also die funktionale Beschreibung eines Netzwerks betrachtet, so gilt die folgende Definition:
Ein Peer-to-Peer-Netzwerk ist ein Kommunikationsnetzwerk zwischen Rechnern, in dem
jeder Teilnehmer sowohl Client als auch Server-Aufgaben durchführt.
Obgleich diese Definition eine gute Intuition gibt, werden wir sehen, dass es tatsächlich Peer-to-PeerNetzwerke gibt (z.B. Napster), die nicht unter diese Definition fallen. Daher ist die Peer-to-Peer-WorkingGroup (http://p2p.internet2.edu/index.html) mit ihrer Definition etwas allgemeiner:
In einem Peer-to-Peer-Netzwerk werden verteilte Rechenresourcen durch direkte Kommunikation gemeinsam genutzt.
Mit dieser Definition ist man sicher zu allgemein. Das Einzige was man mit Sicherheit über Peer-toPeer-Netzwerke sagen kann, ist dass Peer-to-Peer-Netzwerke nicht Client-Server-Netzwerke sind.
Ein besseres Verständnis, was Peer-to-Peer-Netzwerke sind, erhält man, indem man sich die noch junge
Geschichte der Peer-to-Peer-Netzwerke betrachtet.
1 laut
dem Wörterbuch von LEO: http://dict.leo.org
7
Client
Client
Datei
Client
Client
Server
Client
Client
Reply
Client
File Download
Query
Client
Abbildung 2.1: Funktionsweise von Napster
2.2
Napster
Napster ist ein geschichtlich wichtiges Netzwerk. Wir werden es hier hauptsächlich aus diesem Grund
vorstellen. Algorithmisch hat es wenig zu bieten und ob es wirklich ein echtes Peer-to-Peer-Netzwerk ist,
gelinde gesagt, umstritten.
2.2.1
Geschichte
Shawn (Napster) Fanning (Jahrgang 1980) brachte im Juni 1999 eine Beta-Version seines mittlerweile legendären Peer-to-Peer-Netzwerks heraus. Die ursprüngliche Aufgabe dieser Software war ein File-SharingSystem mit dem man Dateien auf Rechnern, die sich an diesem Rechnern anmelden, lokalisieren kann und
dann direkt von diesen Rechnern herunterladen kann. Erst durch das Engagement eines Freundes von ihm
wurde aus dem File-Sharing-System ein Musik-Portal, das hauptsächlich zur Verbreitung von Musikdateien diente. Dadurch wurde aus Napster schon im Herbst 1999 der Download des Jahres.
Wegen der systembedingten Missachtung von Urheberschutzrechten der Musikautoren klagten Musikverlage gegen Fanning und drohten mit einer Stillegung des Systems. Tatsächlich geschah einige Zeit nichts
und durch die durch den Rechtsfall gesteigerte Publizität nahm die Anzahl der Teilnehmer sogar zu. In einer
überaschenden Wendung ging Fanning Ende 2000 einen Kooperationsvertrag mit Bertelsmann Ecommerce
ein und wandelte seine bislang kostenloses System in eine kommerzielle File-Sharing-Plattform um.
2.2.2
Aufbau
Der Aufbau und Funktionsweise von Napster ist weitaus weniger aufregend als die Geschichte von Napster.
Napster folgt im wesentlich einer Client-Server-Struktur, siehe Abbildung 2.1. Ein Server unterhält einen
Index mit Meta-Datein über den Dateinamen, das Dateidatum und ähnlichen Informationen. Neben dieser
Datenbank hat der Server eine Tabelle über die Verbindungen der teilnehmenden Clients. Aus dieser Tabelle
aller öffentlich gemachten Dateien der teilnehmenden Clients werden jetzt die Anfragen bedient.
Bei einer Anfrage (Query) fragt ein Client nach dem Dateinamen und der Server sucht in seiner Datenbank nach dem passenden Teilnehmer. Der Server teilt dann dem Client mit welcher andere Client die
gewünschte Datei besitzt. Der Anfrage-Client lädt dann die Datei direkt vom dateibesitzenden Client herunter.
Dieser letzte Schritt im File-Sharing ist der einzig Schritt der unserer eingangs formulierten Definition
eines Peer-to-Peer-Netzwerks entspricht. Man kann sich vorstellen, dass diese Lösung genau dann Sinn
8
macht, wenn der Server nicht in der Lage ist alle Dateien zu speichern. Auch wird so unnötiger Datenverkehr zwischen Server und Clients vermieden. Und genau dieser Aspekt regte die Fantasie vieler Entwickler
an, diesen Mechanismus weiter auszubauen.
2.2.3
Diskussion
Die Vorteile von Napster sind seine Einfachheit und die Möglichkeit schnell und effizient auf Dateiverweise zu finden.
Die Nachteile sind vor allen in der Client-Server-Struktur begründet. Diese zentrale Struktur erleichtert feindliche Eingriffe in das System. Dies muss nicht unbedingt eine richterliche Verfügung im Auftrag
eines Muskverlags sein, es kann sich auch die represssive Verfolgung in einem Unrechtsstaat handeln. Des
weiteren sind auch Denial-of-Service-Angriffe eine einfache Methode solche zentralen offenen Strukturen
zu torbpedieren. Viel einfacher kann das Versagen eines solchen zentrierten Systems durch einen Systemausfall der zentralen Kompononente (Programmabsturz, Hardware-Ausfall, etc.) geschehen.
Ein weiter Nachteil ist, dass Napster nicht skaliert. Wenn die Teilnehmerzahl zunimmt, kann der zentrale Server die Anfragen nicht mehr schnell genug bearbeiten. Ausserdem kann schon die Speicherung der
Meta-Daten leicht überhand nehmen.
Als Resumee bleibt festzuhalten, dass Napster keine akzeptable Peer-to-Peer-Netzwerklösung darstellt.
Bis auf den direkten Download ist Napster gar kein Peer-to-Peer-Netzwerk im eigentlichen Sinne.
2.3
Gnutella in der Originalversion
Ein echtes Peer-to-Peer-Netzwerk ist dagegen Gnutella.
2.3.1
Aufbau
Gnutella wurde im März 2000 von Justin Frankel und Tom Pepper (Nullsoft) herausgegeben. Wie Napster
handelt es sich bei Gnutella um ein File-Sharing-System. Im Gegensatz zu Napster handelt es sich um ein
echtes Peer-to-Peer-Netzwerk ohne jegliche zentrale Strukturen und zentrale Kontrolle.
Wie kann man aber ereichen, dass ein Netzwerk entsteht ohne zentrale Kontrolle. Das Problem fängt
schon beim Download der Software an. Da die Benutzer einander anfangs nicht kennen, müssen bestimmte
Adressen im Programm voreingestellt werden. Wie kann man aber verhindern, dass diese nicht als Server dienen. Nun Gnutella wird mit einer Liste von Adresse ausgeliefert, die bei Programmstart von den
Gnutella-Peers durchprobiert werden. Wird nun ein aktiver Peer aus dieser Liste gefunden, so wird eine
k-hop-Nachbarschaft des Peers angefragt und daraus eine eigene Nachbarschaftsliste aufgebaut. Hat ein
Peer erste eine eigene Nachbarschaftsliste gewonnen, so speichert er diese und startet beim nächsten Mal
mit dieser und erweitert sie wie eben beschrieben.
Auf diese Weise erhält jeder Peer sein eigenes Umfeld und kann auf eine robuste (eigene) Liste von
Peers zurückgreifen, sollte einmal kein Peer auf der originären Liste verfügbar sein.
Gnutella baut auf dem IP (Internet Protocol) auf und das Gnutella-Protocol benutzt nur vier verschiede
Nachrichtentypen, wie in Tabelle 2.1 gezeigt.
Deer Standard-Header einer Nachricht besteht nach der Gnutella Spezifikation [Gnu] aus
• Message identifier: Das ist eine 2-Byte-ID, welche anzeigt ob diese Nachricht bereits empfangen
wurde.
• Function identifier: Hier wird der Typ der Nachricht beschrieben (Ping, Pong, Push Request, Query,
Query Hits)
• TTL: Das ist das Time-to-Live-Feld. Analog zum TTL-Feld im IP-Protokoll wird hier die maximale
Anzahl von Übertragungen (Hops) der Nachricht festgelegt
• Hops: Anzahl der bereitszurückgelegten Strecke der Nachricht
• Payload length: Länge der Nachricht
9
Typ
Ping
Pong
Beschreibung
Anfrage an Peer, sich anzukündigen
Antwort auf Ping
Query
Suchanfrage
Query-Hits
Antwort auf Query
Inhalt
—
IP und Port-Adresse des Antwortgebers, Anzahl und Größe veröffentlichter Dateien
minimale Geschwindigkeitsanforderung des Antwortgebers, Suchstring
IP und Port-Adress, Geschwindigkeit des Antwortgebers, Anzahl
passender Datein und ihre indizierte
Ergebnismenge
Tabelle 2.1: Nachrichtentypen in Gnutella
Mit dem eingangs beschriebenen Prozess erhält so jeder Peer eine Nachbarschaftsliste, die immer weiter verlängert und gespeichert werden. Dabei ist die Anzahl aktiver Nachbarn beschränkt (typischer Wert
wäre fünf). Man beachte insbesondere, dass die Antworten auf die Ping-Anfragen (die Pongs) auf dem
Anfragepfad zurückgeschickt werden (und nicht etwa auf dem kürzesten Weg).
Der Informationsprozess folgt immer dem Prinzip eines beschränkten Broadcast. Das bedeutet, dass
der Erzeuger einer Nachricht eine Sprungweite, TTL genannt, der ersten Nachricht mitgibt und dieser
Wert wird mit jeder Weitergabe um eins verringert. Jeder Peer, der eine Ping- oder Query-Nachricht erhält,
reicht diese an alle Nachbarn, weiter. Diese Art der Informationsweitergabe ähnelt damit gewissermaßen
der Verbreitung einer Epidemie oder eines Virus.
Die resultierende Graphstruktur ensteht also durch einen zufälligen Prozess, da sie allein durch die
Menge der (zufällig) aktiven Prozessoren und deren gerade aktiven Nachbarn bestimmt wird. Man sieht,
dass es keine zentrale Instanz oder verteilte Kontrollmechanismen gibt (außer dem TTL-Feld), welche die
Struktur des Verbindungsgraph kontrollieren. Gewisse statistische Gesetzmäßigkeiten lassen sich dennoch
entdecken. So unterliegen wichtige Parameter der Graphstruktur, wie die Verteilung des Grades der Knoten, der Pareto-Verteilung [JAB01]. Ein Schnappschuss eines solchen Verbindungsnetzwerks aus diesem
Artikel wird in Abbildung 2.4 gezeigt.
Die Dateianfrage geschieht völlig analog zum Ping-Pong-Prozess. Eine Query wird durch beschänkten Broadcast an alle Nachbarn im Graph in Entfernung TTL weitergeleitet und in entgegengesetzter
Richtung werden die Antworten (Typ: Query-Hits) auf denselben Pfaden zurückgeleitet. Wenn der Anfrager die gewünschte Datei identifiziert hat, kann er sie direkt von dem Knoten herunterladen. Siehe auch
Abbildung2.3.
Wir sehen also, dass im Gegensatz zu Napster hier zum ersten Mal ein echtes Peer-to-Peer-Netzwerk
vorliegt, welches vollständig ohne zentrale Kontrollmechanismen auskommt.
2.3.2
Diskussion
Die Vorteile von Gnutella rühren von dieser verteilten Netzwerkstruktur. Dadurch ist Gnutella extrem
robust und praktisch unangreifbar. Diese Netzwerkstruktur skaliert auch sehr gut, was hier heisst, dass
beliebig viele Knoten ohne Performanzverlust aufgenommen werden können.
Dennoch hat Gnutella eine Reihe von Nachteilen. Das Hauptproblem ist, dass durch die tiefenbeschränkte Suche nur in einem Teilnetzwerk nach der Zieldatei gesucht wird. Hat nun die Zieldatei eine
große Verbreitung, wie zum Beispiel die Kassenschlager der Musik (top ten), dann werden sie dennoch gefunden. Selten vorhandene Dateien können dagegen nicht gefunden werden. Dieses Problem könnte man
durch Erhöhung des TTL-Eintrags erhöhen, wenn nicht der zweite Nachteil von Gnutella dadurch nicht
noch verschärft würde. Dies ist das Nachrichtenaufkommen. Da es völlig unklar ist, wo die Zieldatei sich
befindet, werden eine Reihe von Zielanfragen (sinnlos) von Knoten weitergeleitet. Daneben ist der Netzwerkdurchmesser eines Gnutella-Netzwerks verglichen mit einer Baumstruktur relativ hoch und dadurch
10
pong
ping
ping
pong
ping
pong
neue
Verbindungen
ping
pong
TTL = 3
pong
ping
ping
Abbildung 2.2: Anbindung von neuen Knoten in Gnutella
Datei
query
query-hits
query
Download
query
query-hits
query
TTL = 3
query-hits
query
query
Abbildung 2.3: Dateisuche in Gnutella
11
Abbildung 2.4: Das Gnutella-Netzerk (Schnappschuss 2000) [JAB01]
muss man zusätlich mit großen Latenzzeiten (Verzögerungszeiten) rechnen.
Es gibt eine Reihe von Verbesserungvorschläge, um das Nachrichtenaufkommen zu verringern. Einer
sieht zum Beispiel die Verwendung von Random Walks statt Broadcasting vor. In einem Random Walk
wird eine Nachricht nicht an alle Nachfolger sondern nur an einem zufälligen weitergereicht. Auf diese
Weise wird die Suchanfrage weiter in das Netzwerk hineingereicht ohne das Nachrichtenaufkommen stark
zu erhöhen.
Andere schlagen die passive Replikation von Information entlang eines Pfads vor. Hierbei werden
Ergebnislisten gespeichert und neue Anfragen nach den selben Dokument können dann sofort ohne weitere
Suchnachrichten beantwortet werden.
2.4
Kazaa, Gnutella (II), Morpheus
Die Schwächen von Gnutella blieben ihren Vätern nicht verborgen und so verbesserten diese die Struktur
zu einem sogenannten hybriden Netzwerk. Eine ähnliche Struktur liegt auch Kazaa und Morpheus zu
Grunde. Wir werden das Prinzip hier kurz vorstellen.
Besonders geeignete Knoten (z.B. mit hoher Bandbreite) werden zu sogenannten Super-Knoten (SuperNodes) ernannt. Zwischen diesen relativ wenigen Super-Nodes wird nun das ursprüngliche Gnutella-Peerto-Peer-Netzwerk etabliert. Normale Knoten werden an diese Super-Knoten als Clients angebunden, siehe
Abbildung2.5.
Die Vorteile einer solchen Netzwerkstruktur sind die verbesserte Skalierbarkeit und geringere Latenzzeiten. Dagegen spricht die Abkehr vom reinen Prinzip, dass jeder Teilnehmer die selben Aufgaben und
Funktionen erhält. So könnte sich zum Beispiel ein Client der Super-Node-Aufgabe verweigern.
Außerdem ist dieses Netzwerk immer noch unzuverlässig und langsam, da es nicht klar ist, ob das TTLFeld nun ausreicht das Netzwerk zu durchqueren und die Wege immer noch lang sein können. Daneben
verringern sich die Nachrichtenmenge innerhalb der Super-Nodes nicht. Hier werden nun praktische alle
(oder zumindestens ein großer Anteil) mit allen Anfragen konfrontiert.
12
Super-Nodes
Client-Nodes
Abbildung 2.5: Eine hybride Netzwerkstruktur
2.5
Zusammenfassung
Wir haben in diesem Abschnitt die Frühphase der Peer-to-Peer-Netzwerke kurz gestreift. Das klassische
Peer-to-Peer-Netzwerk ist sicherlich Gnutella, während Napster obgleich seiner Client-Server-nahen Struktur, durch siene Publizität die Aufmerksamkeit und Fantasie einer größeren Öffentlichkeit erregt hat.
Es gibt eine Reihe von Fragestellungen im Bereich der Datenbanken, die Ontologie und Autnomie von
Daten betreffen, die von hohen Interesse liegen, die im Rahmen dieser Vorlesung (aufgrund der algorithmischen Ausrichtung) nicht erwähnt werden, siehe hierzu [DGMY02].
Daneben gibt es auch eine Reihe von praktischen Fragestellungen, die wir hier nur am Rande streifen
werden. Dies sind zum Beispiel nach Nelson Minar [Min01]:
• Die Handhabbarkeit eines Peer-to-Peer-Netzwerks
Sind die Kontrollmechanismen zu kompliziert, dass eine Implementation praktisch nicht durchführbar wird?
• Die Informationskohärenz
Also wie gut wird die Information verteilt, wie gut ist sie verfügbar.
• Erweiterbarkeit oder Skalierbarkeit
Wie gut kann das Netzwerk wachsen und dabei noch schnell Anfragen verarbeiten?
• Fehlertoleranz
Wie gut können Ausfälle von Peers oder fehlerhafte und veraltete Information im Netzwerk verkraftet werden.
• Sicherheit
Wie leicht kann es mutwillig zerstört werden?
• Schutz gegen politische Verfolgung
Kann eine Regierungsbehörde das Netzwerk einfach ausschalten?
Wir werden uns beginnen mit dem nächsten Kapitel hauptsichlich um das Problem der Erweiterbarkeit
oder Skalierbarkeit kümmern. Die anderen Problemstellungen sind sicherlich für die praktische Umsetzung
oder für die Verbreitung eines Peer-to-Peer-Netzwerk von entscheidender Kontrolle, wird aber im Rahmen
dieser Veranstaltung nicht tiefer besprochen.
Kommen wir zurück zu der eingangs gestellten Frage, was ein Peer-to-Peer-Netzwerk ausmacht. Ein
Lackmustest für Peer-to-Peer-Netzwerke [Shi01] kann sein:
13
• Sind variable Verbindungen und temporäre Netzwerkverbindungen die Norm?
• Sind die Kanten des Netzwerks autonom?
14
Kapitel 3
Skalierende Peer-to-Peer-Netzwerke
Die Frage der Skalierbarkeit eines Peer-to-Peer-Netzwerks ist eines der zentralen Problemstellungen in
dieser Veranstaltung.
2.Vorlesung
30.04.2004
3.1
Warum manche Netzwerke nicht skalieren
Bei Napster haben wir vor dem Download es nur mit einer Client-Server-Struktur zu tun. Der Schwachpunkt ist nun der Server der alle Anfragen der Clients zu bedienen hat. Wenn nun diese Anzahl steigt
(und man kann sich bei Millionen von Teilnehmern sich das leicht vorstellen), dann wird er zum Flaschenhals der Kommunikation. Graphtheoretische entspricht die Client-Server-Struktur einem Stern-Graph, siehe Abbildung 3.1. Der Server steht mit dem Grad n − 1 im Mittelpunkt und ist auch hinsichtlich des
Graphzusammenhangs ein Schwachpunkt, da der Stern-Graph nur 1-zusammenhängend ist.
Definition 1 Ein Graph ist k-zusammenhängend, wenn nach Entfernen von k − 1 beliebigen Knoten der
Graph noch zusammenhängend ist und wenn nach dem Entfernen von k Knoten der Graph nicht mehr
zusammenhängend ist.
Der Zusammenhang bei Gnutella ist höher. Genaue Werte lassen sich hier nicht angeben, da der Graph
durch die Verbindungsaufnahme am Anfang eine zufällige Struktur erhält, wie in Abbildung 3.2 angedeutet. Statistische Untersuchungen in [JAB01] zeigen aber, dass sich bezüglich Durchmesser und Verteilung
des Grads doch ein gesetzmäßiges Verhalten nachweisen lässt. So ist der Durchmesser nur logarithmisch in
der Anzahl der Teilnehmer und der Grad ist Pareto-verteilt, d.h. Knoten mit dem Grad d kommen in einer
Häufigkeit propotional zu dα für eine Konstante α < 0 vor. Die Ausnahmestellung der Pareto-Verteilung
zur Beschreibung von Netzwerken, die durch menschliches Wirken enstehen zeigt sich hier wie bereits bei
Abbildung 3.1: Die Client-Server-Struktur von Napster entspricht einem Stern-Graph [JAB01]
15
Abbildung 3.2: Ein zufälliger Graph, der die Struktur von Gnutella symbolisieren soll
der Anzahl von Links auf Web-Seiten. Es ist schon länger bekannt, dass die Verteilung der Bevölkerung
in Städten, der Wortlängen in Sprachen, des Vermögens in der Bevölkerungs, der Dateinamenlängen im
Unix-Betriebssystem und vieles mehr dieser Verteilung gehorcht. Eine weitere Beobachtung ist, dass der
durchschnittliche Grad im Gnutella-Netzwerk nur konstant ist (also α < −1).
Trotz dieser positiven Grapheigenschaften skaliert Gnutella sehr schlecht1 . Das Hauptproblem ist, dass
eine Anfrage an alle Nachbarn einer gewissen Umgebung weiter gegeben wird. Dadurch werden Peers in
einer Umgebung mit einer Reihe von Fragen belästigt, während es dieses Nachrichtenaufkommen nicht garantiert nicht, dass die Anfrage korrekt beantwortet wird, da weiter entfernte Information nicht abgegriffen
werden können.
Bei den hybriden Netzwerkstrukturen verbessert sich die Anfrageverarbeitung. Dennoch müssen dann
alle Super-Knoten die Anfrage bearbeiten. Damit skalieren dieses Netzwerke immer noch schlecht, da diese
wie bei Napstern dann unter Umständen Millionen von Anfragen zu bearbeiten haben.
Halten wir fest, dass die Skalierbarkeit eines Netzwerks von der schnellen Bearbeitung von zwei Fragen
abhöngt:
• Wo befindet sich die Information?
Bei Napster wird diese Frage einfach und effizient beantwortet, während bei Gnutella nur durch eine
ausufernde Suche gelöst werden kann.
• Wie kommt man dorthin?
Bei Napster ist dies das Problem, da der Zugang zum Server durch andere Anfragen blockiert werden
kann. Bei Gnutella ist dieses Problem auch nur unzufriedenstellend gelöst durch das Fluten des
Netzwerks mit Nachrichten.
3.2
Distributed Hash-Table
Die Verwendung einer effizienten Datenstruktur wie man sie in der Grundlagen-Veranstaltung Datenstrukturen und Algorithmen gelernt hat, könnte diese Problem leicht lösen. Verwendet man ein Wörterbuch zum
Speicher der Metaeinträge, dann kann man diese sehr effizient (in logarithmischer Zeit) wiederfinden. Die
beiden wichtigsten Datenstrukturen hierzu sind Bäume und Hash-Tabellen und wir werden beide Typen in
diesem Zusammenhang wiederfinden.
Wir beginnen unsere Überlegungen mit Hash-Tabellen. Hashing bedeutet wortwörtlich zerhacken (vgl.
Haschee) und tatsächlich wird der Schlüsseleintrag durch eine Funktion, die diesen geeignet verkürzt zerkleinert und diese dementsprechend in den Speicherbereich geschrieben. Eine einfache Hash-Funktion ist
zum Beispiel die Modulo-Funktion a mod p, die den Rest der Zahl a nach Division durch p bezeichnet.
1 Genauer gesagt, Gnutella skaliert hinsichtlich sehr gut, wenn es darum geht neue Knoten aufzunehmen. Leider gestaltet sich
dann die Suche in dieser entweder als äußerst nachrichtenintensiv oder sie ist erfolglos (je nach der Wahl der Sprungweite der Suche)
16
Abbildung 3.3: Der Standardansatz einer Hash-Tabelle ist nicht geeignet als Peer-to-Peer-Netzwerk
Werden dann die Zahlen 10, 20, 30 in ein Feld der Größe p = 7 gespeichert, so wird 10 in den Speicherplatz 10 mod 7 = 3 geschrieben; 20 in den Speicherplatz 20 mod 7 = 6 und 30 mod 7 = 2. Natürlich
wird es irgendwann nicht zu vermeiden sein, dass mehrere Elemente in einen Speicherplatz abgebildet
werden. Diese Situation nennt man Kollision. Um diese Kollisionen zu beheben, wurden im den Grundstudiumsveranstaltung verschiedene Techniken vorgestellt. Wir verwenden hier nur einfache Verkettung, das
heisst wir speichern alle kollidierten Einträge mit einer doppelt verketteten Liste.
Eine einfache Übertragung dieses Konzepts als Peer-to-Peer-Netzwerk ist in Abbildung 3.3 dargestellt.
Man identifiziert die Peers mit den Speicherplätzen der Hash-Tabelle. Die Peers sind verbunden durch eine
Kette. Für eine Suche würde man zuerst die Hashfunktion f (x) des Elements x berechnen und dann je
nach der eigenen Nummer die Anfrage in die Richtung leiten.
Zwar sind jetzt die Index-Dateien des Peer-to-Peer-Netzwerk leicht aufzufinden, jedoch erkennt man
sofort eine Reihe von Nachteilen in dieser Umsetzung.
• Die Suchzeit steigt mit der Anzahl der teilnehmenden Peers linear an.
• Die Zeit, um neue Peers (auf der rechten Seite) einzufügen ist ebenfalls lienar. Genauso lange braucht
es auch, um alleine die Nummerieruung der Peers zu verändern, wenn ein Peer das Netzwerk verläßt.
• Gravierender wiegt aber, dass wenn ein Peer das Netzwerk betritt, die Hash-Funktion angepasst
werden muss und dass dann (bei unglücklicher Wahl dieser neuen Funktion) fast alle gespeicherten
Einträge neu zugeordnet werden müssen. Genauso verhält es sich, wenn ein Peer das Netzwerk
verlässt.
Diesen letzten Punkt lösen Distributed Hash-Tables (verteilte Hash-Tabellen). Diese Technik wurde
ursprünglich zur Auflösung von sogenannten Hot-Spots2 im Internet eingeführt zur verteilten Speicherung
von HTML-Seiten oder Bilddateiten [KLL+ 97]. Hierzu werden nicht jedem Peer eine einzige Zahl zugeordnet, sondern ein zusammenhängender Bereich des Hash-Funktionsbildbereichs. Dieser Bildbereich
muss nicht mehr klein gehalten werden, da die Angabe der Bereichsgrenzen genügt. Man sorgt dafür, dass
nur wenige Bereiche aneinander stoßen. Die Daten werden gemäß der Schlüssel ebenfalls auf diesen HashFunktionsbildbereich abgebildet und gemäß der den Peers zugeordneten Bereich auf diese abgebildet, siehe
Abbildung 3.4.
Kommt nun ein neuer Peer hinzu, wird der Bereich zweier benachbarter Peers neu aufgeteilt. Der neue
Peer, siehe Abbildung 3.5 (schwarzer Kreis), erhält einen Teilbereich der vormals benachbarten Peers (roter
und weißer Kreis). Dadurch müssen nur die Daten-Elemente weniger Peers neu umgelagert werden.
Genauso verhält es sich, wenn ein Peer das Netzwerk verlässt, siehe Abbildung 3.6. Der Peer (grüner
Kreis), der das Netzwerk verlässt, übergibt seine Bereiche den direkten Nachbarn. Wiederum sind nur
wenige Peers und Datenelemente betroffen. Diese Operation hat nur lokale Auswirkungen.
Damit lässt sich also das Problem des Einfügen und Entfernen von Knoten lösen.Tatsächlich beruhen
fast alle modernen Peer-to-Peer-Netzwerke auf diesen verteilten Hash-Tabellen (außer Skipnet [HJS+ 03],
die in dieser Vorlesung nicht behandelt werden). Es bleibt aber noch offen, welches Netzwerk diese Peers
verbinden sollen, um die Datensuche zu optimieren.
2 Unter Hot Spots versteht man Überlastungen von Web-Server durch eine Anhäufung von Seitenanfragen. Hierfür hat sich mittler-
weile eine ganze Industrie von Dienstleistern entwickelt, die verteilte Web-Services anbieten, wobei die Web-Seiten oder Seiteninhalte
auf verschiedene über das Internet verstreute Ersatzserver verteilt wird.
17
Abbildung 3.4: Bei der verteilten Hash-Tabelle wird jedem Peer (farbiger Kreis) ein Bereich zu geordnet.
Alle Daten (Rechtecke) die auf diesen Bereich abgebildet werden, werden entsprechen den Peers zugeordnet.
Abbildung 3.5: Nach dem Einfügen eines Peers sind nur die Zuordnungen der benachhbarten betroffen
3.3
CAN — Content Addressable Network
Das Peer-to-Peer-Netzwerk CAN von Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp und
Scott Shenker [RFH+ 01] baut auf diesem Konzept der Hash-Tabellen auf und verwendet wie wir gleich
sehen werden sowohl ein geometrisches gitterbasiertes Konzept als auch Zufallsbäume (Random Trees).
3.3.1
Aufbau
Der Bildbereich der Hash-Funktion bildet auf den kontinuierlichen zwei-dimensionalen Raum [0, 1]2 ab. Ist
anfangs nur ein Peer im Netzwerk, so erhält dieser den gesamten Bildbreich. Kommt nun ein neuer hinzu
wird der Bildbreich quer zur x-Achse geteilt und die Einträge entsprechend aufgeteilt. Jeder Besitzer eines
Berechs speichert also alle Einträge in seiner Zone. Kommt nun wieder ein Peer hinzu, so wählt der Peer
einen zufälligen Punkt im Quadrat aus. Dann wird der zuständige Peer kontaktiert und die Zone aufgeteilt
(in x oder y-Richtung, in der umgekehrten Richtung in welcher der Besitzer der Zone zuvor geteilt hat). In
Abbildung 3.7 ist eine solche Folge dargestellt.
3.3.2
Die Balancierung der Zonen nach dem Aufbau
Sei nun R(p) das Rechteck eines Peers p und A(p) die Fläche dieses Rechtecks des Peers p. Ferner bezeichnen wir mit n die Anzahl der Peers. Dann läßt sich für diese Parameter nach dem Einfügen von n
Peers von der Startsituation eines Peers folgendes nachweisen.
Lemma 1
1. Für alle Peers p gilt E[A(p)] =
1
n.
Abbildung 3.6: Das Löschen eines Peers in der DHT betrifft nur die Bereiche der direkten Nachbarn
18
Abbildung 3.7: Der Aufbau der Zonen in CAN
19
2. Sei PR,n die Wahrscheinlichkeit, dass keines der n Peers in das Rechteck R mit Fläche V (R) fällt.
Dann gilt
PR,n ≤ e−nV (R) .
Beweis:
1. Wir nehmen an, dass die Peers in irgendeiner unbestimmten Reihenfolge eintreffen. Dennach gilt
wegen Symmetrie für zwei beliebige Peers i, j: E[A(i)] = E[A(j)].
Ferner gilt für die Summe der Flächen
n
X
A(i) = 1 .
i=1
Daraus folgt
1=
n
X
i=1
"
A(i) = E
n
X
#
A(i) =
i=1
n
X
E[A(i)] = nE[A(1)] .
i=1
Diese Gleichung gilt, da der Erwartungswert einer Summe von zwei Zufallsvariablen der Summe
der Erwartungswerte der Zufallsvariablen entsprich. Daraus folgt die Behauptung.
2. Für den Beweis der zweiten Aussage betrachten wir ein Rechteck R mit Fläche x = V (R). Die
Wahrscheinlichkeit, dass ein bestimmter Peer nicht in dieses Fläche hineinabgebildet wird, ist
1−x.
Das geschieht unabhängig von dem Verhalten anderern Peers. Somit ist die Wahrscheinlichkeit, dass
n Peers nicht R hineinfallen, ist daher
(1 − x)n .
Nun gilt für alle m > 0:
1
1−
m
m
≤
1
.
e
Daraus folgt für diese Wahrscheinlichkeit
nx
1
≤ e−nx
(1 − x)n = (1 − x) x
und damit das Lemma.
Die erste Aussage hat nur geringe Bedeutung, da aufgrund der Symmetrieannahme auch eine beliebig
schlechte Gewichtung diese durchschnittlen Flächengröße ergeben hätte.
Die zweite Aussage ist schon wesentlich aussagekräftiger. So ist es zum Beispiel extrem unwahrscheinlich, dass eine Fläche der Größe 21 das Eintreten von n Peers ungeteilt überlebt, nämlich e−n/2 .
Aus diesem Lemma kann man die Größe eines noch ungeteilten Rechtecks aber noch genauer abschätzen.
Theorem 1 Keine Zone eines Peers der Größe 2c lnnn bleibt nach Einfügen von n Peers mit hoher Wahrscheinlickeit ungeteilt, d.h. mit Wahrscheinlichkeit nk für eine Konstante k > 0.
Beweis: Aus dem obigen Lemma folgt für ein Rechteck Ri der Größe 2−i und c2i ln n Peers eine Wahrscheinlichkeit von
i
PRi ,c2i ln n ≤ e−c2 ln nV (Ri ) = e−c ln n = n−c ,
Es genügen also c2i ln n Peers um Ri mit Wahrscheinlichkeit 1 − n−c zu teilen. Diese kommen jetzt
hintereinander und so können nun nach log 2c nln n solchen Staffeln von Peer mit dieser Wahrscheinlichkeit
auch ein Rechteck der Größe 2c lnnn geteilt werden, da
ln
n
2c ln n
X
i=1
ln
i
c2 ln n = c(ln n)
n
2c ln n
X
i=1
20
n
2i ≤ c(ln n)2 2c ln n = n .
Abbildung 3.8: Iterierte Join-Operationen als Random Tree
Damit wird dieses Rechteck mit Wahrscheinlichkeit n−c log n nicht geteilt. Von diesen Rechtecken gibt es
höchstens n viele, damit ist die Wahrscheinlichkeit, dass eines dieser ungeteilt bleibt n·n−c log n ≤ n−c+2 .
Wählt man also c groß genug, so wird jede gewünschte polynomiell kleine Fehlerwahrscheinlichkeit unterschritten.
Nun ist die erwartete Anzahl gespeicherten Daten proportional zur Fläche der Peerzonen. Im Durchschnitt ist diese Fläche n1 , und mit hoher Wahrscheinlichkeit ist dies höchstens 2c lnnn . Somit speichert jeder
Peer höchstens 2c(ln n) mal mehr Daten als der Durchnittspeer.
3.Vorlesung
07.05.2004
3.3.3
Die Join-Operation
Die iterative Anwendung von Join-Operationen entspricht von der Aufteilung genau dem Aufbau eines
randomisierten Binärbaums, für den an jedem Knoten zufällig entschieden wird, wo das Blatt eingefügt
wird (Eine entsprechende Analyse in solchen Bäumen war schon Bestandteil einer Übungsaufgabe). In
Abbildung 3.8 ist dieser Zusammenhang bildlich dargestellt. Von randomisierten Zufallsbäumen weiss
man, dass die erwartete Tiefe 2 log n + O(1) ist und dass hoher Wahrscheinlichkeit, d.h. 1 − n−O(1) , die
Tiefe O(1) nicht überschritten wird.
3.3.4
Entfernen eines Peers
Gemäß der CAN-Datenstruktur ist es erlaubt, dass ein Peer für mehr als ein Rechteck notwendig ist. Dieser
Umstand ergibt sich aus dem Fall, wenn Knoten das Netzwerk verlassen. Geschieht dies, so kann man
nicht davon ausgehen, dass diese ihre Nachbarn rechtzeitig davon unterrichten. Daher fragen die Peers
regelmäßig ihre Nachbarn ab, ob sie noch leben. Meldet sich einer nicht zurück, so übernimmt der erste
der dies merkt (nach Ablauf eines Wartezeitraums) das Gebiet des abwesenden Peers, siehe Abbildung 3.9.
Man kann sich vorstellen, dass sich das fortlaufende Einfügen und Löschen eines Knotens zu einer
immer weitergehenden Fragmentierung des Netzwerks führen wird.
Das Entfernen eines Peers kann nun mittels dieser Darstelluns als Binärbaum leicht interpretiert werden. Der Peer muss dann einen geeigneten Nachbarn finden, der sein Gebiet übernehmen kann. Dazu ist
eine Umbalancierung notwendig, die wir nun skizzieren werden.
3.3.5
Defragmentierung
Auf Dauer ist es nicht hinnehmbar, dass ein Peer ein Konglomerat aus benachbarten Flächen verwaltet
(wobei wir gleich sehen können, dass wenn diese Flächen nicht benachbart sind, widerum Vorteile daraus
erwachsen). Daher wird von Zeit zu Zeit eine Defragmentierung im CAN-Baum vorgenommen.
21
Peer
A
Peer
B
Peer
E
Peer
C
Peer
D
Abbildung 3.9: Verläßt ein Knoten das CAN-Netzwerk, übernimmt sein Nachbar das Gebiet
Dieser Prozess kann von jedem Peer angestoßen werden, der mehr als ein Gebiet zu verwalten hat.
Hierbei geschieht folgendes. Der Peer wählt die kleinste Zone A und betrachtet gemäß der oben beschriebenen Binärbaumbeschreibung den Bruderbaum. Besteht dieser nur aus einem Blatt, was einer ungeteilten
Zone entspricht, so kann er in diesem einfachen Fall dem Nachbarn sein Gebiet übergeben. Damit vergößert sich das Gebiet des Nachbarn um das Doppelte ohne das eine weitere Fragmentierung stattfindet, siehe
Abbildung 3.10
4. und
Vorlesung
17.05.2004
21.05.2004
Ist aber die Nachbarzone weiter unterteilt, so muss erst ein geeigneter Kandidat zur übernahme dieser
Zone A gefunden werden. Hierfür wird im Bruderbaum eine Tiefensuche durchgeführt nach zwei benachbarten Blättern. Sind diese gefunden, wird einem das Gebiet seines Nachbarn übertragen. Dem nun
5. freigeworden Blatt (Peer) wird die Zone A übertragen.
3.3.6
Ungleichungen der Wahrscheinlichkeitstheorie
Der Erwartungswert E[X] einer Zufallsvariable gibt ein Indiz, wie der Wert einer Durchschnittsvariable
bei häufiger Wiederholung im Mittel sein wird. Er ist für diskrete Zufallsvariablen definiert durch
E[X] =
X
P[X = x]x .
x∈R
Aus dieser Definition lässt sich schon eine grobe Abschätzung für die Wahrscheinlichkeit ableiten, wie
stark man von dieser Schranke abweicht. Betrachtet man alle Summenterme, für die das Ereignis mindes22
Peer
B
Peer
B
Tiefensuche
Peer
E
Peer
C
Peer
D
Peer
E
Peer
C
Abbildung 3.10: Der einfache Fall der Defragmentierung in CAN
Peer
D
Abbildung 3.11: Der schwierige Fall der Defragmentierung in CAN
23
tens kE[X] ist, so bezeichnet P[X > kE[X]] die Wahrscheinlichkeit dafür. Nun ist
E[X]
=
X
P[X = x]x
x∈R
≥
X
P[X = x]x
x≥kE[X]
≥
X
P[X = x] · k · E[X]
x≥kE[X]
= k · E[X] ·
X
P[X = x]
x≥k·E[X]
= k · E[X] · P[x ≥ k · E[X]] .
Hieraus folgt nun die Markoff-Ungleichung, indem man für positiven Erwartungswert beide Seiten durch
den E[X] teilt.
Theorem 2 Markoff-Ungleichung Für eine Zufallsvariable X mit E[X] > 0 gilt
P[x ≥ k · E[X]] <
1
.
k
Eine bessere Abschätzung ergibt sich durch Chebyshevs Ungleichung welche besagt, dass
P[|X − E[X]| ≥ k] ≤
V [X]
,
k2
wobei V [X] := E[(X − E[X])2 ] die Varianz von X bezeichnet.
Besteht aber die Zufallsvariable aus einer Reihe von unabhängigen 0/1 Experimenten, genannt BernuolliExperimente, so ergibt sich mit der nun folgenden Chernoff-Schranke ein wesentlich mächtigeres Hilfsmittel zur Beschränkung der Abweichung.
Theorem 3 Chernoff-Schranke
Seien P
x1 , . . . , xn unabhängige Bernoulli-Experimente mit P[xi = 1] = p und P[xi = 0] = 1 − p. Sei
n
Sn = i=1 xi .
1. Dann gilt für jedes c > 0
P[Sn ≥ (1 + c)E[Sn ]] ≤ e−
min{c,c2 }
pn
3
.
2. Für c ∈ [0, 1] :
P[Sn ≤ (1 − c)E[Sn ]] ≤ e−
c2
2
pn
.
Beweis:
1. Es gilt für jedes t > 0:
P[Sn ≥ (1 + c)pn] = P[etSn ≥ et(1+c)pn ] .
Die Markov-Ungleichung liefert nun
1
P etSn ≥ kE etSn ≤
.
k
24
E[etSn ]
h Pn
i
= E et i=1 xi
" n
#
Y
txi
= E
e
i=1
=
=
n
Y
i=1
n
Y
E etxi
(e0 (1 − p) + et p)
i=1
= (1 − p + et p)n
= (1 + (et − 1)p)n
Hierbei haben wir die Voraussetzung benutzt, dass die Zufallsvariablen xi unabhängig sind (und
damit auch die Zufallsvariablen etxi ). Für die erste Schranke wählen wir nun k = et(1+c)pn /E[et·Sn ]
und t = ln(1 + c) > 0.
Damit ist nun
P[Sn ≥ (1 + c)pn] ≤ e−t(1+c)pn · (1 + p(et − 1))n
−t(1+c)pn
≤ e
pn(et −1)
·e
(3.1)
(3.2)
−t(1+c)pn+pn(et −1)
= e
= e−(1+c) ln(1+c)pn+cpn
= e(c−(1+c) ln(1+c))pn
(3.3)
Dabei folgt (3.1) durch Einsetzen von k. Dann folgt (3.2) weil für alle a gilt (1 + a) ≤ ea und damit
insbesondere für a = p(et − 1).
Nun ist
1
d ln(1 + x)
=
= 1 − x + x2 − x3 + x4 − . . .
dx
1+x
und daraus folgt, dass
1
1
1
ln(1 + x) = x − x2 + x3 − x4 + . . .
2
3
4
Damit ist
(1 + c) ln(1 + c)
1 1 3
1 1 4
1 1 5
1 2
= c+ 1−
c −
−
c +
−
c −
−
c + ...
2
2 3
3 4
4 5
1
1
1
1
= c + c2 − c3 − c4 + c5 − . . .
2
6
12
20
Daraus folgt die Ungleichung (1 + c) ln(1 + c) ≥ c + 12 c2 − 61 c3 ≥ c + 13 c2 für c ∈ [0, 1]. Das setzen
wir in die Ungleichung (3.3) ein und erhalten
P[Sn ≥ (1 + c)pn] ≤ e(c−(1+c) ln(1+c))pn
2. Nun sei t < 0. Dann gilt
P[Sn ≤ (1 − c)pn] = P[etSn ≥ et(1−c)pn ] .
Die Markov-Ungleichung kann nun ebenfalls angewendet werden
1
P etSn ≥ kE etSn ≤
.
k
25
1
2
≤ e− 3 pnc
Analog wie im ersten Fall erhalten wir
E[etSn ] = (1 + (et − 1)p)n
Wir wählen nun k = et(1−c)pn /E[et·Sn ] und t = ln(1 − c) < 0.
Damit ist nun
P[Sn ≤ (1 − c)pn] ≤ e−t(1−c)pn · (1 + p(et − 1))n
−t(1−c)pn
≤ e
pn(et −1)
·e
(3.4)
(3.5)
−t(1−c)pn+pn(et −1)
= e
= e−(1−c) ln(1−c)pn−cpn
= e−c−(1−c) ln(1−c))pn
(3.6)
(3.7)
Dabei folgt (3.4) durch Einsetzen von k, (3.6) durch Einsetzen von t. Dann folgt (3.5) weil für alle
a ∈ R 1 + a ≤ ea gilt (und insbesondere für a = p(et − 1)).
Nun zeigen wir noch für c ∈ (0, 1), dass
1
−c − (1 − c) ln(1 − c) ≤ − c2 .
2
Für c = 0 erhält man sowohl auf der linken als auch auf der rechten Seite 0. Die Ableitung nach c
der linken Seite ist ln(1 − c), die der rechten Seite ist −c. Nun ist für c ≤ 1:
1
1
ln(1 − c) = −c − c2 − c3 − . . . < −c .
2
3
Daraus folgt, dass wie gewünscht −c − (1 − c) ln(1 − c) ≤ − 21 c2 und das impliziert nun
1 2
P[Sn ≤ (1 − c)pn] ≤ e− 2 c
pn
.
3.3.7
Realitäten
Hier fehlt noch was . . .
3.4
CHORD: Konsistentes Hashing für P2P-Netzwerke
Dieses System benutzt eine Zeigerstruktur aus O(log n) Zeigern für jeden Knoten. Es wurde in [SMK+ 01]
von Stoica, Karger, Kaashoek und Balakrishnan im Jahr 2001 vorgestellt und benutzt konsistentes Hashing.
3.4.1
Die Datenstruktur von Chord
Wir bezeichnen mit V die Knotenmenge, (d.h. n = |V |) und mit K die Schlüsselmenge (d.h. k = |K|).
Eine relativ unwesentliche Veränderung gegenüber dem oben vorgestellten konsistenten Hashing ist
dass wir nicht mehr auf das kontinuierliche Intervall [0, 1] sondern auf die Zahlen Z2m = {0, 1, 2, . . . , 2m −
1} abbilden. Die Zahl m muss groß genug gewählt werden, so dass eine Kollision mit vernachlässigbarer
Wahrscheinlichkeit geschieht (Eine Wahl m ≥ max{2 log n, 2 log k} ist hierfür ausreichend). Andererseits
sollte m auch nicht zu groß sein, damit sie im Darstellungsbereich der Zahlen der Rechner verbleibt.
Es werden wiederum zwei Hashfunktionen rV : V × Z2m und rK : K × Z2m verwendet.
• rV (b) bildet den Knoten b zufällig auf das Intervall {0, . . . , 2m − 1} ab.
• rK (i) bildet den Schlüssel i zufällig auf das selbe Intervall {0, . . . , 2m − 1} ab.
26
HEINZ NIXDORF INS TITUT
Chord als DHT
Universität Paderborn
Algorithmen und Komplexität
Christian Schindelhauer
rV( b) = b+1 mod 8
!n: Knotenanzahl, Knotenmenge V
5
!k: Anzahl Schlüssel, Schlüsselmenge
K
6
!m: Hashwertlänge: m >> log
max{K,N}
5
!Zwei Hash-Funktionen bilden auf
{0,..,2m-1} ab
– rV(b): bildet Peer b zufällig auf
{0,..,2m-1} ab
– rK(i): bildet Index i zufällig auf
{0,..,2m-1} ab
!Abbildung von i auf einen Peer b = fv(i)
–
7
3
rK( i) = 3i-2 mod 8
2
4
2
3
0
6
Index
2
1
0
fV(i) := arg minb!V (rB(b)-rK(i)) mod 2m
Abbildung 3.12: Konsistentes Hashing in der Chord-Datenstruktur
Algorithmen für Peer-to-PeerNetzw erke
19
Die Zuordnung der Schlüssel auf die Knoten wird nun durch die Funktion fV : K → V beschrieben.
fV (i) := arg min(rV (b) − rK (i)) mod 2m .
b∈V
In Abbildung 3.12 wird diese Abbildung beschrieben. Als Hilfsfunktionen definieren wir nun p : Z2m →
V als den Knoten der dem Hashwert vorangeht (p wie predecessor):
p(x) := min{b ∈ V | rV (b) < z} .
Für die andere Richtung definieren wir s : Z2m → V als den Knoten der dem Hashwert nachfolgt (s wie
successor):
s(x) := min{b ∈ V | rV (b) > z} .
Wir setzen im Folgenden immer voraus, dass weder bei den Schlüsseln noch bei den Knoten jemals eine
Kollision auftritt.
Nun werden für jeden Knoten folgende Zeiger auf andere Knoten angelegt (Abbildung 3.13).
• Successor: b.succ := s(rV (b))
Der Nachfolgerzeiger zeigt auf den im Bildintervall folgenden Knoten. Mit diesen Zeiger kann jeder
Knoten auf dem Ring erreicht werden, wenn auch im worst-case und im Durchschnitt linearer Zeit.
• Predecessor: b.pred := p(rV (b))
Der Vorgängerzeiger entspricht der umgekehrten Version des Nachfolgerzeigers. Zusammen mit diesen erhalten wir so einen doppelt verketteten Ring als Grunddatenstruktur.
• Finger: b.finger[i] := s(rV (b) + 2i − 1) für i ∈ {0, . . . , m − 1}
Diese m Finger implementieren die effiziente Datenstruktur. Hiermit kann man sich sehr effizient
durch den Ring bewegen, wie wir gleich sehen werden. Jeder dieser Finger ist im Prinzip ein Nachfolgerzeiger, der in der Lage ist die Hälfte, ein Viertel oder ein Achtel, etc. der Knoten zu überspringen. Für kleine i werden nur wenig unterschiedliche Fingereinträge vorkommen. Daher werden wir
nur unterschiedliche Fingereinträge speichern, um den Speicheraufwand zu minimieren.
Um die Anzahl der Fingereinträge abzuschätzen, benötigen wir folgendes Lemma.
Lemma 2 Der Abstand (rV (b.succ) − rV (b)) mod 2m ist
27
successor
predecessor
finger[m-3]
finger[m-2]
finger[m-1]
Abbildung 3.13: Die Zeigerstruktur von Chord.
1. im Erwartungswert 2m /n.
2. mit polynomieller Wahrscheinlichkeit höchstens O( 2
m
log n
)
n
m
3. und mit polynomieller Wahrscheinlichkeit mindestens O( 2nc ).
m
4. In einem Intervall der Länge w 2n sind mit polynomieller Wahrscheinlichkeit
(a) höchstens O(w) Knoten, falls w = Ω(log n);
(b) höchstens O(w log n) Knoten, falls w = O(log n).
Beweis: Die Aussage über den Erwartungswert folgt daraus, dass die Summe aller n Intervalllängen 2m
ergibt.
Die Aussage über die Mindestlänge des Intervalls ergibt sich daraus, dass die Wahrscheinlichkeit, dass
ein Knoten in ein solch kleines Intervall fällt, höchstens n−c ist. Damit hat jeder Knoten, der neu hinzukommt nur mit Wahrscheinlichkeit 2nc−1 die Möglichkeit so dicht neben einen vorhandenen Knoten zu
liegen zu kommen. Da dass höchstens n mal passiert, ist die Gesamtwahrscheinlichkeit beschränkt durch
2n−c+2 .
Die anderen Aussagen leiten sich durch Anwenden der Chernoff-Schranke an (Der Beweis dieser Aussage eignet sich hervorragend, um den Umgang mit Chernoff-Schranken einzuüben).
Aus diesem Lemma ergibt sich nun.
Lemma 3 Die Anzahl der verschiedenen Fingerzeiger eines Knotens ist mit polynomieller Wahrscheinlichkeit O(log n)
Diese Aussage folgt aus der unteren Schranke der Mindestlänge eines Intervalls. Damit ist mit hoher Wahrscheinlichkeit die Chord-Datenstruktur eine sehr kompakte Datenstruktur. Auch der Ingrad eines
Knotens ist polylogarithmisch beschränkt.
Lemma 4 Die Anzahl der Knoten, die einen Fingerzeiger auf einen Knoten b besitzen, ist
• im Erwartungswert höchstens O(log n)
28
Chord-Suche(b,i)
begin
x ← rK (i)
while x 6∈ [rV (b), rV (b.succ)) do
for i ← m − 1 downto 0 do
if x ∈ [rV (b.finger[i]), rV (b.finger[i + 1])) then
b ← b.finger[i]
fi
od
return(b)
end.
Abbildung 3.14: Der Suchalgorithmus für die Chord-Datenstruktur
• und mit polynomieller Wahrscheinlichkeit beschränkt durch O(log2 n).
Beweis: Die Aussage über den Erwartungswert ergibt sich daraus, dass die Anzahl der eingehenden Kanten gleich der Anzahl der ausgehenden Kanten ist. Damit ist für einen zufälligen Knoten b der erwartete
Eingrad gleich dem erwarteten Ausgrad.
Wir gehen also davon aus, dass mit polynomieller Wahrscheinlichkeit, der Abstand zweier benachbarter
Knoten auf dem Ring beschränkt ist durch c2m n−1 log n. Wir betrachten jetzt einen der maximal O(log n)
Werte für i, für die Fingerzeiger vom Nachfolger verschieden sind.
Alle Bilder von Knoten, die auf b zeigen müssen im Intervall [rV (b.pred) − 2i + 1, rV (b) − 2i + 1]
liegen. Auch dieses Intervall hat die Maximallänge c2m n−1 log n. Damit ist die erwartete Anzahl von
Knoten in diesem Intervall c log n. Durch Anwenden der Chernoff-Schranke erhalten wir für δ > 1 also
2
2
Anzahl der Knoten b0 mit b0 .pred = b ist
P
≤ e−δ c log n/3 ≤ n−cδ /3 .
größer als (1 + δ)c log n
Diese logarithmische Anzahl von Fingerzeigen im Abstand 2i müssen wir noch mit der logarithmischen
Anzahl von Zeigerebenen multiplizieren.
3.4.2
Suche in Chord
Die Suche nach einem Schlüssel erfolgt mit dem Suchalgorithmus, der in Abbildung 3.14 dargestellt wird.
Die Effizienz eines solchen Algorithmus wird in der Anzahl von Nachrichten gemessen. Als Eingabe erhält
der Algorithmus irgendeinen Knoten des Rings und den Schlüssel. Als Ausgabe erhält man den Knoten,
der für die Verwaltung des Schlüssels verantwortlich ist.
Zwei Iterationen dieses Suchalgorithmus sind in Abbildung 3.15 dargestellt. Dieser Algorithmus arbeitet tatsächlich sehr effizient:
Theorem 4 Die Schlüsselsuche in Chord kann mit O(log n) Anfrage mit polynomieller Wahrscheinlichkeiit erfolgen, d.h. O(log n) Nachrichten genügen für das Einfügen und Löschen von Schlüsseln.
Beweis: Die Anzahl der Nachrichten, um einen Durchlauf der For-Schleife durchzuführen ist konstant.
In jedem Durchlauf dieser For-Schleife verkleinert sich das nächste Suchintervall um die Hälfte, da der
Mindestabstand zweiter Knoten auf dem Ring polynomiell ist (mit polynomieller Wahrscheinlichkeit) folgt
hieraus das Theorem.
3.4.3
Aufnehmen von Peers
Der Aufwand um Knoten aufzunehmen und zu Entfernen ist geringfügig höher. Schließlich kann der Eingrad in bis zu O(log2 n) betragen und diese Zeiger müssen aktualisiert werden.
29
Abbildung 3.15: Schlüsselsuche im Chord P2P-Netzwerk
Theorem 5 Es genügen O(log2 n) Nachrichten mit polynomieller Wahrscheinlichkeit, um einen Knoten in
die Chord-Datenstruktur aufzunehmen oder aus ihr zu entfernen.
Beweis: Wir geben hier eine Beweisskizze für den Fall an, dass ein Knoten aufgenommen wird. Entsprechende Überlegungen gelten für den Fall, dass ein Knoten entfert wird.
Der Aufwand, um die Stelle zu finden, in der ein Knoten eingefügt werden soll, ist wie oben beschrieben
O(log n). Um ihn in den doppelt verketteten Ring einzufügen müssen nur konstant viele Zeiger umgehängt
werden.
Wir werden jetzt zeigen, dass für jeden Level i die O(log n) Nachrichten für das Anpassen der Zeigerstruktur genügen. Wir wissen bereits, dass in so einem Level nur O(log n) Knoten betroffen sind. Diese
sind im Ring zusammenhängend. Um den ersten zu finden sind wieder O(log n) Interaktionen notwendig.
Danach kann man die Ringnachfolgerzeiger verwenden um in O(log n) nachfolgenden Schritten jeden dieser Knoten zu besuchen. Der Aufwand, um den entsprechenden Fingerzeiger anzupassen ist entsprechend
konstant. Hieraus folgt die gewünschte Schranke für die Anzahl der Nachrichten
3.5
Koorde
6. Vorlesung
28.05.2004
Das Peer-to-Peer-Netzwerk von Karger und Kaashoek [KK03] verbessert den Ansatz von Chord hinsichtlich des Grads der Knoten und der Zeitdauer für die Einfüge-Operationen. Wir haben bei Chord einen
Grad von O(log n) (mit hoher Wahrscheinlichkeit) beobacht. Dabei hat CHORD einen Durchmesser von
O(log n). Einen wesentlich kleineren Grad kann bei diesem Grad nicht erwarten. Denn bei Grad g kann
man in d Schritten höchstens g d Knoten erreichen.
Akzeptiert man als sinnvollen Ausgrad für ein Peer-to-Peer-Netzwerk den Grad g = log n dann kann
man bestenfalls nach d Schritten für (log n)d = n einen beliebigen anderen Peer erreichen. Löst man
diese Gleichung nach d auf, erhält man d = logloglogn n . Das ist zwar asymptotisch kleiner als log n, jedoch
nur um den Term log log n, der für alle sinnvollen Netzwerkgrößen höchstens 6 wird (Tatsächlich gibt es
Netzwerke mit solch guten Eigenschaften. Diese Eigenschaft wird insbesondere vom log n-dimensionalen
Hyperwürfel erfüllt).
Da nun hinsichtlich der Weglänge in Peer-to-Peer-Netzwerke sehr wenig Spielraum zur Verbesserung
vorhanden sind, untersuchen wir jetzt die Frage, ob bei logarithmischen Durchmesser sich der Grad reduzieren kann. Dann wenn man den Ausgrad des Graphen auf zum Beispiel 4 reduziert, dann ist nach obiger
Überlegung immer noch ein Durchmesser von O(log n) möglich. Tatsächlich erreicht dies Koorde [KK03]
durch eine sehr elegante Kombination durch einen Ring-Graph und einen DeBrujin-Graphen, die wir hier
vorstellen werden.
3.5.1
Der DeBrujin-Graph
Doch wollen wir zuerst den DeBrujin-Graph vorstellen. Wir definieren hierfür einige einfache PermutationsFunktionen auf Binär-Zeichenketten der Länge m.
30
0 1 1 1 0 1 1
0 1 1 1 0 1 1
1 1 1 0 1 1 1
1 1 1 0 1 1 0
1 1 0 1 1 1 0
Abbildung 3.16: Die Shuffle-Operation.
1 0 1 1 1 0 0
0 1 1 1 0 1 1
0 1 1 1 0 0 1
0 1 1 1 0 1 0
1 1 1 0 0 1 1
Abbildung 3.17: Die Exchange-Operation.
0 1 1 1 0 1 1
1 1 0 0 1 1 1
1 1 1 0 1 1 1
1 0 0 1 1 1 1
Abbildung 3.18: Die Shuffle-Exchange-Operation.
Abbildung 3.19: Jeder String lässt sich durch m
Shuffle- oder Shuffle-Exchange-Operationen in jeden beliebigen anderen überführen.
• Die Shuffle-Operation rotiert die m Bits nach links. Für Bits s1 , . . . , sm ∈ {0, 1} ist sie definiert
durch
shuffle(s1 , s2 , . . . , sm ) := (s2 , s3 , . . . , sm , s1 ) .
Siehe auch Abbildung 3.16.
• Bei der Exchange-Operation wird das niedrigst-wertige Bit invertiert, d.h. für Bits s1 , . . . , sm ∈
{0, 1}:
exchange(s1 , s2 , . . . , sm ) := (s1 , s2 , . . . , ¬sm ) .
Siehe auch Abbildung 3.17.
• Bei der Shuffle-Exchange-Operation (auch SE-Operation) wird zuerst ein Shuffle und daraufhin
eine Exchange-Operation auf dem Bitstring (Binärzeichenkette) ausgeführt:
SE(S) := exchange(shuffle(S) .
In der Bit-Darstellung ergibt sich
SE(s1 , . . . , sm ) = (s2 , s3 , . . . , sm , ¬s1 ) .
Siehe auch Abbildung 3.18
Wir halten folgnde Beobachtung fest.
Fakt 1 Jeder String A aus m Bits lässt sich in jeden beliebigen String B durch m-faches Anwenden von
Shuffle- und Shuffle-Exchange-Operationen umwandeln.
31
000
001
000
111
100
001
010
110
101
011
010
110
101
011
111
100
Abbildung 3.20: Der DeBrujinGraph für 8 Knoten.
Abbildung 3.21: Der selbe DeBrujin-Graph. Die Knoten sind sortiert
auf dem Ring aufgetragen.
In Abbildung3.19 ist dies am Beispiel von A = (0111011) und B = (1001111) dargestellt. Man sieht an
diesem Beispiel, dass jedes der m Bits sukzessive auf den korrekten Wert gesetzt werden. Die notwendige
Folge der Operationen erhält man dann indem man A und B bitweise durch XOr kombiniert. Das Bit 1
zeigt dann an, dass eine Shuffle-Exchange-Operation anzuwenden ist, und Bit 0 steht dann für eine ShuffleOperation.
Der DeBrujin-Graph kann jetzt mit Hilfe von Shuffle- und Exchange-Operationen wie folgt dargestellt
werden. Der DeBrujin-Graph hat n = 2m Knoten. Jeder dieser Knoten stellt eine m-stellige Binärzahl
dar. Jeder Knoten hat nun zwei ausgehende Kanten, wobei die erste Kante von u auf shuffle(u) und die
zweite Kante von u auf SE(u) zeigt. Als Beispiel ist in Abbildung3.20 ein DeBrujin-Graph aus 8 Knoten
dargestellt.
Lemma 5 Der DeBrujin-Graph hat Eingrad und Ausgrad von jeweils 2 und Durchmesser log n
Beweis: Die Eingrad-Bedingung folgt aus der Definition. Die Ausgrad-Bedingung folgt aus der Eigenschaft, dass sowohl Shuffle als auch Shuffle-Exchange Permutationen über den Binärzahlen sind.
Dass der Durchmesser durch log n beschränkt ist, folgt aus Fakt3.16. Dieser Durchmesser wird auch
nicht unterschritten, wie man am Beispiel der Knoten 0, . . . , 0 und 1, . . . , 1 leicht einsieht.
3.5.2
Die Topologie von Koorde
Wie bereits erwähnt kombiniert man jetzt diesen DeBrujin-Graph mit einer Ring-Topologie und erhält
(schon fast) die Koorde-Datenstruktur, dargestellt in Abbildung 3.21. Nun besitzt jeder Peer noch zusätzlich zwei Zeiger, jeweils auf den Vorgänger und Nachfolger, wobei hier die Bitstrings als Binärzahlen
interpretiert werden. Aus dieser Abbildung ist nicht sofort die Struktur ersichtlich. Es entsteht vielmehr der
Eindruck, dass die Struktur-Information des DeBrujin-Graphen hier nicht dargestellt wird. Dem ist aber
nicht so.
Daher betrachten wir noch einmal die Shuffle und Shuffle-Exchange-Operationen und interpretieren
die Zahlen nun als ganzen Zahlen über dem Ring {0, . . . , 20 m − 1}. Es gilt
shuffle(x)
SE(x)
=
=
(x div 2m−1 ) + (2x) mod 2m ,
1 − (x div 2m−1 ) + (2x) mod 2m .
32
0
1
x
2y+1
2y
2x
2x+1
y
n/2
Abbildung 3.22: Die Verbindungsstruktur der DeBrujin-Kanten auf dem Ring.
Also zeigen die DeBrujin-Kanten von x auf 2x mod 2m und (2x + 1) mod 20 m, wie in Abbildung3.22
dargestellt. Damit wird die Bedeutung der Verbindung anschaulich beschrieben.
Man kann aber nicht voraussetzen, dass eine Zuordnung der Peers auf Bitstrings der Länge m so durchgeführt werden kann, dass weder ein Bitstring nicht verwendet wird noch ein Bitstring mehrfach verwendet
wird. Wählt man zufällige Bitstrings, so muss man m mindestens als
m > (1 + c)log(n)
für eine geeignete Konstante c wählen, um eine Kollision zu vermeiden. Dann ist nämlich die Wahrscheinlichkeit einer Kollision zweier Peers auf den selben Knoten höchstens n−c . Damit werden die meisten
Bitstrings überhaupt nicht angenommen, d.h. die entsprechenden DeBrujin-Knoten werden nicht mit Peers
besetzt.
Um die Leerstellen aufzufüllen verwaltet jeder Peer alle DeBrujin-Knoten bis zu seinem Nachfolger
auf dem Ring. Dieses betrifft aber nur die eingehenden Kanten. Die fehlenden ausgehenden Kanten werden
vom Peer nicht übernommen.
3.5.3
Eigenschaften von Koorde
Der Ausgrad bleibt damit auf zwei beschränkt, wobei der Eingrad zunehmen könnte. Nun gilt folgendes
Theorem.
Theorem 6 Für die Verbindungsstruktur von Koorde gelten folgende Eigenschaften
1. Jeder Peer hat vier Zeiger.
2. Auf jedem Knoten zeigen mit hoher Wahrscheinlichkeit höchstens O(logn) Zeiger.
3. Der Durchmesser ist mit hoher Wahrscheinlichkeit O(logn).
4. Der Lookup in Koorde kann mit O(log n) Sprüngen/Nachrichten durchgeführt werden.
Beweis:
1. Die erste Eigenschaft folgt aus der Definition der Nachbarschaft.
33
virtuelle
DeBrujin-Knoten im
Verantwortungsbereich des Peers
00
10
20
21
02
O(log n) Peers
im Intervall der Länge
c (log n)/n 2m
11
01
12
22
Abbildung 3.24: Ein Grad-3-DeBrujin-Graph
Abbildung 3.23: Der Eingrad der Knoten in Koorde ist mit hoher Wahrscheinlichkeit O(log n)
2. Wie bei Chord kann man mit hoher Wahrscheinlichkeit zeigen, dass der Abstand zweier benachbarter
Peers mit hoher Wahrscheinlichkeit höchstens c(log n) größer ist als der durchschnittliche Abstand
2m /n. Die Strecke von der Peers auf diese virtuellen Knoten zeigen können, umfasst daher höchstens
2m c (logn)
Knoten des DeBrujin-Graphen, siehe Abbildung 3.23. Mit Hilfe der Chernoff-Schranke
2n
kann man nun zeigen, dass darin sich höchstens O(log n) Peers. Damit ist der Eingrad mit hoher
Wahrscheinlichkeit beschränkt durch O(log n).
3. Wir starten mit dem Pfad der Länge m und verwenden hier auch (nicht-existierende) Kanten zwischen virtuellen DeBrujin-Knoten. Die Länge dieses Pfades ist nun m = O(log n).
In einem zweiten Schritt ersetzen wir diese durch Ring-Kanten und die Kanten der verantwortlichen
Peers. Im Erwartungswert wird jeder dieser Sprünge dadurch nur konstant, d.h. um drei Schritte
pro kante, verlängert. Wodurch kann sich nun ein Pfad auf k + 3m Sprünge verlängern? Wenn
zwischen virtuellen Knoten und Peer insgesamt mindestens k Peers liegen. Die erwartete Anzahl ist
aber pro Sprung konstant und die Peers sind hinreichend unabhängig verteilt worden. Wir setzen nun
k = c log n ein und wende daraufhin die Chernoff-Schranke an.
4. Dieses Verfahren zur Bestimmung des Durchmessers war konstruktiv und kann von einem LookupAlgorithmus nachvollzogen werden. Damit folgt die Schranke von O(log n) Sprüngen für eine
Lookup-Operation.
Damit liegt uns mit Koorde eine einfache Netzwerkstruktur vor, die mit konstanten Ausgrad äußerst
effiziente Operationen zur Verfügungstellt. Schließlich folgt aus dem logarithmischen Aufwand zum Suchen einer Position (lookup), dass das Einfügen oder Löschen eines Peers ebenfalls in logarithmischer Zeit
vorgenommen werden kann.
Damit ist Koorde ebenso einfach wie Chord, nur effizienter. Negativ ist, dass im Gegensatz zu Chord
für Koorde noch keine Stabilisierungsstrategie bekannt ist. Der kleine Grad bringt außerdem nicht nur
Vorteile. So ist der Zusammenhang des Graphen entsprechend kleiner und damit nimmt die Gefahr zu,
dass bei Ausfällen von Peers das Netzwerk auseinander fällt.
34
Will man dieses Problem lösen, dann kann man den Grad des Graphen erhöhen, indem man sogenannte
Grad k-DeBrujin-Graphen betrachtet. Hierfür betrachten wir ein Alphabet aus k (statt zwei) Buchstaben,
z.B. für k = 3, m = 2 siehe Abbildung 3.24. Jeder k-DeBrujin-Knoten x hat nun die Nachfolger (kx
mod k m ), (kx + 1 mod k m ), (kx + 2 mod k m ), . . . , (kx + k − 1 mod k m ). Dadurch verkürzt sich der
Durchmesser auf (logm)/(logk), während sich der Graphzusammenhang auf k erhöht. Diese Konstruktion
stellt eine natürliche Verallgemeinerung von Koorde dar und die Ergebnisse lassen sich hier weitestgehend
übertragen.
7. Vorlesung
05.06.2004
Vertretung
3.6 Tapestry
Peter Mahlmann
Das Peer-to-Peer Netzwerk Tapestry [HKRZ02] wurde in seiner ursprünglichen Version von Ben Y. Zhao,
John D. Kubiatowicz und Anthony Joseph an der University of California, Berkeley, entwickelt. Als Besonderheit dieses Netzwerkes ist hervorzuheben, dass beim Aufbau des Netzwerkes Lokalität berücksichtigt
wird um die beim Routing entstehenden Latenzzeiten gering zu halten. Wir werden zunächst einige Grundlegende Begriffe kennen lernen und uns dann mit der Netzwerkstruktur, dem Routing, der Verwaltung von
Objekten und dem Einfügen neuer Peers beschäftigen.
3.6.1
Grundlegende Terminologie
Objekte bzw. Peers im Tapestry-Netzwerk werden durch eindeutige Objekt-IDs bzw. Peer-IDs identifiziert.
Peer-IDs können dabei zufällig vergeben oder durch Hashfunktionen bestimmt werden. Objekt-IDs werden
wie schon bei CAN und CHORD durch Hashfunktionen berechnet. Beliebt hierfür sind kryptographische
Hashfunktionen wie z.B. SHA-1. Der Vorteil einer kryptographischen Hashfunktion ist, dass böswillige
Anwender nicht ständig Objekte einfügen können, für die ein ausgewählter Peer zuständig ist – was zur
Überlastung des Peers führen würde. Denn um dieses zu erreichen, müsste der Anwender viele Objekte
erstellen, die alle in einem kleinen Intervall des Bildbereichs der Hashfunktion liegen. Eben dieses wird für
kryptographische Hashfunktionen jedoch als schwer angesehen.
Eine Besonderheit im Tapestry-Netzwerk ist, dass die IDs als Zahlen bzw. Zeichenketten zur Basis
b = 2k , k ∈ N interpretiert werden. Die Begründung hierfür liegt im Routing-Algorithmus des Netzwerks,
wie wir später sehen werden. Für eine Zeichenkette α über dem Alphabet b bezeichne von nun an |α| die
Länge dieser Zeichenkette.
3.6.2
Nachbarschaftsmengen
Ein beliebiger Peer mit ID A unterhält Links zu ausgewählten anderen Peers, die einen Prefix x seiner
Peer-ID mit ihm gemeinsam haben. Ein anderer Peer mit ID B = x ◦ δ kann also nur mit A benachbart
sein, falls x◦δ 0 = A, für beliebiges δ, δ 0 . Wir bezeichnen dabei l = |x|+1 als den Level der Nachbarschaft.
Abbildung 3.6.2 zeigt beispielhaft die Nachbarschaft des Peers mit ID 4227.
A
Die Nachbarn eines Peer werden in Nachbarschaftsmengen Nx,j
eingeteilt. Für jedes Prefix x und jeden
A
Buchstaben j ∈ [0, b − 1] des Alphabets enthält die Nachbarschaftsmenge Nx,j
Peers, deren IDs das Prefix
x ◦ j mit A teilen. Wir werden diese im Folgenden als (x, j) Nachbarn bezeichnen. Für jedes x und j wird
A
der gemäß einer festgelegten Metrik naheste Peer zu A in Nx,j
als primärer (x, j)-Nachbar bezeichnet,
alle Weiteren als sekundäre (x, j)-Nachbarn.
A
A
A
, . . . , Nx,b−1
die Level-l Routing Tabelle des
Wenn l = |x| + 1, dann bilden die Mengen Nx,0
, Nx,1
Peers A. Die Kardinalität der Nachbarschaftsmengen ist durch eine Konstante R begrenzt (sonst würde die
Level-1 Routing Tabelle eines Peers alle anderen Peers enthalten und wir hätten es mit einem vollständigen
Graphen zu tun).
3.6.3
Eigenschaften der Nachbarschaftsmengen und Routing
A
Eigenschaft 1: Konsistenz. Falls Nx,j
= ∅ für beliebiges A gilt, dann existieren keine (x, j) Nachbarn
im gesamten Netzwerk. Wir bezeichnen dies als ein „Loch“ in der Routing-Tabelle von A in Level
|x| + 1, Buchstabe j.
35
4226
5233
Level 4
Level 1
4227
Level 2
4311
Level 3
Level 3
4264
4256
Abbildung 3.25: Nachbarschaft des Peers 4227.
Aus der Konsistenz Eigenschaft, lässt sich direkt folgern, dass das Netzwerk zusammenhängend ist.
Somit lässt sich ein einfacher Routing-Algorithmus für das Netzwerk angeben. Wir nehmen an, dass wir
von einem Knoten mit ID A0 zu einem Knoten mit ID B = j1 ◦ j2 ◦ · · · ◦ jn routen möchten. Dies gelingt,
A0
wählen. Von Peer A1 aus wählen wir schrittweise
in dem wir im ersten Schritt einen Peer A1 ∈ N∅,j
1
A1
A2
Peers A2 ∈ Nj1 ,j2 , A3 ∈ Nj1 ◦j2 ,j3 usw. Auf diese Weise wird in jedem Routing-Schritt ein weiterer
Buchstabe von A0 an B angepasst und nach logb |B| Schritten sind wir am gewünschten Ziel angelangt.
Wir vernachlässigen zunächst, dass wir beim Routing auf Löcher in den Routing-Tabellen stossen können.
Eine Lösung hierfür werden wir in Kürze kennen lernen.
Eine wichtige Eigenschaft des Netzwerkes, die es von vielen anderen unterscheidet, ist die folgende:
A
Eigenschaft 2: Lokalität. Jede Nachbarschaftsmenge Nx,j
enthält die bezüglich eines gegebenen metrischen Raumes nahesten (x, j) Nachbarn von Peer A. Der naheste Peer mit Prefix x ◦ j ist der primäre
Nachbar, alle anderen sind sekundäre Nachbarn.
Diese Eigenschaft gewährleistet, dass die beim Routing entstehenden Latenzzeiten möglichst gering
gehalten werden. Des Weiteren kann
Eigenschaft jeder Peer A seinen (gemäß der Latenzzeit)
S durch diese
A
nahesten Nachbarn in der Menge j∈[0,b−1] N∅,j
finden.
3.6.4
Objekte und Routing
Peers die Objekte bereitstellen, werden in Tapestry Storage-Server genannt. Da ein Objekt von mehreren
Storage-Servern bereitgestellt werden kann gibt es zusätzlich zu den Storage-Servern so genannte RootPeers, die für bestimmte Objekte verantwortlich.
Für die Verwaltung eines Objekts mit ID ψ wird eine Menge Rψ = M apRoots(ψ) von Root-Peers
eingesetzt. Die Menge Rψ bezeichnen wir im Weiteren als Root-Set und die Elemente dieser Mengen als
Root-Peers. Aufgabe dieser Root-Peers ist es Links auf diejenigen Peers zu verwalten, die die entsprechenden Objekte bereitstellen. Man beachte, dass jedes Peer sowohl Storage-Server als auch Root-Peer sein
kann. Um Objekte jederzeit lokalisieren zu können, muss Folgendes gewährleistet sein:
Eigenschaft 3: Eindeutiges Root-Set. Das Root-Set Rψ für Objekt ψ muss eindeutig sein und insbesondere muss die Funktion M apRoots(ψ) immer das gleiche Root-Set Rψ generieren, egal wo im
Netzwerk die Funktion aufgerufen wird.
36
437B
437A
43FE
4361
4228
4BF4
4664
4A6D
437E
197E
CE75
39AA
437E
Abbildung 3.26: Publikation von Objekten.
Eine einfache Lösung die garantiert, dass M apRoots(ψ) immer die gleichen Server zurückliefert, egal
wo im Netzwerk die Funktion aufgerufen wird ist die Verwendung von Hashfunktionen. Problematisch
ist, dass dabei Peer-IDs zurückgeliefert werden können, die nicht im Netzwerk existieren. Dieses Problem
könnte gelöst werden, in dem der dem berechneten Hashwert numerisch am nächsten liegende Peer verwendet wird. Hierfür ist jedoch eine globale Ordnung aller Peer-IDs notwendig, die in einem Peer-to-Peer
System schwer aufrecht zu erhalten ist. Wie sich dieses Problem ohne globale Ordnung lösen lässt, werden
wir in Abschnitt 3.6.5 sehen.
Storage-Server müssen den zuständigen Root-Servern mitteilen, dass sie das entsprechende Objekt bereitstellen um es im Netzwerk verfügbar zu machen. Dies geschieht in dem sie eine entsprechende Nachricht entlang primärer Nachbarn zu jedem Peer A ∈ Rψ schicken. Auf jedem Peer der diese Nachricht
weiterleitet wird dabei ein Objekt-Link auf den Storage-Server gespeichert, der die Nachricht abgeschickt
hat. Abbildung 3.26 veranschaulicht diesen Vorgang.
Um Fehlertoleranz zu gewährleisten werden alle beim Publikationsprozess entstandenen Zeiger nach
einer festgelegten Zeit verworfen. Ein Storage-Server muss seine Objekte also in festgelgten Intervallen
republizieren. Dies hat den Vorteil, dass Objekte von Peers die unerwartet ausgefallen sind, automatisch aus
dem System entfernt werden. Des Weiteren werden Peers die sich erst nach dem ersten Publikationsprozess
dem Netzwerk angeschlossen haben und nun auf dem Publikationspfad liegen nach kurzer Zeit automatisch
mit den entsprechenden Objekt-Links versorgt.
Falls von einem Peer aus nach einem Objekt ψ gesucht wird, so wird von diesem Peer das entsprechende
Root Set Rψ berechnet und anschließend zu einem beliebigen Root-Server aus Rψ geroutet. Wird auf dem
Weg zu dem ausgewählten Root-Server auf einen Link für das gesuchte Objekt getroffen, so wird direkt
zu dem Storage-Server gesprungen. Auf diese Weise werden Peers die nahe (bezüglich ihrer ID) zu dem
gesuchten Storage-Server liegen bei der Suche schnell auf Abkürzungen treffen und müssen nicht bis zum
Storage-Server routen.
In Abbildung 3.27 wird der Routing-Vorgang dargestellt. Peer 197E sucht nach Objekt 437E und
schickt die Anfrage an den zuständigen Root-Server 437B. Auf dem Weg dahin wird bei Peer 4361 ein
Objekt-Link für das gesuchte Objekt gefunden. Das Routing wird abgebrochen und es wird direkt zu Peer
39AA gesprungen, der das gesuchte Objekt bereitstellt.
37
437B
437A
43FE
4361
4228
4BF4
4664
4A6D
437E
197E
CE75
39AA
437E
Abbildung 3.27: Routing im Tapestry Netzwerk.
3.6.5
Surrogate-Routing
Ein Problem, dass wir bislang vernachlässigt haben, ist, dass die von M apRoots(ψ) gelieferten Peers unter
umständen gar nicht im Netzwerk existieren. Dies ist sogar wahrscheinlich, da der Namensraum nur sehr
dünn besetzt ist um Kollisionen zu vermeiden. Ein anderes Problem sind die dadurch entstehenden Löcher
in den Routing-Tabellen.
Die Lösung für dieses Problem wurde von den Autoren Surrogate-Routing genannt und funktioniert
wie folgt. Wie bisher wird schrittweise versucht den Root-Server zu erreichen. Wird dabei auf ein Loch an
Stelle (x, j) der Routing Tabelle eines Peers gestossen, so wird stattdessen nach (x, j +1) geroutet. Handelt
es sich auch dabei um ein Loch in der Routing Tabelle, wird jeweils das nächst höhere j genommen.
Dieser Vorgang wird so lange wiederholt, bis der gesuchte Peer erreicht wurde oder der aktuelle Peer
keine Einträge in höheren Leveln und nur den einen, über den er erreicht wurde, im aktuellen Level seiner
Routing Tabelle hat. Es bleibt folgendes Theorem zu zeigen:
Theorem 7 Wenn Eigenschaft 1 (Konsistenz) gilt, dann wird durch Surrogate Routing ein eindeutiger Peer
erreicht, egal von wo im Netzwerk das Routing startet.
Beweis: Beweis durch Widerspruch. Wir nehmen an eine Anfrage nach Objekt ψ endet bei zwei verschiedenen Peers A und B. Sei x das längste gemeinsame Prefix von A und B mit |x| = i. Seien A0 und B 0 die
Peers, die den i + 1-ten Routing Schritt durchführen. Man beachte, dass nach diesem Schritt die ersten i + 1
Buchstaben stets gleich bleiben. A0 und B 0 sind also diejenigen Peers, die unterschiedliche Wege wählen.
A0
B0
Wegen der Konsistenz Eigenschaft gilt jedoch, dass von den Mengen Nx,∗
und Nx,∗
die gleichen leer sein
0
0
müssen. Deshalb werden A und B die Nachricht an einen Peer mit demselben Buchstaben an Stelle i + 1
schicken, es sei denn, die Konsistenz ist gestört. Dies ist ein Widerspruch!
Wir halten an dieser Stelle fest, dass Surrogate Routing höchstens O(log n) (n ist die Anzahl der Peers)
Hops benötigt um das gewünschte Ziel zu erreichen, da in jedem Schritt ein Buchstabe angepasst wird.
3.6.6
Einfügen neuer Peers
Wird ein neuer Peer in ein bestehendes Netzwerk eingefügt, so soll das resultierende Netzwerk demjenigen
gleich sein, dass enstanden wäre, wenn das Netzwerk von Grund auf mit diesem Peer konstruiert worden
38
wäre. Um dies gewährleisten zu können, müsste zusätzlich folgende Eigenschaft erfüllt sein:
Eigenschaft 4. Liegt ein Peer A auf dem Pfad zwischen dem publizierenden Peer von Objekt ψ und dessen
Root-Server, dann besitzt A einen Objekt-Link auf ψ.
Objekte bleiben jedoch auch erreichbar, wenn diese Eigenschaft nicht erfüllt ist. Das schlimmste was
passieren kann, ist dass die Suche etwas länger benötigt (jedoch immer noch höchstens (O log n) Hops).
Deshalb werden wir diese Eigenschaft hier vernachlässigen, wir halten jedoch fest, dass es einen einfachen
Algorithmus hierfür gibt [HKRZ02].
Kommen wir nun zum Einfüge-Algorithmus für neue Peers. Dieser lässt sich in drei wesentliche Schritte teilen:
1. Suche nach der eigenen ID im Netzwerk. Kopiere die Routing Tabelle des so gefundenen Surrogate
Peers.
2. Kontaktiere die Peers, die Löcher in ihren Routingtabellen haben, die durch den neuen Peer gefüllt
werden können.
3. Aufbauen und optimieren der eigenen Routing Tabelle.
Wir werden die einzelnen Schritte der einfüge Operation nun näher erläutern.
Schritt 1. Schritt 1 ist unproblematisch und benötigt O(log n) Hops.
Schritt 2. Schritt 2 ist notwendig um Eigenschaft 2 (Konsistenz) gewährleisten zu können. Um dies
zu erreichen wird der Acknowledged Multicast Algorithmus verwendet. Hierfür wird zunächst das längste gemeinsame Prefix x zwischen dem neuen Peer und dem beim Einfügen gefundenen Surrogate Peer
bestimmt. Daraufhin wird wie folgt vorgegangen:
• Der neue Peer sendet eine Multicast Nachricht an seinen Surrogate Peer. Diese besteht aus dem
gemeinsamen Prefix und einer Funktion (dazu später mehr).
A
• Empfängt ein Peer A eine Multicast Nachricht, so sendet er sie weiter an jeweils einen seiner Nx,j
,
j ∈ [0, b − 1], Nachbarn mit Prefix x ◦ j.
• Empfängt ein Peer eine Nachricht, die er nicht mehr weiterleiten kann, führt er die in der Nachricht
enthaltene Funktion aus.
• Die mitgesendete Funktion transferiert Verweise auf Objekte zum neuen Peer, falls dieser ein altes
Surrogate Peer ersetzt und entfernt nicht mehr benötigte Verweise. Auf diese Weise wird verhindert,
dass Objekte unerreichbar werden.
• Jeder Peer, der Multicast Nachrichten verschickt hat, erwartet eine Rückmeldung (Acknowledge) von
allen Empfängern. Sind alle Rückmeldungen eingetroffen, so benachrichtigt er den im Aufrufbaum
„über“ ihm liegenden Peer.
Wir werden nun zeigen, dass der Acknowledged Multicast Algorithmus tatsächlich alle Peers mit Prefix
x erreicht.
Theorem 8 Wenn der Empfänger einer Multicast Nachricht mit Prefix x sein Acknowledge versendet, dann
haben zuvor alle Peers mit Prefix x eine Multicast Nachricht erhalten.
Beweis: Beweis durch Induktion über die Länge von x.
Induktionsanfang: Wir nehmen an, dass Peer A eine Multicast Nachricht mit Prefix x erhält und A der
einzige Peer mit Prefix x ist. In diesem Fall ist die Behauptung offensichtlich korrekt.
39
Induktionsschritt von |x| = i → |x| = i − 1: Angenommen die Behauptung gilt für einen Prefix x mit
|x| = i. Des Weiteren nehmen wir an, dass Peer A eine Multicast Nachricht mit Prefix x erhält.
Dann sendet A Multicast Nachrichten an jeweils einen Peer mit den möglichen Erweiterungen von x
(also x ◦ 0, . . . , x ◦ j − 1). Sobald A von jedem dieser Peers Acknowledge Nachrichten erhalten hat,
wurden alle Peers mit Prefix x erreicht. Da A auf diese Acknowledge Nachrichten wartet, bevor die
eigene Acknowledge Nachricht gesendet wird, haben bereits alle Peers mit Prefix x eine Multicast
Nachricht erhalten, wenn A sein Acknowledge sendet.
Schritt 3. Wir kommen nun zum dritten Schritt des Einfüge-Algorithmus für neue Peers. In diesem müssen die Nachbarschaftsmengen des neuen Peers aufgebaut und optimiert werden um die Eigenschaften 1
(Konsistenz) und insbesondere 2 (Lokalität) zu erfüllen. Dieses kommt dem Lösen des Naheste-Nachbarn
Problems für viele verschiedene Prefixe gleich.
Der Aufbau der Nachbarschaftsmengen geschieht Level-weise. Aus dem vorigen Schritt (Multicast)
kennen wir bereits alle Peers, die das grösste gemeinsame Prefix x, |x| = i, mit dem neuen Peer A teilen.
A
Somit sind alle potentiellen Level i Nachbarn bekannt und es müssen nur noch für jede der Mengen Nx,j
(j ∈ [0, i − 1]) die k nahesten von diesen ausgewählt werden.
Anschließend werden sukzessive die Level i − 1 Nachbarn mit Hilfe der zuvor berechneten Level i
Nachbarn berechnet, bis Level 1 erreicht wurde. Dies geschieht nach folgendem Algorithmus:
1. Fordere von allen Level i Nachbarn Listen mit Links ihrer Level i − 1 Nachbarn an.
2. Messe die Entfernung zu jedem der in Schritt 1 erhaltenen Peers gemäß einer gewählten Metrik3 .
3. Wähle die k nahesten für jedes j aus und speichere diese in der entsprechenden Nachbarschaftsmenge.
Schritt 2 des Algorithmus ist von elementarer Bedeutung um die Lokalität des Netzwerkes zu gewährleisten. Damit dies tatsächlich funktioniert müssen wir zeigen, dass mit Hilfe der k nahesten Level
i Nachbarn mit hoher Wahrscheinlichkeit die k nahesten Level i − i nachbarn gefunden werden können.
Dies gelingt tatsächlich mit hoher Wahrscheinlichkeit, wenn k = O(log n) gewählt wird und die folgende
Restriktion des metrischen Raumes, in dem die Peers sich befinden, angenommen wird:
Wachstums-Restriktion: Bezeichne BA (r) die Menge aller Peers die sich im Ball mit Radius r um Peer
A befinden. Dann muss für eine Konstante c
|BA (2r)| ≤ c|BA (r)|
2
und c < b gelten. Die Konstante c wird als Expansionskonstante des Netzwerks bezeichnet.
Diese Restriktion kann man sich etwa als eine gleichmässige Verteilung der Peers im Raum vorstellen,
die gelten muss. Gilt diese Annahme nicht, so ist nicht mehr garantiert, dass der Algorithmus mit hoher
Wahrscheinlichkeit die Lokalitätseigenschaft der Nachbarschaftsmengen aufrecht erhalten kann. Wir werden auf den Beweis der Korrektheit des Algorithmus an dieser Stelle aus Platzgründen verzichten. Er kann
in [HKRZ02] nachgelesen werden.
Betrachten wir abschließend den Aufwand des Einfüge-Algorithmus. Hierbei konzentrieren wir uns
wieder auf die Netzwerklast und vernachlässigen lokale Berechnungen. In Schritt 1 kann der Surrogate
Peer mit O(log n) Hops gefunden werden. Der Acknowledged Multicast Algorithmus (Schritt 2) benötigt
O(m) Hops, wobei m die Zahl der erreichten Peers ist. m ist klein im Vergleich zu n [HKRZ02] und
konstant. Der Aufbau der Nachbarschaftsmengen kann mit O(log2 n) Hops geschehen, da jeder Peer eine
konstante Anzahl Nachbarn je Level hat beträgt die Laufzeit des Algorithmus zum Aufbau der Nachbarschaftsmengen O(k) = O(log n) pro Level und somit insgesamt O(log2 n) für alle Level. Insgesamt ergibt
sich somit:
8. Vorlesung
14.06.2004
Theorem 9 Das Einfügen eines neuen Peers in Tapestry kann mit O(log2 n) Hops geschehen.
3 Eine
geeignete Metrik wird z.B. durch die Ping-Zeit geliefert.
40
3.7
Pastry
Peter Druschel (Rice University, Housten, Texas) und Antony Rowstron (Microsoft Research, Cambridge,
GB) entwickelten in Cambridge bei Microsoft Research das Pastry-Peer-to-Peer-Netzwerk. Pastry und
Tapestry werden wegen ihrer Ähnlichkeit gerne zusammen erwähnt. Tatsächlich beruhen beide auf den
Routing-Algorithmus von Plaxton et al [PRR97]. Es gibt aber sowohl in der Umsetzung als auch in der
Herangehensweise erhebliche Unterschiede, die wir nun vorstellen werden. Zielsetzung von Pastry ist ein
vollständig dezentralisiertes, fehler-tolerantes, skalierbares und zuverlässiges Peer-to-Peer-Netzwerk. Wir
beziehen uns hier im wesentlichen auf den Originalartikel [DR01b]: „Scalable, decentralized object location and routing for large scale peer-to-peer-network“.
Pastry soll eine Basis bilden für die Konstruktion von Peer-to-Peer-Anwendungen, wie zum Beispiel
globales File-Sharing, File-Storage und Gruppen-Kommunikation. In diesem Zusammenhang ist auch
PAST zu sehen, vorgestellt in [DR01a] „A large-scale, persistent peer-to-peer storage utility“ von den
selben Autoren.
Überblick In Pastry werden jedem Peer 128-bit Identifikationsnummern (nodeID) gleichmäßig zugeordnet. Dies kann zum Beispiel durch zufällige Wahl geschehen oder durch das Anwenden einer kryptographischen Verschlüsselungsfunktion auf die IP-Adresse des Peers. Dadurch soll sicher gestellt werden,
dass keine zwei die gleiche nodeID erhalten.
Die Einträge werden durch Schlüssel adressiert, die ebenfalls auf {0, 1}128 abgebildet werden. Gemäß
einer Metrik werden diese Schlüssel-Einträge zum nächstgelegenen Nachbarn weitergereicht.
Die eigentliche Zeigerstruktur zwischen den Peers wird bei Pastry Routingtabelle genannt (erfüllt die
Aufgabe der Finger bei Chord). Diese Routingtabelle hat bei Pastry (1+)(2b − 1) logb n + ` Einträge, wobei
> 0 für große Anzahl n der Peers gegen 0 strebt. Die Parameter b (Wortlänge) und ` stellen Konfigurationsparameter dar (eine typische Wahl ist b = 4 und ` = 16). Der Zusammenhalt von Pastry ist wesentlich
größer als zum Beisipiel der Chord. Dies wird durch den Parameter ` gesteuert und insbesondere ist die
Auslieferung von Nachrichten garantiert, solange nicht mehr als `/2 beliebige Knoten ausfallen. Daneben
ist das Einfügen von Peers ebenfalls effizient umgesetzt. Hierbei werden höchstens O((log n)/b) Nachrichten benötigt.
3.7.1
Die Zeigerstruktur
Die Zeiger werden nun Routing-Tabelle und Leaf-Set genannt.
Die Routingtabelle Die Routing-Tabelle orientiert sich am Routing von Plaxton et al. [PRR97]. Hierfür
wird die NodeID zur Basis 2b dargestellt, also zum Beispiel NodeID: 65A0BA13 für b = 4.
Nun kennt jeder Peer für jeden Präfix (Anfangsteilstring) p der NodeID über dem Alphabet 2b und für
jeden Buchstaben x ∈ {0, . . . , 2b−1 } einen Repräsentanten der mit px anfängt, siehe Abbildung 3.28. Also
im Beispiel mit b = 4 ist 2b = 16 und die Routing-tabelle des Konten mit NodeID 65A0BA13 besteht aus
• 15 Einträgen von Knoten mit NodeID 0*,1*, . . . , F*
• 15 Einträge für 60*, 61*, . . . , 6F*
• 15 Einträge für 650*, 651*, . . . , 65F*
• ···
Existiert kein Repräsentant, wird kein Eintrag vorgenommen. Gibt es mehrere Möglichkeiten einen
Eintrag vorzunehmen, wird der bestmögliche Nachbar ausgewählt. Hierfür wird eine Abstandsmetrik zugrunde gelegt, die sich aus dem Latenzzeit (RTT — round trip time) zwischen Knoten und Repräsentanten
ergibt. Wir werden gleich auf den Prozess zum Finden dieser Repräsentanten zurückkommen.
41
Abbildung 3.28: Beispiel einer Pastry-Routing-Tabelle [Aus einem Web-Dokument von Druschel und
Rowstron, das nicht zitiert werden soll]
333
001
012
323
021
032
311
101
300
103
223
130
220
213
210
133
Abbildung 3.29: Die Pastry-Zeigerstruktur im Knoten 001 für b = 2 und ` = 2
Nachbarschaftsmengen Zusätzlich zu dieser Routing-Tabelle werden ` Nachbarn gemäß der NodeID
gespeichert (gemäß der Anordnung der NodeID auf dem Ring). Hierzu werden d`/2e Peers rechts vom
Ausgangspeer und b`/2c links vom Peer auf dem Ring addressiert. Als triviale Beobachtung können wir
festhalten, dass alleine durch diese Nachbarschaftsmengen die Zielknoten immer gefunden
In Abbildung 3.29 ist die Zeigerstruktur von Knoten mit NodeID 001 für b = 2 und ` = 4 beispielhaft
dargestellt.
Durch die zufällige Wahl der NodeIDs, ist die Anzahl der Speichereinträge in der Routing-Tabelle wie
folgt beschränkt.
Lemma 6 Für n Peers sind mit hoher Wahrscheinlichkeit sind (1 + )2b logb n Einträge in jeder Routingtabelle für beliebiges > 0.
Beweis: Die Wahrscheinlichkeit, dass ein Peer einen bestimmten m-stelligen Präfix erhält ist 2−bm . Damit
ist die Wahrscheinlichkeit, dass ein m-stelliger Präfix besetzt wird, höchstens
n2−bm
42
003
333
001
012
323
021
032
311
101
300
103
223
130
220
213
210
133
Abbildung 3.30: Pastry-insert.pdf
Setzen wir nun m = (1 + ) logb n ein, erhalten wir
n2−bm = n2−(1+) log n = n · n−1− = n−
Mit hoher Wahrscheinlichkeit ist also kein Peer mit dem gleichen Präfix der Länge (1 + )(log n)/b vorhanden. Damit gibt es (1 + )(log n)/b Zeilen á 2b − 1 Einträge. Daraus folgt das Lemma.
3.7.2
Einfügen von Peers
Will ein neuer Peer X in das Pastry-Netzwerk aufgenommen werden, so muss er wenigstens einen Knoten des Netzwerks bereits kennen. Von diesem Knoten fahndet X nach dem Knoten Z mit dem längsten
gemeinsamen Präfix p, indem X den Routing-Algorithmus aufruft.
X erhält nun die Routing-Tabelle und die Nachbarschaftsmenge von Z. Dabei aktualisiert auch Z seine
Nachbarschaftsmenge. Nun informiert X die `-Nachbarschaft, damit die Nachbarschaftsmengen aktualisiert werden können. Zusätzlich informiert X Peers in seiner Routing-Tabelle Peers mit gleichen Präfix p,
so dass diese so weit notwendig, X als neuen Peer eintragen.
Der Aufwand dieser Einfüge-Operation besteht aus ` Nachrichten an die Nachbarn der Nachbarschaftsmengen und erwartet 2b (log n)/b Nachrichten an Knoten mit gemeinsamen Präfix und natürlich einer
Nachricht von Knoten Z, sowie einer Lookup-Operation, siehe auch Abbildung 3.30.
Wenn das Einfügen versagt Die Einfüge-Operation von Pastry ist damit wesentlich einfach einfacher
als die von Tapestry. Dagegen ist sie aber auch nicht immer korrekt. Es kann passieren, dass notwendige
Zeigereinträge nicht aktualisiert werden. Dieses ist in Abbildung 3.31 dargestellt.
Es ist nämlich nicht ausreichend nur die Zeiger der Peers des nächstgelegenden Peers zu aktualisieren,
wie das Beispiel der Abbildung 3.31 lehrt:
Falls kein Peer mit 1* vorhanden ist, müssen alle anderen Peers auf den neuen Knoten zeigen. Aber
nach Einfügen von 11, erhält 11 nur die Einträge 22, 33 und 03 in der Routing-Tabelle (diese werden ihm
von 03 übergeben). Damit informiert er zu wenig Peers, dass ab sofort auch der Präfix 1* besetzt wird. Es
müssen nämlich alle Peers diese Eintrag besitzen.
Reparatur-Maßnahmen Nun ist aber das Routing (Lookup) selbst dann sichergestellt, wenn Einträge in
der Routing-Table fehlen, solange die Leaf-Sets (Nachbarschaftsmengen) ordentlich geführt werden. Peers
43
Neuer Peer
Einträge in Leaf-Set
00 01 02 03
11
20 21 22 23 30 31 32 33
Notwendige Einträge in Routing-Table
Fehlende Einträge
Tatsächliche Einträge
Abbildung 3.31: Nach dem Einfügen von Peer 11 werden nicht alle notwendigen Einträge aktualisiert
021
Fehlender Link
00*
Anfrage an
bekannte
Nachbarn
03*
01*
Links der Nachbarn
Abbildung 3.32: Der Reparatur-Mechanismus für Pastry
werden also in jedem Fall gefunden werden. Der einzige Nachteil, der durch fehlende Routing-TableEinträge erwächst, ist ein Verlust in der Geschwindigkeit.
Um solche fehlenden Einträge in Routing-Tables zu reparieren, ist ein Mechanismus in Pastry vorgesehen.
Angenommen, der Tabelleneintrag R`i fehlt bei Peer D (d.h. `-te Zeile, i-te Spalte des Routing-Table).
Peer D bemerkt diesen Verlust zum Beispiel dadurch, dass eine Nachricht an oder von einem Peer mit
diesem Präfix durch D befördert wird. Es kann aber auch vorkommen, dass ein Peer das Netzwerk verlässt
und dadurch alte Einträge in der Routing-Table falsch oder überflüssig werden.
Der Reparatur-Mechanismus geschieht wie folgt: Zuerst werden Peers der selben Zeile kontaktiert.
Fehlt also beispielsweise dem Peer 021 ein Link zum Präfix 01*, dann fragt er die Nachbarn mit Präfix
00*, 02* und 03* nach diesem (siehe Abb. 3.32), falls einer dieser Peers diesen Präfix-Eintrag hat, wird er
kopiert. Scheitert dies, wird ein Routing (Look-Up) zu der Adresse durchgeführt und aufgrund der Antwort
der Eintrag gesetzt.
3.7.3
Routing
Im Prinzip funktioniert der Look-Up (hier Routing genannt) wie folgt. Zuerst wird durch Hash-Funktion
die Zieladresse hergestellt. Befindet sich die Zieladresse innerhalb der `-Nachbarschaft, wird direkt dorthin
ausgeliefert oder zum nächsten Peer. Der nächste Peer ist derjenige, der das Fehlen eines Datums, Peers
oder ähnliches feststellen kann.
Ansonsten wird in der Routingtabelle die Adresse mit gemeinsame Präfix gesucht und dorthin die
Nachricht weitergeleitet.
Jetzt kann es, wie bereits erwähnt, geschehen, dass die Routing-Table fehlerhafte oder fehlende Einträge besitzt. Ist man dann mehr als `/2 Schritte vom Ziel entfernt, so kann man entweder versuchen
gemäß der Nachbarschaft (die immer ordnungsgemäß geführt wird) den auf dem Ring entlanglaufen, was
n/` Schritte im schlimmsten Fall benötigt. Man kann aber auch versuchen, den nächstbesten vorhandenen
44
L
R
M
D
A
Rij
Li
Di
shl(A)
`-Nachbarschaft
Routing-Table
Knoten in der Nähe von A (gemäß Latenzzeit)
Schlüssel als Adresse auf dem Ring
Node-ID des aktuellen Peers
j-te Zeile und i-te Spalte der Routing-Table
Nummerierung der `-Nachbarschaft
i-te Ziffer des Schlüssels D
Länge des gemeinsamen Präfix von A und D in
Ziffern über dem Alphabet {0, . . . , 2b − 1}
Tabelle 3.1: Notation des Routing-Algorithmus von Pastry in Abbildung 3.33
Abbildung 3.33: Pastry-Routing-Alg
funktionierenden Routing-Table-Eintrag zu verwenden.
Tatsächlich wird in Pastry eine Kombination dieser Möglichkeiten verwendet, wobei noch eine Menge M von (latenz)-nahen Knoten hier hinzugenommen wird4 . Aus dieser Menge wird nun ein beliebiger
Knoten genommen, der hinsichtlich der Namensmetrik (NodeID) näher am Ziel ist als der momentan betrachtete Peer.
Wir geben hier die Originalbeschreibung des Algorithmus aus [DR01b] in Abbildung 3.33 wieder. Die
verwendete Notation ist in Tabelle 3.1 dargestellt. Vorsicht: Die Variable `, die hier im Algorithmus verwendet wird bezeichnet nicht etwa die Größe der Nachbarschaft, sondern die Länge des größten gemeinsamen
Präfix mit dem Ziel.
Diskussion Für die Anzahl der Nachrichten und Sprünge, die Routing benötigt, um eine Nachricht auszuliefern, bedeutet dass, falls die Routing-Table korrekt und vollständig ist, benötigt Routing Aufwand
O((log n)/b). Ist die Routing-Table vollständig unbrauchbar und wenigstens die Nachbarschaftsmenge
korrekt, so benötigt Routing den Aufwand O(n/`) an Nachrichten und Sprüngen. Tatsächlich wird diese
Laufzeit selbst bei durchgehend stark beschädigten Routing-Tables nicht erreicht. Routing ist selbst dann
wesentlich schneller, da wenige korrekte Routing-Table-Einträge erhebliche Beschleunigungen ermöglicht.
4 die
in der Beschreibung des Algorithmus zuvor in [DR01b] nicht erwähnt wird
45
In dieser reinen Form berücksichtigt das Routing nicht die wahren Abstände (bezüglich Latenzzeiten
des zugrunde liegenden Netzwerks). Die ominöse Menge M wird nur benutzt, falls Fehler in der RoutingTabelle vorliegen. Es besteht aber die Möglichkeit durch Ausnutzung der Lokalität, Verbesserungen zu
erreichen.
Hierzu verwendet Pastry heuristische Ansätze zur Verbesserung der Latenzzeit. Diese werden in den
besonders teuren letzten Hops angewendet (welches wie wir gleich sehen werden die letzten Schritte des
Routings sind).
Lokalisierung der k nächsten Knoten Eine wichtige Beobachtung zur Latenzzeit ist, dass die Nähe
eines Knoten bezüglich der Ringmetrik (Raum über {0, 1}128 ) und der Latenzzeitmetrik (gemessen in der
Zeit, die eine Nachricht durchschnittlich zwischen zwei Knoten benötigt) völlig unabhängig voneinander
sind. Das heißt insbesondere, dass direkte Nachbarn im Peer-to-Peer-Netzwerk sind nicht Knoten in der
Nähe sind. So könnte zum Beispiel ein Link von einen Rechner in Neuseeland nach Ostwestfalen führen,
oder von Indien nach Kalifornien.
Nun misst das TCP-Protokoll des Internets misst sowieso Latenzzeiten (durch die RTT — round trip
time). Damit kann eine Metrik definiert werden, welche die Grundlage ist für die Suche eines nächsten
Peers für die Einträge in der Routing-Table. So werden die Einträge in der Routing-Table optimiert. Diese
Verfahren in Pastry beruhen auf heuristischen Überlegungen und kein mathematischer Nachweis der Güte
der Verfahren ist bisher erbracht worden. Insbesondere gilt dies auch für die Annahme, dass diese Latenzmetrik euklidisch ist (d.h. es existiert eine Einbettung der Punkte in einem Raum, so dass die Latenzmetrik
sich durch den Euklidischen Abstand dieser Punkte entsteht).
Lokalität in der Routing-Table Um die Latenzzeit zu verkleiner wird folgende Heuristik angewendet.
Es wird angenommen, dass beim Einfügen eines Peers A der Knoten zuerst einen (latenz-) nahen Knoten
P kontaktiert. Weiter wird davon ausgegangen, dass alle anderen Peer ihre Routing-Table bereits optimiert
haben (so dass jeder Zeiger auf einen Präfix p*, den Peer adressiert, der bzgl. der Latenzzeit am nächsten
ist).
Das Problem ist nun, dass der zuerst kontaktiert Peer P bezüglich der NodeID nicht sehr nahe sein
wird. Trotzdem kann man aus der Nähe zu P einen Nutzen ziehen:
Zuerst werden alle Einträge der ersten Zeile der Routing-Table von P in A übernommen. Da angenommen wurde, dass die Latenzzeit eine Euklidische Metrik ist, erhält man so zwar nicht unbedingt, den
nächsten, aber im schlimmsten Fall höchsten einen, der doppelt so weit ist, wie der nächste.
In einem zweiten Schritt wird der Peer aus der Routing-Table von P kontaktiert, der den ersten Buchstaben wie A hat. Nun wird der erste Schritt und zweite Schritt wiederholt, bis der Peer A seine Routing-Table
so aufgefüllt hat. Die Abbildung 3.34 aus [DR01b] soll diesen Algorithmus veranschaulichen.
Lokalität im Routing Wird für jeden Eintrag tatsächlich der latenz-nächste Peer ausgewählt, so steigt
mit dem Zeilenindex die Länge der Sprünge exponentiell an (siehe Abbildung 3.35), falls die Peers im
Euklidischen Raum gleich verteilt sind (Eine sehr weit gehende Annahme). Nun heisst das aber nicht, dass
das Routing den kürzesten Weg wählt (das wäre bei einer Metrik in jedem Fall die direkte Verbindung
zwischen zwei Punkten). Es besteht aber die Hoffnung, dass kurze Wege entstehen. Schließlich ist nun
der Sprung am teuersten der die letzte Zeile der Routing-Table benötigt und hier kann man mittels der
Leaf-Set-Einträge (Nachbarschaftsmengen) einen direkten Sprung benutzen und weitere sehr teure Wege
verhindern.
Lokalisierung (latenz-) naher Knoten Da wie bereits gesagt der Raum der Node-IDs und die Latenzmetrik völlig unvergleichbar sind, können bei der Speicherung replizierter Daten auf k Knoten, (latenz-)
nahe Peers mit ähnlicher Node-ID übersehen werden. Diesen Umstand versuchen die Autoren mit einer
Heuristik zu lösen, auf die hier aus Zeit- und Platz-Gründen nicht eingegangen wird. Zumindestens scheinen experimentelle Untersuchungen die Güte dieses Ansatzes zu bestätigen
46
Abbildung 3.34: Beim Einfügen eines Peers in Pastry, kann man die Latenzzeiten des Routing klein halten,
indem man latenznahe Knoten eines Levels bevorzugt [DR01b]
Abbildung 3.35: Die Latenzzeiten der Level i-Sprünge steigen bei Pastry expontiell in i an [DR01b]
47
Abbildung 3.36: Durchschnittliche Anzahl von Hops beim Routing von Pastry mit steigender Knotenanzahl
(b = 4, ` = 16 und |M | = 32) [DR01b]
Bösartige Fehler Ein allgemeines Problem bei Peer-to-Peer-Netzwerke ist die Behandlung von Peers, die
sich nicht systemgemäß verhalten. Pastry sieht hierzu (noch) keine Lösungen vor. Als mögliche Lösungen
werden eine Randomisierung des deterministisichen Routings vorgesehen, sowie der Einfüge-Operation.
Für eine ausführliche Diskussion von Sicherheit und der Behandlung von bösartigen Angriffen auf ein
Peer-to-Peer-Netzwerk sei auf spätere Kapitel dieses Skripts verwiesen.
Ein weiteres Problem sein sogenannten IP-Routing-Anomalien. Mitunter sind Routen im Internet nicht
vorhanden und Knoten nur über Umwege erreichbar. Dieses Problemen wird von Pastry, wie auch von
anderen Peer-to-Peer-Netzwerken nicht gelöst. Diskutiert wird in [DR01b] eine Lösung durch IP Multicast.
Überzeugen können diese Ansätze aber nicht.
3.7.4
Experimentelle Resultate
Aufgrund der Schwierigkeit der analytischen Evaluation ihrer heuristischen Routinen, stellen die Autoren
Druschel und Rowstron weitreichende experimentelle Untersuchungen ihres Peer-to-Peer-Netzwerks vor.
Skalierung Für den Nachweis der Skalierbarkeit des Netzwerks werden für Parameter b = 4, ` = 16
und M = 32 die durchschnittliche Hop-Distanz, die beim Routing auftritt dargestellt. In diesem Experiment (Abb. 3.36) steigt die durchschnittlich Hop-Distanz logarithmisch mit der Knotenanzahl an. Eine
mathematische Analyse sagt hier 4 log n voraus, was durch dieses Experiment nur bestätigt wird.
Verteilung der Routing-Hops In Abbildung 3.37 ist die Auswertung dieses Experiments hinsichtlich der
Verteilung der Hop-Entfernung dargestellt. Die Abweichung von der erwarteten Hop-Distanz ist extrem
gering. Tatsächlich sagt auch die Analyse eine Abweichung mit polynomiell kleiner Wahrscheinlichkeit
voraus. Wiederum eine gute Übereinstimmung von Analyse und Experiment.
Latenzzeit Zuletzt werden die Latenzzeit (Abbildung 3.38) der direkten Entfernung mit dem kürzesten
(direkten?) Weg verglichen. Der Unterschied ist erstaunlich gering und durchweg höchstens 30%-40%
länger als bestmöglich. Mit steigender Knotenzahl scheint diese Kurve nicht zuzunehmen.
Kritische Betrachtung der Experimente Mit der Parameterwahl b = 4, ` = 16 wird die Anzahl der
Links pro Knoten relativ groß. Damit kann der Faktor 2b /b = 4 das Ergebnis erheblich beeinflussen. Wenn
zum Beispiel n = 106 , dann sind 2b /b log n = 4 log n > 60 Links in der Routing-Table. Hinzu kommen
noch 16 Links in der Nachbarschaftsmenge (Leaf-Set) und 32 in M (über deren genaue Wahl nichts bekannt
48
Abbildung 3.37: Verteilung der Hops beim Routing von Pastry mit steigender Knotenanzahl (b = 4, ` = 16,
|M | = 32 und n = 106 ) [DR01b]
Abbildung 3.38: Pastry-latency.pdf
49
Abbildung 3.39: Güte der Routing-Table von Pastry vor und nach dem Ausfall von 500 von 5.000 Peers
und nach Abschluss der Repeartur-Routine [DR01b]
wird). Dadurch ist der Grad im Verhältnis zu anderen Protokollen wie Chord oder auch Tapestry weitaus
größer.
Zumal die Annahme Euklidischer Latenzzeiten aus der Luft gegriffen, aber dennoch die Grundalge der
experimentellen Untersuchungen ist. Die Stagnation des Verhältnis der Latenzzeit zur optimalen Latenzzeit
nährt zuerst eher Zweifel an der Aussagekraft des Experiments.
Knotenausfälle Zuletzt sei hier noch ein Experiment für die Zuverlässigkeit des Reparaturmechanismus
wieder gegeben (Abbildung: 3.39). Hierbei bezeichnet No fail, die durchschnittlichen Einträge der RoutingTable vor dem Ausfall der Knoten. Dann fallen 500 von 5.000 Peers aus und No repair zeigten den Zustand
der Routing-Table an. Repairl bezeichnet den Zustand nach der Reparatur. Die weiteren Parameter sind
b = 4, ` = 16, |M | = 32 und n = 5.000.
3.7.5
Pastry versus Tapestry
Pastry und Tapestry werden gerne in einem Atemzug genannt. Tatsächlich beruhen beide Peer-to-PeerNetzwerke auf dem selben Routing-Prinzip von Plaxton, Rajamaran und Richa [PRR97]. Dies stellt eine Verallgemeinerung von Routing auf dem Hyperwürfel dar und verringert die Congestion in StandardNetzwerken.
Tapestry ist nicht vollständig selbstorganisierend, achtet aber stark auf die Konsistenz der RoutingTabelle. Tapestry ist ist analytisch gut verstanden und hat nachweisbare Performanz-Eigenschaften.
In Pastry werden statt analytischer Methodik viele heuristische Methoden eingesetzt. Die eigentliche algorithmische Beschreibung ist ungenau (siehe M ) und experimentelle Verifikation ersetzt hier analytische
Untersuchungen. Dagegen lässt sich Pastry praktisch besser umsetzen und ist durch die Nachbarschafts9. Vorlesung mengenn sehr robust.
11.06.2004
3.8
Viceroy — Ein Butterfly basiertes Peer-to-Peer-Netzwerk
Es gab einige Zeit den Wettlauf, den Grad (Anzahl der Zeiger pro Peer) und Durchmesser von Peer-toPeer-Netzwerken zu minimieren. Angefangen hat es mit CAN, welches polynomiellen Durchmesser und
konstanten Grad besitzt. Der Durchmesser war damit unakzeptabel hoch. Chord löste dies mittels einer
50
Abbildung 3.40: Der Butterfly-Graph
Datenstruktur mit logarithmischen Durchmesser. Nur hat sich dadurch der Grad auf O(log n) verschlechtert. Dies löste dann Koorde (welches eigentlich später erschien als ViceRoy) ohne den logarithmischen
Durchmesser zu verlieren. Koorde hat konstanten Ausgrad, aber logarithmischen Eingrad, d.h. jeder Peer
zeigt nur auf vier andere, aber eine größere Anzahl von Peers können mitunter auf einen einzelnen Peer
zeigen. Solche eine Situation kann zu einer ungleichen Verteilung von Datenlast führen und daher stellen
wir in diesem und dem folgenden Abschnitt jeweils ein Peer-to-Peer-Netzwerk vor, dass dieses Problem
löst und konstanten Ein- und Aus-Grad als auch logarithmischen Durchmesser vorsieht.
Der Name Viceroy, bedeutet zugleich Vizekönig ist aber auch zugleich der Name einer Schmetterlingsart, welches auf die Grundprinzip hinweist. Viceroy wurde von Dahlia Malkhi, Moni Naor und David
Ratajczak im Jahr 2001 [MNR02] entwickelt um eine skalierbare und dynamische Emulation des ButterflyGraphen vorzustellen.
3.8.1
Der Butterfly-Graph
Für eine natürliche Zahl k besteht ein Butterfly-Graph aus k · 2k Knoten und 2k · 2k Kanten, wobei jeder
Knoten Grad vier besitzt. Die Knoten eines Butterfly-Graphen werden mit (i, S) bezeichnet, wobei i ∈
{0, . . . , k − 1} und S einen k-stelligen Binär-String bezeichnet. Als Interpretation kann man sich k Ebenen
vorstellen und in jeder Ebene befinden sich m = 2k Knoten. Kanten verbinden immer Ebene i mit Ebene
i + 1 mod k. Es gibt zwei Typen von Kanten:
• Senkrechte Kanten von (i, (b1 , . . . , bk )) nach (i + 1 mod k, (b1 , . . . , bk )) für alle i ∈ {0, . . . , k − 1}.
• Diagonale Kanten von (i, (b1 , . . . , bi , . . . , bk )) nach (i + 1 mod k, (b1 , . . . , ¬bi , . . . , bk )) für alle
i ∈ {0, . . . , k − 1} und bj ∈ {0, 1}.
In Abbildung ist eine Butterfly-Graph für k = 3 dargestellt. Der Übersicht halber wurde die Ebene 0
zweimal dargestellt, nämlich in der untersten und obersten Reihe. Die Ebene 1 befindet sich in der zweiten
Reihe von oben und die Ebene 2 in der dritten von oben.
Eigenschaften Butterfly-Graph Aus der Definition ergibt sich schon, dass der Grad des ButterflyGraphen vier. Der Durchmesser ist log m = log n − log log n und damit optimal.
Darüber hinaus besitzt der Butterfly-Graphen eine ganze Reihe guter Eigenschaften. Zum Beispiel
können beliebige Netzwerke sehr effizient in einen Butterfly-Graphen eingebettet werden. Eine Einbettung
eines Graphen in einen anderen geschieht dadurch, dass die Knoten des einen Graphen auf die des anderen
(nicht notwendigerweise eineindeutig) abgebildet werden und die Kanten des einen Graphen durch Pfade
in dem andern Graph dargestellte werden. Die Güte einer solchen Einbettung misst man dann in der Anzahl
der Knoten, die der Zielgraph in einem seiner Knoten übernehmen muss und durch die maximale Pfadlänge
einer simulierten Kante.
51
Daneben gibt es nicht nur sehr einfache Routing-Algorithmen, in denen eine Routing-Entscheidung
lokal in konstanter Zeit möglich ist. Es können auch Flaschenhälse im Routing sehr einfach vermieden
werden. Hierzu wird die Nachricht von Ebene i zu Ebene i + 1, i + 2, . . . , i + k − 1 mod k in jeweils
eine zufällige Richtung versendet und dann in maximal 2k − 1 Schritten auf den direkten Weg entlang
der Ebenen i, i + 1, . . . versendet. Durch ein solches Routing tritt keine um den Faktor O(log n) höhere
Last auf als auf dem besten lastminimierenden Routing. Somit wird durch dieses einfache Verfahren kein
Knoten beim Routing mit Nachrichten überlasten.
Daneben hat der Butterfly-Graph eine hohe Fehlertoleranz, d.h. der Ausfall von Knoten kann gut ausgeglichen werden. Viele Gründe, die dafür sprechen auf einen Butterfly-Graphen ein Peer-to-Peer-Netzwerk
aufzubauen.
3.8.2
Übersicht
Die Zielsetzungen von ViceRoy waren neben der Skalierbarkeit, die Bewältigung von dynamischen Lastanforderungen und die gleichmäßige Verteilung des Nachrichtenaufkommens (Traffic). Dieses misst man mit
dem Begriff der Congestion, das ist für ein bestimmtes Routing, die maximale Anzahl von Paketen, die ein
Peer transportieren muss. Es ist einsichtig, dass die Congestion für die Zeit, die benötigt wird Nachrichten
zu befördern, eine untere Schranke darstellt.
Daneben sollen auch die Kosten für die Aufnahme und das Entfernen eines Peers klein gehalten werden,
als auch die Länge des Suchpfads, welches im Routing-Bereich mit dem Begriff der Dilation bekannt ist.
All diese Eigenschafte erfüllte Viceroy und außerdem war Viceroy das erste P2P-Netzwerk mit optimaler Beziehung zwischen Grad und Durchmesser. Dafür benutzt Viceroy Techniken, die sich auf andere
Peer-to-Peer-Netzwerke übertragen lassen.
Der Aufbau von Viceroy Leider ist der Aufbau von Viceroy etwas komplexer als der vergleichbarer
Netzwerke. Vom Prinzip her versucht man in Viceroy die Peers auf die Knoten eines Butterfly-Graphen zu
setzen. Jeder Peer wählt zufällig eine Ebene i und einen zufälligen Binärstring S und nimmt diesen Platz
ein. Hierzu ist es aber notwendig, den Logarithmus der Knotenanzahl (log n) zu kennen und Mechanismen
vorzusehen, falls der Butterfly-Graph nicht vollständig gefüllt ist (Das ist insbesondere dann der Fall, wenn
n nicht die Form k · 2k hat.
Viceroy erreicht dies durch eine Kombination von drei Strukturen:
1. Einen doppelt verketteten Ring für alle Peers. Dieser verknüpft ähnlich wie der Ring von Chord alle
Peers und sorgt für einen elementaren Zusammenhalt. Die Reihenfolge der Peers auf diesen Ring ist
nicht wichtig. Es wird auch nicht für Such-Operationen verwendet.
2. Für jede der log n Ebenen wird ein doppelt verketteter Ring angelegt. Hierfür wählt jeder der Peers
zufällig eine Ebene und dann eine zufällige Zahl aus dem reellen Intervall [0, 1). Die ersten log n Ziffern der Binärdarstellung dieser Zahl x bestimmen dann (in etwa) die Position des Peers im ButterflyGraphen.
3. Schließlich kommen noch die eigentlichen Butterfly-Kanten hinzu: Hat ein Peer die Ebene i und dort
die Zufallszahl x gezogen, dann hat er vier Zeiger (für k = log n). Siehe hierzu Abbildung 3.41.
• Einen zum Nachfolger-Peer (auf dem Ring) der Adresse (i + 1 mod k, x) (Senkrechte Kante)
• Einen Zeiger zum Nachfolger-Peer (auf dem Ring) der Adresse (i+1 mod k, x+2i ) (Diagonale
Kante), falls x + 2i ≥ 1 ist, wird der Nachfolge-Peer von (i + 1 mod k, x + 2i − 1) genommen
• Einen Zeiger zum Vorgänger (auf dem Ring) von (i − 1 mod k, x) (Senkrechte Rückwärtskante)
• Einen Zeiger zum Vorgänger (auf dem Ring) von (i − 1 mod k, x − 2i ) (Senkrechte Rückwärtskante) (und entsprechend der Vorgänger von (i − 1 mod k, x − 2i + 1), falls x − 2i < 0).
52
Abbildung 3.41: Die Viceroy-Umsetzung eines Butterfly-Graphen aus [MNR02]
Berechnung von log n Für Viceroy ist es notwendig, die Größe von log n zu kennen. Für ein Peer-toPeer-Netzwerk ist das keine triviale Aufgabe. Schließlich verlassen und betreten Peers ständig das Netzwerk ohne dass es lokal wahrgenommen wird.
Eine einfache Methode zur Bestimmung von log n bis auf ± log log n + O(1) erhält man indem man
den Abstand d zu dem k-nächsten Nachbarn auf einem Ring wie bei Chord betrachtet. Im Erwartungs wert
ist dieser Abstand k/n. Man kann zeigen, dass er davon mit hoher Wahrscheinlichkeit nur um einen Faktor
von O(log n) abweicht (durch Verwendung der Chernoff-Schranke). Damit ist log d − log k bis auf den
additiven Term log log n + O(1) eine Approximation von log n. Wählt man k = c log n, dann wird der
additive Fehlerterm mit hoher Wahrscheinlichkeit nur noch eine Konstante. Wir werden später im Kapitel
Datenaggregation Methoden kennen lernen, wie man n exakt in einem Peer-to-Peer-Netzwerk berechnen
kann.
3.8.3
Einfügen eines Peers
Ein neuer Peer an einer beliebigen Stelle des Rings eingefügt. Wir nehmen an log n sei bekannt. Dann
wählt der Peer i zufällig aus {0, . . . , log n − 1}. Nun sucht der Peer durch ein Lookup ausgehend vom
Ringnachbarn seiner Ebene die gewünschten Peers. Er fügt dann die oben beschreiben Zeiger ein. Ebenso
werden die entsprechenden Peers der benachbarten Ebenen informiert ihre Zeige neu zu justieren.
Die Laufzeit und Anzahl der Nachrichten sind dann im wesentlichen die Zeit für ein LookUp mit
O(log n) und das Finden der Nachfolger und Vorgänger mit Zeit O(log n).
3.8.4
Lookup
In Abbildung 3.42 ist der Lookup-Algorithmus von Viceroy beschrieben. Er beruht auf der Annahme, dass
auf jedem der Ebenen im Butterfly-Graph keine größeren Abstände als log2 n/n zwischen den Knoten
auftreten. Ist das nicht der Fall, besteht die Möglichkeit, dass er nicht zum Ziel führt. Die logarithmische
Laufzeit ist in Gefahr, falls in auf den Ebenen in einer Strecke von (log n)2 /n sich mehr als O(log n) Peers
befinden.
Lemma 7 Mit hoher Wahrscheinlichkeit benötigt der Lookup in Viceroy O(log n) Zeit und Nachrichten.
53
Viceroy-Suche(Peer (i, x) erhält Suchanfrage nach (j, y)
begin
2
if i = j and |x − y| ≤ (lognn) then
Leite Suchanfrage auf näheren Ringnachbar in Ebene i weiter
else
if y weiter rechts als x + 2i then
Leite Suchanfrage and Nachfolger von (i + 1, x + 2i ) weiter
else
if Nachfolger Z von (i + 1, x) weiter rechts als x then
Suche auf dem Ring i + 1 von Z aus einen Knoten (i + 1, p) mit p ≤ x
fi
fi
fi
end.
Abbildung 3.42: Der Suchalgorithmus für die Viceroy-Datenstruktur
Dieses Lemma folgt aus den oben beschrieben Abstandseigenschaften, die direkt aus der Anwendung
der Chernoff-Schranke folgen (wenn man annimmt, dass Peers nur eingefügt worden sind).
3.8.5
Eigenschaften von ViceRoy
Viceroy besitzt durch die Konstruktion konstanten Ausgrad und erwartet konstanten Eingrad. Der Durchmesser ist O(log n) und die Suche kann davon profitieren.
Durch die Struktur des Butterfly-Graphen kann die Kommunikationslast sehr gut balanciert werden,
weil zum einen beliebige andere Graphen sehr gut eingebetteten werden können und andererseits die Bisektionsweite mit n/ log n sehr groß ist. Sie ist wie folgt definiert.
Definition 2 Sei G = (V, E) ein ungerichteter Graph und V1 , V2 ⊂ V und V1 ∪˙ V2 = V . Bezeiche
Ext(V1 , V2 ) die Anzahl der Kanten, die den Schnitt (V1 , V2 ) kreuzen. Dann ist die Bisektionsweite ρ(G)
definiert als:
ρ(G) = min{Ext(V1 , V2 ) | V = V1 ∪˙ V2 und | |V1 | − |V2 | | ≤ 1}
Zwischen der Größe Bisektionsweite und der Fähigkeit Congestion-effizientes Routing bereitzustellen
besteht eine sehr Korrelation (Andererseits teilen auch andere Graphen, wie etwa DeBrujin-Graphen diese
Eigenschaft).
Die Sache mit dem Grad Zwar ist der Ausgrad eines Knoten mit zwei Kanten für den allgemeneinen
Ring, zwei Kanten für jede Ebene des Butterfly-Graphen und vier Kanten für die Butterfly-Kanten genau
acht. Aber der Eingrad ist nur dann konstant wenn die Knoten auf den Ebenen des Butterfly-Graphen
perfekt verteilt werden, d.h. Abstand zum Nachbarn ist bis auf einen konstanten Faktor (log n)/n. Wählt
man aber die Positionen auf den Ring zufällig kommt auch ein um den Faktor log n erhöhter Abstand mit
konstanter Wahrscheinlichkeit vor. Damit kommt mit konstanter Wahrscheinlichkeit ein logarithmischer
Ein-Grad vor.
Also ist ViceRoy nicht besser als das einfacher Koorde-Netzwerk (außer dass ViceRoy früher erschien
als Koorde).
Dieses Problem, dass große Abstände auf den Viceroy-Ring viele eingehende Links anziehen und die
Nachbarn in der nächsten Ebene mit kleineren Abstände den Ein-Grad erhöhen kann man nur Lösen, indem man die Peers nicht rein zufällig einordnet. Die Lösung bringt das Prinzip der vielfachen Auswahl
(principle of multipe choice).
54
3.8.6
Das Prinzip der mehrfachen Auswahl (principle multiple choice)
Statt eine zufällige Position in der Ebene des Butterfly-Rings zu wählen, wählt jeder Peer c log n zufällige
Positionen. Für jede dieser Positionen p(j) wird der Abstand a(j) zwischen den potentiellen linken und
rechten Nachhbarn gemessen. Nun wird der Peer an der Position p(j ∗ ) genau in der Mitte der vorhandenen
Peers eingefügt, für welche a(j ∗ ) maximal ist, d.h. a(j ∗ ) ≥ a(j) für alle j.
Lemma 8 Mit hoher Wahrscheinlichkeit ist der Abstand zweier Peers in den log n Viceroy-Ringen nur um
einen konstanten Faktor größer oder kleiner als der durchschnittliche Abstand O((log n)/n).
Beweis: Wir werden dieses Lemma beweisen, indem wir nur einen Ring betrachten und dort n Peers nach
diesem Prinzip einfügen. Man kann mit Hilfe der Chernoff-Schranke nachweisen, dass jeder der log n
Ringe mit hoher Wahrscheinlichkeit zwischen n/(2 log n) und 2n/(log n) Peers erhält. Dann kann man
für jeden Ring das nun folgende Lemma 9 anwenden.
Lemma 9 Nach Einfügen von n = 2k (für k ∈ N) Peers auf einem Ring [0, 1) unter Verwendung des
1 1
, n und n2 übrig.
Prinzips der mehrfachen Auswahl, bleiben nur Intervalle der Größe 2n
Beweis: Da die Intervall immer genau in der Mitte geteilt werden, entstehen als Intervallgrößen immer nur
1
Zweier-Potenzen. Es genügt also zu zeigen, dass zum einen nicht Intervalle kleiner als 2n
und nicht größer
2
als n entstehen.
1. Teil: Mit hoher Wahrscheinlichkeit gibt es kein Intervall länger als 2/n:
Wir beweisen zunächst folgendes Lemma:
Lemma 10 Sei das längste Intervall c/n (c kann von n abhängig sein). Dann sind nach Einfügen
von 2n/c Peers alle Intervalle kürzer als c/(2n) mit hoher Wahrscheinlichkeit.
Beweis: Wir betrachte ein Intervall der Länge c/n. Mit Wahrscheinlichkeit c/n wird ein solches
Intervall von einem Peer getroffen Angenommen, es werden für jeden Peer t log n Intervalle untersucht. Die erwartete Anzahl von Treffern X eines solchen Intervalls ist also
E[X] =
c 2n
·
· t log n = 2t log n .
n c
Die Chernoff-Schranke liefert dann für δ ∈ (0, 1):
P[X ≤ (1 − δ)E[X]] ≤ n−δ
2
t
.
Ist δ 2 t ≥ 2 werden all diese Intervalle mindestens 2(1 − δ)t log n-mal getroffen. Man muss aber
auch berücksichtigen, dass jedes Mal wenn ein Intervall geteilt wird, die t log n zusätzlichen Treffer
keine Teilung bewirken können.
Wir wählen also 2(1 − δ) ≥ 1 und erhalten dass jedes der Intervalle der Mindestlänge c/n mit hoher
Wahrscheinlichkeit geteilt werden.
Wendet man dieses Lemma sukzessive für c = n/2, n/4, ..., 4 an, folgt der erste Teil des Beweises.
2. Teil: Kein Intervall entsteht, das kleiner ist als 1/(2n).
Die Gesamtlänge aller Intervalle der Größe 1/(2n) ist vor jedem Einfügen höchstens n/2. Damit
wird bei c log n Versuchen, jedes so kleine Intervall höchstens mit Wahrscheinlichkeit 21 getroffen. Die Wahrscheinlichkeit, dass unter clogn Intervallen nur solche gewählt werden, ist höchstens
2−c log n = n−c . Damit wird für c > 1 mit nur polynomiell kleiner Wahrscheinlichkeit ein Intervall
der Länge 1/(2n) weiter unterteilt.
55
(x,x/2)
0
1
(x,1/2 + x/2)
Abbildung 3.43: Links- und Rechts-Kanten des kontinuierlichen Graphen des Distance-Halving-Peer-toPeer-Netzwerks.
3.8.7
Resumee
Der Butterfly-Graph ist für Routing besonders gut geeignet. Er ermöglicht viele bekannte erprobte gute
Algorithmen und eine ganze Reihe von Arbeiten hat sich gerade mit solchen Netzwerktypen beschäftigt.
Viceroy war das erste Peer-to-Peer-Netzwerk mit konstanten Ein- und Ausgrad.
Aber die mehrfache Ringstruktur ist relativ kompliziert. Wendet man das Prinzip der mehrfachen Auswahl an, so vergrößert sich der Aufwand zum Einfügen eines Peers auf O(log2 n). Dieses Prinzip der
mehrfachen Auswahl kann aber auch bei anderen Netzwertypen, wie etwa bei DeBrujin-Netzwerken angewendet werden. Diese sind wesentlich einfacher und besitzen die gleichen vorteilhaften Netzwerkeigenschaften wie Butterfly-Netzwerke.
Dies waren wohl die Gründe, warum (zwei der drei) Autoren selbst ein anderes Peer-to-Peer-Netzwerk
als Nachfolger von Viceroy vorschlugen, dass sie Distance Halving nannten.
3.9
Distance Halving
Im Jahre 2003 stellten Moni Naor und Udi Wieder Distance Halving [NW03] vor. Ziel war es nicht nur ein
weiteres Peer-to-Peer-Netzwerk, sondern es wurde besonderen Wert auf dem Prinzip der kontinuierlichen
Graphens gelegt, der eigentlich schon CAN und Chord zu Grunde lag. Hier aber erstmals formalisiert
wurde.
3.9.1
Kontinuierliche Graphen
Genauso wie man diskrete Graphen definiert über als Kantenmenge über einer endlichen Knotenmenge,
kann man auch kontinuierliche Graphen definieren. Nur ist hier schon die Knotenmenge unendlich groß.
Als anschauliches Beispiel eines kontinuierlichen Graphs kann schon der in Distance-Halving verwendete Graph dienen. Die Knotenmenge V = [0, 1] ist das kontinuierliche Intervall der Zahlen von 0 bis 1.
Die Kantenmenge E ⊂ V × V bildet eine ebenfalls kontinuierliche Paarmenge zwischen diesen Knoten.
Es werden zwei Kanten (siehe Abbildung 3.43) verwendet:
• Die Links-Kanten: x, x2 für x ∈ [0, 1] und
• die Rechts-Kanten: x, 12 + x2 für x ∈ [0, 1] .
Hinzu kommen
noch die entsprechenden Kanten in der Gegenrichtung, das sind für x ∈ [0, 1] die
Kanten x2 , x und 21 + x2 , x .
Der Übergang vom kontinuierlichen zum diskreten Fall Natürlich lassen sich solche kontinuierliche
Graph nicht direkt verwenden. Daher muss vom kontinuierlichen zum diskreten Fall ein Übergang gefunden werden. Hierzu wird eine Partitionierung von V in Teilintervalle durchgeführt und der diskretisierte
Graph hat eben diese Intervalle als Knotenmenge und für die Kantenmenge gilt: Eine Kante zwischen
Teilintervall A und B existiert genau dann, falls es ein x ∈ A und y ∈ B gibt, so dass (x, y) Kante des
56
(x,x/2)
0
1
(x,1/2 + x/2)
(x,x/2) 0
1
(x,1/2 + x/2)
Abbildung 3.44: Durch die Diskretisierung eine kontinuierlichen Graphen ensteht das Distance-HalvingNetzwerkt
kontinuierlichen Graphs sind. Die Teilintervalle selber entstehen durch sukzessive Halbierung bestehender
Intervalle.
Das durch Diskretisierung aus dem oben beschriebenen kontinuierlichen Graph entstehende Netzwerk
wird Distance-Halving-Netzwerk genannt (warum sehen wir gleich), siehe Abbildung 3.44. Zusätzlich
werden noch Zeiger zwischen benachbarten Teilintervallen eingefügt.5
Wenn man nun zwei Punkte x, y im kontinuierlichen Graph betrachtet, so zeigen die Links-Kanten
auf zwei Punkte x/2, y/2 deren Abstand
x y zu deinander nur noch halb so groß ist wie zuvor. Vorher war er
nämlich d = |x − y| und
danach
1 x 12 − y2 = 2d . Genaus verringert sich der Abstand der Punkte auf den die
Rechts-Kanten zeigen: 2 + 2 − 2 − 2 = 2 . Wegen dieser Halbierung des Distanz erhielt des Peer-toPeer-Netzwerk seinen Namen Distance-Halving. Für die entsprechenden Rückwärtskanten verdoppelt sich
dann entsprechend die Distanz.
Aus dieser Distanz-Eigenschaft folgt sofort, dass der Grad von Distance-Halving konstant ist, falls das
Verhältnis aus größten und kleinsten Intervall konstant ist, wie Dies kann beim Einfügen durch das Prinzip der mehrfachen Auswahl (multiple choice principle), welches wir bei Viceroy kennen gelernt haben,
erreicht werden.
3.9.2
Einfügen von Peers in Distance-Halving
Der Aufbau von Distance-Halving geschieht wie folgt. Neue Peers werden den Teilintervallen zugewiesen, die aus einer Testmenge von O(log n) vielen Intervallen am größten sind. Die Grüße von n ergibt
sich übrigens bis auf einen konstanten Faktor schon aus dem ersten Intervall, dass der Peer testet (mit
hoher Wahrscheinlichkeit). Dies folgt auch aus dem Prinzip der mehrfachen Auswahl. Schließlich hat das
1
größte Intervall mit hoher Wahrscheinlichkeit die Länge n2 und das Kleinste die Länge 2n
(falls n eine
Zweierpotenz ist).
Die Teilintervalle werden jeweils durch ein Lookup lokalisiert. Dieser kostet wie wir gleich sehen
werden jeweils O(log n) Sprünge und Nachrichten. Nachdem das Intervall gefunden worden ist, werde
zuerst die Verkettungen mit den Nachbar-Intervallen vorgenommen und dann aus den Zeiger der Peers
der Nachbar-Intervalle die neuen Zeiger ausgewählt. Entsprechend aktualisieren die Peers der NachbarIntervalle ebenfalls ihre Zeiger.
Dadurch erhalten wir ein Peer-to-Peer-Netzwerk mit konstantem Ein- und Ausgrad und logarithmischen Durchmesser, wie wir gleich sehen werden.
5 So
gesehen ist das CAN-Netzwerk die Diskretisierung des zwei-dimensionalen Quadrats [0, 1]2 ohne jegliche Kanten.
57
Distance-Halving-Lookup(Start, Ziel)
begin
if Start und Ziel benachbart then
Leite Nachricht von Start nach Ziel
else
if Start ist links von Ziel then
Neuer-Start = Links-Zeiger(Start)
Neues-Ziel = Links-Zeiger(Ziel)
else
Neuer-Start = Rechts-Zeiger(Start)
Neues-Ziel = Rechts-Zeiger(Ziel)
fi
Sende Nachricht von Start nach Neuer-Start
Distance-Halving-Lookup(Neuer-Start, Neues-Ziel)
Sende Nachricht von Neues-Ziel nach Ziel
fi
end.
Abbildung 3.45: Der Suchalgorithmus für das Distance-Halving-Netzwerk
Neuer
Start
Neues
Ziel
Start
Start
Ziel
Ziel
Neuer
Start
Neues
Ziel
Abbildung 3.46: Rekursiver Lookup-Aufruf von Abbildung 3.47: Rekursiver Lookup-Aufruf von
Distance-Halving falls der Start-Peer sich links vom Distance-Halving falls der Start-Peer sich rechts
Ziel-Peer befindet
vom Ziel-Peer befindet
3.9.3
Lookup in Distance-Halving
Der Lookup-Algorithmus geschieht rekursiv und ist in Abbildung 3.45 dargestellt.
In Abbildung 3.46 ist dargestellt, was passiert, falls der Start-Peer sich links vom Ziel-Peer befindet
(und sie nicht benachbart sind). Dann verkürzt sich durch den beidseitigen Links-Sprung die Entfernung
zwischen dem neuem Start-Peer und dem neuen Ziel-Peer auf die Hälfte. Hierzu werden nur zwei zusätzliche Sprünge investiert. Analoges geschieht im Fall, falls der Start-Peer sich rechts vom Ziel-Peer befindet,
siehe Abbildung 3.47.
Da durch die Abbildung der Links-Kanten der Start-Ziel-Anstand halbiert wird und da alle Intervalle
sich nur um den Faktor vier unterscheiden, benötigt der Lookup-Algorithmus nur 2+log n Rekursionen um
eine Nachricht auszuliefern. Dann kann durch einen Schritt auf dem Ring der aktuelle Ziel-Peer erreicht
werden. Jeder Rekursionsschritt benötigt zwei Sprünge und dadurch ergibt sich der Aufwand des Lookups
durch 2 log n + 5:
Lemma 11 Mit hoher Wahrscheinlichkeit benötigt der Lookup in Distance-Halving-Netzwerken höchstens
2 log n + 5 sequentielle Nachrichtenübertragungen.
Congestion beim Lookup Betrachtet man den Lookup-Algorithmus etwas genauer, so war die Bedingung, ob der Start-Peer links von Ziel-Peer liegt, gar nicht notwendig. Man diesen Algorithmus durch den
58
Distance-Halving-Random-Lookup(Start, Ziel)
begin
if Start und Ziel benachbart then
Leite Nachricht von Start nach Ziel
else
if Münze fällt auf Zahl then
Neuer-Start = Links-Zeiger(Start)
Neues-Ziel = Links-Zeiger(Ziel)
else
Neuer-Start = Rechts-Zeiger(Start)
Neues-Ziel = Rechts-Zeiger(Ziel)
fi
Sende Nachricht von Start nach Neuer-Start
Distance-Halving-Lookup(Neuer-Start, Neues-Ziel)
Sende Nachricht von Neues-Ziel nach Ziel
fi
end.
Abbildung 3.48: Congestion-optimierter Suchalgorithmus für das Distance-Halving-Netzwerk
in Abbildung 3.48 ersetzten, ohne dass zusätzliche Kosten entstehen. Hier wird log n + O(1) mal zufällig
den Links- oder Rechts-Kanten gefolgt.
Analog zu Valiants Routing-Ergebnis auf dem Hyper-Würfel kann man hier zeigen, dass die Congestion
eines Knoten höchstens O(log n)-mal höher ist, als die maximal zu sendende oder zu empfangene Menge
von Nachrichten eines Peers (Das selbe Resultat kann man übrigens für Viceroy ebenfalls zeigen).
3.9.4
Resumee Distance-Halving
Mit Distance-Halving haben wir zum Abschluss der Reiher skalierbarer Peer-to-Peer-Netzwerk ein einfaches effizientes Peer-to-Peer-Netzwerk kennen gelernt. Mit hoher Wahrscheinlichkeit hat Distance-Halving
sowohl konstanten Ein-und-Ausgrad, logarithmischen Durchmesser, verfügt über Methoden zur Lastbalancierung und logarithmischen Lookup. Die Einfüge-Operation benötigt O(log2 n) Hops und Nachrichten.
Ferner wurde hier erstmals das Prinzip des Übergangs von kontinuierlichen zu diskreten Graphen formalisiert. Tatsächlich haben wir es in der einen oder anderen Form schon in Chord, Koorde, ViceRoy und
nicht zuletzt auch CAN kennen gelernt.
Folgerungen aus Viceroy und Distance-Halving Das Prinzip der mehrfachen Auswahl (multiple choice
principle) kann auch auf andere Peer-to-Peer-Netzwerke angewendet werden. So kann man damit bei Chord
den Ein- und Ausgrad auf O(log n) optimieren, während Einfüge-Operationen benötigt weiterhin Aufwand
O(log2 n) benötigen. Auch bei Koorde kann dieses Prinzip angewendet werden. Dann ist dort der Ein- und
Ausgrad konstant und die Einfüge-Operationen benötigten Aufwand O(log2 n) 6
6 Bei
näherer Betrachtung zeigt sich außerdem, dass dann Koorde und Distance-Halving dann isomorph sind
59
60
Kapitel 4
Epidemische Algorithmen und
Datenaggregation
10.
VorIn diesem Kapitel werden wir uns mit zwei sehr verwandten Methoden zur Informationsverteilung in lose lesung
organisierten Kommunikationsnetzwerken . Diese werden hier unterschieden als Epidemische Algorithmen 21.06.2004
und Datenaggregation. Bei näherer Betrachtung handelt es sich hier nur um die diskrete und kontinuierliche
Ausprägung des selben algorithmischen Prinzips.
4.1
Epidemische Algorithmen
Epidemische Algorithmen werden bisher (nach Wissen der Autoren) kaum in Peer-to-Peer-Netzwerken
eingesetzt. Trotzdem sind sie eine sehr elegante und effiziente Methode zur Informationsausbreitung und
sollten den Informatiker, der Peer-to-Peer-Netzwerk-Algorithmen entwickelt als wertvolles Werkzeug zur
Hand stehen. Bisher wurden epidemische Algorithmen im Bereich der replizierten Datenbanken eingesetzt.
4.1.1
Replizierte Datenbanken
Die Ausgangssituation von [DGH+ 87] ist hierbei die Folgende. Knoten eines Kommunikationsnetzwerks
sind durch dichtes Netzwerk verbunden, wobei einzelnen Knoten und Netzwerkverbindungen (Kanten )
ausfallen können. Die Aufgabe der Knoten ist es lokal ermittelte Information durch das Netzwerk an alle
zu verteilen. Dabei ist die genaue Verbindungsstruktur unklar und auch die Teilnehmerlisten sind zwar allen
im Prinzip bekannt, aber durch die Fluktuation der Teilnehmer und durch ungünstige Verbindungsausfälle
kann es sein, dass diese Liste lokal von der tatsächlichen Teilnehmerliste abweicht.
Replizierte Datenbanken (replicated database) sind im Idealfall exakte Kopien einer Datenbank an
verschiedenen Orten. Neue Einträge in diese Datenbanken entstehen lokal und daher ist es notwendig, den
Datenbestand in bestimmten Zeitintervallen anzupassen, damit die Konsistenz der replizierten Datenbanken erhalten wird, siehe auch Abbildung 4.1.
Ein Beispiel für die Anwendung von replizierten Datenbanken sind z.B. Name-Server im Internet.
Wenn neue Rechner ihre Host-ID und IP-Adresse ihrem Router bekanntgeben, ist es nötig, dass diese
Information domain-weit zur Verfügung steht. Dafür muß diese Information verbreitet werden. Ferner ist
es möglich, dass ganze Teilnetzwerke sich an- oder abkoppeln. Außerdem sind nicht alle Rechner, die mit
der Verwaltung von diesen Rechnernamen vertraut sind, nicht allen anderen Rechnern bekannt.
Ein ideales Verfahren soll also robust und dezentral diese Informationsverbreitung erledigen, auch wenn
Netzwerkverbindungen oder Rechner ausfallen.
In [DGH+ 87] werden folgende Lösungen diskutuiert:
• Unicast
61
Abbildung 4.1: Replizierte Datenbanken sollen den gleichen Datenbestand verteilt unterhalten ohne dass
Knoten und Kantenausfälle dies beeinträchtigen
Hier wird jede neue Information an alle Standorte der replizierten Datenbank direkt verschickt. Problematisch ist der Fall, wenn nicht alle Standorte bekannt sind, oder die Standorte zeitweise nicht
erreichbar sind.
• Anti-Entropie
In diesem Verfahren gleichen von Zeit zu Zeit zwei Datenbankenstandorte ihren gesamten Informationsstand aus und bereinigen zeitweise Unterschiede. Die Auswahl dieser zwei Standorte kann
zufällig, oder auch nach einen bestimmten Auswahlschema ablaufen.
Dieses Verfahren ist sehr zuverlässig, indem jede Information mit der Zeit in allen lokalen Datenbanken vorhanden ist. Dagegen kann es einige Zeit dauern bis dieser Zustand erreicht ist. Das Hauptproblem bei dieser Methode ist der Kommunikationsoverhead für das Überprüfen bereits allseits
bekannter Daten.
• Epicast
Epicast setzt sich aus Epidemie und Broadcast zusammen. Hier nutzt man einen sogenannten epidemischen Algorithmus zur Verbreitung der Information. Hierfür wird in einem geeigneten Kontaktmodell die lokal neu entstandene Information als Virus (oder auch Gerücht) interpretiert. Ähnlich
wie ein Virus eine ganze Population anstecken kann oder wie ein Gerücht sich in einer Menschenmenge ausbreitet, so soll die Information eines Updates sich im Netzwerk ausbreiten. Damit ist die
Durchdringung des Netzwerkes garantiert, solange es zusammenhängend ist. Hierbei wird für jede
Änderung ein neues Gerücht erzeugt, dass dann im Netzwerk verbreitet wird. Hierzu nehmen in einem geeigneten Kommunikationsmodell (dies wird gleich vorgestellt) zwei Partner jeweils Kontakt
auf und einer (oder beide) teilen dem anderen ihre Aktualisierungen mit. Die Verbreitung ist sicher
gestellt, wenn mit hoher Wahrscheinlichkeit ein Gerücht allen mitgeteilt worden ist. Wir konzentrieren uns im weiteren mit der Verbreitung eines einzelnen Gerüchts. Wenn nämlich dieses schon mit
hoher Wahrscheinlichkeit effizient und umfassend verbreitet worden ist, so geschieht das im allgemeinen mit den anderen Gerüchten auch.
Das Problem des Kommunikationsoverhead entsteht dann, wenn die Virus-(Gerüchte-)Verbreitung
nicht gestoppt wird. Dann wird immer wieder die selbe neue information zwischen den Knoten hin
und her gereicht. Daher ist die Wahl eines geeigneten Terminierungsmechanismus notwendig, damit
die Anzahl unnötig versandter Informationen eingedämmt wird.
4.1.2
Mathematische Modellierung von Epidemien
In der Wissenschaft beschäftigt man sich aus Leid geplagter Erfahrung schon sehr langen mit Epidemien.
So schreibt Hippokrates ca 400 v.Chr. Über Epidemien. Die lange Reihe von Untersuchungen im medizinischen Bereicht beinhailtet Arbeiten von John Graunt (1662), Louis Pasteur, und Robert Koch (19. Jhd.). In
62
Abbildung 4.2: Informationsverbreitung im Push-Modell
der Mathematik beschäftigte sich schon Daniel Bernoulli (1760) mit der Modellierung von Epidemien. Ein
einfaches Epidemie-Modell wurde im Jahr 1911 von Ross entwickelt, das dann im Jahr 1927 von Kermack
und McKendrick verallgemeiner wurde. Wir beschäftigen uns hier mit diesem sogenannten Push-Modell,
dass hinsichtlich des Erwartungswerts von Pittel [Pit87] exakt charakterisiert worden ist. Die Ergebniss
hinsichlich des Push-, Pull- und Push&Pull-Modells gehen auf [KSSV00] zurück.
4.1.3
Epicast
Wie bereits erwähnt wird eine Aktualisierung zum Gerücht, dass effizient verbreitet werden muss. Hierbei
interessieren wir uns für zwei Komplexitätsmaße: Für die Zeit und für die Anzahl der Nachrichten, die
benötigt werden, um das Gerücht mit hoher Wahrscheinlichkeit allen zugänglich zu machen.
Diese Art des Epicasts wurde in [DGH+ 87] eingeführt und umfassend in [KSSV00] analysiert, wobei in
letzterer Arbeit ein effizienterer Terminierungsalgorithmus für Gerüchte (Der Median-Counter-Algorithmus)
vorgestellt wurde. Eine solche Terminierung von Gerüchten ist notwendig, um die ununterbrochene Verteilung dieses Gerüchts zu verhindern. Ist nämlich ein Gerücht alt und damit allen bekannt, sollten alle
Teilnehmer zum Schluss kommen, die Weiterverbreitung zu stoppen. Hierbei handelt es sich aber keineswegs um ein triviales Problem, da allen Teilnehmer nicht unbedingt klar ist, wer an dieser Verbreitung
teilnimmt und wer das Gerücht schon kennt.
4.1.4
Anruf-Model (Random Call)
Das hier verwendete Kommunikationsmodell wird Anruf-Modell (Random Call)-Modell genannt. Es liefert das Grundgerüst, um die Kommunikationsmethoden Push, Pull, und Push&Pull darzustellen.
Die Kommunikation findet (der Einfachheit halber) synchronisiert in Runden statt. In jeder Runde
kontaktiert jeder Teilnehmer einen zufällig gewählten anderen Teilnehmer, gleichwahrscheinlich und unabhängig gewählt aus der Menge aller Teilnehmer. Derjenige der diese Wahl ausführt wird der Anrufer
genannt. Jener, der das Ziel dieser Wahl ist, wird der Angerufene genannt. In jeder Runde ist jeder Teilnehmer ein Anrufer, kann aber auch zugleich (und von mehreren) angerufen werden. Nun geschieht je nach
Kommunikationsmethode folgendes:
• Im Push-Modell teilt der Anrufer sein Gerücht dem Angerufenen mit. In der Gegenrichtung wird
kein Gerücht durchgegeben1 , siehe Abbildung 4.2.
• Im Pull-Modell teilt der Angerufene sein Gerücht dem Anrufer mit. Auch hier wird das Gerücht nur
einer Richtung mitgeteilt2 , siehe Abbildung 4.3.
• Im Push&Pull-Modell tauschen beide ihre Gerüchte aus, siehe Abbildung 4.4.
1 Es
sei denn, zufälligerweise ruft der Angerufene auch den Anrufer an
natürlich der Anrufer wird auch von Angerufenen angerufen
2 Außer
63
Abbildung 4.3: Informationsverbreitung im Pull-Modell
Abbildung 4.4: Informationsverbreitung im Push&Pull-Modell
In jedem Fall wird ein Gerücht nur über eine Station weitergeteilt. Das heisst insbesondere, wenn im
Push-Modell Peer A Peer B und gleichzeitig Peer B Peer C anruft. Dann kann A sein Gerücht nur bis B
weiterreichen und nicht etwa bis Peer C durchreichen.
Umsetzung des Anruf-Modells in Peer-to-Peer-Netzwerken Epidemische Algorithmen werden schon
länger betrachtet als Peer-to-Peer-Netzwerke (1987 versus 1999). Grundlage des Anrufmodells ist die zufällige Adressierung. Viele Peer-to-Peer-Netzwerke unterstützen dies sehr effizient. So kann man zum Beispiel in Gnutella dies durch einen sogenannten Random Walk erreichen. Hier wird von jedem Peer ein
zufälliger Nachfolger-Peer gewählt und sofort, bis eine vorgegebene Schrittweite erreicht ist.
In CAN kann man einen zufälligen Peer erreichen, falls das CAN-Netzwerke über mindestens zwei
Realitäten verfügt. Dadurch wird ein zufälliger Peer in konstant vielen Sprüngen erreicht werden. Da man
in jeder Runde einen neuen zufälligen Peer benötigt, kann man weitere durch mehrere Sprünge in den Realitäten erreichen (Für die nachfolgenden vorgestellten Verfahren genügen Folgen von O(log n) zufällige
Peers, dies kann mit O(log log n) Sprüngen zwischen den Realitäten erreicht werden).
In Chord, Koorde, Viceroy, Distance-Halving, Pastry und Tapestry erreicht man jeweils in log n Sprüngen zu einem unabhängig gewählten gleichwahrscheinlichen Peers, so dass die Operation ebenso teuer ist
wie ein Lookup.
Notation Wir betrachten nur ein Gerücht und nehmen an, dass diese Gerücht in Runde 0 nur einem
Teilnehmer bekannt ist. Die absolute Anzahl aller Teilnehmer, die das Gerücht kennen, bezeichen wir mit
I(t) (wie informiert), wobei t die Rundenanzahl ist, also
I(0) = 1 .
Die Gesamtanzahl aller Teilnehmer sei n und die Anzahl der Teilnehmer, die das Gerücht noch nicht
kennen sei S(t) := n − I(t). Wir beschäftigen uns hier hauptsächlich mit den relativen Häufigkeiten dieser
64
Mengen, nämlich
s(t) =
S(t)
n
Foglich ist zu Beginn i(0) = n1 , s(0) = 1 −
alle Teilnehmer das Gerücht erhalten haben.
i(t) =
und
1
n
I(t)
.
n
und zum Ende sollte i(t) = 1 und s(t) = 0 gelten, damit
Struktur-Eigenschaften des Anruf-Modells Bevor wir uns der Frage zuwenden, wie schnell das Gerücht durch die verschiedenen Kommunikationsmethoden verbreitet werden, betrachten einige StrukturEigenschaften des Anruf-Modells näher. Wir können das Kommunikationsverhältnis zwischen Anrufer und
Angerufenen als gerichteten Graph darstellen, wobei eine Kante vom Anrufer zum Angerufenen gezogen
wird. In jeder Runde wird dieser Kommunikationsgraph durch einen neuen ersetzt.
In einer fest gewählten Runde beobachten wir, dass der Aus-Grad in einem Knoten immer eins ist. Für
den Ein-Grad kann jeder Fall, von keiner eingehender Kante bis dass ein Knoten n eingehende Kanten
(einschließlich einer Schlinge, d.h. einer In-sich-Kante). Diese Fälle treten aber nicht mit gleicher Wahrscheinlichkeit auf.
Der Fall, dass ein Knoten Ein-Grad 0 hat, also kein Anderer ihn anruft, geschieht mit Wahrscheinlichkeit
n
1
,
1−
n
was wie wir bereits wissen, sehr schnell gegen 1e konvergiert. Fast genauso wahrscheinlich ist der Fall, dass
genau eine eingehende Kante in einem Knoten auftritt. Dies geschieht mit Wahrscheinlichkeit
n
1
n
1−
1
n
n−1
=
1−
1
n
n−1
,
was ebenfalls für zunehmendes n schnell gegen 1e konvergiert.
Im Allgemeinen beobachten wir k eingehende Kanten mit Wahrscheinlichkeit
n
n−k
n 1
1
n(n − 1) · . . . · (n − k) 1
1
1
−
=
1
−
.
k nk
n
nk
k!
n
1
. Damit beobachten wir für kleine k für den
Für große n und festes k konvergiert dieser Term gegen ek!
Ein-Grad im wesentlichen eine Poisson-Verteilung mit Erwartungswert 1.
4.1.5
Ausbreitungsverhalten im Push-Modell
Im Anruf-Modell wird in jeder Runde t ein neuer gerichteter Graph Gt = ([n], Et ) betrachtet. In diesem
Graph hat jeder Knoten eine ausgehende Kante, die gleichwahrscheinlich aus der Knotenmenge [n] gewählt
wird. Damit sind auch Schleifen, d.h. Kanten mit gleichen Anfangspunkt und Endpunkt möglich. Die
Weitergabe des Gerüchts wird nun in Runde t entlang einer gerichteten Kante weitergegeben, d.h. jeder
informierte Knoten u in Runde t wählt gleichwahrscheinlich einen Knoten aus [n] als Kontaktpartner v
und informiert ihn.
In Abbildung 4.5 wird die Ausbreitung eines Gerüchts im Push-Modell beispielhaft dargestellt. Für
einen informierten (und infizierenden) Knoten u ∈ I(t) ergeben sich in einer Runde drei Möglichkeiten:
1. Er kontaktiert und informiert als einziger informierter Knoten einen uninformierten Knoten.
2. Er kontaktiert einen bereits informierten Knoten.
3. Er kontaktiert mit anderen informierten Knoten zusammen einen uninformierten Knoten.
Die Wahrscheinlichkeit, dass Fall 2 vorliegt, ist i(t). Die Wahrscheinlichkeit für Fall 3 ist höchstens
i(t), da maximal I(t) Kanten in dieser Runde für die Nachrichtenübertragung verwendet werden. Damit
ist die Wahrscheinlichkeit für Fall 1 mindestens 1 − 2i(t). Diese Überlegung ergibt das folgende Lemma.
65
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
2
3
3
3
3
3
3
3
3
3
3
4
4
4
4
4
4
4
4
4
4
5
5
5
5
5
5
5
5
5
5
6
6
6
6
6
6
6
6
6
6
7
7
7
7
7
7
7
7
7
7
8
8
8
8
8
8
8
8
8
8
9
9
9
9
9
9
9
9
9
9
A
A
A
A
A
A
A
A
A
A
B
B
B
B
B
B
B
B
B
B
C
C
C
C
C
C
C
C
C
C
D
D
D
D
D
D
D
D
D
D
E
E
E
E
E
E
E
E
E
E
F
F
F
F
F
F
F
F
F
F
Abbildung 4.5: Beispielhafte Informationsverbreitung im Push-Modell
Lemma 12 Jeder informierte Knoten informiert unabhängig von den anderen Knoten einen uninformierten Knoten mit Wahrscheinlichkeit von mindestens 1 − 2i(t) (im Push-Modell).
Der Verlauf einer SI-Epidemie im Push-Modell verläuft in zwei verschiedenen Phasen ab:
1. Exponentielles Wachstum
Die Anzahl der informierten wächst bis ein konstanter Anteil informiert ist, in jeder Runde um einen
konstanten Faktor. Gegen Ende dieser Periode schwächt sich dieses Wachstum etwas ab.
Nach Lemma 12 ist die erwartete Anzahl von Nachrichtenübertragungen in der nächsten Runde
gegeben durch:
c(ln n)2
E[i(t + 1)] ≥ 2i(t) − 2i(t)2 ≥ 2i(t) 1 −
.
n
Wir unterscheiden in der exponentiellen Wachstumsphase folgende Teilphasen:
(a) Startphase I(t) ≤ 2c(ln n)3
Hierbei können wir den rechten Faktor getrost vernachlässigen, da wir wissen, dass erst nach
n
c(ln n)3 dieser Faktor eine konstante Auswirkung hat, weil
c(ln n)2
1−
n
n
c(ln n)3
≤
1
.
e
In viel kürzerer Zeit (wenn n ≥ c log c) ist der Term 2t größer als 2c(ln n)2 , nämlich nach
log(2c(ln n)3 ) ≤ 3 + log c + log log n Runden.
Dieser Term beschreibt ganz gut die zu erwartende Rundenzahl, denn die Wahrscheinlichkeit,
dass alle I(t) informierten Teilnehmer nur uninformierte Teilnehmer infizieren ist:
(1 − i(t))I(t) ≥ 1 − i(t)I(t) ≥ 1 −
4c2 (ln n)3
.
n
Damit findet die Verdopplung mit Wahrscheinlichkeit 1 − O( (ln n)
mal 3 + log c + log log n Runden statt.
66
3
log log n
)
n
in jeder der maxi-
(b) Hauptphase: I(t) ∈ [2c(ln n)3 , lnnn ]
Um die Gültigkeit der Verdopplung in jeder Phase mit hoher Sicherheit (d.h. mit Wahrscheinlichkeit 1 − O(n−c ) nachzuweisen, verwenden wir hier eine Chernoff-Schranke:
Pm
Chernoff: Es gilt für unabhängige binäre Zufallsvariablen Xi ∈ {0, 1} und Xm = i=1 Xi
für alle δ ∈ [0, 1]:
δ 2 E[Xm ]
−
2
.
P[Xm ≤ (1 − δ)E[Xm ]] ≤ e
Wir setzen für Xm die Anzahl der Gerüchtübertragungen einer Runde und erhalten daher
−
P[I(t + 1) ≤ (1 − δ)E[I(t + 1)]] ≤ e
Setzen wir nun δ =
sionsgleichung:
1
ln n
δ 2 E[I(t + 1)]
δ 2 2c(ln n)3
2
2
−
2
2
≤ e
≤ n−cδ (ln n) .
erhalten wir die gewünschte Sicherheit. Damit erhalten wir als Rekur-
I(t + 1) ≥ 2I(t)(1 − i(t))(1 − δ)
mit Wahrscheinlichkeit 1 − O(n−c ) .
Der Faktor (1 − i(t))(1 − δ) ≥ 1 − i(t) − δ(t) = 1 − ln2n . Damit ergibt sich nach log n Runden
ein konstanter Faktor von mindestens
log n 23 ln n
2
2
≥ e−3 .
≥ 1−
1−
ln n
ln n
Neben dem Faktor 2log n = n fällt dieser Faktor kaum ins Gewicht.
Wir können also in der Hauptphase mit großer Wahrscheinlichkeit davon aus gehen, dass eine
Verdoppelung stattfindet.
(c) Zwischenphase: I(t) ∈ [ lnnn , n3 ]
Nun kann der Term 2i(t)2 nicht mehr vernachlässigt werden. Zumindestens gilt hier
2
4
2i(t) − 2i(t)2 ≥ 2i(t) − i(t) ≥ i(t) .
3
3
Damit ist noch exponentielles Wachstum vorhanden, wenn auch bezüglich einer kleineren Basis. Mit Hilfe der Chernoff-Schranke läßt sich dieses Wachstum auch mit hoher Wahrscheinlichkeit nachweisen.
Die Dauer dieser Zwischenphase ist sehr kurz, d.h. dauert nur O(log log n) Runden.
2. Sättigung: I(t) ∈ [ n3 , n]
Ist ein konstanter Anteil der Population informiert, stoppt das exponentielle Wachstum. Die Wahrscheinlichkeit,
dass ein uninformierter Knoten in einer Runde überhaupt nicht kontaktiert wird, ist
n
1 − n1 . Für n ≥ 2 ist die Wahrscheinlichkeit also mindestens 41 und höchstens 1e .
Tatsächlich ist aber nur ein konstanter Anteil i(t)
cnaller Knoten informiert und wir erhalten für dieses
Informierungswahrscheinlichkeit p := 1 − n1
die folgenden Schranken.
4−i(t) ≤ p ≤ e−i(t) .
Damit gilt für die erwartete Anzahl der uninformierten Teilnehmer:
1
E[S(t + 1)] = p · S(t) ≤ e−i(t) S(t) ≤ e− 3 S(t) .
Damit schrumpft die Anzahl der uninformierten Teilnehmer exponentiell schnell, wobei die Basis
1
rasch von e− 3 gegen 1e konvergiert.
Ähnlich wie im ersten Fall läßt sich dieses Verhalten durch Anwenden einer Chernoff-Schranke auch
mit hoher Wahrscheinlichkeit für die Zufallsvariablen S(t) und S(t + 1) nachweisen.
67
Abbildung 4.6: Wachstumsphasen im Push-Modell
Damit ist mit hoher Wahrscheinlichkeit das Gerücht nach O(log n) Runden verteilt. Eine vereinfachte
Darstellung dieser verschiedenen Informationsphasen ist in Abbildung 4.6 dargestellt. Für die erwarteten
Rundenanzahl wurde von Pittel folgender Satz beweisen:
Theorem 10 [Pit87] Eine SI-Epidemie im Push-Modell benötigt erwartungsgemäß log2 n + ln n + O(1)
Runden.
Das Pull-Modell
Genauso wie beim Push-Modell wird in jeder Runde t ein neuer gerichteter Graph Gt = ([n], Et ) betrachtet, in welchen jeder Knoten eine ausgehende Kante, die gleichwahrscheinlich aus der Knotenmenge [n]
gewählt wird.
Der Unterschied zum Push-Modell ist, dass die Übertragung entgegen der Kantenrichtung verläuft.
Ist also Kante (u, v) ∈ Et und ist v zum Zeitpunkt t informiert, dann ist u spätestens ab den Zeitpunkt
t + 1 informiert.
Auf den ersten Blick erscheint dieses Modell analog zum Push-Modell. Tatsächlich werden wir aber
große Unterschiede beobachten. Ein Beispiel für eine SI-Epidemie im Pull-Modell ist in Abbildung 4.3
dargestellt.
Die Wahrscheinlichkeit, dass ein uninformierter Knoten in Runde t einen Informierten kontaktiert ist
damit genau i(t) = I(t)/n. Dieses Ereignis ist insbesondere unabhängig von der Informierung anderer
uninformierter Knoten. Damit erhalten wir für den relativen Anteil der informierten Knoten:
S(t) − S(t)i(t)
= s(t) − s(t)i(t) = s(t)(1 − i(t)) = s(t)2 .
n
Für den erwarteten relativen Anteil der informierten bedeutet dies.
E[s(t + 1)] =
E[i(t + 1)] = 1 − s(t)2 = 1 − (1 − i(t))2 = 2i(t) − i(t)2 .
68
0
0
0
0
0
0
1
1
1
1
1
1
2
2
2
2
2
2
3
3
3
3
3
3
4
4
4
4
4
4
5
5
5
5
5
5
6
6
6
6
6
6
7
7
7
7
7
7
8
8
8
8
8
8
9
9
9
9
9
9
A
A
A
A
A
A
B
B
B
B
B
B
C
C
C
C
C
C
D
D
D
D
D
D
E
E
E
E
E
E
F
F
F
F
F
F
Abbildung 4.7: Beispielhafte Informationsverbreitung im Pull-Modell
69
Für die Anfangsphase der Informationsverbreitung, wenn i(t) 1, gilt damit E[i(t + 1)] ≈ 2i(t) .
Damit beobachten wir die folgenden zwei Phasen der Informationsverbreitung:
1. Exponentielles Wachstum: I(t) ∈ [1, n/2]
(a) Startphase: I(t) ≤ 2c(ln n)3
Die Wahrscheinlichkeit, dass ein informierter überhaupt das Gerücht einmal verbreiten kann,
ist
n−1
1
1−
.
n
Dies entspricht einer konstant großen Wahrscheinlichkeit für die Stagnation der Gerüchteverbreitung. Damit ist die Wahrscheinlichkeit, dass die Epidemie log n Runden am Anfang stagniert, ein Polynom mit n−c .
Mit zunehmender Anzahl der informierten Knoten wird die Verdoppelung in jedem Schritt
sogar mit hoher Wahrscheinlichkeit (d.h. mit Wahrscheinlichkeit 1−n−c ) geschehen. Garantiert
ist dies jedoch erst wenn polylogarithmisch viele Knoten informiert sind.
Betrachten wir nur die erwartete Dauer dieser Phase, so läßt sich zeigen, dass sie nur O(log log n)
Runden dauert.
(b) Hauptphase: I(t) ∈ [2c(ln n)3 , lnnn ]
Hier liegt exponentielles Wachstum zur Basis 2 − ln1n mit hoher Wahrscheinlichkeit vor. Die
Analyse dieser Phase mittels einer Chernoff-Schranke ist analog zur Analyse der Hauptphase
des exponentiellen Wachstums im Push-Modell.
(c) Zwischenphase: I(t) ∈ [ lnnn , n2 ]
Das exponentielle Wachstums verlangsamt sich jetzt. Jedoch gilt immer noch
1
3
E[i(t + 1)] = 2i(t) − i(t)2 ≥ 2i(t) − i(t) = i(t) .
2
2
Mittels Chernoff-Schranken läßt sich diese Rekursion auch mit hoher Wahrscheinlichkeit nachweisen.
2. Quadratischen Schrumpfen I(t) ∈ [ n2 , n]
In dieser Phase quadriert sich der auf 21 beschränkte Anteil der uninformierten erwartungsgemäß in
jeder Runde. Fände dieses Quadrierung deterministisch statt, dann wäre nach log log n + 1 Runden
der Anteil kleiner als n1 und somit alle informiert, weil:
2log log n+1
log n
1
1
1
<
=
.
2
2
n
Nun muß man natürlich berücksichtigen, dass die Rekursion nur auf den Erwartungswerten beruht
und dass sich die Abweichungen von diesen mit der Zeit erheblich vergrößern können. In [KSSV00]
wurde aber gezeigt, dass die Epidemie tatsächlich nur O(log log n) benötigt, um alle zu infizieren.
Damit gibt es einen enormen Unterschied im Ausbreitungsverhalten im Push- und im Pull-Modell.
Trotzdem die gleiche Erwartete Anzahl von Kontaktpartnern vorliegt, unterscheidet sich das Ausbreitungsverhalten in der Schlußphase um Größenordnungen. Die erwartete Ausbreitungsdauer einer SI-Epidemie
im Pull-Modell dauert also log n + O(log log n) Runden.
Das Push&Pull-Modell
Kombiniert man Push und Pull, erhält man eine Verbreitung des Gerüchts, welche die Ausbreitungsgeschwindigkeit beider Kontaktmodelle kombiniert. In diesem Modell kann als die Informationsübertragung
sowohl entlang als auch entgegen einer Kante, die mit einem Knoten inzident ist, übertragen werden.
In [KSSV00] wird gezeigt, dass hierbei folgende Phasen auftreten:
70
Abbildung 4.8: Wachstumsphasen im Pull-Modell
0
0
0
0
1
1
1
1
2
2
2
2
3
3
3
3
4
4
4
4
5
5
5
5
6
6
6
6
7
7
7
7
8
8
8
8
9
9
9
9
A
A
A
A
B
B
B
B
C
C
C
C
D
D
D
D
E
E
E
E
F
F
F
F
Abbildung 4.9: Beispielhafte Informationsverbreitung im Push&Pull-Modell
71
Abbildung 4.10: Wachstumsphasen im Push&Pull-Modell
1. Exponentielles Wachstum
(a) Startphase: I(t) ≤ 2c(ln n)3
Push-Kontakte garantieren, dass sich die SI-Epidemie exponentiell schnell ausbreitet. Somit
dauert diese Phase nur log log n + O(1) Runden.
(b) Hauptphase: I(t) ∈ [2c(ln n)3 , lnnn ]
Durch die Kombination der Push und der Pull-Ausbreitung läßt sich mit hoher Wahrscheinlichkeit die Gleichung
1
i(t)
i(t + 1) ≥ 3 − O
ln n
nachweisen.
(c) Zwischenphase: I(t) ∈ [ lnnn , n/2]
Der Anteil der Gerüchte-Übertragungen durch Push-Kontakte nimmt hier verglichen mit den
Pull-Übertragungen ab. Das Wachstum von I(t) verlangsamt sich, bleibt aber immer noch exponentiell.
2. Quadratisches Schrumpfen
Die Push-Übertragungen sind nun kaum noch erfolgreich. Jetzt werden, wie schon im Pull-Modell
beobachtet, alle Teilnehmer in O(log log n) Runden fast ausschließlich mittels Pull-Kontakten informiert
Damit dauert die Informierung aller Teilnehmer im Push&Pull höchstens log3 n+O(log log n) Runden.
72
4.1.6
Eine einfache Terminierungsstrategie
Als effektive und einfache Terminierungsstrategie erweist sich das Alterungskonzept. Jedes Gerücht wird
erweitert um einen Zähler, der mit jeder weiteren Übertragung um eins heraufgesetzt wird. Ist der Zähler
größer als ctrmax , wird das Gerücht nicht weiter verbreitet.
Damit ist die Anzahl der übertragenen Nachrichten natürlich beschränkt durch n · ctrmax , wobei n die
Anzahl der lokalen Datenbankkopien bezeichnet. Problematisch ist die Wahl von ctrmax . Wählt ctrmax
zu hoch, werden mehr Nachrichten als notwendig versandt, während eine zu kleine Wahl das Risiko birgt,
dass nicht alle Knoten informiert werden. Insbesondere ist die Wahl abhängig von dem Kontaktmodell der
Gerüchteverbreitung, die hier vom Datenbankdesigner frei gewählt werden kann.
• Push-Modell
Wählt man das Push-Modell, so muß man ctrmax ≥ log2 n + c ln n wählen, wobei mit zunehmenden konstanten Faktor c > 1 die Sicherheit der Information aller Knoten zunimmt. Für eine geeignete
Wahl von c werden alle Knoten mit hoher Wahrscheinlichkeit informier, d.h. mit Wahrscheinlichkeit
1 − n−O(1) . Die Nachrichtenmenge ist dann O(n log n).
• Pull-Modell
Damit alle Teilehmer mit hoher Wahrscheinlichkeit informiert werden, ist die Startphase des exponentiellen Wachstums kritisch. Hier zeigt sich, dass eine Wahl von ctrmax ∈ c logn mit c > 1
notwendig ist, obwohl erwartungsgemäß alle Knoten schon in Zeit log n + O(log log n) informiert
sind. Damit ergibt sich eine Nachrichtenmenge von O(n log n).
• Push&Pull-Modell
Da hier die Zeit für die vollständige Verbreitung des Gerüchtst sogar mit hoher Wahrscheinlichkeit
beschränkt ist durch log3 n + O(log log n) garantiert die Wahl ctrmax = log3 n + c log log n, dass
alle Knoten informiert werden. In [KSSV00] wird gezeigt, dass die Nachrichtenmenge dann sogar
nur O(n log log n) für jedes übetragenes Gerücht beträgt.
Der Grund für diese geringe Nachrichtenmenge ist, dass in der exponentiellen Verbreitungsphase nur
linear viele Nachrichten entstehen. Das Gros der Nachrichten wird daher erst beim quadratischen
Schrumpfen des Anteils der Nichtinformierten erzeugt, der dann nur noch O(log log n) Runden benötigt.
Der Nachteil dieser Terminierungsstrategie, ist dass die Wahl von ctrmax sich sehr stark auf die Nachrichtenmenge auswirkt. Ist also zum Beispiel ein gleichmäßiges Kontaktmodell wie Push&Pull nicht erreichbar, weil gewisse Teile des Netzwerks nicht von allen erreicht werden können, so ergibt sich ein
Trade-Off zwischen der Robustheit und der Nachrichtenmenge.
4.1.7
Shenkers Min-Counter-Algorithmus
Scott Shenker [KSSV00] entwarf einen cleveren Terminierungsmechanismus, der dieses Problem elegant
löst. Die Idee ist, dass jeder Spieler P für ein Gerücht R einen Zähler ctrR (P ) unterhält, der nur dann
um eins erhöht wird, falls in der vergangenen Runde alle Zählerstände von Kontaktpartnern für dieses
Gerücht mindestens ebenso groß waren. Ist der Zähler größer als ctrmax , dann wird das Gerücht nicht
mehr weitergegeben. Im einzelnen arbeitet der Termininierungsmechanismus wie folgt.
• Sei ctrmax ∈ O(log log n).
• Zustand A: Jeder Spieler P führt Variable ctrR (P ) für Gerücht R, die initialisiert ist mit ctrR (P ) =
0, falls P das Gerücht R noch nicht kennt.
• Zustand B: Entsteht bei P das Gerücht R, setze ctrR (P ) ← 1 und verbreite das Gerücht durch
Push und Pull
73
Teilnehmer in
Zustand
B
C
D
A
B−1
2 3
< log n
O(log log n)
3
Abbildung 4.11: Häufigkeit der einzelnen Zustände des Min-Counter-Algorithmus
• Zustand B: Seien Q1 , . . . , Qm Kommunikationspartner von P in dieser Runde. Falls alle das Gerücht
weiterverbreiten und falls
min{ctrR (Qi )} ≥ ctrR (P ) ,
i
dann setzte ctrR (P ) ← ctrR (P ) + 1.
• Zustand B: Falls ctrR (P ) ≥ ctrmax gehe in Zustand C
• Zustand C: Verbreite ctrmax Runden lang das Gerücht weiter. Gehe dann in Zustand D über.
• Zustand D: Gerücht wird nicht mehr weiterverbreitet.
In Abbildung 4.11 wird gezeigt, wann welche Zustände mit welcher Häufigkeit auftreten.
Theorem 11 [KKPS00] Shenkers Min-Counter-Algorithmus informiert mittels Push&Pull-Kommunikation
alle Teilnehmer in log3 n+O(log log n) Runden mit Wahrscheinlichkeit 1−nO(1) , wobei maximal O(n log log n)
Nachrichten übertragen werden.
Es stellt sich im übrigen heraus, dass dieses Verhalten selbst dann garantiert ist, wenn die Partnerwahl im Kontaktgraphen Gt (von Push und Pull) nicht mit einer gleichmäßigen Wahrscheinlichkeitsverteilung durchgeführt wird. Da eine ungleichmäßige Wahrscheinlichkeitsverteilung die Verbreitung des
Gerüchts erheblich verkürzen kann, ist die gleiche Performance wie Min-Counter dann mit der einfachen Alterungsterminierungsstrategie nicht zu erreichen. Eine weitere Verbesserung lässt sich erzielen,
wenn der Min-Counter Algorithmus leicht verändert wird. Berthold Vöcking schlug daher vor, im Zustand
B statt der Mininums-Bildung den Median zu verwenden und tatsächlich funktioniert der dadurch entstehende Median-Counter-Algorithmus für beliebige Wahrscheinlichkeitsverteilungen im Anruf-Modell
[KKPS00].
Damit erweist sich dieser Median-Counter-Strategie als eine robuste Terminierungsstrategie für epideVor- mische Informationsausbreitung.
11.
lesung
02.07.2004
74
4.2
Datenaggregation
Epidemische Informationsausbreitung kann aber mehr, als nur eine Information in einem Netzwerk verbreiten. Man kann damit einfache Mechanismen zum Zählen, zur Durchschnittsbildung und für andere
interessante Funktionen bereit stellen. Dies sind Überlegungen aus den Arbeiten [JM04, JMÖB04] von
Alberto Montresor, Márk Jelasity und Ozalp Babaoglu von der Universität Bologna.
4.2.1
Zählen
Wir starten mit einem Problem, dass uns schon in Viceroy begegnet ist. Wie kann man in einem Peer-toPeer-Netzwerk die Anzahl der Teilnehmer bestimmen? Diese auf den ersten Blick einfachere Aufgabe als
z.B. einen bestimmten Peer ist aber bei weitem nicht trivial. Das Problem ist, dass Teilnehmer sehr effizient
eingebunden werden in das Netzwerk und keine zentrale Kontrolle diesen Zugang protokolliert.
Folgende Ansätze führen nur bedingt zum Erfolg:
1. Ansatz
Wir setze in einem Peer eine Zähler-Variable auf 1 und übergeben diese Variable an den Nachbarn.
Dieser erhöht den Zähler um 1 und gibt ihn wieder weiter. Das Problem hier ist, dass hier Kontrollmechansimen stattfinden müssen, die sicher stellen dass zum Einen keiner zweimal die Variable
erhöht und zum anderen sicherstellen, dass tatsächlich alle Teilehmer diese Variable mindestens einmal erhalten.
Ohne diese funktioniert dieser Ansatz z.B. auf dem Ring und benötigt in jedem Fall die nicht praktikable Laufzeit von n − 1 Sprüngen.
2. Ansatz
Eine Liste aller Peers wird durch einen epidemischen Algorithmus verbreitet. Jedesmal wenn Listen
zwischen Peers ausgetauscht werden, werden die Einträge ergänzt. Die Laufzeit eines solchen Algorithmus wäre wie eben bewiesen nur O(log n) wobei insgesamt O(n log log n) Nachrichten im Fall
von Push&Pull verwendet werden. Der Nachteil dieser Methode liegt auf der Hand: Die Nachrichtenlänge wird auf lineare Größe anschwellen und dadurch wird die eigentliche Nachrichtenmenge
mindestens Ω(n2 log log n)
3. Ansatz für Zählen
In vielen Peer-to-Peer-Netzwerke werden Knoten zufällig auf einen Ring oder in ein Intervall gesetzt.
Ferner hat man effiziente Methoden die Abstände zu den direkten Nachbarn zu bestimmen. Wir
betrachte dann Abstand zu den nächsten O(log n) Nachbarn auf den Ring. Wenn man hieraus den
Durchschnitt µ berechnet, dann liefert − log(µ)/µ eine Approximation mit einem konstanten Faktor
von n.
Dieses Verfahren arbeitet sogar mit nur einer Anfrage, wenn zum Einfügen das Prinzip der mehrfachen Auswahl angwendet wird. Dann muss nur der Abstand zum direkten Nachbarn gemessen
werden um eine Approximation mit dem Faktor 2 zu erhalten.
Man kann zeigen, dass diese Approximation sogar mit hoher Wahrscheinlichkeit zum exakten Resultat führt, wenn man O(log2 n) Nachbarn betrachtet und es dann geeignet anpasst.
Dieses Verfahren funktioniert natürlich nur, wenn tatsächlich Knoten zufällig platziert werden. Wird
von dieser zufällige Platzierung abgegangen, so entstehen Fehler, die die Ausgabe verfälschen könnten. Außerdem gibt es eine Reihe von Peer-to-Peer-Netzwerken, bei denen dieses Verfahren nicht
verwendet werden kann (wie z.B. Pastry oder Gnutella).
Kann man auch exakt zählen mit Hilfe von Push & Pull ?
75
Average-Algorithmus(s1 , . . . , sn )
begin
loop n do
(i, j) = getPair()
si ← (si + sj )/2
sj ← (si + sj )/2
od
end.
Abbildung 4.12: Der Average-Algorithmus zur Daten-Aggregation
Zählen durch Datenaggregation Tatsächlich gibt es ein wesentlich einfacheres und eleganteres Verfahren zum Zählen. Hierzu betrachten wir den folgenden verteilten Algorithmus [JM04].
• Initialisierung.
Ein Peer kann den Zählvorgang starten. Dies sei Peer 1 und dieser setzt eine (reell-wertige) Variable
s1 ← 1.
• Verbreitung.
Jeder weitere Peer i hat ebenfalls eine Variable si , die sobald dieser Peer vom Vorgang des Zählens
(ausgelöst durch 1) erfährt mit si ← 0 initialisiert.
• Ausgleich.
Kontaktiert der Peer i den Peer j. Dann aktualisieren sie ihre Variablen (gleichzeitig) wie folgt:
si
sj
← (si + sj )/2
← (si + sj )/2
Nach relativ kurzer Zeit, wie wir im nächsten Teilabschnitt sehen werden, konvergieren alle Variablen
relativ schnell zu n1 . Daraus erhält jeder Teilnehmer aus dem reziproken Wert die Teilnehmeranzahl.
Theorem 12 Nach O(log n) Runden gilt für alle Peers i mit hoher Wahrscheinlichkeit.
1
1
+
=n
si
2
4.2.2
Der Average-Algorithmus
Damit verwendet der Zählalgorithmus folgenden verallgemeinerten Algorithmus mit Eingabe: s1 , . . . , sn ,
wobei die Variable si lokal in Peer i vorkommt3 . Dieser Algorithmus berechnet als Ausgabe:
µ=
1
(s1 + . . . + sn ) .
n
Dies geschieht dadurch, dass die Variablen si gegen diesen Wert konvergieren und dass ab einen gewissen
Zeitpunkt jeder Peer diesen Wert approximiert.
Das Kommunikationsmodell wird durch getPair() festgelegt. getPair() liefert zwei verschiedene Peers gleichwahrscheinlich aus der Menge aller n vorhandenen Peers. Der Average-Algorithmus arbeitet
wie in Abbildung 4.12 dargestellt.
3 Diese
Nummerierung ist willkürlich und den Peers selber nicht bekannt. Sie dient nur zur Beschreibung des Algorithmus.
76
Wir betrachten folgende Potenzialfunktion P (S) für S := (s1 , . . . , sn ) 4 in Runde t, wobei
P (S) :=
X
(si − µ)2 .
i∈[n]
Für a = si und b = sj gilt nun
(a − µ)2 + (b − µ)2 − 2
2
a+b
−µ
2
= a2 + b2 − 2aµ − 2bµ −
=
=
≥
a2
b2
−
+ ab + 2aµ + 2bµ
2
2
a2
b2
+
− ab
2
2
1
(a − b)2
2
1
(a − b)2
2
Nun ist
E[(si − sj )2 ] = 2E[s2i ] − 2E[si sj ] = 2E[s2i ] − 2µ2 = 2E[(si − µ)2 ] =
In jedem Schritt der Teilrunde verringert sich also P (S) erwartungsgemäß um
folgende Rekursionsgleichung für die erwartete Potentialfunktion:
0
E[P (S )] =
1
1−
n
2
P (S) .
n
2
n P (S).
Damit erhält man
P (S)
Somit gilt nach einer Runde:
E[P (St+1 )] =
1
1−
n
n
P (St ) =
1
P (St ) .
e
Nach 2c ln Runden ist die erwartete Potentialfunktion dann höchstens n−c P (St ). Die maximale Abweichung vom Durchschnitt µ ist aber höchstens n · µ (für positive Ausgangswerte. Wenn nun
P (St ) ≤ n−c P (S0 )
gilt, dann gilt für alle si : |si − µ|2 ≤ n−c n max{(si − µ)2 }. Somit ist erwartungsgemäß nach 2c + 2
Runden der maximale Abstand um den polynomiellen Faktor n−c verringert worden.
4.2.3
Experimentelle Resultate
Um diese Untersuchungen experimentell zu verifzieren, wurde in [JM04] dieser Zählprozess experimentell
verifiziert. Hierzu wurde ein Knoten wurde mit dem Wert 100.000 initialisiert und alle anderen Knoten
mit 0. Das Kommunikations netzwerk aus 20 Nachbarn für jeden Peer wurde (abweichend von dem oben
beschriebenen Modell) einmalig uniform gewählt. Trotzdem zeigt Abbildung 4.13, dass der Algorithmus
sehr schnell konvergiert.
Aber auch in dynamischen Netzwerken gelingt es mit Hilfe der Datenaggregation die Netzwergröße
zeitnah abzuschätzen. Hierzu wurde der Zählprozess immer wieder neu gestarten, während die Anzahl der
Knoten zwischen 90.000 und 110.000 gleichmäßig oszillierte. In Abbildung 4.14 kann man sehen, dass mit
Hilfe dieses Zählalgorithms die Netzwerkgröße angenähert werden kann.
4 Wir geben hier eine vom Skript und vom Artikel [JM04] abweichende Beweisidee wieder. Das heisst insbesondere, dass wieder
dieser noch der in der Vorelesung vorgestellte Beweis prüfungsrelevant sind.
77
Abbildung 4.13: Experimentell Verifikation des Average-Aggregations-Algorithmus [JM04]
Abbildung 4.14: Zählen der Peers durch Datenaggregation in einem dynamischen Netzwerk [JM04]
78
Peer-Ausfälle Des weiteren wurden Peer-Ausfälle untersucht. Im schlimmsten Fall, fallen die Peers zu
Beginn aus. Angenommen, pf n Knoten fallen gleichverteilt durch einen Zufallsprozess aus und sei wiederum µf das Mittel von si . So ist nach [JM04] die Varianz von Mittelwert durch folgende Funktion
beschrieben
Var[µt ] =
pf
E[σ02 ]
n(1 − pf )
1
ρ
1−pf
ρ
− 1−p
f
1−
t
.
Die Hauptbeobachtung hierbei sit, dass mit zunehmender Teilnehmerzahl, nimmt der Einfluss der ausfallenden Peers ab (bei gleicher Ausfallwahrscheinlichkeit) und dass obgleich mit pf immer der gleiche
Anteil von Peers ausfällt.
4.2.4
Weitere Aggregations-Funktionen
Folgende Funktionen können ebenfalls effizient berechnet werden:
• Das Minimum
Hierzu berechnet man f (x, y) = min{x, y}.
• Das Maximum
Hierzu berechnet man f (x, y) = max{x, y}.
Es bleibt anzumerken, dass sowohl Minimum als auch Maximum durch klassische epidemische Verfahren in Kombination mit den oben genannten Terminierungsmechanismen wesentlich effizienter
berechnet werden kann. (Und das richtige Ergebnis liegt nach garantierter Laufzeit vor und wird
nicht etwa nur approximiert).
• Die Summe
Hierzu wird der Average-Algorithmus für die Summanden verwendet und das Teilergebnis µ mit der
Anzahl von Peers n , die ein parallel laufender Zählalgorithmus liefert, kombiniert. Ausgabe: µ · n
• Das geometrische Mittel:
Hierfür wird statt der arithmetischen Mittelwertbildung die geometrische Verwendet:
s0i = s0j =
√
si · sj
• Produkt:
Hier wird ähnlich wie bei der Summe, das geometrische Mittel g mit der Anzahl der Peers (aus einem
parallelen Datenaggregationsalgorithmus) kombiniert: g n
4.2.5
Resumee
Datenaggregation funktioniert auf jeder zusammenhängenden Netzwerktopologie und nicht nur im RandomCall-Modell dort aber mit logarithmischer Konvergenzzeit. Die Konvergenz ist stark abhängig von der
Netzwerkstruktur, wobei für statische Netzwerke eine Analyse mit Markov-Prozessen möglich ist.
Wegen der mangelnden Expander-Eigenschaft ergibt sich nur polynomielle Konvergenzzeit für Topologien wie den Ring oder das Gitter. Dagegen kann man logarithmische Konvergenz in Netzwerken zeigen,
wie balancierte Bäume, Hyperwürfel, De-Brujin-Netzwerke, Butterfly-Netzwerke und CAN-Netzwerke
mit mehreren Realitäten.
Bis heute sind noch einige Fragen offengeblieben, wie zum Beispiel Welche Funktionen sind für Datenaggregation geeignet? Außerdem findet man bei der Datenaggregation keine so schnelle Konvergenz
wie bei Push&Pull? Wie lässt sich dieser Unterschied erklären?
79
80
Kapitel 5
Routing und Sicherheit
12.
VorPeer-to-Peer-Netzwerke stecken noch in den Kinderschuhen, so dass wichtige Aspekte wie Optimierung lesung
des Routing und Sicherheit noch nicht ausreichend untersucht worden sind. Wir werden uns in diesem 09.07.2004
Kapitel mit ausgewählten, aktuellen Arbeiten aus diesen Bereichen beschäftigen.
5.1
Sicherheit in Peer-to-Peer-Netzwerken
Bevor wir uns den spezifischen Sicherheitsaspekten von Peer-to-Peer-Netzwerken zuwenden, werden wir
einen sehr kurzen Überblick über elementare Methoden der Kryptographie geben.
5.1.1
Methoden der Kryptographie
Die klassische Verschlüsselungsmethode ist das symmetrisches Verschlüsselungsverfahren. Bekannte Verfahren sind hierbei z.B. Cäsars Code, DES (Digital Encryption Standard) und AES (Advanced Encryption
Standard). Solche Verfahren bestehen aus den Funktionen f und g, sowie einem geheimen Schlüssel S.
Ein Text T wird nun zum Code C verschlüsselt durch Anwenden von f :
f (k, T ) = C ,
wobei aus C ohne die Kenntnis von k nicht der Originaltext rekonstruiert werden kann. Die Entschlüsselung geschieht durch Anwenden der Funktion g mit Kenntnis des selben Schlüssels k:
g(k, C) = T .
In der Regeln werden für f und g bekannte Verfahren verwendet, so dass die Sicherheit dieser symmetrischen Verschlüsselungsverfahren ausschließlich auf der Geheimhaltung des Schlüssels k beruht.
Anders verhält es sich hier bei den Asymmetrischen Verschlüsselungsverfahren, wie z.B. RSA von
Ronald Rivest, Adi Shamir, Lenard Adleman [RSA78] oder dem Diffie-Hellman-Schema [DH76] oder
PGP (Pretty good privacy) [Zim92]. Hier gibt es zwei Schlüssel: einen geheimen Schlüssel S und einen
öffentlichen Schlüssel P . Der geheime Schlüssel und der öffentliche Schlüssel werden von dem (zukünftigen) Empfänger einer verschlüsselten Nachricht zu einander passend erzeugt. Dann wird der öffentliche
Schlüssel allen potenziellen Sender mitgeteilt. Diese verwenden ihn dann zur Verschlüsselung der Nachricht T in den Code C:
f (P, T ) = C .
Der Empfänger kann dann als einziger diese Nachricht entschlüsseln durch die Kenntnis des geheimen
Schlüssels S:
g(S, C) = T .
Hierbei sind die Verschlüsselungsfunktion f und die Entschlüsselungsfunktion g in der Regel veröffentlicht. Die Sicherheit des Verfahrens beruht hier auf der Schwierigkeit den geheimen Schlüssel aus der
81
Kenntnis des öffentlichen Schlüssels zu rekonstruieren (oder aus einer Menge von Text/Code-Paaren eine
Gesetzmäßigkeit in der Entschlüsselungsfunktion aufzudecken).
Eine weitere wichtige Methode der Kryptographie sind die sogenannten Digitalen Unterschriften (Signaturen). Diese beruhen auf asymmetrischen Verschlüsselungsverfahren, wie z.B. RSA. Der Unterzeichner erzeugt auch hier einen geheimen Schlüssel S und öffentlichen Schlüssel P , sowie das Komprimat K
des Texts T , z.B. durch kryptographsiche Hash-Funktion h:
K = h(T ) .
Nun berechnet der Unterzeichner die Funktion
g(S, K) = U .
Der Empfänger kann nun mittels des öffentlichen Schlüssels P und des Textes T die Unterschrift U verifizieren, indem er die folgende Gleichheit überprüft:
f (P, U ) = h(T ) .
Ein Problem hierbei ist, dass durch die Veröffentlichung von Text/Code-Paaren die Sicherheit des Verfahrens gefährdet ist. insbesondere dann wenn der Angreifer gewählte Dokumente zur Unterschrift vorlegt
(chosen-message-attack). Dieses Problem wurde gelöst durch eine Signaturschema von Shafi Goldwasser,
Silvio Micali, und Ronald Rivest [GMR88], das unter bestimmten Annahmen nachweisbar sicher ist.
5.1.2
Sicherheitsanforderungen in Peer-to-Peer-Netzwerken
Zumeist sind Peer-to-Peer-Netzwerke darauf angelegt, offen und autonom zu sein. Dies scheint in einem
Widerspruch zu Sicherheitsanforderungen zu stehen. Schließlich arbeiten Peer-to-Peer-Netzwerke in einem
feindlichen Umfeld.
Als Anforderungen kann man folgende Punkte formulieren:
• Verfügbarkeit
Ein großses Problem für Peer-to-Peer-Netzwerke stellen Dienstverweigerungsangriffe dar (Denialof-Service Attacks). Hier bombardieren beispielsweise eine große Menge von koopierenden Peers
Knoten mit Anfragen nach einem Dokument. Dies kann zum Beispiell in Gnutella (II) zu einem
Kollaps eines Super-Nodes führen (chosen-victim-attack).
Eine andere Methode ist, dass ein bösartiger Peer sich zum Super-Node erklären läßt. Dann erzeugt
er eine Menge von Scheinanfragen und blockiert so das ganze Netzwerke.
Typisch ist auch ein Angriff durch Ausnutzung von Protokoll-Fehlern und Schwächen. Auf solche
Angriffe kann mit der Nachbesserung des Netzwerksoftware reagiert werden.
Für die Lösung der Infiltration bösartiger Peers verweisen wir auf die nachfolgende Diskussion von
Sybil-Attacken und byzantinischen Generälen.
• Dokumentauthentifikation
Wenn man in einem Peer-to-Peer-Netzwerk ein Dokument bezieht, dann kann es sein, dass dieses
Dokument in mehrfacher Kopie mit leichten Veränderungen vorhanden ist. Welches Dokument ist
dann authentisch? Welches ist gefälscht, nachgemacht oder verfälscht? Welcher Autor hat die Urheberrechte?
Eine Lösung kann sein Digitale Unterschriften zu verwenden. Diese beantworten aber nicht die Frage, welches Dokument zuerst da war (Das Independent-Label oder der Markentitel).
Wie kann man nachweisen, dass eine Datei älter ist als ein anders? In der wirklichen Welt hilft die
Physik weiter (C14-Methode, Vergilbung etc.). In der digitalen Welt funktioniert das natürlich nicht.
Man kann mit herkömlichen Methoden höchstens nachweisen, dass ein Dokument jung ist (aber
nicht, dass es alt ist) z.B. durch Referenz auf aktuelle nicht vorhersehbare Ereignisse1 .
1 Es
gibt aber durchaus Ansätze für Systeme, die das Alter von Dokumenten nachweisen können.
82
• Anonymität
Eine Motivation für die Anonymität ist nicht nur die Verhinderung des berechtigten Zugriffs staatlicher Verfolgungsbehörden gegen die unrechtliche Verletzung von Urheberschutzgesetzen. Das Internet ist weltumspannend und oftmals das einzige Medium, dass der Zensur und Verfolgung in
Diktaturen entzogen ist.
Man kann folgende Stufen der Anonymität unterscheiden:
– Autor: Wer hat das erzeugt?
– Server: Wo wird das gespeichert?
– Leser: Wer hat sich das geholt?
– Dokument: Welche Dokumente werden auf einen bestimmten Peer gespeichert?
Die Peer-to-Peer-Netzwerke Free Haven und Crowds widmen sich dieser Problemstellung und bieten
eine Palette verschiedener Stufen der Anonymität.
• Zugangskontrolle
Peer-to-Peer-Netzwerke werden aber auch in geschützten Bereichen, wie in Unternehmen und im
Militär eingesetzt, die über das Internet eine sichere verteilte robuste Netzwerkstruktur unterhalten wollen. Eine Anwendung sind zum Beispiel Bezahl-Peer-to-Peer-Netzwerke, wie im aktuellen
Napster-System.
Eine Lösung kann hierzu eine zentrale Authorisierung sind. Auch kann man hier virtuelles Geld
verwenden (dass ebenfalls zentral authentifiziert ist). Bei verteilte Lösungen ergibt sich ds Problem
der Identifizierung und eine Interessenskollision mit dem Prinzip der Anonymität.
Als Maßnahmen gegen Attacken unterscheiden wir die Entdeckung der Attacke, ihre Handhabung, die
Systemwiederherstellung nach einer Attacke und natürlich im besten Falle die Verhinderung ein er Attacke.
5.1.3
Die Sybil Attacke
Mit dem Namen “Sybil” kann kaum einer in Europa etwas verbinden (ganz im Unterschied zu den USA).
Im Jahr 1973 erschien das Buch “Sybil” von Flora Rheta Schreiber, das von einer Frau mit 16 separaten
Persönlichkeiten handelte (mit 16 unterschiedlichen Namen): Sybil ware eine Aushilfslehrerin mit ZeitAussetzern, Peggy war ein 9 Jahre altes wütendes, verängstigtes Mädchen, Vicki sprach fließend französisch, Vanessa spielte Klavier und war mit den Nachbarn befreundet, Marsha war eine dunkle Persönlichkeit mit Selbstmordabsichten, usw. Das Buch (und der darauf beruhende Film aus dem Jahr 1976) geht
auf einen tatsächlichen Fall zurück von Multipler Persönichkeitsstörung (mehrfacher Schizophrenie). Bis
heute ist umstritten, in wie weit diese Krankheit bei Menschen wirklich existiert.
Bei Peer-to-Peer-Netzwerken ist eine absichtliche Persönlichkeitsstörung jedenfalls ein probates Mittel
um die Strukturen zu attackieren. Hierzu gibt sich ein Peer als eine Vielzahl virtueller Peers aus und wird
dadurch an mehreren Stellen im Netzwerk aktiv.
Was kann eine Sybil-Attacke bewirken? Ein Netzwerk kann dadurch den Zusammenhalt verlieren.
Dies betrifft beispielsweise CAN, Chord, Viceroy, Pastry und Tapestry aber nicht Napster (da Napster
nicht verteilt arbeitet) und nicht zwingend Gnutella. Außerdem können Mehrheitsabstimmungen über den
Zustand des Netzwerks gestört werden. Dies betrifft insbesondere die Mehrheitsfrage: “Verhält sich ein
Peer korrekt?”. Dies Frage ist entscheidend für die Lösung des Problems der byzantinischen Generäle, wie
wir gleich sehen werden.
Außerdem könne durch eine Sybil-Attacke Anfragen im Netzwerk weitestgehend observiert werden.
Das Netzwerk kann absichtlich verlangsamt werden oder gar ganz zerstört werden. Natürlich kann man
mittels einer Sybil-Attacke auch einen Dienstverweigerungsangriff starten.
Wir halten daher fest: Sybil-Attacken greifen Peer-to-peer-Netzwerke wirkungsvoll an.
83
Wie kann man Sybil-Attacken abwehren? Ein nahe liegender Ansatz ist eine zentrale Authorisierungsstelle, welche die Identität der teilnehmenden Peers bestätigt. Diese zentrale Instanz authentifiziert
die Existenz eines Teilnehmers und die Gültigkeit seiner öffentlicher Schlüssel durch eine digitale Unterschrift. Jeder Peer kann sich dadurch von der Existenz des Peers überzeugen. Damit kann natürlich kein
anonymes Peer-to-Peer-Netzwerk betrieben werden.
Problematisch sind dezentrale Authorisierungsstrategien. Erlaubt man z.B. einem Peer auch nur eine kleine Menge von anderen Peers zu authorisieren, dann kann Peer 1 den Peer 2 authorisieren. Dieser
authorisiert Peer 3, der dann Peer 4 usw. Damit steht einer Sybil-Attacke nichts mehr im Wege.
5.1.4
Der Sybil-Abwehransatz John Douceur
Ein interessanter Ansatz zur Abwehr von Sybil-Attacken wurde von John Douceur (Microsoft Research)
[Dou02] entwickelt.
Die Annahmen sind hier, dass Peers einzelne Rechner sind, die einer Person unterstehen. Außerderm
verfügen Einzelpersonen nicht über unbeschränkte Rechenresourcen.
Die Lösungsstrategie ist, dass alle Teilnehmer des Peer-to-Peer-Netzwerks ein bestimmtes mathematisches Problem (Challenge) lösen müssen. Zum Beispiel müssen sie für verschiedene Werte y, den Wert x
finden mit h(x) = y, wobei h ist eine kryptographisch sichere Hash-Funktion ist. Hierbei wurde y = h(x)
von einem herausfordenden Peer (Challenger) gewählt. Die Größe der Aufgabe kann durch die teilweise
Bekanntgabe der Bits von x eingestellt werden. Innerhalb einer gewissen Zeit kann jeder virtuelle Peer nur
eine bestimmte Anzahl von solchen “Challenges” lösen.
Der Vorteil dieses Ansatzes ist, dass hiermit ein Ansatz vorhanden ist überhaupt Sybil-Attacken zu
begegnen.
Nachteile Der Hauptnachhteil ist sicherlich die unglaubliche Verschwendung von Rechenresourcen (Energie, Zeit, Rechenleistung, etc.) Dagegen stehen einem Angreifer duch “Ein-Hacken” in fremde Rechner
enorme Rechenkapazitäten zur Verfügung.
Daneben sind die den Benutzern zur Verfügung stehenden Rechenressourcen enorm heterogen. Studenten an Universitäten können über Pool-Recher große Rechenkapazitäten verfügen, staatliche Einrichtung
verfügen über noch größere Resourcen (siehe Motivation). Wenig leistungsfähige Peers können durch den
Challenge überfordert werden, wie zum Beispiel ältere PCs, Pocket-PCs, etc. Der Challenge selbst ist ein
institutionalisierte Form des Denial-of-Service-Attacks.
5.1.5
Das Problem der byzantinischen Generäle
Ein ganz typisches Problem im Netzwerkbereich ist das sogannte Problem der byzantinischen Generäle
[LSP95]. Im oströmischen Reich besaßen die Generäle immer Ambitionen Kaiser zu werden und verfolgten
daher mit ihren Armeen mitunter höchst eigennützige Strategien. Daher konnten sich die Mit-Generäle im
Falle eines Kriegs nicht unbedingt auf ihre Kollegen verlassen. Wir modellieren hier den Fall von drei
Generälen.
Drei byzantinische Armeen stehen unter dem Kommando dreier Generäle bereit, die gegnerische Burg
zu erobern. Die Armeen sind räumlich getrennt und kommunizieren über Boten. Die militärische Lage ist
die Folgende: Greift nur eine Armee an, so verliert diese. Greifen zwei an, so gewinnen diese. Greift keine
an, so gewinnen die Armeen auch, da durch die fortwährende Belagerung die Burg ausgehungert wird.
Jetzt ist aber ein General übergelaufen und man weiß nicht, welcher es ist.
Wie in Abbildung 5.1 gezeigt, versucht der übergelaufene General X versucht General A zum Angriff
zu überreden und General B zum abwarten. Wenn nun B diesen Befehl A übermittelt und A den gegenteiligen Befehl an B, so können die beiden Generäle diesen Widerspruch nicht auflösen. Schlimmer wiegt
der Umstand, dass weder B noch A den General X als Überläufer überführen können oder als Übermittler
widersprüchlicher Befehle, da dieser jeweils einen der andern Generäle beschuldigen kann.
Theorem 13 Das Problem der drei byzantinischen Generäle kann nicht gelöst werden. Für vier Generäle
ist das Problem lösbar.
84
Abbildung 5.1: Der übergelaufene General X gibt widersprüchliche Anweisungen
Abbildung 5.2: Unauflösbare Verwirrung unter den Generälen
Wir werden die Strategie für vier Generäle kurz skizzieren. Im Falle von vier Generälen müssen alle
drei ehrlichen Generäle angreifen oder alle drei abwarten. Dieses Problem kann auf das “1-General, 3
Offiziere-Problem” reduziert werden, siehe Abbild
Ist nun der General loyal und einer der drei Offiziere ein Überläufer. So gibt der General konsistente
Anweisungen für den Angriff. Diese geben diese Information an alle anderen Offiziere weiter. Diese berechnun eine Mehrheitsentscheidung, die durch einen der drei Offiziere nicht behindert werden kann, siehe
Abbildung 5.3 und 5.4.
Ist der General nicht loyal, so werden seine (widersprüchlichen) Befehle korrekt unter den Offizieren
ausgetauscht. Diese folgen dann der Mehrheitsentscheidung des loyalen Generals, der damit ein gemeinsames Handeln der Offiziere nicht verhindern kann, siehe Abbildung 5.5.
Im allgemeinen gilt das folgende Theorem.
Theorem 14 Falls m Generäle Überläufer sind, müssen mindestens 2m + 1 Generäle ehrlich sein, damit
das Problem der Byzantinischen Generäle lösbar ist.
Diese Schranke ist genau, wenn keine kryptographischen Annahmen gemacht werden, wenn also asymmetrische Kryptographie-Verfahren nicht verfügbar sind2 . D.h. wenn man genug Zeit hat jede Verschlüsselung zu brechen
Theorem 15 Steht ein digitales Signaturschema zur Verfügung, dann kann eine beliebige Anzahl von
falschen Generälen verkraftet werden.
Beweis: Hierbei unterschreibt jeder General seinen Befehl und in der folgenden Runde gibt jeder General
alle Befehle mit Unterschriften an alle anderen Generäle weiter. Hat nun jeder den korrekten öffentlichen
Schlüssel, kann jeder inkonsistente Befehl oder jede falsche Weitergabe aufgedeckt werden.
2 Im
strengen Berechenbarkeitsbegriff der Rekursionstheorie ist jedes asymmetrisches Verfahren unsicher, da man “nur” jeden geheimen Schlüssel ausprobieren muß, der zum öffentlichen Schlüssel passen könnte. Das berücksichtigt aber nicht die kombinatorische
Vielfalt und die Beschränktheit der Rechenmaschinen sich dorthin zurecht zu finden (falls P =
6 N P)
85
Abbildung 5.3: Der loyale General gibt konsistente Befehle
Abbildung 5.4: Eine Mehrheitsentscheidung unter den drei Offizieren kann von dem Überläufer nicht gestört werden
Abbildung 5.5: byz-loes-3.pdf
86
Abbildung 5.6: Struktur des Peer-to-Peer-Netzwerks von [FS02]
Byzantinische Generäle und Peer-to-Peer-Netzwerke - Ein Resumee Durch den Einsatz von digitalen
Unterschriften reduziert sich das Problem auf den (bösartigen) Ausfall von Knoten in einem Netzwerk
wenn die Nachbarn die Kommunikation rekonstruieren können. Das Hauptproblem ist, dass dafür O(n)
Nachrichten pro Peer verwendet werden müssen.
5.1.6
Ein Zensor-Resistentes Peer-to-Peer-Netzwerk
Amos Fiat und Jared Saia stellen in [FS02] ein Peer-to-Peer-Netzwerk vor, dass in der Lage ist, den Ausfall
von 50% aller Peers durch einen Angriff zu verkraften. Voraussetzung hierfür, ist dass der Angreifer nichts
über die interne Netzwerk-Struktur weiss. Weist man den Knoten die Aufgaben zufällig zu, so fällt jeder
Knoten mit Wahrscheinlichkeit 12 aus.
Das Netzwerk besteht aus einer Butterfly-Struktur mit Clustern der Größe c log n als Knoten. Die Cluster sind bipartite Expander-Graphen.
Definition 3 Bipartiter Graph Ein bipartiter Graph besteht aus zwei disjunkten Knotenmengen A und B,
so dass jede Kante einen Knoten aus A und B verbindet.
Definition 4 Expander-Graph Ein bipartiter Graph ist ein Expander-Graph, wenn für jede Teilmenge
X von A, deren Kardinalität A um höchstens einen konstanten Faktor kleiner 1 erreicht, die Menge der
Nachbarknoten in B um einen konstanten Mindestfaktor größer als 1 ist.
Diskussion Damit hat man zugleich ein sehr effizientes, robustes, als auch einfaches Verfahren. Auch
lässt sich das Funktionsprinzip auf alle bisher diskutierten Verfahren verallgemeinern.
Problematisch ist nur, dass der Angreifer wenig über die interne Struktur weiss. Somit funktioniert
dieses System wohl nur bei Systemen mit Zugangskontrolle. Denn falls der Angreifer die Struktur kennt,
87
dann kann er jedes System mit konstanten Grad mit einem Denial-of-Service-Angriff auf wenige Peers
13.
Vor- aushebeln.
lesung
12.07.2004
5.2
Routing in Peer-to-Peer-Netzwerken
Bis jetzt haben wir uns (unter anderen) darauf konzentriert, die Netzwerkstruktur hinsichtlich des Durchmessers und des Grads zu optimieren. Die Motivation, um den Durchmesser zu minimieren, war die
Routing-Zeit zu minimieren. Hierbei muss man aber zwei Operationen unterscheiden, welche die Datenabfrage betreffen.
• Fetch: Wie lange dauert das Laden der Daten. Interessanterweise kann man auch hier die Zeit durch
den Einsatz von verteilten Kopien oder Caches verringern.
• Lookup: Dieser beschreibt die Zeit, die notwendig ist den Peer zu finden, der die gewünschten Daten
trägt. Diese Zeit ist nicht notwendigerweise linear in der Anzahl der Hops, wie wir gleich sehen
werden. Wir werden uns in diesem Abschnitt der Optimierung dieses Aspekts zuwenden.
Weitere Optimierungsziele sind die Verläßlichkeit des Lookup, die Knotenlast und die Netzwerklast.
Bezüglich der Verlässlichkeit interessiert man sich dafür, welche Netzwerkstrukturen den Ausfall von
Peers am besten kompensieren können. Welche der dazu notwendigen Replizierungsstrategien sind empfehlenswert?
Die Knotenlast beschreibt die Anzahl der Informationen, die auf einem Knoten gespeichert werden
und die Anzahl der Anfragen. Um Peers nicht zu überlasten, strebt man hier eine möglichst gleichmäßige
Verteilung an.
Die Netzwerklast bedingt den Datendurchsatz. Kurze Routing-Wege können zu Engpässen führen. Ein
Peer kann dadurch gezwungen werden, sehr viele Anfragen weiter zu leiten. Anzustreben ist ein Routing,
dass möglichst gleichmässig Peers als Router einsetzt (wie wir es schon in Viceroy und in Distance-Halving
gesehen haben).
Wir werden in der verbliebenen knappen Zeit diese Fragen nicht behandeln können. Wir konzentrieren
hier uns auf die Lookup-Latzenzeit und wenden uns der Routing-Optimierung von zwei elementaren Peerto-Peer-Netzwerken zu, die wir zu Beginn besprochen haben: CAN und CHORD.
5.2.1
Techniken für CAN
In [RFH+ 01] wurden folgende Techniken zur Latenzzeit-Optimierung vorgestellt.3
Latenzoptimiertes Routing Durch Messung der RTT (round trip time) von Testnachrichten wird eine Abstandsmessung vorgenommen. Dann wird bezüglich dieser Abstandmetrik ein Routing durchgeführt, dass nähere Nachbarn bevorzugt. Eine noch bessere Zeitersparnis ergibt sich durch die Topologieangepasste Netzwerkkonstruktion, welche das CAN-Netzwerk von Anfang an gemäß der Latenzzeiten
aufbaut.
Überladen von Zonen Hierbei wird mehreren Peers die Verantwortung für eine Zone übertragen. In
diese Zone werden bis zu M AXPEERS Diese unterhalten dann Kopien der Information oder geben Anfragen
in dieser Zone direkt weiter. Der Vorteil dieser Methode ist, dass für das Routing mehr (latenz-) nahe
Peers zur Verfügung stehe (Außerdem verringert sich der Durchmesser des um den Faktor O(M AXPEERS).
Dadurch verringert sich die Latenzzeit erheblich und die Fehlertoleranz (Verlässlichkeit) wird verbessert.
Datenkopien Daten im CAN-Netzwerk können auch mehrfach unter verschiedenen Adressen abgespeichert werden. Dadurch kombiniert man den Schlüssel mit einer Zahl k aus {1, 2, .., C OPIES} kombiniert.
Auch dies erhöht die Robustheit (Verlässlichkeit) und verringert die Hop-Distanz für den Lookup (und damit die Latenzzeit), da nur noch der Lookup zu der nächsten Kopie notwendig wird. Die Anzahl der Hops
zu der nächsten Kopie nimmt hierbei indirekt proportional mit der Anzahl der Kopien ab.
3 Diese
wurden bereits in der dritten Vorlesung vorgestellt
88
Abbildung 5.7: Zwei Realitäten eines (zwei-dimensionalen) CAN-Peer-to-Peer-Netzwerks
Weitere Designparameter in CAN Die Leistungsfähigkeit von CAN hängt stark von der verwendeten
Dimension d ab. Wählt man einen höherdimensionalen Bildbereich, so verringert sich die Hop-Distanz
O(n1/d ), während sich der (erwartete) Grad auf 2d erhöht.
Ein weiteres Konzept war die Verwendung von verschiedenen Realitäten, siehe Abbildung 5.7. Simultan werden r CAN-Netzwerke aufgebaut, wobei jeder Peer mit für jeder Realität unterschiedlich HashFunktion abgebildet wird. Dadurch erhöht sich der Grad um den Faktor von r, während die verschiedenen
Realitäten sowohl die Zuverlässigkeit als auch die Hop-Distanz und Latenzeit verringert. Vergleicht man
aber diese Werte mit den Gewinnen aus einer Vergrößerung der Dimension, so schneidet die Dimensionserhöherung besser ab.
5.2.2
Routing-Techniken für CHORD: DHash++
Wir haben gesehen, dass in CAN es verschiedene Parameter gibt, die helfen können die Latenz-Zeit und
Zuverlässigkeit zu erhöhen. Auf den ersten Blick hat CHORD nicht diese Vielfalt an Parametern. Tatsächlich kann man aber mit einer Reihe von Techniken auch in CHORD Gewinne in der Latenz-Zeit erreichen.
Wir folgen hier den Untersuchungen von Dabek, Li, Robertson und Kaashoek folgen [DLS+ 04].
In der Datenstruktur von Chord gibt es für jeden Peer b einen Nachfolger (successor) und VorgängerZeiger (predeccessor) auf dem Ring, wo jedem Peer eine zufällige Position zugewiesen wird. Wesentlich
für die Suche sind die Finger:
Für i ∈ {0, .., m − 1} bezeichnet Finger[i] den Peer, dar auf den Wert rV (b + 2i ) auf dem Ring folgt.
Für kleine i werden unterscheiden sich diese Finger-Einträge nciht mehr. Mit hoher Wahrscheinlichkeit
müssen nur O(log n) verschiede Finger gespeichert werden. Chord benötigt mit dieser Struktur O(log n)
Hops für eine Lookup-Operation und O(log 2 n) Hops für das Einfügen oder Entfernen von Peers (jeweils
mit hoher Wahrscheinlichkeit).
Diese Datenstruktur ist nun die Ausgangsbasis von [DLS+ 04]. Ausgehend von Chord werden die folgenden Techniken verwendet, um die Latenzzeit zu verringern.
• Datenlayout
• Rekursion (statt Iteration)
• Nächste Nachbarauswahl
• Replikation versus Kodierung von Daten
• Fehlerkodierungs-optimierter Lookup
• Striped Transport Protocol (statt STP)
Wir werden diese Techniken nun im Detail vorstellen.
89
4
5
#dimensions=2
increasing dimensions, #realities=2
1 reality
2 realities
3 realities
4 realities
d=2, r=2
26.00
24.00
Number of hops
22.00
4096
16K
64K
256K
1M
Number of nodes = 131,072
20.00
r=3
18.00
16.00
r=4
14.00
d=3
12.00
r=5
r=6
Number of nodes
10.00
d=4
8.00
ect of multiple realities on
in
can
by
TT)
is
to
vel
increasing realities, #dimensions=2
d=5
6.00
8
12
16
20
d=6
24
r=7
d=7
28
Number of neighbors
Abbildung 5.8: Hop-Distanz-Verringerung durch Erhöhung der Dimension und der Anzahl der Realitäten
in CAN [RFH+ 01]
Figure 6: Path length with increasing
neighbor state
which is the maximum number of allowable peers per zone (we
imagine that this value would typically be rather low, 3 or 4 for
example).
With zone overloading, a node maintains a list of its peers in
addition to its neighbor list. While a node must know all the peers in
its own zone, it need not track all the peers in its neighboring zones.
Rather, a node selects one node from each of its neighboring zones.
Thus, zone overloading does not increase the90amount of neighbor
information an individual node must hold, but does require it to
Abbildung 5.9: Iterativer Lookup in Chord
Abbildung 5.10: Rekursiver Lookup in Chord
Datenlayout Eine wesentliche Frage, die wir bislang noch nicht untersucht haben, ist, ob die Daten
überhaupt verteilt gespeichert werden sollen?
Die Alternativen ist zum Beispiel ein sogenannter “Key location service”. Hier wird die Referenzinformation auf Dokumente gespeichert. Eine weitere Methode ist die verteilte Datenspeicherung, bei der
die Dokumente auf die Peers verteilt werden. Eine weitere Methode ist die verteilte Speicherung von
Datenblöcken, d.h. Entweder Caching von Datenblöcken oder blockweise Verteilung aller Daten über das
Netzwerk.
Hierzu gibt es weitere Alternativen (die im [DLS+ 04] nicht betrachtet werden). Zum Beispiel die semantische Partitionierung und Speicherung von Dokumenten (wenn wie bei XML-Dokumenten solche
Information verfügbar ist).
Von diesen Methoden verwendet DHash++ eine blockweise (unsemantische) Verteilung aller Daten
über das Netzwerk.
Rekursiver versus Iterativer Lookup Bei der Durchführung eines Lookups in Chord kann man folgende Varianten verwenden:
Iterativer Lookup: Wie in Abbildung 5.9 dargestellt, kontrolliert der Lookup-initiierende Peer die Suche, indem er sukzessive die Peers auf dem Lookup-Pfad nach den Finger-Zeigern abfragt.
Rekursiver Lookup: Hier übergibt jeder Peer die Suchanfrage an den nächsten zuständigen Peer, der
diese dann entsprechend weiterleitet, siehe Abbildung 5.10. Der Zielpeer liefert dann die gesuchte Information direkt an den Initiator des Lookups zurückt.
DHash++ wählt diesen rekursiven Lookup, da der Lookup dann fast um den Faktor zwei schneller
ist als für den iterativen Lookup. In Abbildung 5.11 ist die kumulative Verteilung der Latenzzeiten aus
Simulationen dieser beiden Methoden dargestellt.
Nächste Nachbarauswahl Ein wichtiges Maß, um die tatsächliche Latenzzeit zwischen zwei Peers im
Internet zu messen ist die so genannte Round-Trip-Time (RTT). Dies ist die Zeit, die benötigt wird, um
eine Nachricht zu einem Peer zu schicken und eine Antwort zu erhalten. Diese Zeit wir in einem Ansatz
von Gummadi, Gummadi, Grippe, Ratnasamy, Shenker und Stoica [GGG+ 03] verwendet verwendet, um
91
Abbildung 5.11: Vergleich von iterativen und rekursiven Lookup in Chord [DLS+ 04]
die Nachbarauswahl zu optimieren.
Proximity Neighbor Selection (PNS): Die Routingtabelle der Peers (d.h. hier die Finger) wird hinsichtlich der Latenzzeit (RTT) optimiert. In Chord kann diese Technik wie folgt angewendet werden. Statt
einem Sprung mit Entfernung 2k für einen Finger des Levels k durchzuführen, wird nach dem Peer im
Intervall [2k−1 , 2k [ rechts vom Ausgangspeer auf dem Ring gesucht, der die kleinste Latenzzeit besitzt,
siehe Abbildung ??
ProximityRouteSelection(PRS): Nachdem die Routingtabelle erstellt ist, wird der nächste Nachhbar aus
der Routing-Tabelle genommen.
Wie kann man diese Methode auf Chord anwenden? Statt immer den größtmöglichen Sprung zu nehmen, der noch vor dem Zielpeer liegt, nimmt man den (latenz)-nächsten Sprung, der noch vor dem Zielpeer
auf dem Ring liegt.
Simulationen (Abbildung 5.13) zeigen, dass der größte Gewinn durch PNS erreicht wird, während die
Kombination von PNS und PRS praktisch nicht besser wird als PNS alleine (In der Abbildung fallen diese
Linien aufeinander).
DHash++ verwendet daher nur PNS (Proximity Neighbor Selection). Diese Optimierung ist aber recht
aufwändig, da für die längsten Finger, Abstandsmessungen zu rund einem Viertel aller Peers durchgeführt werden müssen. Statt im gesamten Intervall nach dem nächsten Nachbarn zu suchen wird unter einer
kleine Auswahl von 16 zufällig gewählten Peers ausgewählt (PNS-Sample). In Abbildung 5.14 wird das
(0, 1; 0, 5; 0, 9)-Perzentil einer solchen PNS-Wahl gezeigt (Das p-Perzentil bezeichnet den Wert eines Elements einer Verteilung mit n Element für das pn kleiner sind als dieses Element). Man sieht, dass praktisch
kein Unterschied festgestellt wird für ≥ 16 Samples.
DHash++ nimmt als Strategie die Proximity-Neighbor-Selection mit einer Testmenge von 16 Elementen. Abbildung 5.15 zeigt die durchschnittliche Latenzzeit bei Lookup, bei Wahl von 16 Elementen im
Vergleich mit der kürzesten Wahl.
Interessanterweise nimmt die Latenzzeit mit der Netzwerkgröße kaum zu. Wie kann man sich das erklären. Eine Intuition liefert die folgende Überlegung. Sei L die durchschnittliche Latenzzeit und nehmen
wir an, dass die Latenzzeiten gleichmäßig (uniform) verteilt sind. Mit 2L sind die beiden letzten Hops
am teuersten. Der vorletzte erhält im Erwartungswert Latenzzeit L/2, weil von zwei möglichen Peers der
schnellere genommen wird. Beim nächsten Finger kann man aus vier Nachbarn wählen, was die durchschnittliche Latenzzeit auf L/4 reduziert. Der nächste Finge hat dann Latenzzeit L/8, usw. Nach dieser
92
Finger minimieren
RTT im Intervall
Abbildung 5.12: Wahl der Finger in Chord durch Proximity Neighbor Selection (PNS) [DLS+ 04]
Abbildung 5.13: Vergleich von PNS, PRS und deren Kombination in Chord [DLS+ 04]
93
Abbildung 5.14: (0, 1; 0, 5; 0, 9)-Perzentile eines solchen PNS-samples verschiedener Größ[DLS+ 04]
Abbildung 5.15: Routing Zeit eines PNS-16-samples im Vergleich zu PNS in Chord [DLS+ 04]
94
Überschlagsrechnung ist dann die erwartete Latenzzeit:
L + L + L/2 + L/4 + L/8 + L/16 + L/32 . . . = 3L .
Dieses Verhalten wird durch Simulationen bestätigt.
Kodierung versus Replikation In [AL96] führten Noga Alon und Mike Luby die sogenannten Erasure
Resilient Codes ein. Damit kodiert man ein Dokument aus m Fragmenten in n Fragmente wobei n > m.
Aus jeder Kombination der m Fragmente lässt sich das Original-Dokument herstellen.
Zum Beispiel: Sei r = 1/4 und ein Dokument bestehe aus 16 Fragmenten Dann vergrößert diese
Kodierung das Dokument auf 64 kodierte Fragmente. Es wird dabei die vierfache Speichermenge benötigt.
Um das Dokument abzufragen, können 16 beliebige der 64 kodierten Fragmente genommen werden und
aus diesen kann das Originaldokument rekonstruiert weden. Hakim Weatherspoon und John Kubiatowicz
zeigten in [WK02] für Oceanstore, dass die Verfügbarkeit von Daten enorm zunimmt, wenn man diese
Kodierung verwendet.
DHash++ verwendet einen m = 7, n = 14, r = 2 Erasure Resilient Code. Damit nimmt die Ausfallwahrscheinlichkeit um zwei Zehnerpotenzen ab Dafür erhöht sich die Fetchzeit im Vergleich zu m = 1,
n = 2, und r = 2, d.h. Download-Zeit, um rund 20%. Die Fetchzeit beider Verfahren ist aber immer
noch im Durchschnitt besser als die Daten direkt abzufragen. Eine weitere Eigenschaft dieser Codes ist,
dass beim Schreibzugriff müssen bei dieser Kodierung nur 8 der 14 Fragmente verändert werden müssen.
Dadurch genügt es die 8 nächsten Fragmente zu verändern, was zu einer Zeitersparnis führt.
Integration von Kodierung und Lookup Die Erasure Resilient kodierten Fragmente werden auf k benachbarten Peers auf den Chord-Ring abgelegt. Das Problem ist nun, dass der letzte Hop am teuersten ist.
Nun genügen aber k/2 der k benachbarten Peers genügen, um das Datum zu erhalten (es wird r = 1/2
gewählt). Somit wird die Chord-Suche wird abgebrochen, wenn schon k/2 Peers in diesem Intervalls gefunden worden sind. Dafür wird in der Rekursion die Menge aller Peers, die schon auf den Weg zum Vorgänger des Teilintervalls aufgefunden worden sind, gespeichert. Sind k/2 Peers dabei aufgelaufen, wird
die Rekursion beendet und die bereits gefundenen k/2 Peers beantworten die Suchanfrage.
Performanzgewinn durch diese Komponenten Abbildung 5.16 fasst nun den Performanzgewinn durch
die Komponenten Datenlayout (Base), Rekursion, nächste Nachbarauswahl (Proximity Routing), Replikation versus Kodierung von Daten (Server selection) und Fehlerkodierungs-optimierter Lookup (Integration)
zusammen und zeigt die kumulativen Beschleunigungen. Hierbei zeigt heller Grund die Lookup-Zeit und
dunkler Untergrund die Fetch-Zeit. Auf der linken Seite sieht man einen realen Test, in der Mitte eine
Simulation und auf der rechten Seiten einen Test mit einer Benchmark-Latenzmatrix.
Das Underlay-Netzwerk: Das Internet Das Internet ist das weltweite, offene WAN (wide area network).
Dies ist in der Regel das den Peer-to-Peer-Netzwerken zu Grunde liegende Netzwerk. Das Internet besteht
im wesentlichen aus der Netzwerkschicht IP (Internet Protokoll), dass mit den Unterprotokollen ICMP
(Internet control message protocol) und IGMP (internet group management protocol) für das Routing der
Pakete verantwortlich ist und aus der Transportschicht. In der Transportschicht gibt es neben UDP (User
Datagram Protocol). TCP erzeugt einen zuverlässigen Datenfluß zwischen zwei Rechnern. Es unterteilt Datenströme aus Anwendungsschicht in Pakete und versendet Empfangsbestätigungen (Acknowledgments).
UDP (user datagram protocol) ist dagegen ein einfacher unzuverlässiger Dienst zum Versand von einzelnen Paketen. Hierzu wandelt es die Eingabe in ein Datagramm um, wobei die Anwendungsschicht die
Paketgröße bestimmt. In beiden Protokollen bestimmt IP den eigentlichen Versand. Für eine weitergehende Einführung zu TCP/IP sei auf die Vorlesungsunteralgen “Algorithmische Grundlagen für das Internet”
in den vergangenen Sommersemestern hingewiesen.
Ein eigenes Transport-Protokoll Es stellt sich heraus, dass TCP sich nicht eignet, um den den Lookup in Peer-to-Peer-Netzwerken zu steuern. Das Problem ist der Stauvermeidungsmechanismus von TCP
(congestion avoidance), der dazu dient die Paketmenge im Internet fair und effizient zu kontrollieren.
95
Abbildung 5.16: Kumulativer Performanz-Gewinn in DHash++ [DLS+ 04]
Hierzu passt TCP die Datenrate an. TCP startet beim Versenden mit einem Paket pro RTT (slow start)
und verdoppelt es in nach dem erfolgreichen Empfangen von Paketen. Dadurch erhöht sich die Latenzzeit.
TCP arbeitet erst effizient bei einer kleinen Anzahl von langlaufenden Verbindungen.
UDP ist keine Lösung, da UDP unzuverlässig (kein Acknowledgment) arbeitet. Deutlich wird dieser
Umstand, wenn man berücksichtigt, dass im Routing-Layer Pakete absichtlich (!) gelöscht werden.
In DHash++ wird UDP als Basis für eigenes Protokoll verwendet: Striped Transport Protocol (STP).
Dies verwendet wie TCP einen Fenster-Kontrollmechanismus zur Datenratenanpassung, verwendet aber
keinen fast-retransmit. TCP verwendet implizites Wissen über die Paketordnung, um verlorengegangen
Pakete schnell nachzusenden. Wegen der stark variierenden Latenzzeiten in CHORD geht diechronologische Ordnung der Pakete verloren. Deswegen kann STP wesentlich schneller Pakete ausliefern, wie Abbildung 5.17 zeigt.
Vergleich von TCP und SCP in DHash++
Diskussion DHash++ DHash++ kombiniert eine Reihe von Techniken zur Verbesserung der Latenzzeit
des Lookups und des Daten-Fetch. DHash++ erhöht dabei Zuverlässigkeit des Datenzugriffs. Dies wird
erreicht durch Latenzoptimierte Routing-Tabellen, Redundante Datenkodierung, Aufbau der Datensuche,
Änderungen in der Transportschicht, und geeignete Integration der Komponenten. Alle diese Komponenten können auch auf andere Peer-to-Peer-Netzwerk angewendet werden. (Tatsächlich sind einige schon
integrale Bestandteile anderer (z.B. Datenkodierung aus Oceanstore und Latenzoptimierung in Pastry).
96
Abbildung 5.17: Vergleich von STP und TCP in DHash++ [DLS+ 04]
97
98
Literaturverzeichnis
[AL96]
A LON und L UBY: A Linear Time Erasure-Resilient Code with Nearly Optimal Recovery.
IEEETIT: IEEE Transactions on Information Theory, 42, 1996.
[DGH+ 87] D EMERS , A LAN, DAN G REENE, C ARL H AUSER, W ES I RISH, J OHN L ARSON, S COTT
S HENKER, H OWARD S TURGIS, DAN S WINEHART und D OUG T ERRY: Epidemic Algorithms
for Replicated Database Maintenance. In: S CHNEIDER , F RED B. (Herausgeber): Proceedings of the 6th Annual ACM Symposium on Principles of Distributed Computing, Seiten
1–12. ACM Press, 1987.
[DGMY02] DASWANI , N EIL, H ECTOR G ARCIA -M OLINA und B EVERLY YANG: Open Problems in
Data-Sharing Peer-to-Peer Systems. In: Proceedings of the 9th International Conference on
Database Theory, Seiten 1–15. Springer-Verlag, 2002.
[DH76]
D IFFIE , W HITFIELD und M ARTIN E. H ELLMAN: New Directions in Cryptography. IEEE
Transactions on Information Theory, IT-22(6):644–654, 1976.
[DLS+ 04]
DABEK , F., J. L I, E. S IT, J. ROBERTSON, M. K AASHOEK und R. M ORRIS: Designing a
DHT for low latency and high throughput, 2004.
[Dou02]
D OUCEUR , J.: The sybil attack, 2002.
[DR01a]
D RUSCHEL , P. und A. ROWSTRON: PAST: A Large-Scale, Persistent Peer-to-Peer Storage
Utility. In: IEEE (Herausgeber): Eighth IEEE Workshop on Hot Topics in Operating Systems
(HotOS-VIII). May 20–23, 2001, Schloss Elmau, Germany, Seiten 75–80, 1109 Spring Street,
Suite 300, Silver Spring, MD 20910, USA, 2001. IEEE Computer Society Press.
[DR01b]
D RUSCHEL , P ETER und A NTONY ROWSTRON: Pastry: Scalable, distributed object location
and routing for large-scale peer-to-peer systems. In: G UERRAOUI , R ACHID (Herausgeber):
Middleware 2001, IFIP/ACM International Conference on Distributed Systems Platforms
Heidelberg, Germany, November 12-16, 2001, Proceedings, Band 2218 der Reihe Lecture
Notes in Computer Science, Seiten 329–350. Springer, 2001.
[FS02]
F IAT, A MOS und JARED S AIA: Censorship Resistant Peer-to-Peer Content Addressable Networks. In: Proceedings of Symposium on Discrete Algorithms, 2002.
[GGG+ 03] G UMMADI , K., R. G UMMADI, S. G RIBBLE, S. R ATNASAMY, S. S HENKER und I. S TOI CA : The impact of DHT routing geometry on resilience and proximity. In: Proceedings of
the 2003 conference on Applications, technologies, architectures, and protocols for computer
communications, Seiten 381–394. ACM Press, 2003.
[GMR88]
G OLDWASSER , S HAFI, S ILVIO M ICALI und RON L. R IVEST: A Digital Signature Scheme
Secure Against Adaptive Chosen-Message Attacks. SIAM Journal on Computing, 17(2):281–
308, 1988.
[Gnu]
G NUTELLA: The Gnutella protocol specification v0.4.
99
[HJS+ 03]
H ARVEY, N., M. J ONES, S. S AROIU, M. T HEIMER und A. W OLMAN: Skipnet: A scalable
overlay network with practical locality properties. In: In Proceedings of USITS (Seattle, WA,
March 2003), USENIX, 2003.
[HKRZ02] H ILDRUM , K., J. D. K UBIATOWICZ, S. R AO und B. Y. Z HAO: Distributed Object Location
in a Dynamic Network. In: Proceedings of the 14th Annual ACM Symposium on Parallel
ALgorithms and Architectures (SPAA-02), Seiten 41–52, New York, August 10–13 2002.
ACM Press.
[JAB01]
J OVANOVIC , M. A., F. S. A NNEXSTEIN und K. A. B ERMAN: Scalability Issues in large
Peer-to-Peer Networks — a Case Study of Gnutella. Technischer Bericht, Univ. of Cincinnati,
2001.
[JM04]
J ELASITY, M ÁRK und A LBERTO M ONTRESOR: Epidemic-Style Proactive Aggregation in
Large Overlay Networks. In: 24th International Conference on Distributed Computing Systems (ICDCS 2004), 24-26 March 2004, Hachioji, Tokyo, Japan, Seiten 102–109. IEEE Computer Society, 2004.
[JMÖB04] J ELASITY, M ÁRK, A LBERTO M ONTRESOR und Ö ZALP BABAOGLU: A Modular Paradigm for Building Self-Organizing Peer-to-Peer Applications. In: S ERUGENDO , G IOVAN NA D I M ARZO , A NTHONY K ARAGEORGOS, O MER F. R ANA und F RANCO Z AMBONELLI
(Herausgeber): Engineering Self-Organising Systems, Nature-Inspired Approaches to Software Engineering [revised and extended papers presented at the Engineering Self-Organising
Applications Workshop, ESOA 2003, held at AAMAS 2003 in Melbourne, Australia, in July
2003 and selected invited papers from leading researchers in self-organisation], Band 2977
der Reihe Lecture Notes in Computer Science, Seiten 265–282. Springer, 2004.
[JZK02]
J OSEPH , A NTHONY D., B EN Y Z HAO und J OHN K UBIATOWICZ: Tapestry: An Infrastructure for Fault-tolerant Wide-area Location and Routing. Januar 15 2002.
[KK03]
K ARGER , DAVID R. und M. F RANS K AASHOEK: Koorde: A simple degree-optimal distributed hash table. Februar 10 2003.
[KKPS00]
K ARP, R ICHARD, E LIAS KOUTSOUPIAS, C HRISTOS H. PAPADIMITRIOU und S COTT
S HENKER: Optimization problems in congestion control. In: 41st Annual Symposium on
Foundations of Computer Science (FOCS’00), Seiten 66–74, 2000.
[KLL+ 97] K ARGER , DAVID, E RIC L EHMAN, T OM L EIGHTON, M ATTHEW L EVINE, DANIEL L EWIN
und R INA PANIGRAHY: Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web. In: Proceedings of the Twenty-Ninth
Annual ACM Symposium on Theory of Computing, Seiten 654–663, El Paso, Texas, 4–6 Mai
1997.
[KSSV00]
K ARP, R ICHARD, C HRISTIAN S CHINDELHAUER, S COTT S HENKER und B ERTHOLD
V ÖCKING: Randomized Rumor Spreading. In: 41st Annual Symposium on Foundations of
Computer Science (FOCS’00), Seiten 565–574, 2000.
[LSP95]
L AMPORT, S HOSTAK und P EASE: The Byzantine Generals Problem. In: Advances in UltraDependable Distributed Systems, N. Suri, C. J. Walter, and M. M. Hugue (Eds.), IEEE Computer Society Press. 1995.
[Min01]
M INAR , N ELSON: Distributed Systems Topologies.
http://www.openp2p.com/pub/a/p2p/2001/12/14/topologies_one.html, 2001.
[MNR02]
M ALKHI , DAHLIA, M ONI NAOR und DAVID R ATAJCZAK: Viceroy: a scalable and dynamic
emulation of the butterfly. In: Proceedings of the twenty-first annual symposium on Principles
of distributed computing, Seiten 183–192. ACM Press, 2002.
100
[NW03]
NAOR , M ONI und U DI W IEDER: Novel architectures for P2P applications: the continuousdiscrete approach. In: Proceedings of the fifteenth annual ACM symposium on Parallel algorithms and architectures, Seiten 50–59. ACM Press, 2003.
[Pit87]
P ITTEL , B ORIS: On Spreading a Rumor. SIAM Journal on Applied Mathematics, 47(1):213–
223, Februar 1987.
[PRR97]
P LAXTON , C. G REG, R AJMOHAN R AJARAMAN und A NDREA R ICHA: Accessing Nearby
Copies of Replicated Objects in a Distributed Environment. In: 9th Annual ACM Symposium
on Parallel Algorithms and Architectures (SPAA ’97), Seiten 311–320, New York, Juni 1997.
Association for Computing Machinery.
[RFH+ 01] R ATNASAMY, S., P. F RANCIS, M. H ANDLEY, R. K ARP und S. S HENKER: A scalable
content-addressable network. In: Computer Communication Review, Band 31, Seiten 161–
172. Dept. of Elec. Eng. and Comp. Sci., University of California, Berkeley, 2001.
[RSA78]
R IVEST, R., A. S HAMIR und L. A DLEMAN: On digital signatures and public key cryptosystems. Comm. A.C.M., 21:120–126, 1978.
[Shi01]
S HIRKY, C.: Listening to Napster. In Oram, A., (ed) Peer-to-Peer: Harnessing the Benefits of
a Disruptive Technology, O’Reilly and Associates, Inc., Sebastopol, California., 2001.
[SMK+ 01] S TOICA , I ON, ROBERT M ORRIS, DAVID K ARGER, F RANS K AASHOEK und H ARI BA LAKRISHNAN : Chord: A Scalable Peer-To-Peer Lookup Service for Internet Applications.
In: G UERIN , ROCH (Herausgeber): Proceedings of the ACM SIGCOMM 2001 Conference
(SIGCOMM-01), Band 31, 4 der Reihe Computer Communication Review, Seiten 149–160,
New York, August 27–31 2001. ACM Press.
[WK02]
W EATHERSPOON , H AKIM und J OHN D. K UBIATOWICZ: Erasure Coding Vs. Replication: A
Quantitative Comparison. Lecture Notes in Computer Science, 2429:328–??, 2002.
[Zim92]
Z IMMERMAN , P.: PGP user’s guide, 1992.
101