Kademlia

Kademlia [MaM02] ist ein Peer-to-Peer-Regelwerk, welches eine Baumtopologie imple-mentiert. Die teilnehmenden Knoten stellen die Bl¨atter eines Bin¨arbaums dar. Die Po-sition eines Knotens wird durch das k¨urzeste eindeutige Pr¨afix der NodeID festgelegt, welche wie bei Chord die L¨ange m = 160 Bit besitzt. Es ist zu erwarten, dass der entstehende Bin¨arbaum durch die Gleichverteilungseigenschaft der Hashfunktion zur Be-zeichnerberechnung ann¨ahernd ausbalanciert ist. Kademlia ist so konstruiert, dass Kon-figurationsnachrichten, z.B. zur Aktualisierung von Routing-Tabellen, fast vollst¨andig vermieden werden. Stattdessen werden Informationen ¨uber andere Knoten aus empfan-genen Lookup-Nachrichten extrahiert.

Als Distanzmetrik wird die XOR-Metrik verwendet: Die Bitstrings xund y werden ¨uber das bin¨are XOR verkn¨upft (bitweise Addition ohne ¨Ubertrag). Damit ist die Distanz zwi-schen zwei Knoten gering, wenn ihre NodeIDs ein langes gemeinsames Pr¨afix besitzen, d.h. ihr kleinster gemeinsamer Unterbaum durch einen m¨oglichst weit von der Wurzel entfernten inneren Knoten begrenzt wird. Im Gegensatz zu den einfacheren Distanz-definitionen in den bislang vorgestellten Protokollen ist diese Metrik nicht unmittelbar einsichtig, da die Distanz - als Dualzahl interpretiert - eine abstrakte, nicht intuitive Maßzahl darstellt. Abbildung 2.7 und Tabelle 2.1 verdeutlichen daher die Anwendung der XOR-Metrik zur Bestimmung der Distanz zwischen Knoten im Bin¨arbaum.

Abbildung 2.7: Beispiel: Bin¨arbaum in Kademlia mit m= 4

x↓ y→ 0001 (1) 0010 (2) 0101 (5) 1000 (8) 1001 (9) 1011 (11) 1101 (13) 1111 (15) 0001 0000 (0) 0011 (3) 0100 (4) 1001 (9) 1000 (8) 1010 (10) 1100 (12) 1110 (14) 1001 (9) 1000 (8) 1011 (11) 1100 (12) 0001 (1) 0000 (0) 0010 (2) 0100 (4) 0110 (6) 1111 (15) 1110 (14) 1101 (13) 1010 (10) 0111 (7) 0110 (6) 0100 (4) 0010 (2) 0000 (0) Tabelle 2.1: Beispiel: Distanzen ∆(x, y) im Kademlia-Bin¨arbaum (dezimale Entsprechung in Klammern)

Es sind stets diejenigen Knotenn_r1, n_r2, ...n_rk ∈ N_bf¨ur einen Bezeichnerbverantwortlich, f¨ur welche die jeweilige Distanz ∆(nri, b) (als Dualzahl interpretiert) zu denkgeringsten im Netz geh¨ort, wobeikein systemweit festgelegter Parameter ist (es gilt also:|N_b|=k).

Im Beispiel-Baum w¨aren also bei k= 3 f¨ur den Bezeichnerb= 1110 die Knoten mit den IDs 1111,1101 und 1011 zust¨andig.

Lookup. Die Routing-Tabelle eines Knotens n_i umfasst m = 160 Zeilen. Jede die-ser Zeilen enth¨alt eine FIFO-Liste mit maximal k Eintr¨agen. Jedes dieser sogenannten k-Buckets repr¨asentiert dabei einen Unterbaum, in welchem n_i nicht enthalten ist. Die in der j-ten Zeile der Routing-Tabelle erfassten Knoten teilen die ersten j−1 Bits mit n_i, w¨ahrend dasj-te Bit abweicht. Die Routing-Tabelle muss, wenn ein Unterbaum min-destens einen Knoten enth¨alt, in der entsprechenden Zeile minmin-destens einen Kontakt beinhalten.

Empfehlung der Entwickler von Kademlia [MaM02] ist k= 20. Abbildung 2.8 zeigt am Beispiel, welche Unterb¨aume in welcher Zeile der Routing-Tabelle vom Knoten mit ID 1011 abgedeckt werden m¨ussen.

Abbildung 2.8: Beispiel: Abzudeckende Unterb¨aume der Routingtabelle von 1011 Jede Lookup-Nachricht enth¨alt die NodeID des sendenden Peers. Empf¨angt ein Knoten eine solche Nachricht, untersucht er die enthaltene NodeID und ¨uberpr¨uft den ¨altesten Eintrag aus dem k-Bucket, dem diese ID zuzuordnen ist. Ist dieser alte Knoten offline, wird er aus der Liste entfernt und die gerade empfangene NodeID an den Anfang der Liste gestellt (Least Recently Seen Policy). Ist er hingegen noch online, so wird er an den Anfang der Liste geschrieben und die NodeID aus dem empfangenen Lookup verworfen.

Diese Form des

”Lazy Update“ der Routing-Tabellen unterscheidet Kademlia wesentlich von den meisten anderen strukturierten Peer-to-Peer-Protokollen und -Regelwerken.

Die Kontrolle f¨ur den Lookup liegt vollst¨andig bei dem Knoten, welcher ihn initiiert: er entscheidet ¨uber die jeweils im n¨achsten Schritt zu kontaktierenden Knoten und ¨ubermit-telt selbst in jedem Schritt die Lookup-Nachricht an die gew¨ahlten Peers - inallenanderen P2P-Protokollen wird hingegen die Lookup-Nachricht von Knoten zu Knoten weiterge-reicht. Einen Vergleich zwischen dem Transfer von Lookup-Nachrichten in Chord (als Repr¨asentant f¨ur die anderen Protokolle) und Kademlia liefern die Abbildungen 2.9(a) und 2.9(b).

