Chord vs. CAN eine Gegenüberstellung zweier skalierbarer Peer-to-Peer Netzwerke

Chord vs. CAN eine Gegenüberstellung zweier skalierbarer Peer-to-Peer Netzwerke Dennis Butterstein November 2006 1 Einleitung Peer-to-Peer Netzwerke haben in den Letzten Jahren sowohl durch die Medien 1, als auch durch die mögliche kriminelle Nutzung Aufsehen erregt und sich dadurch viele Befürworter, aber auch eine Vielzahl an Gegnern geschaffen, wie z.b. die Musikbranche. Warum sollte man in diese Richtung weiterforschen, wenn diese Technologie hauptsächlich zum illegalen Austausch von Software und Musik genutzt wird? Was vielen dieser Gegener nicht einleuchtet ist die Tatsache, dass diese Systeme auch für andere Zwecke genutzt werden können. Beispielsweise als riesige Netzwerke, welche ohne unverantwortlich hohe Investitionen in Hardware, Bandbreite oder Ahnlichen auch für Firmenzwecke hilfreich sind. Peer-to-Peer Netzwerke haben stets die Aufgabe sich - so effizient wie möglich - grundlegender Probleme anzunehmen, die sich jedem verteilten Netzwerk stellen. Diese Probleme sind hauptsächlich: 1. Lokalisierung von Netzwerkteilnehmern Wiederfinden eines Netzwerteilnehmers, der bestimmte Daten bereitstellt. 2. Handhabung der ständigen Größenänderung des Netzwerks Wie kann man Netzwerkteilnehmer effizient ins Netzwerk einbinden bzw. Datenkonsistenz und Netzwerkstabilität beim Verlassen von Netzwerkteilnehmern gewährleisten. Im Folgenden möchte ich die Lösungsansätze hierzu, zweier dezentraler Peer-to-Peer Protokolle genauer beleuchten und darüber hinaus weitere Funktionalitäten von Chord und CAN 2 darstellen und vergleichen. 2 Chord Chord erstellt sowohl aus der IP-Adresse eines Netzwerteilnehmers einen Hashwert (Identifier) als auch aus den Schlüsseln (Keys), welche dann den Netwerkteilnehmern zugeordnet werden. Die Tabelle, in der diese Identifier vermerkt sind, ist auf alle Netzwerkteilnehmer verteilt, weshalb man von einer verteilten Hashtabelle spricht. Diesen Schlüsseln werden dann Daten zugeordnet, wodurch man diese von jedem Netzwerkteilnehmer ausgehend im Chord-Netzwerk finden kann. 1 hauptsächlich Napster 2 Content-Adressable Network

