Effizientes Routing in Peer-to-Peer Netzwerken

Transkript

1 Universität des Saarlandes Naturwissenschaftlich-Technische Fakultät I Fachbereich Informatik Diplomarbeit Effizientes Routing in Peer-to-Peer Netzwerken vorgelegt von Dennis Schade Angefertigt unter der Leitung von Prof. Dr. Gerhard Weikum Max-Planck-Institut für Informatik AG5 Databases and Information Systems Group Saarbrücken, 28. März 2005

2

3 Hiermit erkläre ich an Eides statt, dass ich diese Arbeit selbständig verfasst und keine anderen als die im Literaturverzeichnis angegebenen Quellen benutzt habe. Dennis Schade Saarbrücken, 28. März 2005

4

5 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis iv vi 1 Einleitung 1 2 Einführung in Peer-to-Peer-Systeme Was ist Peer-to-Peer? Vor- und Nachteile von Peer-to-Peer-Systemen Verschiedene Lösungsansätze Hybride P2P-Systeme Echte P2P-Systeme Fazit Der Chord-Algorithmus Das Chord-Systemmodell Das Auffinden von Schlüsseln im Chord-Ring Einfache Suche Skalierbare Suche mit Fingertabellen Der Chord-Peer Die Chord-Stabilisierungsalgorithmen Erzeugen eines Chord-Rings und Integration von Peers Die Nachfolgerliste Verlassen und Reparatur des Chord-Rings Aktualisierung der Fingertabelle Lastbalancierung Sicherheit Verwandte Arbeiten i

6 4 Implementierung Klassendesign Die Klasse DHTNode Die Klasse Location Die Klasse LookupKeyThread und LookupFingerThread Die Klasse FingerTableStabilizer Die Klasse Stabilizer Die Klassen DHTServer, PeerConnectionServer und -Client Die Klasse RemoteMessage Die Klasse Mediator Kommunikation und Interaktion Betreten und Verlassen des Chord-Rings Durchführung von Lookups Aktualisierung der Fingertabelle Ausführung des Stabilisierungsprotokolls Datenvolumen Datenvolumen je Lookup Datenvolumen je Stabilisierung Experimentelle Analyse Der statische Chord-Ring Lookups im statischen Chord-Ring Nachrichtenaufkommen durch Lookups Der dynamische Chord-Ring Lookups im dynamischen Chord-Ring Systemstabilität Bandbreitenverbrauch Bandbreitenverbrauch durch Lookups Bandbreitenverbrauch durch Stabilisierung Mindestbandbreitenverbrauch Zusammenfassung und Ausblick 83 A UML-Darstellungen vii B Auswertung der Experimente ix C Nachrichten und Nachrichtengrößen xiii ii

7 D Die Konfigurationsdatei Literaturverzeichnis xvi xvii iii

8 Abbildungsverzeichnis 2.1 Arbeitsweise von Napster Suchen mit Gnutella Aufbau von Super-Peer-Netzwerken dimensionales CAN Chord-Ring, 10 Peers und 6 Keys Einfache Suche Fingertabelle von Peer Suche mit Hilfe der Fingertabelle Integration eines neuen Peers Zyklus beim Weiterleiten einer Suche UML-Klassendiagramm: DHTNnode UML-Klassendiagramm: Location UML-Klassendiagramm: LookupThreads UML-Klassendiagramm: PeerConnectionClient und -Server UML-Klassendiagramm: Mediator UML-Sequenzdiagramm: Durchführung von Lookups UML-Sequenzdiagramm: Antwort auf Lookups UML-Sequenzdiagramm: Aktualisierung eines Fingers Vererbung der Nachfolgerliste Durchschnittlich Suchdauer im statischen Chord-Ring Pfadlänge: Suche im statischen Chord-Ring (absolut) Pfadlänge: Suche im statischen Chord-Ring (prozentual) Nachrichtenanzahl (KEY LOOKUP) Anteil fehlgeschlagener Suchen im dynamischen Chord-Ring Durchschnittliche Suchzeit für dynamische Chord-Ringe iv

9 5.7 Pfadlänge für 16 Peers in dynamischen Chord-Ringen mit verschiedenen Join-Leave-Zeiten Pfadlänge für 64 Peers in dynamischen Chord-Ringen mit verschiedenen Join-Leave-Zeiten Durchschnittliche Pfadlänge in dynamischen Chord-Ringen Stabilität im Join-Leave-Fall, t stab = 1.5s Vom Ring getrennte Peers im Join-Leave-Fall, t stab = 1.5s Stabilität im Join-Fail-Fall, t stab = 1.5s Vom Ring getrennte Peers im Join-Fail-Fall, t stab = 1.5s Stabilität im Join-Fail-Fall, t stab = 3s Vom Ring getrennte Peers im Join-Fail-Fall, t stab = 3s Bandbreite pro Lookup Bandbreite in KB/s für Lookups pro Sekunde Bandbreite Stabilisierung A.1 UML-Klassendiagramme (1) vii A.2 UML-Klassendiagramme (2) viii B.1 Pfadlänge für 8 Peers in dynamischen Chord-Ringen mit verschiedenen Join-Leave-Zeiten x B.2 Pfadlänge für 32 Peers in dynamischen Chord-Ringen mit verschiedenen Join-Leave-Zeiten x B.3 Pfadlänge für 48 Peers in dynamischen Chord-Ringen mit verschiedenen Join-Leave-Zeiten xi v

10 Tabellenverzeichnis 2.1 Das Gnutella Protokoll Beispiele für RemoteMessages B.1 Pfadlänge: Suche im statischen Chord-Ring (absolut) ix B.2 Pfadlänge: Suche im statischen Chord-Ring (prozentual) ix B.3 Durch Lookups belegte Bandbreite xii B.4 Durch Stabilisierung belegte Bandbreite xii C.1 Nachrichtenaufbau und -größe xv D.1 Parameter der Konfigurationsdatei xvi vi

11 1 Einleitung Viele im Internet verfügbare Dienste, wie z. B. das World Wide Web (WWW) oder das Domain Name System (DNS) [30], sind durch das Client-Server-Prinzip und eine hierarchische Organisationsstruktur geprägt. In den letzten Jahren kommt jedoch zunehmend eine andere Organisationsform zur Anwendung: Peer-to-Peer-Systeme (P2P-Systeme). P2P-Systeme schließen ihre Teilnehmer (Peers) zu einem virtuellen Netzwerk innerhalb des Internets zusammen, in dem jeder Peer als Client teilnimmt und gleichzeitig aber auch als Server agiert, indem er einen Teil seiner Ressourcen zur Verfügung stellt. Durch dieses Prinzip werden die Kosten für die Speicherung und Verteilung von im P2P-System gespeicherten Daten auf die einzelnen Peers verteilt, was P2P-Systeme besonders für die Speicherung und Verteilung von große Datenmengen interessant macht. So erfreuen sich P2P-Systeme einer derart großen Beliebtheit, dass sie mittlerweile den größten Teil des Datenaufkommens im Internet verursachen [20]. Die anfänglich verwendeten P2P-Systeme hatten jedoch noch Designschwächen, wie mangelnde Skalierbarkeit und hohen Bandbreitenverbrauch. Um diesem Problem zu begegnen, hat sich ein neuer Ansatz herausgebildet, der auf verteilten Hashtabellen beruht. Die meisten P2P-Systeme, die verteilte Hashtabellen verwenden, benutzen recht komplizierte und nicht immer intuitiv nachvollziehbare Such- bzw. Routingalgorithmen. Die Chord-Architektur [43] ist hier jedoch eine positive Ausnahme. Aus diesem Grund soll Chord im Rahmen dieser Arbeit genauer untersucht werden. Kapitel 2 beschreibt zunächst kurz die grundlegenden Eigenschaften von P2P-Systemen und gibt einen Überblick über die verschiedenen P2P-Ansätze. Im Anschluss daran beschreibt Kapitel 3 das Chord-Systemmodell und erklärt die verwendeten Algorithmen. Eine Beschreibung der im Rahmen dieser Arbeit entstandenen Implementierung von Chord sowie der wichtigsten Klassen erfolgt in Kapitel 4. Kapitel 5 beschäftigt sich mit der experimentellen Analyse des Chord-Algorithmus. Zum Abschluss fasst Kapitel 6 die 1

