Hierarchische P2P-Netze

BTU Cottbus
Wintersemester 2005/06
Seminar P2P Networking
Hierarchische P2P-Netze
Uwe Mannl
Klassische unstrukturierte und strukturierte Peer-To-Peer-Netzwerke haben jeweils für sich
Vorteile, aber natürlich auch Nachteile. Doch eines zeichnet sie alle aus: sie sind flach. Nur
stellt sich die Frage, warum man sich darauf beschränken soll. Schließlich ist das Internet
selber auch nicht nur flach. In vielen Bereichen kommen schon hierarchische Prinzipien zum
Einsatz, wie zum Beispiel beim Domain Name System.
In diesem Text wird deshalb erläutert, wie man beide bisherigen Systeme um die Möglichkeit
der Hierarchie erweitern kann, um damit zum einen die Skalierbarkeitsprobleme
einzugrenzen, zum anderen aber eine mindestens gleich gute, wenn nicht sogar bessere
Robustheit zu gewährleisten. Dazu wird im ersten Teil erläutert, wie man bisherige
unstrukturierte P2P-Netze wie Gnutella zu Super-P2P-Netzwerken erweitern kann. Diese
P2P-Netze mit ihrem wichtigstem Vertreter, dem FastTrack-Protokoll, bilden die 3.
Generation der P2P-Netzwerke.
Folgend darauf wird eingegangen, wie in diese Super-P2P-Netzwerke noch die Vorteile der
strukturierten Netze mit ihren Distributed Hash Tables eingearbeitet werden kann.
Inhaltsverzeichnis
1 Einführung............................................................................................................................... 2
2 Netzarchitekturen .................................................................................................................... 2
2.1 Pure P2P-Systeme ............................................................................................................ 2
2.2 Hybride P2P-Systeme ...................................................................................................... 3
2.3 Super-P2P-Systeme.......................................................................................................... 3
3 Suche in Super-P2P-Systemen ................................................................................................ 4
4 Hierarchical DHTs .................................................................................................................. 5
5 Topologien .............................................................................................................................. 6
5.1 Chord................................................................................................................................ 6
5.2 Chord als Top-Level-Netzwerk........................................................................................ 8
5.3 Bottom-Level-Netzwerke................................................................................................. 8
6 Vorteile.................................................................................................................................... 9
6.1 Skalierbarkeit ................................................................................................................... 9
6.2 Robustheit....................................................................................................................... 10
6.3 Suchoptimierungen......................................................................................................... 10
7 Beispiele für hierarchische P2P-Netzwerke.......................................................................... 11
7.1 FastTrack........................................................................................................................ 11
7.2 Gnutella (3. Generation)................................................................................................. 12
8 Literatur................................................................................................................................. 14
1

1 Einführung
Hierarchische Peer-To-Peer-Systeme mit ihrer hierarchischen Struktur bilden das Gegenstück
zu flachen P2P-Systemen, wie es z.B. bei Gnutella in der 1. Generation der Fall ist. Statt dass
es wie bei Gnutella keine Unterscheidung der einzelnen Peers gibt, existieren in
hierarchischen P2P-Systemen Rollen für die Peers. Neben den normalen Peers werden
manchen Peers, erfüllen sie bestimmte Voraussetzungen, die Aufgabe so genannter Super-
Peers zugewiesen. Aus diesem Grund werden solche Systeme Super-P2P-Systeme oder kurz
Super-Peer-Systems genannt.
Gleichzeitig sind hierarchische P2P-Systeme eine Mischform aus dem typischen
zentralisierten Client-Server-Modell und dem dezentralisierten Modell, welches auch in
Gnutella zu tragen kommt. Kein Computer übernimmt im dezentralisierten Modell die
Aufgabe eines Servers, sondern alle angeschlossenen Peers sind in ihrem Erscheinen und ihrer
Aufgabe gleich. In der Literatur wird das Super-P2P-Netzwerk deswegen auch als eine
Mischform aus dem puren P2P-Netzwerk und dem hybriden-P2P-Netzwerk bezeichnet. Es
wird im nächsten Abschnitt „Netzarchitekturen“ auf die eben genannten Netzformen
nochmals eingegangen, um eine bessere Erklärung der hierarchischen P2P-Systeme zu
ermöglichen.
Als wichtigsten Vertreter der hierarchischen P2P-Systeme ist das FastTrack-Netzwerk zu
nennen, welches sich sogar mit Hilfe der Programme KaZaA und deren freien Alternativen
zum größten P2P-Netzwerk für allgemeinen Datenaustausch entwickelt hatte [1].
Der Einsatz von hierarchischen P2P-Netzen beschränkt sich aber nicht nur auf den
Dateiaustausch mittels Tauschbörsen, sondern hat noch weitere Anwendungsgebiete. So wäre
das Overlay Multicast zu nennen, bei dem es darum geht, dass ein Sender Daten an mehrere
Empfänger gleichzeitig schickt. So ist in dem NICE-Protokoll eine hierarchische Topologie
implementiert.
2 Netzarchitekturen
Um den Aufbau eines hierarchischen P2P-Netzwerkes besser verstehen zu können ist es
hilfreich, erst einmal die beiden Grundformen von P2P-Systemen in ihrem Aufbau und ihrer
Arbeitsweise zu kennen. Der Name Peer-To-Peer-Netzwerke kommt daher, dass zum
eigentlichen Übertragen von Informationen zwischen den beiden Peers eine direkte
Verbindung aufgebaut wird. Dies geschieht natürlich erst nach dem Suchen, und genau hier
liegen die Hauptunterschiede der verschiedenen Peer-To-Peer-Netzwerkarchitekturen.
2.1 Pure P2P-Systeme
Wie schon erwähnt kommen pure P2P-Systeme wie Gnutella ganz ohne Server aus. Jeder
Peer, der im speziellen Fall von Gnutella auch Servant oder Servent genannt wird [2],
übernimmt dieselben Aufgaben wie das Routing und das Suchen. So funktioniert zum
Beispiel eine Suche nach dem Schneeballprinzip: Ein Peer schickt die Anfrage, im englischen
Query genannt, an alle ihm bekannten anderen Peers. Diese schauen nach ob sie die
entsprechende Information, meist eine Datei, besitzen, und schicken zusätzlich die Anfrage an
alle ihnen bekannten Peers weiter. Zusätzlich bekommt jede Suchanfrage einen TTL-Flag
(Time-To-Live-Flag) mit gesandt, welcher angibt, wann eine Suchanfrage stirbt.
Beispielsweise bedeutet ein TTL-Flag von 1, dass die Suchanfrage vom anfragenden
2