2.1 Aufbau eines Chord-Netzwerks Man muss sich ein ringförmig angeordnetes Netzwerk modulo2 m vorstellen. Jedem auf dem Ring befindlichen Identifier kann ein Netzwerkteilnehmer zugeordnet werden und den Netzwerkteilnehmern können wiederum Schlüssel zugeteilt werden, mit denen Daten wiederaufgefunden werden können. Diese Schlüssel sind mit bestimmten Daten verknüpft, das heißt, derjenige Netzwerkteilnehmer, der einen Schlüssel zugeordnet bekommt, bekommt automatisch mit dem Schlüssel Daten zugeordnet. Jeder Netzwerkteilnehmer speichert seine Schlüssel zusammen mit den zu dem Schlüssel gehörigen Daten ab und stellt sie somit dem Chord-Netzwerk zur verfügung. 2.1.1 Verteilung der Netzwerkteilnehmer und Daten auf Identifiers im Ring Die Verteilung der Netzwerkteilnehmer auf die Identifier und der Schlüssel auf die Netzwerkteilnehmer erfolgt über Consistent Hashing 3, welches automatisch einen gewissen Lastausgleich schafft. Consistent Hashing stellt das Herzstück von Chord dar. Durch eine Hashfunktion werden aus den IP-Adressen der Netzwerkteilnehmer und den Schlüssel Hashwerte berechnet. Die Schlüssel werden dann wie folgt den Netzwerkteilnehmern an den jeweiligen Identifiern zugewiesen: Zunächst werden die Identifier in einem Kreis (modulo 2 m ) so angeordnet, dass die Werte im Uhrzeigersinn aufsteigend sortiert sind. Nun werden die IP-Adressen der Netzwerkteilnehmer durch die Hashfunktion in Hashwerte umgerechnet und den Identifiern entsprechend zugeordnet, d.h. ein Netzwerkteilnehmer wird an der Stelle in den Kreis eingefügt, an der sein Hashwert dem Identifierwert im Kreis entspricht. Im Folgenden müssen den Netzwerkteilnehmern noch Schlüssel zugeordnet werden, damit später im Netzwerk Daten aufgefunden werden können, also kann man die Schlüssel mit Ortsangaben vergleichen. Zunächst berechnet die selbe Hashfunktion den entsprechenden Hashwert aus dem Schlüssel. Dieser wird entweder dem Netzwerkteilnehmer zugeordnet, dessen Hashwert gleich dem Hashwert des Schlüssel, oder größer ist. Man nennt diesen Netzwerkteilnehmer dann Nachfolgerknoten des Schlüssel. Da Consistent Hashing verwendet wird resultiert ein gewisser Grad an Lastausgleich 4 im Netzwerk. In Abbildung1 ist der Vorgang der Zuordnung graphisch aufbereitet und leicht nachvollziehbar. Abbildung 1: Chord Ring Zu speichernde Routingdaten Die Netzwerkteilnehmer sollten natürlich so wenig Routingdaten wie möglich speichern müssen, um zu viel unnötige Datentransfers beispielsweise beim Aktualisieren dieser Routinginformationen zu vermeiden. Deshalb sind bei Chord nur sehr wenige gespeicherte Daten nötig um Daten oder Netzwerkteilnehmer in akzeptabler Zeit aufzufinden. Jeder Netzwerkteilnehmer hält folgende Informationen um ein effizientes Routing zu gewährleisten: 3 erfolgt über SHA-1 4 siehe: Paper über Consistent Hashing START INTERVALL NACHFOLGER 2 [2,3) 3 3 [3,5) 3 5 [5,1) 7 Abbildung 2: Fingertable von Netzwerkteilnehmer 1

1. Nachfolgerzeiger zeigt auf den im Uhrzeigersinn nachfolgenden Netzwerkteilnehmer 2. Fingertables enthalten den Identifier, die IP-Adresse und den Port des Netzwerkteilnehmers Die Nachfolgerzeiger zeigen wie oben beschrieben jeweils auf den im Uhrzeigersinn folgenden Netzwerkteilnehmer im Netzwerk. Dadurch wird es möglich von Netzwerkteilnehmer zu Netzwerkteilnehmer zu springen um Anfragen nach einem bestimmten Schlüssel zu erfüllen. Allerdings birgt dieses Vorgehen erhebliche Nachteile, auf die in Sektion 2.1.2 eingegangen wird. Des Weiteren werden Fingertables bei den Netzwerkteilnehmern gespeichert, die m einträge 5 haben. Diese Informationen lassen Sprünge innerhalb des Kreises zu, da die Fingertable-Einträge lediglich Zeiger auf Nachfolger darstellen, deren Abstand zum Netzwerkteilnehmer, der den Fingertable hält, exponentiell wächst. In Abbildung 2 ist ein Beispiel eines typischen Fingertables abgedruckt. 2.1.2 Lokalisation von Daten und Netzwerkteilnehmern Nachdem nun bekannt ist, welche Informationen jeder Netzwerkteilnehmer speichert kann man jetzt näher auf die Vorgehensweise beim Routing eines Chord Netzwerks eingehen. Im Wesentlichen werden im Standard-Chord-Protokoll zwei Arten des Routings unterstützt, welche die, in 2.1.1 erläuterten Routingmechanismen benutzen. Routing Eine Variante davon ist, einfach Netzwerkteilnehmer für Netzwerkteilnehmer, nach einem bestimmten Schlüssel abzusuchen, indem man einfach über die gespeicherten Nachfolgerpointer kontinuierlich einen Netzwerkteilnehmer weiter geht. Wird der Schlüssel hier nicht gefunden geht man wieder einen Netzwerkteilnehmer weiter, bis man den erforderlichen Schlüssel ausfindig gemacht hat. Allerdings ist diese Vorgehensweise reichlich ineffizient, wenn der gesuchte Schlüssel z.b. weit entfernt im Netzwerk liegt. Hinzu kommt, dass die Länge des Pfades bis zum Ziel linear mit der Anzahl der im Netzwerk befindlichen Netzwerkteilnehmer wächst. Die daraus resultierende Wartezeit für die Antwort auf Anfragen ist also bei dieser Art des Routings lediglich für direkte Nachbarn, des anfragenden Netzwerkteilnehmers akzeptabel und somit für Schlüssel, die möglicherweise weit entfernt liegen, unbrauchbar. Deshalb wird dieser Algorithmus auch lediglich zur Sicherung des Routings benutzt, falls es mit den Fingertables einmal Probleme geben sollte. Hier kommen die Fingertables ins Spiel. Diese enthalten Zeiger auf Nachfolger, deren Abstand zum anfragenden Netzwerkteilnehmer exponentiell mit der Zahl des Eintrags wächst. Das heißt der i. Eintrag im Fingertable ist der Netzwerkteilnehmer, der vom aktuellen Netzwerkteilnehmer den Mindestabstand (im Identifierspace!) 2 i 1 hat, also hätte der Netzwerkteilnehmer auf den der 3. Fingereintrag zeigt einen Mindestabstand von 2 3 1 = 4 zu dem Netzwerkteilnehmer, der den betreffenden Fingertable hält. Wenn also ein Netzwerkteilnehmer n einen Nachfolger eines gegebenen Hashwerts finden will, kann er dies nicht direkt aus dem Fingertable lesen, sondern n durchsucht seinen Fingertable nach einem Identifierwert (in den Intervallen), der möglichst nahe 6 an dem gesuchten Hashwert liegt. Dann überprüft n den so gefundenen Netzwerkteilnehmer auf seine Nachfolger. Ist der gesuchte Hashwert dabei wird dieser zurückgegeben, ansonsten wird nach demselben Schema weitergesucht und sobald der Hashwert gefunden wird, wird er dem Netzwerkteilnehmer zurückgeliefert, der die Anfrage ursprünglich gestartet hat. Da die Fingertables aufgebaut sind wie oben erklärt, lässt sich beweisen, 5 m entspricht der Anzahl der Bits der verwendeten Identifier 6 Nähe bedeutet hier kleiner Unterschied zwischen Identifierwerten der Netzwerkteilnehmer