12 1 Einleitung Ergebnisse dieser Arbeit kurz zusammen und zeigt weitere Arbeitsfelder auf. 2

13 2 Einführung in Peer-to-Peer-Systeme 2.1 Was ist Peer-to-Peer? Die Idee von Peer-to-Peer-Netzwerken (P2P) ist es, Ressourcen wie Rechenleistung oder Speicherplatz miteinander zu teilen. Die teilnehmenden Hosts (Peers) können auf die Ressourcen anderer Peers zugreifen und bezahlen dafür, indem sie einen Teil ihrer Ressourcen im P2P-Netzwerk zur Verfügung stellen. Der Unterschied zum klassischen Client-Server-Design besteht darin, dass ein Peer sowohl Client als auch Server sein kann. Ein Peer agiert dabei als Client, wenn er auf Ressourcen anderer Peers zugreift, und er agiert als Server, wenn er Ressourcen im Netzwerk bereitstellt. Die klassischen Client-Server-Architekturen wie das DNS [31, 30] sind durch einen hierarchischen Aufbau mit zentralen Servern gekennzeichnet. P2P-Architekturen verzichten darauf und organisieren die Peers dezentral. Das P2P-Netzwerk entsteht dadurch, dass die Peers in irgendeiner Weise innerhalb des Internet zu einem virtuellen Netzwerk verbunden werden, in dem jeder Peer potenziell alle Aufgaben übernehmen kann. Darüber hinaus sind P2P-Systeme darauf ausgelegt, dass insbesondere auch Heimanwender mit ihren privaten PC s daran teilnehmen können. Da viele Heimanwender jedoch nicht ständig mit dem Internet verbunden sind, nehmen diese nicht permanent am P2P-Netzwerk teil, sondern nur dann, wenn sie auch mit dem Internet verbunden sind. Schaltet der Heimanwender seinen PC ab, oder trennt er die Internetverbindung, so fällt der entsprechende Peer im P2P-Netzwerk aus. Daher verändert sich die Topologie des P2P-Netzwerks fortwährend. 3

14 2.2 Vor- und Nachteile von Peer-to-Peer-Systemen 2.2 Vor- und Nachteile von Peer-to-Peer-Systemen Einer der Vorteile von P2P ist, dass zentrale Server durch die Dezentralisierung entfallen. Dies ist insoweit ein Vorteil, da in Client-Server-Architekturen das Funktionieren des gesamten Systems hauptsächlich vom Betrieb des Servers abhängt. Kommt es an dieser Stelle, dem so genannten single-point-of-failure, zu einem Fehler, so ist das gesamte System nicht mehr verfügbar. Eine weiterer entscheidender Vorteil von P2P-Systemen ist, dass durch zentrale Server bedingte Performanzprobleme entfallen. Den Flaschenhals (bottle neck) für die Leistung eines Client-Server-Systems stellt meistens der Server dar. Ist der Server überlastet, so ist meist das gesamte System nicht mehr verfügbar. Eine Überlastung des Servers kann z. B. dadurch entstehen, dass zu viele Clients gleichzeitig auf die von ihm angebotenen Dienste zugreifen möchten. In P2P-Systemen wird einer solchen Überlastung entgegengewirkt, da hier hier die Systemlast auf mehreren Peers verteilt werden kann. Der größte Vorteil von P2P-Architekturen ist aber, dass sie, da sie ohne zentrale Server auskommen, besser skalierbar sind als herkömmliche Client-Server-Architekturen, wodurch potenziell die Anzahl der Peers fast beliebig erhöht werden kann. Ein Nachteil von P2P-Architekturen liegt darin, dass sich die Topologie des Netzwerks ständig verändert. Wird ein Peer vom P2P-Netzwerk getrennt, so sind damit die Ressourcen des ausgefallenen Peers nicht mehr ansprechbar. Da ständig Peers vom Netzwerk getrennt werden, lassen sich in der Regel keine verlässlichen Aussagen über die Verfügbarkeit einer bestimmten Ressource treffen. Hinzu kommt, dass die einzelnen Peers wegen der dezentralen Organisation und der sich ständig verändernden Topologie des P2P-Netzwerks, in der Regel nicht alle anderen Peers im Netzwerk kennen. Insbesondere liegt, bedingt durch die Dynamik, zu keinem Zeitpunkt ein vollständiges Abbild des aktuellen Netzwerkzustandes vor. Würde jeder Peer ein vollständiges Abbild besitzen, so müsste auch jeder Peer informiert werden, wenn sich der Netzwerkzustand ändert. Das wiederum würde aber einen sehr hohen Ressourcenverbrauch hervorrufen. Aus diesem Grund kennt jeder Peer nur einen begrenzten Teil des Netzwerks, wodurch sich das Auffinden von Ressourcen komplexer darstellt als in herkömmlichen Client-Server-Architekturen. Auf Grund dieser Problematik haben sich mit der Zeit unterschiedliche Lösungsansätze zur Organisation der Peers sowie der Lokalisierung von Ressourcen herausgebildet. Im folgenden wird ein kurzer Überblick über diese gegeben. Einen solchen 4

15 2.3 Verschiedene Lösungsansätze Überblick geben auch [4] und [7]. 2.3 Verschiedene Lösungsansätze Das gemeinsame Problem aller P2P-Systeme ist die Lokalisierung von Ressourcen, das so genannte Lookup Problem. Dieses wird in [7] so formuliert: Gegeben sei ein Datenelement X, das von einer dynamischen Teilmenge von Peers im System gespeichert wird. Finde X. 1 Im Laufe der Zeit entstanden unterschiedliche Ansätze zur Lösung des Lookup Problems. Neben hybriden P2P-Systemen, einer Mischform aus Client-Server und P2P, bei der die Peers bei der Ressourcensuche von einem zentralen Server abhängig sind, gibt es die echten P2P-Systeme. Charakteristisch für echte P2P-Systeme ist, dass sie, zumindest auf physikalischer Ebene ohne zentrale Verzeichnisse arbeiten und ein verteiltes Suchprotokoll implementieren Hybride P2P-Systeme Hybride P2P-Systeme wie Napster [46] verzichten nicht vollständig auf die Client- Server-Struktur. Sie führen die Suche nach Ressourcen mit Hilfe von zentralen Verzeichnissen durch, welche auf einem Server hinterlegt sind. Jeder Peer registriert die von ihm bereitgestellten Ressourcen in diesem zentralen Verzeichnis. Sucht ein Peer nun nach einer bestimmten Ressource, so erhält er aus dem zentralen Verzeichnis die Information, welcher Peer diese zur Verfügung stellt. Der eigentliche Zugriff auf die Ressource erfolgt dann über den für P2P-Systeme charakteristischen, direkten Kontakt zum entsprechenden Peer. Abbildung 2.1 stellt die Arbeitsweise von Napster grafisch dar. Diese Arbeitsweise birgt den Vorteil, dass sie die sonst in P2P-Systemen vorhandenen Probleme wie das Auffinden von Ressourcen und Routing von Suchen umgeht. Auch lässt sich zumindest eine verlässliche obere Schranke für die Dauer einer Abfrage angeben, da man hinreichend Informationen über das Netzwerk und den Ablauf der Suche besitzt. Der Nachteil dieser hybriden Architektur besteht darin, dass sie nicht so gut skalierbar ist wie echte P2P-Systeme. Alle Peers greifen bei der Suche nach und der Registrierung von Ressourcen auf einen zentralen Server zu, wobei die maximale Peeranzahl 1 Given a data item X stored at some dynamic set of nodes in the system, find it. 5