Computer aus nur zu seinen direkten Nachbarn geht, von dort aber nicht weitergeleitet wird.
Erst bei einem höheren TTL-Flag würden diese Nachbarn ihr Suchanfrage wiederum an ihre
Nachbarn übermitteln.
Ergibt eine Suchanfrage einen Erfolg, also wurde die Datei gefunden, so wird zwischen dem
anfragenden Peer und dem Peer mit der Datei eine direkte Verbindung aufgebaut, um darüber
die Datei zu übertragen.
2.2 Hybride P2P-Systeme
Hybride P2P-Systeme sind ihrerseits eine Mischung aus den puren P2P-Systemen
(dezentrales Modell) und dem Client-Server-Modell (zentrales Modell). Alle Suchanfragen
richtet ein Peer an einem ihn bekannten Server, welcher die Suchanfragen bearbeitet und eine
Antwort dem Peer zurücksendet, von wo er die entsprechende Datei bekommen kann. Dies ist
der Client-Server-Teil. Der Peer baut daraufhin die direkte Verbindung zu dem anderen Peer
auf. Dies ist der dezentrale Teil, da die Verbindung dann direkt erfolgt und nicht mehr über
den Server.
Das bekannteste Beispiel für ein Hybrides P2P-System ist die erste erfolgreiche und
allgemein bekannte Tauschbörse Napster. Diese lief damals mit 200 Index-Servern [3], auf
welche beim Programmstart eine Liste der zur Verfügung stehenden Dateien übertragen
wurde. Die Server waren jedoch nicht untereinander synchronisiert, was zur Folge hatte, dass
eine Suchanfrage an einen Server nie die Clients bekannt gab, welche zu den anderen Servern
verbunden waren [1].
In einigen Veröffentlichungen wird Napster den Super-P2P-Systemen mit nur einer Gruppe
zugeschrieben, welche jetzt vorstellt werden.
2.3 Super-P2P-Systeme
In den Super-P2P-Systemen wird versucht, den Vorteil der effizienten, zentralisierten Suche
mit dem Vorteil der autonomen, lastverteilten und gegen Angriffe robusten dezentralen Suche
unter einen Hut zu bringen. Zusätzlich schafft man es so, die unterschiedlichen Stärken der
einzelnen Peers wie Bandbreite und Rechenleistung zu nutzen [4].
Abbildungen 1 und 2 zeigen den typischen Aufbau eines Super-Peer-Systems. Jeder Peer,
welcher in einem Graphen als Knoten bezeichnet wird, gehört einer Gruppe an. Es wird in
Abbildung 1 nur der so genannte Top-Level-Overlay gezeigt, welcher die Verbindung
zwischen den Gruppen darstellt.
Abbildung 1: Top-Level-Overlay eines Super-Peer-Systems (entnommen [6])
3