dass man mit diesem Verfahren im Mittel lediglich O(log N) Netzwerkteilnehmer 7 kontaktiert werden müssen um den gesuchten Nachfolger zu finden. An einem praktischen Beispiel ist dies leichter verständlich: Angenommen man möchte von einem Netzwerkteilnehmer n aus den Nachfolgenden Netzwerkteilnehmer von k erreichen, p sei der Vorgänger von k und i sei immernoch die Nummer des Fingertable-Eintrages. Demnach wird n also seinen Fingertable nach dem am nähesten an k liegenden Vorgänger durchsuchen. Den so gefundenen Netzwerkteilnehmer nennen wir f. Nun muss der Abstand zwischen n und f, nach dem Aufbau der Fingertables mindestens 2 i 1 betragen und da f und p im selben Fingerintervall liegen müssen folgt, dass f und p nur noch maximal 2 i 1 Identifierwerte auseinanderliegen können. Das heißt also, dass die Distanz zwischen f und p bei jedem Hop halbiert werden kann und daraus resultiert eine mittlerre Pfadlänge von O(log N). Anmelden von Netzwerkteilnehmern Das Anmelden neuer Netzwerkteilnehmer am Netzwerk ist ein zentrales Problem von Peer-to-Peer Netzwerken. Die Lösung des Chordprotokolls dafür wird hier nun erklärt: Jeder Chord Netzwerkteilnehmer speichert hierfür zusätzlich zu oben genannten Daten einen Vorgängerzeiger. Chord stützt sein Vorgehen auf zwei Pfeiler. Der Nachfolgerzeiger eines jeden Netzwerkteilnehmers ist korrekt und für jeden Netzwerkteilnehmer ist sein direkter Nachfolger verantwortlich. Zwar sollten die Fingertables auch korrekt sein, aber diese dienen lediglich der höheren Geschwindigkeit bei Anfragen, nicht aber der Sicherung der Funktionalität des Netzwerks. Wenn also ein neuer Netzwerkteilnehmer n sich am Netzwerk anmeldet bekommt dieser zunächst einmal Informationen über irgendeinen beliebigen Netzwerkteilnehmer, welcher ihm auf Anfrage sowohl Vorgängerzeiger und Fingertabelle erstellt und liefert. Da n nun seine Daten hat, müssen jetzt die anderen Netzwerkteilnehmer im Netzwerk aktualisiert werden, d.h. sein Vorgänger muss seinen Nachfolgerzeiger aktualisiern und sein Nachfolger muss seinen Vorgängerzeiger aktualisieren. Zusätzlich müssen auch einige Fingertables bestehender Netzwerkteilnehmer angepasst werden. Unser n wird nur in Fingertables an i. Stelle bestehender Netzwerkteilnehmer eingetragen, wenn folgende Bedingungen erfüllt sind: 1. n ist mindestens 2 i 1 Identifierwerte entfernt 8 von dem Netzwerkteilnehmer, in dessen Fingertable er eingetragen wird 2. der i. Eintrag des aktualisierten Fingertables ist Nachfolger von n Dieses Vorgehen wird wiederholt und bei jedem Netzwerkteilnehmer angewandt, der die Bedingungen erfüllt und zwar werden diese Netzwerkteilnehmer gegen den Uhrzeigersinn gesucht. Der Algorithmus terminiert, sobald er auf einen Netzwerkteilnehmer trifft, dessen Fingertables i. Eintrag Vorgänger von n ist. Schließlich muss n noch einen Aufgabenbereich erhalten, d.h. bis jetzt ist n noch völlig unnütz. Er bekommt 9 also von seinem direkten Nachfolger diejenigen Schlüssel/Datenpaare transferiert, für deren Schlüssel n nun der Nachfolger ist. Nach diesem Schritt ist ein neuer Netzwerkteilnehmer dann komplett ins Netzwerk eingebunden. Der Obige Abschnitt bezieht sich auf vereinzeilte Anmeldungen am Netzwerk, was aber unter Realbedingungen in dieser Weise nicht beibehalten werden kann, dass heißt, wenn Netzwerkteilnehmer ständig kommen und gehen. Dabei entstehen unter anderem Concurrent Joins weshalb man Realbedingungen anders handhaben muss. Der folgende Abschnitt erklärt diese Erweiterung 10 zum 7 N sei die Gesamtanzahl Netzwerkteilnehmer im Netzwerk 8 im Uhrzeigersinn 9 hängt von der Software ab. Entweder kopiert o.ä. 10 wird Stabilisierung genannt

