Peer-to-Peer-Netzwerke: Algorithmen und Methoden

Abbildung 6.12 zeigt beispielhaft einen Ausschnitt der Nachbarschaft eines Peers mit ID 4227 in einem Netzwerk mit 32-Bit IDs and 2b = JB I = 16.

    Wir werden im Folgenden einige wichtige Eigenschaften der Nachbarschaftsmengen in Tapestry erlautern. Eine wesentliche Eigenschaft ist die folgende Konsistenzeigenschaft.

    Abb. 6.12. Ausschnitt der Nachbarschaft eines Peers mit ID 4227.

    Tapestry Ubernimmt vom Plaxton-Routing den Gedanken zur Verringerung der Latenzzeiten beim Routing durch das Bevorzugen bezuglich der Latenzmetrik naher Peers. So ergibt sich die folgende Lokalitatseigenschaft.

6.3.2 Daten and Routing
    Peers, die Daten bereitstellen, werden in Tapestry Storage-Server genannt. Da ein Datum von mehreren Storage-Servern bereitgestellt werden kann, gibt es zusatzlich zu den Storage-Servern so genannte Root-Peers, die fur bestimmte Objekte verantwortlich sind.
    Fur die Verwaltung eines Datums mit ID V wird eine Menge Rp von Root-Peers eingesetzt, die durch eine Funktion MapRoots(b) (dazu gleich meter) bestimmt werden kann. Die Menge R bezeichnen wir im Weiteren als Root-Set. Aufgabe der Root-Peers ist es, Links auf diejenigen Peers zu verwalten, die das entsprechende Datum bereitstellen. Es ist zu beachten, dass jeder Peer sowohl Storage-Server als auch Root-Peer sein kann. Um ein Datum jederzeit lokalisieren zu konnen, muss Folgendes gewahrleistet sein:
    Eigenschaft 3: Eindeutiges Root-Set. Das Root-Set R , fur jedes Objekt 0 muss eindeutig sein, and insbesondere muss die Funktion MapRoots(O) immer das gleiche Root-Set Rp generieren, egal wo im Netzwerk die Funktion aufgerufen wird.
    Eine einfache Losung, die garantiert, dass MapRoots(O) immer die gleichen Server zuruckliefert, egal wo im Netzwerk die Funktion aufgerufen wird, ist die Verwendung einer Hash-Funktion. Das bedeutet, MapRoots(V) wurden z.B. einfach die ID des Datums 0 zuruckliefern (da diese ja auch durch Hashing entsteht). Nun sollte die Ausgabe von MapRoots(V) jedoch die ID eines oder mehrerer Root-Peers sein. Mit hoher Wahrscheinlichkeit wird jedoch kein Peer im Netzwerk existieren, der zufallig genau die gleiche ID wie das Datum besitzt. Dieses Problem konnte gelost werden, indent der dent berechneten Hash-Wert numerisch am nachsten liegende Peer verwendet wird. HierfUr ist jedoch eine globale Ordnung aller Peer-IDs notwendig, die in einem Peer-to-Peer-Netzwerk schwer aufrecht zu erhalten ist. Wie sich dieses Problem ohne globale Ordnung losen lasst, werden wir in Abschnitt 6.3.3 sehen.

    Storage-Server mussen den zustandigen Root-Servern mitteilen, dass sie das entsprechende Datum' bereitstellen, um es im Netzwerk verf igbar zu machen. Dies geschieht, indem sie eine entsprechende Nachricht entlang primarer Nachbarn zu jedem Peer p E Rp des Root-Sets schicken. Jeder der Peer, der these Nachricht weiterleitet, speichert dabei einen Datenlink auf den Storage-Server, der die Nachricht abgeschickt hat.
    Abb. 6.13. Publikation von Objekten im Tapestry-Netzwerk.
    Abbildung 6.13 veranschaulicht diesen Vorgang. Die Peers mit ID 39AA and 4228 sind Storage-Server des Datums mit ID 4378. Beide Peers publizieren ihr Datum entlang primarer Nachbarn beim zustandigen Root-Peer mit ID 4377. Jeder Peer, der die Publikationsnachricht weitergeleitet hat, speichert lokal einen Zeiger auf denjenigen Peer, der das publizierte Datum bereitstellt. So speichert der Peer mit ID 4361 beispielsweise einen Link fur das Datum 4378 auf Peer 39AA.
    Um Fehlertoleranz zu gewahrleisten, werden alle beim Publikationsprozess ent- standenen Zeiger nach einer festgelegten Zeit verworfen. Ein Storage-Server muss die von ihm bereitgestellten Daten also in festgelegten Intervallen erneut publizieren. Dies hat den Vorteil, dass Daten von Peers, die unerwartet ausgefallen sind, automatisch aus dem System entfernt werden. Des Weiteren werden Peers, die sich erst nach dem ersten Publikationsprozess dem Netzwerk angeschlossen haben and nun auf dem Publikationspfad liegen, nach kurzer Zeit automatisch mit den entsprechenden Links auf die Daten versorgt.

    Falls von einem Peer aus nach einem Datum V gesucht wird, so wird von diesem Peer das entsprechende Root-Set R, berechnet and anschlieBend zu einem beliebigen Root-Server aus RV, geroutet. Wird auf dem Weg zu dem ausgewahlten RootServer ein Link fur das gesuchte Datum getroffen, so wird direkt zu dem im Link gespeicherten Storage-Server gesprungen. Auf these Weise werden Peers, die nahe (bezuglich ihrer ID) zu dem gesuchten