In Abbildung 2 wird dann sichtbar, wie die Kommunikation zwischen den Gruppen erfolgt.
Die grau gefüllten Kreise entsprechen SuperPeers, die weißen, ungefüllten Kreise stehen für
normale Peers. Für die Kommunikation zwischen den Gruppen sind die SuperPeers zuständig,
denn nur diese senden Anfragen der Peers weiter.
Abbildung 2: Aufbau eines Super-Peer-Netzwerkes (entnommen [6])
Dazu muss jeder Peer mit einem SuperPeer aus der Gruppe verbunden sein. Pro Gruppe
existiert mindestens 1 SuperPeer, mehrere sind jedoch genauso möglich und erhöhen die
Robustheit des Netzwerkes. Die Auswahl der SuperPeers erfolgt nach gewissen Kriterien,
wonach bestimmte Peers bevorzugt werden. Zu den Kriterien zählen einerseits die
Rechenleistung sowie die Bandbreite der Anbindung an das Netz, andererseits aber auch, wie
lange ein Peer im Vergleich zu anderen schon im Netz aktiv ist. Verbindet sich beispielsweise
ein neuer Peer mit dem Netzwerk und meldet sich in einer entsprechenden Gruppe an, so
übermittelt er dem zuständigen SuperPeer neben anderen Informationen auch seine
Leistungsdaten. Anhand dieser Daten aller Peers in einer Gruppe kann ein SuperPeer
entscheiden, welcher Peer am ehesten geeignet ist, um die Rolle eines zusätzlichen oder neuen
SuperPeers zu übernehmen. Genauso muss im Falle des Ausfalls eines SuperPeers
entschieden werden, welcher Peer dessen Funktionen übernimmt. Bei der Ernennung eines
neuen SuperPeers werden alle Peers in der Gruppe darüber informiert sowie die SuperPeers in
den benachbarten Gruppen. Damit wird eine gute Stabilität des Top-Levels erreicht.
Sinnvoll bei der Bildung von Gruppen ist es darauf zu achten, dass topologisch nahe liegende
Peers zu einer Gruppe zusammengefasst werden. Diese hätten dann eine höhere Chance für
bessere Übertragungsraten untereinander, was zum dem Vorteil des Content-Cachings führt.
Dieses wird im Abschnitt 6.3 „Suchoptimierungen“ genauer dargelegt. Während man bei der
Kommunikation der SuperPeers untereinander vom Top-Level-Overlay spricht, so wird der
Zusammenschluss der Peers innerhalb einer Gruppe als Bottom-Level oder auch Intra-Group
bezeichnet.
3 Suche in Super-P2P-Systemen
Super-P2P-Systeme sind im Allgemeinen unstrukturierte P2P-Systeme. Von strukturierten
hierarchischen P2P-Systemen spricht man erst, wenn zum Beispiel Verteilte Hash-Tabellen
genutzt werden, wie im nächsten Abschnitt „Hierarchical DHTs“ beschrieben wird.
4

Die Suchanfrage in Super-P2P-Systemen erfolgt also ähnlich wie in den puren P2P-Systemen.
Die SuperPeers haben jedoch noch die zusätzliche Aufgabe, einen Index zu verwalten. In
diesem Index steht, welcher Peer welche Informationen, Daten oder speziell Dateien besitzt.
Der SuperPeer speichert nur die Informationen der an ihm angeschlossenen Peers, also aller
Peers in seiner Gruppe
Abbildung 3 zeigt den Ablauf einer Suche, die von Peer P1 gestartet wird. Er schickt seine
Anfrage nach der Datei k an einen beliebigen SuperPeer seiner Gruppe g1. Dieser behandelt
die Suchanfrage jetzt wie seine eigene, und schaut zuerst nach, ob ein anderer Peer derselben
Gruppe die von P1 erfragte Datei besitzt. Zusätzlich wird die Suchanfrage an alle von g1
bekannten Nachbarn geschickt, in dem Fall an g2 und g4. Die SuperPeers schauen jeweils
wieder in der eigenen Gruppe nach, und senden die Anfrage außerdem an g3 weiter. Die
Suche erfolgt also nur zwischen den SuperPeers auf dem Top-Level-Overlay. Der SuperPeer
der Gruppe g3 hat schließlich in seinem Index stehen, dass Peer P2 die gesuchte Datei besitzt.
Demzufolge kann dieser SuperPeer die Daten über P2, wie seine IP-Adresse, auf dem
gleichen Weg, wie die Suche erfolgt, zurückschicken. P1 kann damit dann eine direkte
Verbindung zu P2 aufbauen und die entsprechende Datei empfangen.
Abbildung 3: Suchablauf in einem Super-Peer-Netzwerk (angelehnt an [6])
Die Suche in unstrukturierten Super-P2P-Systemen besitzt dieselben Nachteile wie die in
puren P2P-Systemen. So ist zwar bei gleicher Anzahl von Teilnehmern im Netz zwar
ausgeschlossen, dass langsame Peers die Suche beeinträchtigen, aber gleich viele Teilnehmer
bedeuten auch gleich viele Suchanfragen und damit eine nicht geringer gewordene Flut von
Suchanfragen, die die SuperPeers bewältigen müssen. Auch ist die Suche nach seltenen Daten
wenig effizient, da nie sichergestellt ist, dass eine Suchanfrage bis zu der Gruppe mit der
entsprechenden Information angelangt. Der TTL-Flag ist schließlich auch hier nötig, um
Suchen nach gewisser Zeit abzubrechen.
4 Hierarchical DHTs
Verteilte Hash-Tabellen (Distributed Hash Tables, kurz DHTs) ermöglichen in flachen,
strukturierten Netzen das schnelle Auffinden von Dateien, indem jeder Datei ein eindeutiger
Key zugewiesen wird. Jeder Peer erhält dann die Zuständigkeit für einen Teil der Hash-
Tabelle, also für bestimmte Keys. Er weiß sozusagen, wo die entsprechenden Dateien liegen.
Erfolgt eine Anfrage nach einer Datei, so sucht der Peer bei sich, ob er zuständig ist. Ist dies
nicht der Fall, wird die Anfrage zu anderen Peers weitergeleitet, wobei zum Peer geroutet
5