Chord Basisprotokoll. Stabilisiert wird durch die Haltung korrekter Nachfolgerpointer durch welche es dann möglich ist die Fingertables zu aktualisieren. Dies funktioniert so, dass jeder Netzwerkteilnehmer periodisch den Algorithmus Stabilisieren ausführt, welcher dann den nachfolgenden Netzwerkteilnehmer nach dessen Vorgänger p. So kann Stabilisieren entscheiden, ob p der Nachfolger des Netzwerkteilnehmers ist, der Stabilisieren ausgeführt hat. So kann man neu angemeldete Netzwerkteilnehmer einbinden. Wenn allerdings Anfragen vor der Beendigung der Stabilisierung an betreffende Netzwerkteilnehmer gemacht werden gibt es drei mögliche Verhaltensweisen des Netzwerks: 1. Benötigte Fingertable-Einträge sind korrekt also kann die Anfrage ganz normal beantwortet werden 2. Nachfolgerzeiger sind korrekt, nicht aber die Fingertables die Anfrage kann ebenfalls beantwortet werden, aber benötigt mehr Zeit 3. Nachfolgerzeiger und Fingertables sind inkorrekt die Anfrage kann fehlschlagen Falls eine Anfrage fehlschlägt ist dies nicht tragisch, da die Software die Chord benutzt dies registrieren kann, um z.b einfach später diese Anfrage zu wiederholen. Abmelden von Netzwerkteilnehmern und Nodefailures Um trotz Nodefailures ein konsistentes und stabiles Netzwerk zu gewährleisten werden diese in Chord wie folgt gehandhabt. Jeder Netzwerkteilnehmer speichert eine kurze Liste mit Zeigern auf die am nähesten liegenden Nachfolger. Wenn ein Netzwerkteilnehmer n ausfällt suchen andere Netzwerkteilnehmer, die n in ihren Fingertables haben dessen Nachfolger. Wenn ein Netzwerkteilnehmer dann merkt, dass sein Nachfolger fehlerhaft ist ersetzt er in dieser Liste einfach seinen Nachfolger einfach durch den ersten Zeiger, von dem er weiß, dass dieser noch vorhanden ist. Damit wird gewährleistet, dass Anfragen auch trotz Nodefailures weitergeleitet werden können ohne fehlerhaft zu werden. Mit der Zeit werden die Fingertables und die Nachfolgerzeiger, die auf fehlende Netzwerkteilnehmer zeigen, wieder in eine korrekte Form gebracht. 3 CAN Can arbeitet ebenfalls als verteilte Hashtabelle, verfolgt aber einen anderen Ansatz als Chord. Hier kann man sich als Grundraum ein Koordinatensystem vorstellen, in dem jeder Netzwerkteilnehmer seine Zone besitzt, für die er verantwortlich ist. Aus den Schlüssel werden hier durch eine Hashfunktion Hashwerte errechnet, die als Koordinaten im Koordinatensystem interpretiert werden. Derjenige Netzwerkteilnehmer, in dessen Zone diese Koordinaten liegen, ist folglich verantworlich für das Schlüssel/Datenpaar. Abbildung 3: CAN Netzwerk 3.1 Aufbau eines CAN-Netzwerks Ein CAN-Netzwerk besteht aus einem, in Zonen aufgeteilten Koordinatensystem, welches eine bestimmte Dimensionalität besitzt.