16 2.3 Verschiedene Lösungsansätze Napster Server X wird von A angeboten registriere X suche X benutze X Peer A Peer B Abbildung 2.1: Arbeitsweise von Napster von der Leistungsfähigkeit des Servers abhängt. Wenn der Server überlastet ist, dann können keine Ressourcen mehr gefunden werden. Ein weiterer Nachteil ist, dass auch ein zentrales Verzeichnis immer einen single-point-of-failure darstellt, wodurch das System anfälliger für Angriffe wie DoS-Attacken wird Echte P2P-Systeme Bei den echten P2P-Systemen existieren wiederum zwei unterschiedliche Lösungsansätze, die unstrukturierten und die strukturierten. Sie unterscheiden sich dadurch, dass unstrukturierte Ansätze auf physikalischer wie auf konzeptioneller Ebene auf zentrale Verzeichnisse verzichten und die Peers einfach in irgendeiner Weise miteinander verbunden sind, wobei strukturierte Ansätze auf konzeptioneller Ebene sehr- wohl mit zentralen Verzeichnissen arbeiten und die Peers in einer bestimmten Weise miteinander verbinden. Eine Sonderstellung unter den echten P2P-Netzwerken nehmen so genannte Super- Peer-Netzwerke [47] ein. Diese sind eine Mischform aus unstrukturierten und hybriden 2 Als DoS-Angriff (Denial of Service) bezeichnet man einen Angriff auf einen Server, mit dem Ziel einen oder mehrere seiner Dienste arbeitsunfähig zu machen. In der Regel geschieht das durch Überlastung, indem eine größere Anzahl Anfragen gestellt wird, als der Server gleichzeitig bearbeiten kann, woraufhin ein Dienst eingestellt wird oder reguläre Anfragen so langsam beantwortet werden, dass diese abgebrochen werden. 6

17 2.3 Verschiedene Lösungsansätze P2P-Systemen. Sie sind der Versuch, die Nachteile von unstrukturierten Ansätzen abzumildern. Unstrukturierte Ansätze Unstrukturierte P2P-Ansätze wie Gnutella [15] oder Freenet [10] verwenden keine bestimmte Ordnung für die Peers. Bei dieser Art der Organisation kennt jeder Peer eine gewisse Anzahl von anderen Peers (Nachbarn). Insbesondere ist es so, dass kein Peer alle Peers im Netzwerk kennt, da das Auffinden sowie das Aktualisieren aller Peers das Netzwerk mit hoher Wahrscheinlichkeit auslasten würde. Betrachtet man nun das P2P-Netzwerk als Graphen, so ergeben sich zwei Möglichkeiten Ressourcen und andere Peers in einem P2P-Netzwerk aufzufinden: Tiefensuche und Breitensuche. Bei der Tiefensuche wird ein Pfad im Graphen bis zur maximalen Pfadlänge abgesucht. Hierzu wird die Suche von Peer zu Peer weitergeleitet. Bei jeder Weiterleitung wählt der Peer, der gerade die Nachricht erhalten hat, einen Peer unter den mit ihm verbundenen Peers aus, und leitet ihm die erhaltene Nachricht weiter. Hierdurch werden bei einer Suchtiefe r genau r Peers erreicht. Bei der Breitensuche leiten die Peers eine erhaltene Nachricht jeweils an alle mit ihnen verbundenen Peers weiter. Hierdurch werden bei einer Suchtiefe r alle Peers erreicht, die vom Ausgangspunkt der Suche innerhalb des Radius r liegen, d. h. die Peers, die maximal r Weiterleitungen entfernt sind. Bei beiden Arten der Suche wird jede für die Suche versandte Nachricht wird mit einer time-to-live (TTL) versehen. Diese gibt an, wie oft eine Nachricht weitergeleitet werden darf und bestimmt somit die Suchtiefe bzw. den Radius der Suche. Bei jeder Weiterleitung wird diese um eins verringert. Gilt T T L = 0, so wird die Nachricht nicht mehr weitergeleitet. Gnutella verfolgt den Ansatz der Breitensuche. Mit ihr ist es möglich, mit einer Suche eine große Anzahl anderer Peers zu erreichen. Wenn ein Peer z. B. mit durchschnittlich C = 5 Peers verbunden ist, eine eingehende Nachricht also an 4 Peers weitergeleitet wird, so werden innerhalb einer T T L = 7 maximal verschiedene Peers erreicht. T T L i=0 C (C 1) i = Ein Gnutella Peer unterscheidet bei der Breitensuche zwischen dem Auffinden anderer bzw. neuer Peers sowie der Suche nach Ressourcen. Dementsprechend sieht das Gnutella Protokoll auch zwei unterschiedliche Nachrichten Ping und Query vor. Tabelle 2.1 gibt einen Überblick über die Nachrichten des Gnutella Protokolls. 7

18 2.3 Verschiedene Lösungsansätze Das Auffinden neuer Peers durch einen Peer x erfolgt durch Versenden der mit einer TTL versehenen Nachricht Ping an alle Peers, die x bereits bekannt sind. Erhält nun Peer y eine Ping-Nachricht von x, so sendet er an Peer x die Antwort Pong. Diese Nachricht wird dabei über den Weg, über den sie gekommen ist, zurückgeroutet. Sofern die TTL der erhaltenen Ping-Nachricht größer als Null ist, verringert y diese um Eins und leitet dann die Ping-Nachricht wiederum an alle ihm bekannten Peers weiter. Da es bei diesem Vorgehen zu Zyklen kommen kann, erhält jede Nachricht zusätzlich einen Identifier. Anhand dieses Identifiers können Peers schon einmal erhaltene und weitergeleitete Nachrichten erkennen. Somit können Zyklen vermieden werden, da bekannte Nachrichten nicht mehr weitergeleitet werden. Nachricht Ping Pong Query QueryHit Push Beschreibung Suche nach anderen Peers Antwort auf Ping Suche nach einer Ressource Antwort auf Query Download von Peers hinter einer Firewall Tabelle 2.1: Das Gnutella Protokoll Bei der Suche nach einer bestimmten Ressource, wird eine dem Auffinden neuer Nachbarn analoge Verfahrensweise angewandt. Der suchende Peer sendet die Nachricht Query an alle ihm bekannten Peers. Diese leiten die Suchanfrage dann wiederum an alle ihnen bekannten Peers weiter, bis die TTL der Suchanfrage abgelaufen ist. Wird dabei innerhalb des Radius TTL kein Peer erreicht, der die gesuchte Ressource zur Verfügung stellt, so ist die Suche erfolglos. Existiert jedoch ein Peer, der die Ressource bereitstellt, innerhalb des durch TTL festgelegten Radius, so sendet dieser die Nachricht QueryHit an den Initiator der Suche zurück. Die Antwort wird dabei über die gleichen Peers geroutet, über die auch die Query-Nachricht gesendet wurde. Abbildung 2.2 zeigt den Ablauf einer Suche bei der Peer A nach Ressource X sucht. Im ersten Schritt sendet A die Nachricht Query an die Peers B und E. Diese wiederum leiten die Suche im zweiten Schritt an die Peers C, B, E und F weiter. Da B und E die Suche schon einmal weitergeleitet haben, wird diese dort nicht noch einmal weitergeleitet. In nächsten Schritt leitet Peer F die Suche an Peer D und C 8