wird, welcher für den Key zuständig ist. Dies kann gezielt zum entsprechenden Peer
geschehen, da die Bereiche linear aufgeteilt sind und Anfragen immer an dem zum Key
nahesten Peer weitergeleitet werden. Dabei ist die Datenverteilung an eine entsprechende
Topologie gebunden. Diese bestimmt, welche Peers zu Nachbarn werden.
In hierarchischen DHTs gibt es jetzt den Unterschied, dass die Suchanfragen zuerst die
Gruppe finden, welche für den Key zuständig ist, dann den Peer in dieser Gruppe, welcher
den Key verwaltet. Dies geschieht ähnlich wie bei den unstrukturierten Super-P2P-Systemen,
nur dass nicht eine bestimmte Datei gesucht wird sondern der Schlüssel zu der Datei.
Im Speziellen bedeutet das: Die Suchanfrage eines Peers geht direkt an einen SuperPeer
seiner Gruppe. Von dort aus sendet der SuperPeer die Anfrage auf dem so genannten Top-
Level weiter, bis die Gruppe gefunden ist, welche für den Key zuständig ist. Dabei wird auch
nur von SuperPeer zu SuperPeer geroutet, die restlichen Peers spielen in der Top-Level-Suche
keine Rolle. Erreicht die Anfrage den entsprechenden SuperPeer, so leitet dieser dann die
Anfrage weiter zum entsprechenden Peer, welcher den Key verwaltet. Dieser Peer kann dann
eine Antwort an den anfragenden Peer schicken. Das geschieht entweder mittels direkter
Verbindung oder einfach rückwärts den Weg, über welcher die Anfrage kam [5].
Möglichkeiten der Suchstrategien im Top-Level sowie im Bottom-Level werden im nächsten
Abschnitt „Topologien“ angeführt.
Interessant ist noch der Aufbau einer Gruppe in einer hierarchischen DHT. Will ein Peer am
Netz mit teilnehmen, so muss ihm eine Gruppe zugewiesen werden. Dazu benötigt er
Informationen wie seine eigene ID, die ID, zu welcher Gruppe er gehören soll und die IP-
Adresse eines schon im Netz vorhandenen Peers. Eine ID ist ein eindeutige Schlüssel oder
eine eindeutige Nummer, die genau den Peer oder die Gruppe ausweist. Die Wahl der
Gruppen-ID wird auch hier anhand verschiedener Gesichtspunkte getroffen.
Beim Anmelden im Netz wird zuerst der schon im Netz aktive Peer kontaktiert und gefragt,
wo die Gruppe zu finden ist, zu welcher der neue Peer angehören wird. Dazu schickt der neue
Peer eine Suchanfrage nach seiner Gruppen-ID los. Über den schon im Netz aktiven Peer
erhält er dann die IP-Adressen der SuperPeers mit der entsprechenden Gruppen-ID. So kann
sich der neue Peer dann in der Gruppe anmelden. Es kann aber auch vorkommen, dass die als
Antwort erhaltende Gruppen-ID nicht exakt seiner eigenen entspricht. In dem Fall macht der
neue Peer eine neue Gruppe mit seiner Gruppen-ID auf, in der er selber der bis dato einzige
SuperPeer ist.
5 Topologien
Es gibt verschiedene Strategien zum Aufbau des Top-Levels sowie des Bottom-Levels. Hier
können schon vorhandene Strukturen adaptiert werden, um z.B. geringste Suchdauern zu
ermöglichen.
Es wird hier nur auf eine spezielle Top-Level DHT eingegangen, die auch in anderen
strukturierten P2P-Systemen zum Einsatz kommt, nämlich Chord. Andere Formen der DHTs
finden sich unter [7], und benötigen ähnlich wie Chord geringfügige Anpassungen, um im
Top-Level-Overlay Verwendung finden zu können
5.1 Chord
Im Chord-System hat jeder Peer und jeder Schlüssel eine m-stellige Bitfolge als ID. Diese IDs
kann man sich auf einem Ring mit dem Umfang von 2 m vorstellen. Jeder Schlüssel ist einem
Peer zugeordnet, dessen ID gleich ist oder der als nächstes in der Reihe folgt. Dieser Peer
6