3.1.1 Verteilung der Daten auf ihre Zonen Jeder Netzwerkteilnehmer besitzt seine eigene Zone im Koordinatensystem. Der Einfachheit halber bezieht sich folgender Text auf ein zweidimensionales Koordinatensystem. Schlüssel / Datenpaare werden den verantwortlichen Zonen folgendermaßen zugewiesen: Zunächst wird wieder durch eine Hashfunktion ein Hashwert aus dem Schlüssel errechnet, welcher dann als Koordinate im Koordinatensystem interpretiert wird. Daraus lässt sich dann direkt ablesen welcher Netzwerkteilnehmer für dieses Schlüssel/Datenpaar verantwortlich ist, indem durch Vergleich der Koordinate mit den Zonendaten geprüft wird, welcher Netzwerkteilnehmer verantwortlich für die Zone ist, in der der errechnete Punkt liegt. Diesem Knoten wird dann das Schlüssel / Datenpaar überschrieben. Zu speichernde Routingdaten Im Gegensatz zu Chord-Netzwerkteilnehmern müssen CAN-Netzwerkteilnehmer andere Daten speichern um Routing gewährleisten zu können. Diese Daten sind: 1. Zoneninformationen ein Netzwerkteilnehmer enthält Informationen seiner eigenen Zone bezüglich des Intervalls. 2. Koordinaten Routingtable enthält eine Liste der IP-Adressen und der Zoneninformationen seiner direkten Nachbarn Ein Netzwerkteilnehmer hält seine eigenen Zoneninformationen um feststellen zu können, ob er die gestellte Anfrage erfüllen kann und um die Schlüssel / Datenpaare den Zonen zuzuordnen. Die Informationen über seine Nachbarn, die ein Netzwerkteilnehmer hält sind deshalb wichtig, dass ein Netzwerkteilnehmer eine Anfrage in die richtige Richtung weiterleiten kann. Unter Nachbarn sind lediglich diejenigen Netzwerkteilnehmer zu verstehen, welche mit dem zentralen Netzwerkteilnehmer eine Kante teilen. Diese Informationen genügen um Routing zu gewährleisten, jedoch ist es in einem zweidimensionalen CAN-Netzwerk weit weniger effizient als in höherdimensionalen oder in Can-Netzwerken mit mehreren Realitäten. Realitäten bezeichnet man im Zusammenhang mit CAN als nebeneinanderliegende Koordinatensysteme, in denen jeder Netzwerkteilnehmer in jedem dieser Koordinatensysteme eine andere Zone zugewiesen bekommt. So kann man die Pfadlänge verkürzen. 3.1.2 Lokalisation von Daten und Netzwerkteilnehmern Mit diesem Vorwissen über gespeicherte Routingdaten kann man sich nun den zugehörigen Algorithmen widmen. Routing Um eine Anfrage 11 beantworten zu können müssen sie in irgendeiner Form durch das CAN-Netzwerk geroutet werden können. Dies geschieht folgendermaßen: Eine Anfrage besteht aus einer CAN-Message, welche den Schlüssel der Anfrage enthält, aus dem die Zielkoordinaten berechnet werden können. Ein Netzwerkteilnehmer prüft also, ob die Zielkoordinaten in der Message in seiner Zone liegen. Ist dies der Fall kann er selbst die Anfrage beantworten, ansonsten prüft der Netzwerkteilnehmer seinen Routingtable und sucht denjenigen Nachbarn aus, dessen Zone am nächsten an den Zielkoordinaten liegt. Dieser geht dann analog vor. Durch diese Vorgehensweise entsteht bei angenommenen n gleichen Zonen in einem d-dimensionalen CAN-Netzwerk eine mittlere Pfadlänge von d/4 n 1/d und man besitzt 11 Es wird eine Anfrage nach einem bestimmten Schlüssel losgeschickt, d.h. aus der Message können die Zielkoordinaten berechnet werden