In Kademlia existieren zwei verschiedene Lookup-Methoden:FIND_NODEundFIND_VALUE.

In jeder Lookup-Nachricht muss vermerkt sein, welche von beiden verwendet wird.

(a) Chord

(b) Kademlia

Abbildung 2.9: Transfer von Lookup-Nachrichten

Mit der Methode FIND_NODE wird nach den k zust¨andigen Knoten f¨ur einen Bezeichner gesucht. Hierbei ermittelt der Initiator zun¨achstα Knoten aus demk-Bucket, welches in der Zeile mit dem l¨angsten gemeinsamen Pr¨afix mit bsteht. Sucht der Knoten 1011 aus Abb. 2.8 also nach den zust¨andigen Knoten f¨ur den Bezeichner 0111, so verwendet er das k-Bucket f¨ur das Pr¨afix 0 (1. Zeile).

Empf¨angt ein Knoten eine FIND_NODE-Nachricht f¨ur b, liefert er - wenn m¨oglich - eine Liste vonkKnoten zur¨uck, deren NodeIDs eine geringere Distanz zubaufweisen als seine eigene. Aus diesen maximal α·kpro Schritt gelieferten NodeIDs w¨ahlt der Initiator des Lookup wiederum α aus und sendet ihnen lookup_b. Dieser Schritt wird wiederholt, bis die kKnoten mit der geringsten Distanz zu bgefunden sind und geantwortet haben.

Die MethodeFIND_VALUEhingegen sucht konkret nach dem Datensatz mit Bezeichnerb.

Wenn ein Knoten also eine Lookup-Nachricht mit dieser Methode empf¨angt, ¨uberpr¨uft er zun¨achst, ob er einen Datensatz mit Bezeichner b gespeichert hat. Wenn ja, liefert er diesen zur¨uck und der Lookup ist beendet. Ansonsten verf¨ahrt er wie bei Methode FIND_NODE und liefert kKnoten mit n¨aher an bliegenden NodeIDs.

Zum Einf¨ugen eines Datensatzes werden ¨uber einen Lookup die k zust¨andigen Peers ermittelt. Der publizierende Knoten sendet dann jedem von ihnen eine Speicheraufforde-rung f¨ur den Datensatz, so dass kReplika erzeugt werden.

Der Aufwand f¨ur den Lookup istO(log₂N). Durch Vergr¨oßerung der Routing-Tabelle auf 2^blog₂bN Eintr¨age (f¨ur erwartete Netzgr¨oßeN) kann er aufO(log₂bN) verringert werden.

Join. Wie bereits beschrieben, werden die Routing-Tabellen der Knoten st¨andig aktu-ell gehalten, indem die Absender aller eingehenden Lookups untersucht und bei Bedarf gespeichert werden. Eink-Bucket wird nur dann aktualisiert, wenn ein alter Kontakt das Netz verlassen hat.

Betritt ein Knoten das Netzwerk, nimmt er Kontakt mit einem aktiven Peer n_e auf und f¨ugt diesen als ersten Kontakt in sein entsprechendesk-Bucket ein. Dann initiiert er mit-tels Weiterleitung einer Lookup-Nachricht an n_e die Suche nach seiner eigenen NodeID n_i. Die im Zuge dieses Lookups kontaktierten Knoten werden dabei bereits von der An-wesenheit des neuen Knotens informiert und erfassen ihn bei Bedarf. Der neue Peer selbst speichert wiederum seine neu gewonnenen Kontakte.

Diese k¨onnen aber nur diek-Buckets zwischenn_eund seiner eigenen NodeIDn_i bef¨ullen.

Knoten in anderen, weiter entfernten Unterb¨aumen wurden beim Lookup nach n_i nicht kontaktiert, da sie ein k¨urzeres Pr¨afix mitn_i teilen alsn_eselbst. Daher f¨uhrtn_ieinen so-genannten Bucket Refresh aus: f¨ur jedes noch leerek-Bucket erzeugt er einen Bezeichner mit entsprechendem Pr¨afix und f¨uhrt einenFIND_NODE-Lookup daf¨ur durch, um Kontak-te in den noch unbekannKontak-ten UnKontak-terb¨aumen zu finden.

Sobald die zust¨andigen Knoten f¨ur Bezeichner n_i von dem neuen Peer erfahren, ¨uberge-ben sie ihm die gespeicherten Datens¨atze, f¨ur die er nun mit zust¨andig ist.

Leave. Verl¨asst ein Knoten das Netzwerk, werden keine anderen Peers informiert. Erst im Zuge neuer Lookups wird der Kontakt gem¨aß der bereits beschriebenen Least Recent-ly Seen Policy nach und nach aus denk-Buckets anderer Knoten entfernt.

Eine ¨Ubertragung der gespeicherten Daten kann somit nicht stattfinden - sie gehen verlo-ren. Die verbleibenden zust¨andigen Knoten halten aber weiterhin Replika der Datens¨atze und ¨ubergeben sie an jeden dem Netz neu beitretenden Peer, dessen NodeID ihn selbst zu einem zust¨andigen Knoten f¨ur diese Datens¨atze macht.

Zudem wird zur Erhaltung der Replika in regelm¨aßigen Abst¨anden ein Republishing durchgef¨uhrt, d.h. jeder Knoten sendet regelm¨aßig und selbst¨andig Speicheraufforderun-gen f¨ur seine gespeicherten Datens¨atze an jeweils alle anderen zust¨andiSpeicheraufforderun-gen Knoten.