wird Successor (Nachfolger) vom Key k genannt. Jeder Peer kennt seinen nachfolgenden und
seinen vorgehenden Peer in dem Ring. Zusätzlich kennt jeder Peer noch m andere Peers, die
so genannten Fingers. Diese werden in einer Finger-Table eines Peers zusammengefasst. Wer
ein Finger eines Peers ist bestimmt folgender Algorithmus: Ein Peer mit der ID p kennt alle
Peers mit den IDs p+2 j-1 (für j von 1 bis m). All diese Informationen ergeben die Chord-
Routing-Table [5]. Abbildung 4 zeigt den Aufbau eines solchen Ringes.
Abbildung 4: Aufbau eines Chord-Ringes (entnommen [6])
Abbildung 5 zeigt den Ablauf einer Suche innerhalb eines Chord-Ringes. Bei einer Suche
nach einer bestimmten Datei wird nach dem entsprechenden Schlüssel dieser Datei gesucht.
Sucht Knoten N8 nach dem Schlüssel 54, so wird die Anfrage an den Peer weitergeleitet,
dessen ID am nächsten ist. N8 hat in seiner Finger-Table den Knoten N42 mit der höchsten ID
zu 54 stehen und leitet die Anfrage an den Knoten weiter. Von N42 geht es dann über N51 zu
N56, welcher für den Key 54 zuständig ist.
Abbildung 5: Suche in Chord (entnommen [7])
Um das Prinzip von Chord auf dem Top-Level eines hierarchischen P2P-Systems anwenden
zu können bedarf es einiger Modifikationen. Diese werden im folgenden Abschnitt „Chord als
Top-Level-Netzwerk“ beschrieben. Der Einfachheit halber wird diese vorm des
hierarchischen Cords auch als Top-Level-Chord bezeichnet.
7

5.2 Chord als Top-Level-Netzwerk
Wie in Abbildung 4 zu sehen ist, besteht der Ring jetzt nicht mehr aus einzelnen Peers,
sondern aus Gruppen. Dies sind genau die Gruppen des Super-P2P-Systems. So sind der
Vorgänger und der Nachfolger nicht mehr einzelne IP-Adressen der Peers, sondern Vektoren,
in denen jeweils die IP-Adressen der SuperPeers in der Nachfolgergruppe bzw. der
Vorgängergruppe stehen. Genauso sind die Fingers jetzt Vektoren mit den IP-Adressen der
entsprechenden SuperPeers in den Gruppen, auf die der Finger zeigt. Die Routing-Tabelle
eines solchen Chords ist in Abbildung 6 gezeigt.
Abbildung 6: Chord in einem Top-Level-Netzwerk (entnommen [6])
Fällt ein einzelner Peer aus (in diesem Fall sind nur die Ausfälle von SuperPeers relevant), so
spielt das aus der Sicht des Chord-Ringes weniger eine Rolle als beim klassischen Chord. Es
tritt in der Gruppe ein anderer Peer an dessen Stelle und wird zum SuperPeer. Dieser neue
SuperPeer aktualisiert die Vektoren der Vorgänger- und Nachfolgergruppen und gewährleistet
somit, dass jede Gruppe einen aktuellen Stand über ihre Vorgänger- und Nachfolgergruppen
hat. Bei den Fingers verhält es sich leicht anders, da Suchanfragen auch ohne Fingers möglich
sind. Die Anfragen können auch nur über Vorgänger und Nachfolger ihr Ziel erreichen, wenn
auch mit höherer Laufzeit. Fingers sind also nicht kritisch für den Zusammenhalt des Rings
und werden deswegen erst aktualisiert, wenn festgestellt wird, dass eine Referenz ungültig
geworden ist.
5.3 Bottom-Level-Netzwerke
Hierarchische P2P-Netzwerke bieten den Vorteil, dass verschiedene Netzstrukturen
zusammengeschlossen werden können, je nachdem, was an bestimmten Stellen besser zum
Einsatz kommt. So können die Bottom-Level-Netze eine andere Topologie als das Top-Level-
Overlay besitzen, und selbst zwischen den Gruppen kann der Aufbau der Bottom-Level-Netze
unterschiedlich sein. So eignen sich für die Intra-Group-Suche verschiedene Strategien, je
nachdem wie viele Teilnehmer eine Gruppe hat.
8