19 2.3 Verschiedene Lösungsansätze X GET X C G F Query X A B D X E 1 Hop 2 Hops 3 Hops G s QueryHit D s QueryHit Abbildung 2.2: Suchen mit Gnutella weiter, während C die Suche an F und G weiterleitet. Da G und D die Ressource X anbieten, senden sie jeweils die Nachricht QueryHit zurück. Ein typischer Wert für die von den meisten Gnutella Clients verwendete time-to-live ist T T L = 7. Diese wurde gewählt, da Gnutella Netzwerke die Eigenschaften von small-world Graphen besitzen, weshalb eine Suche mit hoher Wahrscheinlichkeit innerhalb dieses Radius erfolgreich verläuft [29, 22]. Der Vorteil von unstrukturierten P2P-Architekturen wie Gnutella ist, dass sie besser skalieren als hybride Systeme und keinen single-point-of-failure mehr besitzen. Nachteile bestehen jedoch u. a. darin, dass durch die bei Gnutella verwendete Breitensuche viele bzw. auch unnötige Nachrichten versendet werden, was große Mengen Netzwerkbandbreite belegt [40]. Im Beispiel von Abbildung 2.2 leitet z. B. Peer B die Suche nach Ressource X in dem Moment an Peer E weiter, in dem E die gleiche Suche umgekehrt an B weiterleitet. Neben dem hohen Bandbreitenverbrauch besteht ein weiterer Nachteil darin, dass durch die willkürliche Anordnung der Peers keine effiziente Lastbalancierung (load-balancing) zwischen den Peers erfolgt. Super-Peer-Netzwerke Super-Peer-Netzwerke [47] sind eine Mischform zwischen unstrukturierten und hybriden P2P-Systemen. Das Ziel von Super-Peer-Architekturen ist es, den sehr hohen 9

20 2.3 Verschiedene Lösungsansätze Bandbreitenverbrauch, der z. B. durch die von Gnutella verwendete Breitensuche entsteht, zu senken. Dies wird durch die Unterteilung des Netzwerks in Cluster erreicht. In einem Cluster ist die Arbeitsweise ähnlich der von Napster. So gibt es innerhalb eines Clusters zwei unterschiedliche Arten von Peers: Super-Peers und Clients. Wie bei Napster agieren die Super-Peers innerhalb eines Clusters für die Clients als zentrale Server. Sie besitzen Informationen über alle im Cluster bereitgestellten Ressourcen. Die Clients registrieren die von ihnen bereitgestellten Ressourcen bei den Super- Peers. Untereinander sind die Cluster durch ihre jeweiligen Super-Peers miteinander verbunden. Die Anzahl der Peers im Cluster, inklusive der Super-Peers, wird mit cluster size bezeichnet. 3 Abbildung 2.3 zeigt den Aufbau eines Super-Peer-Netzwerks aus 4 Clustern mit ihren Super-Peers SP1 bis SP4. SP2 SP3 SP1 SP4 Abbildung 2.3: Aufbau von Super-Peer-Netzwerken Sucht ein Client eine Ressource, so stellt er seine Anfrage an den Super-Peer des eigenen Clusters. Dieser überprüft zunächst, ob innerhalb des Clusters ein Peer existiert, der die Ressource bereitstellt. Ist dies der Fall, so sendet er eine entsprechende Antwort an den suchenden Peer. Erst wenn kein solcher Peer existiert, leitet der Super- Peer die Suche an die mit ihm verbundenen Super-Peers weiter. Diese überprüfen dann wiederum, ob in ihrem Cluster ein Peer existiert, der die gesuchte Ressource 3 Das P2P-Netzwerk Gnutella stellt ein degeneriertes Super-Peer-Netzwerk mit cluster size = 1 dar. 10

21 2.3 Verschiedene Lösungsansätze bereitstellt. Wird die gesuchte Ressource nun gefunden, so wird eine entsprechende Antwort an den fragenden Super-Peer gesendet, der dann den suchenden Peer in seinem Cluster verständigt. Kann die Ressource wiederum nicht gefunden werden, so leiten die Super-Peers die Suche erneut an andere Super-Peers in anderen Clustern weiter. Ein Beispiel für ein auf einer Super-Peer-Architektur beruhendes P2P-Netzwerk ist KaZaA [32]. Super-Peer-Netzwerke sind durch die Verwendung von Client-Server innerhalb der Cluster jedoch keine echten P2P-Netzwerke im eigentlichen Sinne. Nicht zuletzt ergeben sich innerhalb der Cluster wieder die für Client-Server-Architekturen typischen Probleme bezüglich Skalierbarbeit und Ausfallsicherheit. 4 Strukturierte Ansätze Im Gegensatz zu unstrukturierten und Super-Peer-Architekturen versuchen die strukturierten Ansätze, die Anzahl der Nachrichten und damit die belegte Bandbreite dadurch zu verringern, dass sie versuchen Ressourcen effizient zu lokalisieren. Um effizient bzw. strukturiert suchen zu können, werden die Ressourcen zunächst in entsprechenden Index-Strukturen erfasst. Hierzu bedienen sich die einzelnen Ansätze unterschiedlicher Indexing-Mechanismen. Eine Möglichkeit der Indizierung sind Skip-Listen bzw. Skip-Graphen [5], wie sie von P-Grid [2] oder SkipNet [16] verwendet werden. Kern dieser Ansätze ist eine über die Peers verteilte sortierte Liste, in der alle bereitgestellten Ressourcen erfasst sind. Für jede Ressource wird in dieser Liste ein String hinterlegt, der die Ressource beschreibt. Die so angelegte Liste wird mittels eines Suchbaumes indiziert, in dem sich das Präfix der indizierten Strings mit zunehmender Suchtiefe verlängert. Ein anderer verbreiteter Ansatz zur Indizierung sind verteilte Hashtabellen (distributed hashtables - DHTs), die von etlichen Projekten [12, 38, 23, 49] verwendet werden. In einer Hashtabelle werden, wie in einem Array, Werte gespeichert. Der Unterschied zum Array besteht darin, dass die Werte nicht über einen Index referenziert werden, sondern durch einen Schlüssel, der mit Hilfe einer Hashfunktion aus dem Wert selbst berechnet wird. Als Werte selbst kann, je nach Implementierung des P2P-Systems, wiederum die Ressource selbst, oder eine Beschreibung, wie auf die Ressource zugegriffen werden kann, abgelegt werden. 4 vgl.: Abschnitt