den Vorteil, dass mehrere Wege zum Ziel existieren, das heißt, wenn ein Netzwerkteilnehmer ausfällt kann sofort ein alternativer Weg einschlagen werden und somit fehlerhafte Netzwerkteilnehmer umgangen werden. Anmelden von Netzwerkteilnehmern Um einem CAN-Netzwerk beizutreten, muss dem neuen Netzwerkteilnehmer eine Zone zugewiesen werden und er muss die Schlüssel/Datenpaare erhalten, für die er ab jetzt verantwortlich sein wird. Dieses Procedere gliedert sich in folgende Schritte: 1. Bootstrap der neue Netzwerkteilnehmer muss zunächst einen bereits existierenden Netzwerkteilnehmer finden. 2. Zone finden er benötigt eine Zone, für die er im folgenden verantwortlich ist. 3. Dem Routing beitreten der neue Netzwerkteilnehmer muss seinen Nachbarn bekannt gemacht werden und umgekehrt. Der Bootstrap erfolgt über einen dem CAN-Netzwerk eigenen DNS Domain-Namen, welcher auf die IP-Adressen von so genannten Bootstrapnodes verweist. Dieser hält Informationen (IP-Adressen) über einige Netzwerkteilnehmer, welche er sobald er kontaktiert wird an den neu angemeldeten Netzwerkteilnehmer weiter gibt. Ist dies erfolgreich abgeschlossen gegangen geht die Anmeldung am Netzwerk in die zweite Phase über und es wird versucht eine Zone für den neuen Netzwerkteilnehmer ausfindig zu machen. Der neue Netzwerkteilnehmer wählt dann zufällig eine Koordinate aus, an die er, über einen bereits existierenden CAN-Netzwerkteilnehmer, einen Join Request sendet. Dieser wird dann, wie im Abschnitt Routing beschrieben zum Ziel weitergeleitet. Der Netzwerkteilnehmer, in dem die Zielkoordinaten liegen, teilt dann seine Zone in zwei Hälften, behält eine für sich, teilt die andere dem neuen Netzwerkteilnehmer zu und überträgt dem neuen Netzwerkteilnehmer die Schlüssel/Datenpaare für die er ab jetzt verantwortlich ist. Schließlich muss der neue Netzwerkteilnehmer noch dem Routing beitreten, indem er seine Nachbarn kennenlernt und diese ihn. Der neue Netzwerkteilnehmer bekommt also von dem Netzwerkteilnehmer, der ihm die neue Zone zugewiesen hat, einen Teil der IP-Adressen seiner Nachbarn und dessen eigene IP-Adresse. In gleicher Weise aktualisiert der alte Netzwerkteilnehmer nun seine Nachbartabelle, da es ja Netzwerkteilnehmers gibt, die nun nicht mehr dessen direkte Nachbarn sind. Nun senden der Netzwerkteilnehmer, der seine Zone geteilt hat und der beigetretene, eine Updatemessage und periodische Refresh Messages mit ihren neuen Zonen an alle direkten Nachbarn, welche dann ihre gespeicherten Daten über die Nachbarn erneuern. Ist dies abgeschlossen ist der neue Netzwerkteilnehmer ins Routing eingebunden. Durch diese Vorgehensweise wird erreicht, dass bei Nodejoins lediglich ein kleiner Teil des Netzwerks aktualisiert werden muss, nämlich exakt die Anzahl der Nachbarn, die betroffen sind. So wird erreicht, dass Nodejoins nur wenige Datentransfers verursachen und das Netzwerk nicht unnötig stark damit belasten. Abmelden von Netzwerkteilnehmern und Nodefailures Wenn ein Netzwerkteilnehmer sich dagegen abmeldet, muss seine Zone von einem anderen Netzwerkteilnehmer übernommen werden. Wenn es möglich ist übergibt der Netzwerkteilnehmer, der das Netzwerk verlässt seine Zone ebenso wie die zugehörigen Schlüssel/Datenpaare an einen seiner Nachbarn. Andernfalls wird dem Nachbarn die Zone zeitweise übergeben, der selbst die kleinste Zone zu