Für Gruppen mit einer kleinen Anzahl an Peers ist ein komplizierter Aufbau des Bottom-
Levels wie z.B. mit Chord nicht nötig, da jeder Rechner genug Leistung aufbringen kann um
selbst alle nötigen Informationen zu speichern. In dem Fall lässt sich CARP oder Consistent-
Hashing nutzen. [5] Dabei speichert jeder Peer die IDs und IP-Adressen aller anderen Peers
derselben Gruppe in einem eigenen Index. Jeder Peer hat dadurch eine Hash-Tabelle, in der
steht, welcher Peer in der Gruppe für welchen Schlüssel zuständig ist. Im Fall von CARP
bilden alle Peers einen Cluster mit einem Master und mehreren Slaves. Nach außen hin, also
aus der Sicht des Top-Level-Overlays, hat der Cluster nur eine virtuelle IP-Adresse, über die
der Cluster angesprochen werden kann. [8]
Für Gruppen mit mehreren Hundert Peers wäre ein SuperPeer effizient, welcher alle Peers in
der Gruppe verwaltet, und alle Suchanfragen und Routingaufgaben übernimmt. Dies
entspricht dem typisch Client-Server-Prinzip, wobei der Server gleichzeitig der SuperPeer ist,
der die Kommunikation zum Top-Level-Overlay übernimmt.
Gruppen mit noch höherer Teilnehmerzahl sollten auf erprobte Systeme mit DHTs wie Chord,
CAN, Pastry oder Tapestry zurückgreifen, um bestmögliche Stabilität und Effizienz zu
gewährleisten.
6 Vorteile
6.1 Skalierbarkeit
Es besteht die Möglichkeit, ein hierarchisches P2P-System nicht nur aus 2, sondern aus 3 oder
mehreren Ebenen aufzubauen. Hierfür eignet es sich, im Bottom-Level das schon angepasste
Top-Level-Chord anzuwenden. Es würden also mehrere Peers zu einer Gruppe
zusammengefasst werden und genug von diesen Gruppen zu Gruppen einer höheren Ebene.
Dies ermöglicht eine gute Skalierbarkeit der hierarchischen P2P-Netze, denn es liegt nur eine
geringe Geschwindigkeitseinbuße vor. Suchanfragen erfolgen nämlich immer nur noch auf
Top-Level, und müssen somit nur wenige SuperPeers durchlaufen.
In [5] wurde mit statistischen Mitteln untersucht, wie viel Verbesserung durch die
Verwendung einer hierarchischen DHT möglich ist im Vergleich zu einer klassischen flachen
DHT. Es wurde Chord als Vergleich genutzt, und gezählt wurden die Anzahl der Sprünge
innerhalb des Ringes, bis der entsprechende Peer gefunden wurde, welcher den gesuchten
Schlüssel besitzt. Als Erläuterung zur Abbildung 7: P steht für die Anzahl der Peers im
gesamten Netz, I für die Anzahl der Gruppen, was natürlich nur im hierarchischen Fall eine
Rolle spielt, und pr bzw. ps steht für die Ausfallwahrscheinlichkeit eines Peers im Chord-
Ring. Da im Top-Level-Chord ein einzelner Knoten für eine Gruppe steht mit seinen
SuperPeers, kann hier eine Ausfallwahrscheinlichkeit von 0 angenommen werden. Ein
ausfallender SuperPeer würde unverzüglich durch einen anderen SuperPeer ersetzt werden,
wodurch der Knoten im Chord-Ring nicht ausfallen wird. Die Zahlen in der Tabelle stehen für
die Anzahl der Sprünge, um einen Schlüssel zu finden. Wie zu erkennen ist, gibt es eine
deutliche Verminderung der Hops (Sprünge). So wird die durchschnittliche Dauer der
Suchanfrage um den Faktor 7 geteilt [5].
9

Abbildung 7: Vergleich flache und hierarchische DHT (entnommen [5])
Es erfolgt außerdem bei Top-Level-Chord für Anfragen immer eine zufällige Auswahl des
SuperPeers aus den Vektoren, um die entsprechende Anfrage weiterzuleiten. Dies bedeutet
eine bessere Lastverteilung, da nicht ein SuperPeer (sowie dessen Anbindungen) übermäßig
mehr belastet wird als ein anderer. Somit ergibt sich auch hier eine bessere Skalierbarkeit,
denn reicht die Anzahl der SuperPeers pro Gruppe nicht aus kann diese relativ einfach erhöht
werden.
6.2 Robustheit
Die Nutzung von Chord im Top-Level führt nicht nur zu einer besseren Skalierbarkeit des
P2P-Netzes, sondern auch zu höherer Robustheit gegenüber Ausfällen.
Da kein zentraler Server existiert, welcher alle Clients steuert, bedeutet der Ausfall eines
beliebigen Peers nicht die Möglichkeit des Zusammenbruches des Netzes. Im schlimmsten
Fall fällt ein SuperPeer aus, was nur dahingehend tragisch wäre, da er eine bessere Leistung
gebracht hat gegenüber den anderen Peers dieser Gruppe. Es wird jedoch sofort der ab jetzt
bestmögliche Peer zum SuperPeer ernannt. Dies geschieht mittels einer Liste, die jeder
SuperPeer über „seine“ Peers führt. Diese Liste ist so geordnet, dass potentiell gute
Kandidaten zum SuperPeer möglichst oben stehen, während ungeeignete Peers unten stehen.
Ein SuperPeer überwacht sozusagen ständig seine Peers und aktualisiert die Liste anhand
bestimmter Kriterien wie Rechenleistung, Bandbreite und Online-Zeit des Peers.
6.3 Suchoptimierungen
In Abschnitt 2.3 „Super-P2P-Systeme“ wurde schon erwähnt, dass es sinnvoll ist, Computer,
die untereinander eine schnelle Anbindung haben, zu einer Gruppe zusammenzufassen.
Dadurch kann den Suchalgorithmus noch verbessern, wie in Abbildung 8 dargestellt. Startet
ein Peer P1 eine Suchanfrage, so wird erst innerhalb der Gruppe geschaut, ob ein Peer P2
verantwortlich für diesen Key ist. In dem Fall holt sich P2 die Datei von dem entsprechenden
Peer P4, cached sie bei sich und leitet sie dann zu Peer P1 weiter. Erfolgt eine weiter
Suchanfrage von Peer P4 nach genau der Datei, so hat sie vielleicht noch P2 im Cache und
kann sie schneller, dank besserer Anbindung, an P4 senden. Die Datei muss nicht noch mal
über die wahrscheinlich langsamere Verbindung von P3 geholt werden.
10