22 2.3 Verschiedene Lösungsansätze Im Fall von Dateien kann also z. B. der Schlüssel festgelegt werden, indem mit der Hashfunktion der Hashwert des Dateinamens berechnet wird. Der zum Hashwert des Dateinamens gespeicherte Wert kann dann sowohl die Datei selbst sein, als auch eine Beschreibung des Peers, der die Datei bereithält. Im Fall von Ressourcen wie CPU- Zeit, welche nicht von einem Peer zum anderen übertragen werden kann, muss als Wert jedoch zwingend eine Beschreibung des Peers gespeichert werden, welcher die CPU-Zeit bereitstellt. Die Idee von verteilten Hashtabellen (DHTs) ist es nun, alle in einem P2P-Netzwerk bereitgestellten Ressourcen logisch in einer einzigen Hashtabelle zu erfassen, diese jedoch physikalisch über die Peers zu verteilen. Dabei wird zunächst jedem Peer x ein eindeutiges Teilintervall [i x..j x ] des Wertebereichs der Hashfunktion zugewiesen. Ein Peer speichert nun die Werte für alle Schlüssel key für die gilt key [i x..j x ]. Die Art der Verteilung der DHT, das Auffinden des für einen bestimmten Schlüssel zuständigen Peers, sowie die dazu verwendeten Verteil- und Routingalgorithmen sind dabei jedoch sehr unterschiedlich. So benutzen z. B. die P2P-Systeme Pastry [39], Tapestry [18] und Kademlia [27] auf Bäumen basierende Algorithmen, während Viceroy [26] auf Butterfly-Netzwerken [25] beruht. CAN [36] hingegen implementiert einen mehrdimensionalen Routingalgorithmus. CAN (Content-Addressable-Network) benutzt eine mehrdimensionale Datenstruktur und unterteilt den Wertebereich für die Schlüssel in den d-dimensionalen Koordinatenraum eines d-torus. Jeder Peer speichert Routinginformationen über seine direkten Nachbarn im Koordinatenraum. Zwei Peers sind dabei benachbart, wenn ihre Koordinatenbereiche entlang d-1 Dimensionen überlappen und in einer Dimension aneinander grenzen. In einem d-dimensionalen Raum besitzt somit jeder Peer O(d) Nachbarn. Bei der Suche wird ein greedy-algorithmus angewandt: Liegt der gesuchte Schlüssel nicht in der Koordinatenzone eines Peers, so leitet er die Suche an denjenigen seiner Nachbarn weiter, dessen Koordinatenzone am nächsten an der gesuchten liegt. Ist der d-dimensionale Raum in n Teile aufgeteilt und besitzt jeder Peer O(d) Nachbarn, so wird eine Suche von O(dn 1/d ) Peers weitergeleitet, bis sie ihr Ziel erreicht. Abbildung 2.4 zeigt ein CAN mit 2-dimensionalem [0,1] [0,1] Koordinatenraum. Zur Vereinfachung wurde der entsprechende 2-Torus in die Ebene projiziert. Die Pfeile zeigen einen möglichen Suchpfad für eine von Peer 8 gestartete Suche nach Schlüssel s=(0.6,0.6), welcher im Zuständigkeitsbereich von Peer 5 liegt. 12

23 2.4 Fazit (0,1) (1,1) (0,0.25,0.75,1) (0.5,0.75,0.75,1) (0.75,1,0.75,1) (0,0.25,0.5,0.75) 2 5 (0.25,0.5,0.5,0.75) (0.5,0.75,0.5,0.75) (0.75,1,0.5,0.75) 1 (0.25,0.5,0.25,0.5) (0.75,1,0.25,0.5) 8 (0,0.25,0,0.25) 4 (0.25,0.5,0,0.25) 9 (0.5,0.75,0,0.25) (0.75,1,0,0.25) (0,0) (1,0) Abbildung 2.4: 2-dimensionales CAN 2.4 Fazit Unter den verschiedenen P2P-Ansätzen ermöglichen es strukturierte Ansätze als einzige, verlässliche Aussagen über die tatsächliche Verfügbarkeit einer Ressource zu treffen, da der Peer, der für den Schlüssel, der die gesuchte Ressource beschreibt, verantwortlich ist, auf jeden Fall gefunden wird. Insbesondere ist es jedoch möglich, Angaben darüber zu machen, über wie viele Peers eine Suche weitergeleitet werden muss, bis die gesuchte Ressource gefunden wird. So wird in CAN eine Suche von O(dn 1/d ) Peers weitergeleitet bis sie ihr Ziel erreicht, während Architekturen wie Kademlia erreichen, dass in Netzwerken mit n Peers eine Suche mit hoher Wahrscheinlichkeit O(log n) mal weitergeleitet werden muss. 5 Skip-Listen basierte Algorithmen haben gegenüber DHT basierten Ansätzen den Vorteil, dass die Sortierung der Strings, die die Ressourcen beschreiben, nicht durch eine Hashfunktion verändert wird. So werden einander ähnliche Ressourcen, also der Ressourcen deren Beschreibung mit dem gleichen Präfix beginnt, von einander benachbarten Peers verwaltet, so dass eine Ähnlichkeitssuchen bzw. Range-Queries für Ressourcen möglich sind. DHT-Ansätze wiederum haben gerade durch die Verwendung der Hashfunktion den Vorteil, dass sie eine bessere Lastbalancierung (load-balancing) als Skip-Listen basierte Algorithmen unter den Peers herstellen, da die Hashfunktion die Zuständigkeit für die Ressourcen besser auf die Peers verteilt [6]. 6 5 mit d = (log 2 n)/2 ist auch bei CAN eine Pfadlänge von O(log n) möglich 6 vgl.: Abschnitt

24 2.4 Fazit Eine Gemeinsamkeit den meisten strukturierten Ansätzen ist jedoch, dass sie nicht immer sehr intuitiv nachzuvollziehen sind und recht komplizierte Routingalgorithmen implementieren. Chord ist neben den bereits erwähnten Ansätzen ein weiterer strukturierter DHT-Ansatz. Wie z. B. Kademlia bietet Chord dabei auch ein Routing in O(log n) Schritten, ist aber wesentlich intuitiver nachvollziehbar. 14

25 3 Der Chord-Algorithmus Chord ist ein strukturierter, auf verteilten Hashtabellen (DHT) beruhender P2P- Ansatz. Unter den DHT-Ansätzen ist Chord einer der intuitivsten. Zur Verteilung der Schlüssel auf die Peers nutzt Chord consistent hashing [21]. Chord stellt nur eine einzige Funktion zur Verfügung: die effiziente Lokalisierung von Schlüsseln. Dabei findet Chord aus n Peers den für einen Schlüssel zuständigen Peer in O(log n) Schritten. Hierbei benötigt ein Peer Informationen über O(log n) andere Peers. 3.1 Das Chord-Systemmodell Die Grundidee von Chord lässt sich folgendermaßen veranschaulichen: Die Peers werden in einer Ringstruktur, dem Chord-Ring organisiert. Hierzu erhält jeder Peer x eine eindeutige m-bit lange ID x (ChordID). Dafür wird zunächst mit Hilfe eines Hash-Algorithmus wie SHA-1 [1] der Hashwert h x der IP-Adresse des Peers x berechnet. Die so gebildeten Hashwerte h x sind jedoch möglicherweise länger als m-bit und werden deshalb auf einen Ring ID x = h x mod 2 m abgebildet. Der durch diese Abbildung entstehende Ring heißt Chord-Ring. Der dabei verwendete Parameter m heißt Exponent des Chord-Rings. Er bestimmt die maximal mögliche Anzahl Peers N = 2 m. Die ID des Peers x (x.id) bestimmt, an welcher Stelle des Chord-Rings sich x befindet. Die Nachbarn, d.h. der Vorgänger (predecessor) und der Nachfolger (successor) von x, ergeben sich aus der auf den IDs definierten Ordnung. Der letzte Peer y für den gilt y.id < x.id ist der Vorgänger von x (x.predecessor). Der Nachfolger z von x (x.successor) ist der erste Peer für den gilt z.id > x.id. Die im DHT-Konzept vorgesehene Verteilung der Schlüssel erfolgt bei Chord so, dass der Peer für den Schlüssel key zuständig ist, der key als erster auf dem Chord-Ring folgt. Schlüssel key wird also dem ersten Peer x zugeordnet, für den gilt: x.id key. Der so bestimmte Peer x wird successor(key) genannt. Sei y = x.predecessor, dann gilt: 15