verwalten hat. Ebenso muss natürlich die Information, dass dieser Netzwerkteilnehmer nicht mehr da ist an die Nachbarn weitergegeben werden. Dies erfolgt ebenfalls nach dem oben benannten Schema. Fällt ein Netzwerkteilnehmer einfach aus wird dies von den Nachbarn bemerkt, weil seine periodischen Updatemessages ausbleiben und es wird in jedem benachbarten Netzwerkteilnehmer ein Übernahmealgorithmus auslöst. Dieser zählt einen Timer herunter, dessen Zeit sich nach der Größe des jeweiligen Nachbarn richtet, d.h. größere Nachbarn haben anfangs höhere Zählerstände als kleinere. Der Nachbar, der als Erster seinen Timer auf null runtergezählt hat übernimmt dann die Zone mit den zugehörigen Schlüssel/Datenpaaren und sendet an die anderen Nachbarn eine Message, die seine Zonengröße enthält. Die Nachbarn prüfen, ob die Zonengröße in der Message kleiner ist als deren Eigene. Ist dies der Fall, brechen sie den Übernahmealgorithmus ab, ansonsten sendet einer, dessen Zone kleiner ist eine Übernahmemessage. Dieser hat dann das Vorrecht. So wird gewährleistet, dass eine gewisse Balance der Zonengrößen erreicht wird. Wenn allerdings viele Netzwerkteilnehmer in einer Nachbarschaft gleichzeitig ausfallen kann es in diesem System zu Inkonsistenzen kommen. 4 Vergleich der beiden Systeme: Dieser Abschnitt soll Chord und Can einander gegenüberstellen und vergleichen und bezieht sich im Allgemeinen nur auf die Basisversionen von Chord und Can. Vergleicht man Chord und CAN hinsichtlich der Skalierbarkeit fällt auf, dass die Pfadlängen der beiden Ansätze sich unterscheiden. Die Anzahl der Schlüssel, die ein Chord-Netzwerkteilnehmer speichern muss wächst linear zu der Anzahl der im Netzwerk vorhanden Schlüssel, was durch Consistent Hashing gewährleistet wird. Bei CAN wächst dies in annähernd gleicher Weise, was aber davon abhängt in welchem Zustand sich das Netzwerk befindet, d.h. wenn jeder Netzwerkteilnehmer dieselbe Zonengröße verwalten muss kann man auch davon ausgehen, dass jeder Netzwerkteilnehmer ungefähr dieselbe Anzahl Schlüssel verwalten muss, was aber durch fortschreitende Fragmentierung bei weiteren Nodejoins und durch Übergabe von Zonen beim Verlassen von Netzwerkteilnehmern etwas verfälscht wird. Da jedoch der Übernahmealgorithmus und ein weiterer Ausgleichsalgorithmus bemüht sind, Zonengrößen auszugleichen, wird CAN ebenfalls annähernd linear skalieren. Die Routingdaten die Chord bei großen Netzwerken an jedem Netzwerkteilnehmer speichern muss sind die Vorgänger-/Nachfolgerzeiger und den Fingertable, der höchstens m einträge 12 hat. Ein CAN-Netzwerkteilnehmer speichert immer dieselbe Anzahl an Nachbardaten, da die Anzahl der Nachbarn immer dieselbe bleibt. Diese Anzahl hängt lediglich von der Anzahl der benutzten Dimensionen ab. Während Chord bei korrekt gehaltenen Fingertables lediglich O(log N) Hops benötigt um ein Ziel zu finden, benötigt CAN O(d/4 n (1/d) ) 13 Hops und ist somit langsamer beim Auffinden eines Ziels. Zwar sind damit beide Netzwerke nicht langsam aber Chord hat dennoch einen Geschwindigkeitsvorteil, der allerdings nur bestehen bleibt, solange die Fingertable-Einträge aktuell sind. Ansonsten degeneriert dieser Vorteil und die Pfadlänge würde beginnen, linear zur Größe des Netzwerks zu wachsen. CAN dagegen lässt nur eine Routingmöglichkeit zu, welche zwar langsamer arbeitet 14 aber auch seine Vorteile besitzt. Diese werden beispielsweise bei Nodefailures deutlich. Nachdem CAN Nachbarn in mehrere Richtungen besitzt kann CAN, wenn ein Netzwerkteilnehmer ausfällt, der auf dem derzeit benötigten Pfad liegt, einfach einen anderen Weg einschlagen und das praktisch ohne Verzögerung. Bei Chord ist dieser Sachverhalt problematischer, da man lediglich 2 Nachbarn besitzt, d.h. man kann (wegen der Ringform) nicht einfach einen anderen möglichen Pfad suchen, da es nur einen gibt. Chord kann in diesem Fall mehr Zeit 12 wobei m die Anzahl der Bits der Hashwerte beträgt 13 n gleichgroße Zonen, d=#der Dimensionen (hier 2) 14 diese ist noch ausbaufähig, beispielsweise durch das Hinzufügen weiterer Dimensionen