Abbildung 8: Content Caching in einem Super-Peer-Netzwerk (angelehnt an [6])
Natürlich spielt bei dieser Art des Cachens die Größe des Caches eine wichtige Rolle sowie
die Dateien, die gecached werden. Es ist umso effizienter, je häufiger eine Datei angefordert
wird, denn bei den meisten Cache-Algorithmen wie LRU (Last Recently Used) bleiben die
am häufigsten benutzen Dateien im Cache, während seltene Dateien eher gelöscht bzw.
überschrieben werden.
7 Beispiele für hierarchische P2P-Netzwerke
7.1 FastTrack
Das FastTrack Protokoll wurde im März 2001 von Niklas Zennström & Janus Friis
veröffentlich und erweiterte das bis dahin verwendete Gnutella Protokoll um Supernodes [9].
Diese Supernodes entsprechen den in diesem Text behandelten SuperPeers.
Kazaa wurde damals gleichzeitig mit dem FastTrack Protokoll entwickelt und ist die
bekannteste Anwendung für dieses Netz. Wie in Abbildung 9 zu erkennen ist, gibt es zum
klassisch unstrukturierten, hierarchischen P2P-System nur geringe Unterschiede, welche sich
auf sicherlich darauf begründen, dass Kazaa auch kommerziell vertrieben wird. So wurden die
Übertragungsprotokolle nie offen gelegt, und viele andere Clients sowie die freie
Implementierung des FastTrack-Protokolls „Open FastTrack“ entstanden mittels Reverse-
Engineering. [10]
11

Abbildung 9: Funktionsweise von Kazaa (entnommen [3])
Arbeitsweise: ein Node (Peer) fragt beim Anmelden am System nicht einen schon bekannten
und aktiven Peer ab, sondern meldet sich bei einem Server an, dessen IP-Adresse direkt im
Programm gespeichert ist. Dieser Server übermittelt daraufhin eine aktuelle Liste von
SuperPeers, bei denen sich der Peer anmelden kann. Der Peer testet daraufhin die SuperPeers
auf die Round-Trip-Time ab. Dazu wird gemessen, wie lange ein Paket vom Peer zum
SuperPeer und wieder zurück braucht, also bis es beantwortet wird. Anhand dieser Zeiten
meldet sich der neue Peer in der Gruppe an, dessen SuperPeers die kleinste Round-Trip-Time
hat, und übermittelt dem zuständigen SuperPeer eine Liste mit den auf dem Peer verfügbaren
Dateien. Suchanfragen sowie Dateiübertragungen funktionieren wie in der für hierarchische
P2P-Netze typischen Art und Weise über die SuperPeers beziehungsweise direkt von Peer zu
Peer.
Ein großer Vorteil in der im FastTrack-Protokoll zugrunde liegenden Technik liegt darin, dass
ein Peer mehrere direkte Verbindungen zu unterschiedlichen Peers aufbauen kann, um von
diesen parallel Daten zu beziehen. Selbst für eine Datei ist ein simultaner Download von
mehreren Peers möglich, indem stets unterschiedliche Teile der Datei herunter geladen
werden. Dies ermöglicht bei geringer Bandbreite zu einzelnen Peers eine höhere
Gesamtdownloadrate.
7.2 Gnutella (3. Generation)
Das Gnutella-Protokoll wurde noch vor dem FastTrack-Protokoll im Jahre 2000 entwickelt
und veröffentlicht. Während die erste wirklich erfolgreiche Tauschbörse namens Napster mit
Klagen überhäuft wurde, konzipierte man Gnutella von vornherein so, dass es ohne jegliche
Server funktioniert. Damit sollte es unmöglich gemacht werden, dass das Netz von Seiten der
Musikindustrie sowie der RIAA (Recording Industry Association of America) geschlossen
werden kann. Dies war bei Napster der Fall mit der Stilllegung derer Server.
Während in der ersten und zweiten Gnutella-Generation schmalbandige Peers entweder von
der Last der Anfragen überwältigt beziehungsweise ihre Anzahl der Verbindungen angepasst
wurden, wurden in der dritten Generation Hierarchien eingeführt. So genannte Ultrapeers
übernehmen die Netzlast für schmalbandige Peers. [11]
Dazu werden alle angeschlossenen Teilnehme in Leaves (Blätter) und Ultrapeers unterteilt.
Ein Leaf entspricht dem in diesem Text behandelten Peers, ein Ultrapeer ist vergleichbar mit
einem SuperPeer. Zusätzlich ist es möglich, dass sich Gnutella-Clients mit dem Netzwerk
12