26 3.2 Das Auffinden von Schlüsseln im Chord-Ring key (y.id, x.id] : successor(key) = x Abbildung 3.1 zeigt einen Chord-Ring mit dem Exponenten m = 6 und 10 Peers, die 6 Schlüssel verwalten. So ist z. B. der Schlüssel S34 Peer P35 zugeordnet, da P35 der erste Peer ist, der S34 folgt. P62 P1 S12 P57 S57 P14 S54 P53 P48 P22 P40 S24 P35 S28 S34 P31 Abbildung 3.1: Chord-Ring, 10 Peers und 6 Keys 3.2 Das Auffinden von Schlüsseln im Chord-Ring Die einzige Funktion, die Chord nach Außen bereitstellt, ist die Funktion lookup(key). Diese Funktion findet den für den Schlüssel key zuständigen Peer. Sucht Peer x nach Schlüssel key, so wird der Suchprozess durch den Aufruf der Funktion x.lookup(key) gestartet. Im folgenden wird der genaue Ablauf der Suche beschrieben Einfache Suche Bei der einfachen Suche nach einem Schlüssel key, wie sie von Algorithmus 1 durchgeführt wird, überprüft Peer x zunächst, ob sein Nachfolger der verantwortliche Peer ist. Ist dies der Fall, so ist der Suchprozess beendet, das Ergebnis ist x.lookup(key) = x. Ist der Nachfolger von x jedoch nicht selbst verantwortlich, so fragt x seinen Nachfolger y = x.successor, indem er dessen Suchfunktion y.lookup(key) aufruft. Dies geschieht solange, bis der für key zuständige Peer gefunden wurde. 16

27 3.2 Das Auffinden von Schlüsseln im Chord-Ring In einem Chord-Ring mit n Peers beträgt die Pfadlänge der Suche somit O(n), wobei die Pfadlänge angibt, wie oft der Lookup an einen anderen Peer weitergeleitet wurde. Abbildung 3.2 stellt den Verlauf der Suche dar, wenn Peer P14 den Schlüssel 58 sucht und der Lookup jeweils an den Nachfolger weitergeleitet wird. Insgesamt wird die Suche 7 mal weitergeleitet. Algorithmus 1 Einfache Suche x.lookup(key) if key (x.id,successor.id] return successor; else return successor.lookup(key); Diese Art der Suche ist zwar intuitiv, jedoch nicht sehr effizient. Da die Pfadlänge für die Suche linear zu der Anzahl der Peers im Chord-Ring steigt, steigt auch die Anzahl der Nachrichten linear mit der Anzahl der Peers an, so dass dieses Vorgehen die Skalierbarkeit eines Chord-Rings stark einschränkt. P62 P1 S12 P57 S57 S54 P53 lookup(58) P14 P48 P22 P40 S24 P35 S28 S34 P31 Abbildung 3.2: Einfache Suche 17

28 3.2 Das Auffinden von Schlüsseln im Chord-Ring Skalierbare Suche mit Fingertabellen Eine Möglichkeit, effizienter als linear zur Anzahl der Peers zu suchen, besteht darin, Peers beim Weiterleiten einer Suche zu überspringen und so mit einer Weiterleitung größere Stecken zurückzulegen. Hierzu muss ein Peer jedoch mehr Peers als nur seinen direkten Nachfolger kennen bzw. mehr über die Verteilung der Peers im Chord-Ring wissen. Bei der skalierbaren Suche verwaltet deshalb jeder Peer eine Tabelle mit Informationen über O(log N ) andere Peers im Chord-Ring. Die Einträge dieser Tabelle heißen Finger, die Tabelle selbst heißt Fingertabelle. In Chord umfasst die Größe der Fingertabelle m Einträge, wobei m der Exponent des Chord-Rings ist. Die Finger dienen bei der skalierbaren Suche als Sprungmarken zu anderen Peers im Chord-Ring. Mit ihrer Hilfe kann ein Lookup nun über größere Distanzen weitergeleitet werden. Der i-te Finger von x ist der Peer, der für den Schlüssel key verantwortlich ist, welcher um 2 i 1 größer ist als der größte Schlüssel, für den x verantwortlich ist. Der größte Schlüssel, für den x verantwortlich ist, ist x.id. Somit gilt für die Fingertabelle von Peer x: x.finger[i] = successor(key i ) : key i = x.id + 2 i 1, i [0, m] Insbesondere gilt, dass der erste Finger von x der Nachfolger von x ist. x.f inger[0] = x.successor Mit dieser Strategie legt ein Lookup mit jeder Weiterleitung mindestens die Hälfte der Distanz zum gesuchten Peer zurück. Abbildung 3.3 zeigt die Fingertabelle von Peer P14 sowie die Lage der für die Finger berechneten Schlüssel. Der entsprechende Finger ist immer der folgende Peer. So ist z. B. der für Finger 6 berechnete Schlüssel P = 46 und P48 der entsprechende Finger. Bei der skalierbaren Suche kommen die Methoden von Algorithmus 2 zum Einsatz. Ist der Nachfolger von Peer x nicht zuständig, so wählt er aus der Fingertabelle denjenigen Finger aus (closest preceeding node(key)), der dem gesuchten Schlüssel key am nächsten ist und im Chord-Ring noch vor key liegt. An diesen leitet x den Lookup weiter. Mit jeder Weiterleitung wird so die Distanz zum gesuchten Peer mindestens halbiert. Hierdurch entspricht dies einer binären Suche, welche bei einer Menge von n Eingabewerten, innerhalb von O(log n) Schritten beendet wird. Somit wird erreicht, 18

29 3.2 Das Auffinden von Schlüsseln im Chord-Ring P57 P62 P1 Finger Tabelle P14+1 P22 P14+2 P22 P14+4 P22 P14+8 P22 P14+16 P31 P14+32 P48 P14 P53 P P22 P40 P35 P31 Abbildung 3.3: Fingertabelle von Peer 14 Algorithmus 2 Skalierbare Suche x.lookup(key) if key (x.id,successor.id] return successor; else y = x.closest preceding node(key); return y.lookup(key); x.closest preceding node(key) for i = m downto 1 if finger[i].id (x.id, key) return finger[i]; return x; 19