in Anspruch nehmen um ein Ziel zu finden da eine Anfrage dann erst nach einem Timeout an einen anderen funktionierenden Netzwerkteilnehmer aus dem Fingertable weitergeleitet wird. Hinsichtlich der Datenverfügbarkeit bei Nodefailures, d.h. die Schlüssel/Datenpaare die der Netzwerkteilnehmer gespeichert hatte, gehen verloren, agiert CAN so, dass diejenigen Netzwerkteilnehmer, die spezifische Daten eingefügt haben diese periodisch wieder auffrischen, um Datenverluste und fehlerhafte Daten zu vermeiden. In Chord ist diese Problematik nicht explizit gelöst und daher der Software, die Chord benutzt, überlassen. Beispielsweise ist vorstellbar Kopien der Schlüssel/Datenpaare eines Netzwerkteilnehmers einfach an einige Netzwerkteilnehmer zu vergeben, die Nachfolger des Schlüssels sind. Beide Netzwerke bieten in ihrer Basisversion kaum bzw. gar keine Anonymität für ihre Benutzer. Chord arbeitet also im Allgemeinen zwar schneller und skaliert etwas besser, aber CAN besitzt die bessere Datenverfügbarkeit, die einfachere Lösung für Nodefailures und es ist weniger aufwändig die Routingdaten aktuell zu halten. Zusammengefasst kann man also sagen, dass sowohl Chord als auch CAN - in ihrer Basisversion - ihre spezifischen Vor- und Nachteile haben. 5 Anhang In der technischen Diskussion des Vortrags wurde eine Frage aufgeworfen: Wäre es sinnvoll einen zweiten Fingertable, der Sprünge gegen den Uhrzeigersinn möglich macht, an den Netzwerkteilnehmern zu speichern? Im Laufe der Diskussion stellte sich heraus, dass man zwar in der Hälfte aller Fälle durch einen weiteren Fingertable einen Hop einsparen könnte, da man mit dem einen oder mit dem andern Table näher am Ziel liegt. Jedoch wäre der Aufwand die Fingertables aktuell zu halten ungleich höher als der Nutzen der durch das Einsparen eines einzigen Hops ensteht. Literatur [1] Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, Scott Shenker, Berkeley CA, A Scalable Content-Adressable Network, 2000 <citeseer.ist.psu.edu/ratnasamy01scalable.html> [2] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan, MIT Laboratory for Computer Science, Chord: A Scalable Peer-to-peer Lookup Service For Internet Applications, 2001 <http://pdos.lcs.mit.edu/chord/> [3] Chord, Humboldt-Universität Berlin <http://sarwiki.informatik.hu-berlin. de/chord>