verbinden können, die noch nicht den Ultrapeer-Modus implementiert haben. Diese werden
Legacy Peers genannt. [12]
Der Aufbau des neuen Gnutella-Netzwerkes unterscheidet sich aber im Vergleich zum
typischen Super-Peer-Netzwerk. Die Ultrapeers bilden zusammen mit den Legacy Peers das
Top-Level-Overlay. Dadurch wird gewährleistet, dass die Clients ohne Ultrapeer-Modus
vollständig im Netz integriert sind. Die Legacy Peers bauen jedoch im Gegensatz zu den
Ultrapeers keine Verbindungen zu den Leaves auf. Ultrapeers haben nämlich die Aufgabe,
Verbindungen von Leaves zu akzeptieren und für sie Such- und Routingaufgaben zu
übernehmen. So übermittelt ein Leaf beim Anmelden an einen Ultrapeer eine Liste seiner
verfügbaren Dateien. Dies erlaubt dem Ultrapeer, Anfragen nur an die Leaves weiterzuleiten,
welche möglicherweise über passende Dateien verfügen. Dies reduziert die Anzahl der
weitergeleiteten Nachrichten zu den Leaves, was zu einer steigenden Skalierbarkeit des
Netzwerkes um einen konstanten Faktor führt [12].
Ein weiterer Unterschied liegt darin, dass ein Ultrapeer mit den an ihm angeschlossenen
Leaves keine in sich geschlossene Gruppe bildet; erkennbar in Abbildung 10. Ein Leaf
verbindet sich im Regelfall zu 3 Ultrapeers, was allerdings im Client geregelt ist. Es wird
empfohlen, die maximale Anzahl dieser Verbindungen auf 10 zu beschränken.
Abbildung 10: Topologie eines modernen Gnutella-Netzwerkes (entnommen [12])
Ob es einem Peer gestattet ist, Ultrapeer zu werden, wird erstens von bestimmten
Bedingungen abhängig gemacht, die unbedingt erfüllt sein müssen. Dazu zählt zum Beispiel
genügend Rechenleistung sowie eine ausreichende Bandbreite von empfohlenen 15 KB/s im
Download und 10 KB/s im Upload. Des Weiteren ist es nötig, dass ein Ultrapeer nicht hinter
einer Firewall sitzt. Auch sind bestimmte Betriebssysteme wie Windows 95 oder 98 nicht
geeignet, um die größere Anzahl von Verbindungen verwalten zu können. Auch ist es wie in
den Super-P2P-Systemen wichtig, dass der Client eine hohe Onlinezeit im Netzwerk
vorweisen kann. Sind diese Bedingungen erfüllt, so ist aber noch nicht gesagt, dass ein Client
unbedingt zu einem Ultrapeer wird. Dies ist davon abhängig, ob überhaupt weitere Ultrapeers
benötigt werden. Die Notwendigkeit nach neuen Ultrapeers kann abgeschätzt werden anhand
der Anzahl im Netz vorhanden Ultrapeers. [13]
13

8 Literatur
[1] Markus Zoier: Peer-to-Peer Tauschbörsen; Seminararbeit; Technische Universität Graz;
Österreich; 2002
[2] Servent; http://en.wikipedia.org/wiki/Servent; Dezember 2005
[3] Rolf Domberger, Daniel Fuchs: Peer-to-Peer Netzwerke und Geschäftsmodelle;
Discussion Paper 2004-04; Schweiz; 2004
[4] Beverly Yang, Hector Garcia-Molina: Designing a Super-Peer Network; Stanford
University; 2003
[5] L. Garces-Erice, E.W. Biersack, P.A. Felber, K.W. Ross, G. Urvoy-Keller: Hierarchical
Peer-to-peer Systems; France, USA; 2003
[6] L. Garces-Erice, E.W. Biersack, P.A. Felber, K.W. Ross, G. Urvoy-Keller: Hierarchical
Peer-to-peer Systems (Foliensammlung); France, USA; 2003
[7] Hari Balakrishnan, M. Frans Kaashoek, David Karger, Robert Morris, Ion Stoica: Looking
up data in P2P systems; 2003
[8] Common Address Redundancy Protocol; http://de.wikipedia.org/wiki/CARP; Dezember
2005
[9] FastTrack; http://de.wikipedia.org/wiki/FastTrack; Dezember 2005
[10] Christoph Steckelberg: Peer to Peer Netzwerke und ihre Anwendung; 2002
[11] Frank Sowinski: Implementierung eines Gnutella-Clients für IPv6; Dezember 2002
[12] Daniel Stutzbach, Reza Rejaie, Subhabrata Sen: Characterizing Unstructured Overlay
Topologies in Modern P2P File-Sharing Systems; University of Oregon; 2005
[13] Ultrapeer Election Principles: http://www.thegdf.org/wiki/index.php?title=Ultrapeer_Election_Principles;
Dezember 2005
14