30 3.3 Der Chord-Peer dass ein Lookup in einem Chord-Ring mit n Peers nur noch O(log n) mal weitergeleitet werden muss. Abbildung 3.4 zeigt den Verlauf einer Suche mit Hilfe der Fingertabelle. Sucht P14 nach Schlüssel 58, so ist P48 der Peer in der Fingertabelle von P14, der Schlüssel 58 am nächsten ist, weshalb dieser die Suche als nächstes erhält. Aus der Fingertabelle von P48 ist P57 dem gesuchten Schlüssel am nächsten, so dass P48 an P57 weiterleitet. Da der Nachfolger von P57 der zuständige Peer ist, wird die Suche erfolgreich beendet. Insgesamt wurde die Suche 2 mal weitergeleitet, während sie bei der einfachen Suche 7 mal weitergeleitet wurde. P57 P62 P1 Finger Tabelle P14+1 P22 P14+2 P22 P14+4 P22 P14+8 P22 P14+16 P31 P14+32 P48 P53 P48+8 P14+32 P14 lookup(58) P48 Finger Tabelle P48+1 P22 P48+2 P53 P48+4 P53 P48+8 P57 P48+16 P1 P48+32 P22 P40 P22 P35 P31 Abbildung 3.4: Suche mit Hilfe der Fingertabelle 3.3 Der Chord-Peer P2P-Netzwerke wie Chord sind darauf ausgelegt, dass ständig Peers hinzukommen oder ausfallen können. Da sich dabei die Topologie des Netzwerkes ändert, implementieren die Peers Algorithmen, die die Integration neuer Peers ermöglichen oder die Reparatur des Chord-Rings und der Fingertabellen vornehmen, wenn Peers ausfallen. Zusammen bilden diese Algorithmen das Chord-Stabilisierungsprotokoll. 20

31 3.3 Der Chord-Peer Die Chord-Stabilisierungsalgorithmen Die Algorithmen des Chord-Stabilisierungsprotokolls werden von jedem Peer in periodischen Zeitabständen aufgerufen. Der Zeitabstand zwischen zwei Durchführungen des Stabilisierungsprotokolls ist das Stabilisierungsintervall. Die Ausführung der Stabilisierungsalgorithmen findet im Hintergrund statt. Die Algorithmen des Stabilisierungsprotokolls sind: x.stabilize(): Prüft, ob der Vorgänger y des Nachfolgers y von Peer x zwischen x selbst und seinem aktuellen Nachfolger y liegt. Ist der Vorgänger des Nachfolgers nicht der fragende Peer selbst (y x), und liegt y zwischen x und y so ändert x seinen Nachfolger dementsprechend ab (x.successor = y ). 1 y.getpredecessor(): Wird von x während x.stabilize() aufgerufen, wobei y der Nachfolger von x ist. Die Funktion liefert den Vorgänger y des Nachfolgers y.predecessor. y.notify(x): Wird von x während x.stabilize() aufgerufen und kündigt Peer y die Existenz von x an. Liegt x zwischen dem aktuellen Vorgänger y von y und y selbst, so wird x der neue Vorgänger von y (y.predecessor = x). 2 x.checkpredecessor(): Testet ob x.predecessor ausgefallen ist. 3 x.fix fingers(): Aktualisiert die Einträge der Fingertabelle. 4 Die Arbeitsweise dieser Funktionen wird im verbleibenden Teil dieses Abschnitts anhand von Beispielen erläutert. So dienen die Funktionen stabilize() sowie getbzw. check Predecessor() und notify() der Erhaltung und Wiederherstellung der korrekten Vorgänger-Nachfolger-Beziehungen wenn Peers hinzukommen oder ausfallen, während fix fingers() die Fingertabelle aktuell hält Erzeugen eines Chord-Rings und Integration von Peers Dieser Abschnitt erläutert das Erzeugen eines neuen Chord-Rings mit zunächst nur einem Peer. Im Anschluss daran wird das Hinzufügen weiterer Peers, sowie die Rolle, die das Stabilisierungsprotokoll dabei spielt, veranschaulicht. 1 siehe Algorithmus 5 2 siehe Algorithmus 5 3 siehe Algorithmus 6 4 siehe Algorithmus 7 21

32 3.3 Der Chord-Peer Erzeugen des Chord-Rings Soll ein neuer Chord-Ring erzeugt werden, so geschieht dies mit Hilfe der Funktion create(). Ruft ein Peer x diese Funktion auf, so wird damit ein neuer Chord-Ring, der nur aus Peer x besteht, erzeugt. In diesem Fall ist x für alle Schlüssel zuständig, dementsprechend ist x sein eigener Nachfolger (x.successor = x). Algorithmus 3 create()-funktion x.create successor = x; predecessor = null; Integration weiterer Peers Zur Integration eines Peers x in einen bestehenden Chord-Ring wird die Funktion join() benutzt. Hierbei muss Peer x bereits ein beliebiger Teilnehmer v des Rings bekannt sein. Algorithmus 4 join()-funktion x.join(v) predecessor = null; successor = v.lookup(x.id); In Abbildung 3.5 werden die Phasen der Integration eines Peers P25 in einen bestehenden Chord-Ring gezeigt. Peer P25 belegt dabei den Platz zwischen den Peers P31 und P22. Zunächst erfragt P25 den Exponenten des Chord-Rings von einem beliebigen ihm bekannten Peer v des Chord-Rings. Danach ermittelt P25 seine eigene ID (P 25.ID = 25), indem er diese aus seiner IP-Adresse mittels der Hashfunktion und dem Exponenten bestimmt. 5 Die ID von P25 gibt nun den Platz vor, welchen P25 später im Chord-Ring belegt. Nachdem Peer P25 seine ID bestimmt hat, ermittelt er seinen Nachfolger. Dies geschieht, indem P25 den Peer bestimmt, der für den Schlüssel key = 25 zuständig ist. Hierzu benötigt er nun Peer v, dessen Lookup-Funktion dazu benutzt wird, Peer P 31 = v.lookup(25) zu finden. Der so ermittelte Peer P31 ist der Nachfolger von P25, weshalb P25 den Zeiger P25.successor = P31 setzt (Abbildung 3.5b). Die Peers P25, P31 und P22 haben nun die folgenden Zustände: 5 vgl.: Abschnitt

33 3.3 Der Chord-Peer Algorithmus 5 stabilize() und notify() x.stabilize() s = successor.get predecessor; if s (x.id, successor.id) then successor = s; successor.notify(x); x.notify(y) if predecessor == null or y.id (predecessor.id, x.id) then predecessor = y; P25.successor = P31 P31.successor P22.successor = P31 P25.predecessor = null P31.predecessor = P22 P22.predecessor Nachdem P25 seinen Nachfolger P31 ermittelt hat, teilt er diesem mit, dass er annimmt, dessen neuer Vorgänger zu sein. Dies geschieht durch Aufruf der Notify- Funktion P31.notify(P25). Peer P31 erhält diese Notify-Nachricht und prüft nun, ob P25 wirklich zwischen ihm und seinem aktuellen Vorgänger P22 liegt und somit als neuer Vorgänger übernommen werden kann (P 25.ID (P 22.ID, P 31.ID)). Ist dies der Fall, so ändert P31 seinen Vorgänger auf P 31.predecessor = P 25 ab (Abbildung 3.5c). Die Peers P25, P31 und P22 haben nun die folgenden Zustände: P25.successor = P31 P31.successor P22.successor = P31 P25.predecessor = null P31.predecessor = P25 P22.predecessor Zum jetzigen Zeitpunkt besitzen Peer P25 und Peer P22 noch den gleichen Nachfolger Peer P31. Damit die Integrität des Chord-Rings wiederhergestellt wird und alle Peers auf den richtigen Nachfolger verweisen, muss P22 seinen Nachfolger auf den neu hinzugekommenen Peer P25 abändern. Dies geschieht bei der nächsten Ausführung des Stabilisierungsprotokolls durch P22. Hierbei führt P22 die Funktion P22.stabilize() aus. Dabei fragt P22 den Vorgänger seines aktuellen Nachfolgers P31 durch P31.getPredecessor() ab. Hierdurch erhält P22 die Information, dass Peer P25 der neue Vorgänger von P31 ist. Jetzt prüft P22, ob P25 tatsächlich zwischen ihm und seinem aktuellen Nachfolger P31 liegt und somit als neuer Nachfolger übernommen werden kann (P 25.ID (P 22.ID, P 31.ID)). Ist 23

34 3.3 Der Chord-Peer dies der Fall, so setzt P22 seinen Nachfolger auf P 22.successor = P 25 (Abbildung 3.5d). Die Peers P25, P31 und P22 haben nun die folgenden Zustände: P25.successor = P31 P31.successor P22.successor = P25 P25.predecessor = null P31.predecessor = P25 P22.predecessor P53 P57 Zum Abschluss der Stabilisierung ruft P22 die Funktion notify() auf. Da er gerade seinen Nachfolger auf P25 abgeändert hat, lautet der entsprechende Aufruf also P25.notify(P22). Da P25 bis zu diesem Zeitpunkt noch keinen Vorgänger besitzt, P1 P1 P1 setzt P25 seinen Vorgänger P62 auf P25.predecessor = P62 P22 (Abbildung 3.5e). Die Peers P62 P25, P31 und P22 haben nun die folgenden Zustände: P57 P53 P25.successor = P31 P14 P31.successor P53 P22.successor = P25 P57 P25.predecessor = P22 P14 P31.predecessor = P25 P22.predecessor P14 P48 P48 P62 P1 P48 P62 P1 P57 P22 P57 P22 P22 P40 P53 P40 P53 P40 P14 P25 P14 P25 P35 P35 (a) P35 (b) (c) P48 P31 P48 P31 P31 P22 P22 P40 P40 P25 P25 P35 P35 (d) (e) P31 P31 Abbildung 3.5: Integration eines neuen Peers Hiermit verweisen nun alle Vorgänger und Nachfolger der Peers P31, P25 und P22 auf die richtigen Peers. Die Integration von P25 ist somit abgeschlossen. Integration des zweiten Peers Die Integration des zweiten Peers in den Chord-Ring stellt einen Sonderfall dar. Wie schon erwähnt besteht der Chord-Rings nach seiner Erzeugung zunächst aus nur 24

35 3.3 Der Chord-Peer einem Peer x, der sich selbst zum Nachfolger und keinen Vorgänger hat. Tritt nun ein zweiter Peer y in den Chord-Ring ein, so lässt y zunächst seinen Nachfolger von x bestimmen. Peer y erhält auf diese Weise seinen Nachfolger Peer x. Zu diesem Zeitpunkt haben die Peers x und y die folgenden Zustände: x.successor = x y.successor = x x.predecessor = null y.predecessor = null Bei der Ausführung des Stabilisierungsprotolls ruft y die Funktion x.getpredecessor() sowie die Funktion x.notify(y) auf. Während x.getpredecessor() keine Veränderung bei y bewirkt (x ist bereits der Nachfolger von y) so wird x durch den Aufruf von x.notify(y) dazu veranlasst, y zu seinem Vorgänger zu machen. Nun haben die Peers x und y die Zustände: x.successor = x y.successor = x x.predecessor = y y.predecessor = null In diesem Zustand kommt es nun zu einem Stillstand. Da x sein eigener Nachfolger ist, ruft x bei der Durchführung des Stabilisierungsprotokolls x.getsuccesor() und x.notify(x) auf. Beide Aufrufe ändern weder den Zustand von x, noch den Zustand von y. Peer y ruft bei der Stabilisierung x.getsuccessor() und x.notify(y) auf. Auch hier ändern beide Aufrufe weder den Zustand von x noch den Zustand von y. Die korrekten Vorgänger-Nachfolgerbeziehungen zwischen den Peers werden also nicht hergestellt. Insbesondere wird x denken, dass er immer noch für alle Schlüssel verantwortlich ist, so dass es zu falschen Lookups kommt. Dieses Problem kann gelöst werden, indem x seinen Nachfolger auf y setzt, sobald y von ihm seinen Nachfolger bestimmen lässt. Hierzu verwendet y den normalen Lookup-Mechanismus. Wird jedoch der normale Lookup-Mechanismus verwendet, so besteht für Peer x kein Unterschied zwischen der Bestimmung des Nachfolgers und der Suche nach einen Schlüssel. Dementsprechend ändert x auch seinen Nachfolger nicht direkt ab. Aus diesem Grund müssen konventionelle Lookups von der Suche nach dem Nachfolger unterscheidbar sein. 6 Sind konventionelle Lookups von der Bestimmung des Nachfolgers unterscheidbar und erhält x nun von y den Auftrag, dessen Nachfolger zu bestimmen, so ändert 6 vgl.: Abschnitt

36 3.3 Der Chord-Peer x seinen Nachfolger auf x.successor = y ab. Die Peers x und y haben somit die folgenden Zustände: x.successor = y y.successor = x x.predecessor = null y.predecessor = null Nachdem x und y jeweils einmal das Stabilisierungsprotokoll ausgeführt haben, besitzen beide die korrekten Vorgänger und Nachfolger. Das beschriebene Problem tritt jedoch nur in diesem speziellen Fall auf. Tritt nun ein dritter Peer z in den Chord-Ring ein, so führt das in Abschnitt beschriebene Stabilisierungsprotokoll zu korrekten Ergebnissen Die Nachfolgerliste Das Funktionieren des Chord-Algorithmus basiert darauf, dass jeder Peer den korrekten Nachfolger kennt. Wenn z. B. im Chord-Ring aus Abbildung 3.6 Peer P22 ausfällt, besitzt P14 keinen Nachfolger mehr. Darüber hinaus wird er nicht wissen, dass P32 sein neuer Nachfolger ist. In der Folge wird P14 nicht wissen, dass er selbst für Schlüssel 30 verantwortlich ist. Einen entsprechenden Lookup wird er verwerfen, da die Finger P32 und P48 hinter dem gesuchten Schlüssel liegen. Für den Fall, dass P14 dennoch den Lookup z. B. an P32 weiterleitet, wird P32 den Lookup gemäß seiner Fingertabelle an P1 weiterleiten. Da P22 ausgefallen ist, ist von den Fingern von P1 wiederum P14 dem gesuchten Schlüssel 30 am nächsten, womit der Lookup wieder an seinem Ausgangspunkt angelangt. So können falsche oder fehlende Nachfolger zu falschen Lookups, bzw. zu Zyklen führen. 7 Um Chord dahingehend robuster zu machen, besitzt jeder Peer nicht nur einen Nachfolger, sondern eine Liste mit den ersten j Nachfolgern. Fällt der Nachfolger aus, so wird der erste nicht ausgefallene Peer in der Nachfolgerliste der neue Nachfolger. Der Fall, dass ein Peer keinen Nachfolger mehr hat, tritt somit nur noch dann ein, wenn alle j Nachfolger gleichzeitig ausfallen. Wenn jeder Peer mit der Wahrscheinlichkeit p ausfällt und jeder Peer j Nachfolger besitzt, dann ist die Wahrscheinlichkeit, dass ein Peer in seiner Nachfolgerliste keinen nicht ausgefallenen Nachfolger mehr findet gleich p j. Bei einer ausreichend langen Nachfolgerliste wird dadurch der Chord-Ring sehr robust. So zeigen die Autoren von [43], dass die Peers sogar dann 7 Beginnt P14 die Suche bei P48, so entsteht ebenfalls ein Zyklus, da P48 auch an P1 weiterleitet. 26