Peer-to-Peer

Kapitel 13
Peer-to-Peer-Netzwerke
11. Vorlesung
Nach der Bedeutung des Wortes peer“ (engl. Gleichrangig“) bezeichnet ein Peer-to-Peer-Netzwerk 27.06.2005
”
”
ein Netzwerk, das Gleichrangige mit anderen Gleichrangigen verbindet. Diese Umschreibung würde Holger Mense
(hmense(at)upb.de)
auch allgemein für Rechner des Internets gelten. Schließlich unterscheiden die Internet Protocol
(IP) Adressen nicht zwischen bevorzugten und weniger bevorzugten Adressen. Trotzdem haben
sich im Internet zentralisierte Client-Server-Strukturen entwickelt, wie zum Beispiel Web- und
Mail-Server.
Bei einer Client-Server-Netzwerk-Struktur kontrolliert ein besonders bevorrechtigter Knoten
(= Server) die anderen Teilnehmer (= Clients). So speichert zum Beispiel ein Web-Server WebSeiten, die von Web-Clients abgerufen werden können. Hierzu melden sie sich beim Web-Server,
welcher dann die angeforderten Web-Seiten an den Web-Client überträgt. Verweigert der WebServer einem Client den Zugriff, so ist dieser machtlos. Des Weiteren sind keine Web-Seiten mehr
abrufbar, wenn der Web-Server ausfällt.
Wenn man also die funktionale Beschreibung eines Netzwerks betrachtet, so gilt die folgende
Definition:
Ein Peer-to-Peer-Netzwerk ist ein Kommunikationsnetzwerk zwischen Rechnern, in
dem jeder Teilnehmer sowohl Client als auch Server-Aufgaben durchführt.
Das bedeutet, es findet ein direkter Datenaustausch statt, der nicht auf Server angewiesen ist.
Allerdings existieren Peer-to-Peer-Netzwerke wie zum Beispiel Napster, die diese Definition nicht
erfüllen.
Eine allgemeinere Definition von Peer-to-Peer-Netzwerken hat die Peer-to-Peer-Workinggroup
formuliert:
In einem Peer-to-Peer-Netzwerk werden verteilte Rechenressourcen durch direkte Kommunikation gemeinsam genutzt.
Diese Definition ist allerdings schon wieder zu allgemein. Die einzige Aussage, die man sicher
Peer-to-Peer-Netzwerke aufstellen kann, ist, dass Peer-to-Peer-Netzwerke nicht dem Client-ServerModell unterliegen.
Durch die verteilte Struktur in einem Peer-to-Peer-Netzwerk unterliegt es einer großen Dynamik. Teilnehmer des Netzwerks (auch bezeichnet als Peers oder Knoten) erscheinen und verschwinden während dessen gesamten Existenz. Dabei hat jeder Knoten nur wenig Informationen über
das Netzwerk. Ein Knoten weiß zum Beispiel nichts über die unterliegende Struktur, mit der alle
Knoten untereinander verbunden sind. Insgesamt kommt das Netzwerk ohne zentrale Kontrolle
oder anderen hierarchischen Strukturen aus. Jeder Knoten verwendet die gleiche Software, um sich
in das Netzwerk einzugliedern und um dann über es zu kommunizieren.
87
88
KAPITEL 13. PEER-TO-PEER-NETZWERKE
13.1
Peer-to-Peer-Netzwerke 2005
Heute sind Peer-to-Peer-Netzwerke sehr populär. Statistisch werden ungefähr 50% des gesamten
Internetdatenverkehrs von Peer-to-Peer-Netzwerken erzeugt. Etwa 30 Millionen Europäer haben
schon mal ein Peer-to-Peer-Netzwerk benutzt.
Trotz dieser Popularität leben Peer-to-Peer-Netzwerke in einer feindlichen Umgebung. In den
Medien treten Peer-to-Peer-Netwerke oft nur mit der Verbreitung illegalen Materials, zum Beispiel
Musik- oder Videodateien, in Erscheinung. Dieser Umstand (und auch der des hohen Anteils am
gesamten Datenverkehr) führt dazu, das Internet Service Provider (ISP) Peer-to-Peer-Netzwerk
Verkehr filtern und so für ihre Kunden unbenutzbar machen. Auch Systemadministratoren kleinerer Netzwerke versuchen ihrer Benutzer an der Verwendung von Peer-to-Peer-Software zu hindern,
um so möglichen Verstoßen gegen das Urheberrecht zu entgehen.
Ein weiteres Problem für Peer-to-Peer-Netzwerke sind egoistische Benutzer, die Daten herunterladen ohne selbst welche zur Verfügung zu stellen. Sobald dieses Verhalten von (fast) allen
Benutzern umgesetzt wird, sind nicht mehr viele Dateien vorhanden, die im Netzwerk getauscht
werden können. Einige Netzwerke sind daher auch dazu übergangen, dass jeder Benutzer, der
Daten herunterladen möchte, auch welche anbieten muss.
Auch algorithmisch sind Peer-to-Peer-Netzwerke eine Herausforderung. Daten sollen in einem
solchen Netzwerk nicht schwer aufzufinden sein, dennoch nimmt gerade die Suche die meiste Zeit in
Anspruch. Ein anderer Aspekt ist die Netzwerkstruktur, mit der die einzelnen Knoten verbunden
sind. Sie darf zum einen nicht zuviel Anforderungen an jeden Client stellen (der Grad eines jeden
Knotens sollte aus Verwaltungsgründen möglichst gering sein), gleichzeitig muss die Struktur aber
einen Zusammenhang garantieren und eine möglichst effiziente Kommunikation erlauben.
13.2
Generationen der Entwicklung von Peer-to-Peer-Netzwerken
Die Entwicklung von Peer-to-Peer-Netzwerken kann in Generationen eingeteilt werden.
1. Generation: Die Entwicklung von Peer-to-Peer-Netzwerke der ersten Generation hat mit
Napster ihren Anfang genommen. Trotz des Peer-to-Peer Ansatzes verfügen sie über eine
Client-Server-Struktur, in der ein Server die Vermittlung zwischen den einzelnen Clients
vornimmt.
2. Generation: In einer zweiten Generation von Peer-to-Peer-Netzwerken sind diese unkoordiniert, aber vollständig dezentral organisiert. Es existiert keine zentrale Komponente mehr,
die für die korrekte Funtkionsweise des Netzwerks erforderlich ist. Dadurch sind sie auch
vollständig unkontrolliert. Keine Instanz kann den Verbindungsaufbau eines bestimmten Benutzers unterbinden. Beispiele für Peer-to-Peer-Netzwerke der zweiten Generation sind unter
anderem Gnutella, eDonkey und Kazaa.
3. Generation: Die dritte Generation von Peer-to-Peer-Netzwerken erweitert Netzwerke der zweiten Generation um weitere Eigenschaften. Zur Verwaltung von Peers und Daten im Netzwerk
werden effiziente Datenstrukturen eingeführt. Solche Ideen finden sich zum Beispiel in den
Peer-to-Peer-Netzwerken CAN, Chord, Pastry oder Tapestry.
Eine weitere neue Eigenschaft ist die Gewährleistung von Anonymität innerhalb des Netzwerks. Ziel ist es, Daten auszutauschen ohne das ermittelt werden kann, wer Daten anbietet
oder abruft. Für die Gewährleistung der Anonymität sind ebenfalls komplexe Datenstrukturen erforderlich. Beispiele für solche Peer-to-Peer-Netzwerke sind Freenet, I2P, GNUnet und
Entropy.
13.3. PEER-TO-PEER-NETZWERKE DER ERSTEN GENERATION
89
Abbildung 13.1: Netzwerkstruktur von Napster
13.3
Peer-to-Peer-Netzwerke der ersten Generation
13.3.1
Napster
Napster ist ein geschichtlich wichtiges Netzwerk [Röt03].
Geschichte
Shawn (Napster) Fanning veröffentlichte im Juni 1999 eine Beta-Version seines Peer-to-PeerNetzwerks Napster. Die Aufgabe dieser Software war ein Tauschbörsen-System, mit dem man
Dateien auf Rechnern, die ebenfalls diese Software einsetzten, lokalisieren und auf den eigenen
Computer herunterladen konnte. Durch das Engagement eines Freundes erweiterte Fanning das
System zu einem Musik-Portal, das zur Verbreitung von Musikdateien diente. Bereits im Herbst
1999 war die Zugangssoftware für Napster Download des Jahres.
Aufgrund der systembedingten Missachtung von Urheberrechten der Autoren, reichte die Musikindustrie im Juni 2000 eine Klage gegen Fanning ein, mit dem Ziel der Stilllegung des Systems.
Durch die gesteigerte Publizität nahm die Anzahl der Teilnehmer zunächst sogar zu. Schließlich
schloß Fanning Ende 2000 einen Kooperationsvertrag mit Bertelsmann Ecommerce, was die Umwandlung des bisher kostenlosen Sytems in eine kommerzielle File-Sharing-Plattform zur Folge
hatte.
Funktionsweise
Napster folgt im Wesentlichen einem Client-Server-Modell (siehe Abbildung 13.1) mit Tendenzen
zu einem Peer-to-Peer-Netzwerk. Ein Server unterhält einen Index mit Meta-Daten über den Dateinamen, das Dateidatum und ähnliche Informationen. Des Weiteren verwaltet der Server eine
Tabelle aller Verbindungen der teilnehmenden Clients. Zusätzlich hat er eine Tabelle mit allen
Dateien, die ein Client anbietet.
Bei einer Anfrage sendet nun ein Client diese an den Server. Dieser durchsucht alle Tabellen,
welche die Namen aller von den Clients veröffentlichten Dateien enthalten, und liefert als Ergebnis
den Client, der die gesuchte Datei anbietet. Der anfragende Client stellt dann eine direkte Verbindung mit dem anbietenden Client her und lädt die Datei herunter. Dieser letzter Schritt ist das
einzige, was der eingangs formulierten Definition eines Peer-to-Peer-Netzwerks entspricht.
Bewertung
Die Vorteile von Napster sind dessen Einfachheit und die Möglichkeit schnell und effizient Dateiverweise zu finden.
90
KAPITEL 13. PEER-TO-PEER-NETZWERKE
Die Nachteile sind vor allem in der Client-Server-Struktur begründet. Die zentrale Struktur ermöglicht feindliche Eingriffe in das System. Dies muss nicht unbedingt eine richterliche Verfügung
im Auftrag eines Musikverlags sein, sondern kann auch durch Zensur von Seiten staatlicher Behördern erfolgen. Zusätzlich ist die zentrale Struktur anfällig für Denial-of-Service Angriffe. Durch
einen gezielten Angriff des Servers wird das gesamte Netzwerk ausgehebelt. Ebenso kann dies aber
auch durch technische Pannen, zum Beispiel Ausfälle der Hardware, eintreten.
Ein weiterer Nachteil ist, dass Napster nicht skaliert, d.h. mit zunehmender Teilnehmerzahl
verschlechtert sich die Performanz des gesamten Netzwerks, da der Server immer mehr Daten
verwalten muss und nur über einen endlichen Speicher verfügt.
Abschließend ist festzuhalten, das Napster keine akzeptable Peer-to-Peer-Netzwerklösung darstellt. Abgesehen vom Download-Aspekt erfüllt es auch keine Definition für Peer-to-Peer-Netzwerke
und ist daher kein Peer-to-Peer-Netzwerk im eigentlichen Sinne.
Skalierbarkeit von Napster
Napsters Client-Server-Struktur entspricht einer Stern-Topologie. Diese hat den Nachteil, dass ein
Server die Anfragen aller Clients bedienen muss. Bei einer steigenden Anzahl an Clients wird
schließlich der Server zum Flaschenhals für die Kommunikation.
Graphentheoretisch entspricht Napster einem Stern-Graph. Der Server steht mit dem Grad n−1
im Mittelpunkt und ist im Hinblick auf den Zusammenhang des Graphens ein Schwachpunkt, da
der Sterngraph nur 1-zusammenhängend ist.
Definition 1 Ein Graph ist k-zusammenhängend, wenn nach Entfernen von k − 1 beliebigen Knoten der Graph noch zusammenhängend ist und wenn nach dem Entfernen von k Knoten der Graph
nicht mehr zusammenhängend ist.
Neben dem hohen Grad des Netzwerkgraphs von Napster ist der Zusammenhang des Graphs
schwach, da bereits der Ausfall eines Knotens (nämlich der des Servers) zu einem Ausfall des
gesamten Netzwerks führt.
13.3.2
Gnutella
Gnutella ist gemäß der Definitionen aus der Einleitung ein richtiges Peer-to-Peer-Netzwerk, entstanden aus der Fortführung von Napster.
Geschichte
Gnutella wurde im März 2000 von der Firma Nullsoft, die bereits seit 1999 eine Tochter von AOL
ist, veröffentlicht. Entwickelt wurde das Netzwerk von Justin Frankel und Tom Pepper. Wie bei
Napster handelt es sich bei Gnutella um ein File-Sharing-System. Anders als Napster arbeitet
Gnutella jedoch völlig ohne zentrale Strukturen und zentrale Kontrolle.
Funktionsweise
Damit der Gnutella-Client sich beim ersten Start auch mit dem Gnutella-Netzwerk verbinden
kann, sind einige Adressen voreingestellt. Diese werden beim Programmstart durchprobiert. Wird
ein aktiver Peer gefunden, übernimmt der Client dessen k -hop-Nachbarschaft, d.h. alle Peers, die
nicht weiter als k Hops vom aktuellen Peer entfernt sind, in die eigene Nachbarschaftsliste. Diese
wird bei einem erneuten Verbindungsversuch mit dem Gnutella-Netzwerk verwendet, um aktive
Peers zu finden.
Innerhalb des Gnutella-Netzwerks hält jeder Peer direkte Verbindungen zu anderen Knoten.
Dabei ist die maximale Anzahl aktiver Nachbarn auf fünf beschränkt. Die Netzwerkstruktur von
Gnutella ist in Abbildung 13.2 schematisch dargestellt.
Die Kommunikation zwischen den Teilnehmern erfolgt mittels Nachrichten[Gnu]. Eine Übersicht aller Nachrichtentypen gibt Tabelle 13.1. Hat ein Peer eine Nachricht vom Typ Ping oder
13.3. PEER-TO-PEER-NETZWERKE DER ERSTEN GENERATION
Abbildung 13.2: Netzwerkstruktur von
Gnutella
91
Abbildung 13.3: Gnutella Schnappschuss im Jahr 2000
Typ
Ping
Pong
Beschreibung
Anfrage an Peer, sich anzukündigen
Antwort auf Ping
Query
Query-Hit
Suchanfrage
Antwort auf Query
Inhalt
IP und Port-Adresse des angefragten Teilnehmers; Anzahl und Größe zur Verfügung
gestellter Dateien
Suchstring
Anzahl passender Dateien und indizierte
Ergebnismenge zur Suchanfrage
Tabelle 13.1: Gnutella: Nachrichtentypen
Query empfangen, leitet er sie an seine aktiven Nachbarn weiter. Der Informationsprozess im
Gnutella-Netzwerk ist somit ein beschränkter Broadcast, da jeder Nachricht auch ein TTL (Timeto-live) Wert mitgeben wird, welcher bei jedem Sprung von einem Peer zum nächsten um eins
verringert wird. Hat der TTL den Wert null erreicht, wird die Nachricht vom Netzwerk entfernt.
Dadurch wird sichergestellt, dass Nachrichten nicht das Netzwerk verstopfen“. Antworten auf
”
Anfragen werden auf dem gleichen Pfad durch das Netz zurückgeschickt, den auch die Anfrage
genommen hat. Es wird also nicht zwingend der kürzeste Weg für eine Nachricht gewählt.
Die Graphenstruktur des Gnutella-Netzwerks entsteht somit durch einen zufälligen Prozess, da
diese allein durch die Menge der zufällig aktiven Peers und deren aktiven Nachbarn bestimmt wird.
Abbildung zeigt 13.3 einen Schnappschuss des Gnutella-Netzwerks aus dem Jahr 2000[MFK01].
Bei einer Dateianfrage sendet der Anfragende Client eine Query-Nachricht an alle seine Nachbarn. Diese leiten die Nachricht wiederum an alle ihre Nachbarn weiter, bis schließlich der TTLWert bei null angekommen ist. Alle Peers, die die Dateianfrage erhalten haben durchsuchen ihren
Datenbestand und senden bei einem positiven Fund eine Query-Hit-Nachricht an den Anfragenden Client zurück. Diese Nachricht wird wiederum auf den gleichen Pfad wie die Anfrage durch
das Netzwerk geleitet. Der Benutzer kann nun aus den Suchergebnissen eine passende Datei auswählen. Der Peer nimmt dann direkten Kontakt mit dem anbietenden Knoten auf, um die Datei
herunterzuladen.
92
KAPITEL 13. PEER-TO-PEER-NETZWERKE
Bewertung
Der Vorteil von Gnutella ist die Sicherheit, begründet durch die verteilte Netzwerkstruktur. Dadurch ist das Netzwerk robust und praktisch unangreifbar, da keine unverzichtbare zentrale Stelle
existiert. Des Weiteren skaliert die Netzwerkstruktur gut. Es können beliebig viele Knoten ohne
Performanzverlust aufgenommen werden.
Dennoch hat Gnutella auch Nachteile. Durch die Begrenzung der Reichweite einer Nachricht
mittels eines TTL-Werts findet für Anfragen eine implizite Partitionierung des Netzwerks statt.
Somit erfolgt die Suche unkoordiniert, damit einer Anfrage nicht das gesamte Netzwerk, sondern
immer nur ein Teilbereich durchsucht wird. Selten vorhandene Dateien können damit nur schwer
gefunden werden. Je niedriger der TTL-Wert ist, desto geringer wird der Anfrageerfolg ausfallen.
Eine simple Erhöhung des TTL-Werts trägt allerdings nicht zur Verbesserung der Situation bei, da
dadurch auch der Datenverkehr durch das Nachrichtenaufkommen weiter verstärkt wird. Da der
Netzwerkdurchmesser eines Gnutella-Netzwerks verglichen mit einer Baumstruktur sehr hoch ist,
entstehen für Nachrichten lange Wege. Diese führen wiederum zu großen Latenzzeiten. Insgesamt
ist die Netzwerkstruktur nicht gut für das Suchen nach Dateien geeignet.
Es existieren mehrere Verbesserungsvorschläge um das Nachrichtenaufkommen im GnutellaNetzwerk zu verringern. So könnten Nachrichten anstatt wie bei einem Broadcast als sogenannter
Random Walk verteilt werden. Bei einem Random Walk wird eine Nachricht nicht an alle Nachbarn, sondern nur einen zufällig ausgewählten Peer weitergereicht. Auf diese Weise kann die Dateianfrage weiter in das Netzwerk hineingereicht werden, ohne das Nachrichtenaufkommen dabei
stark zu erhöhen.
Eine weitere Möglichkeit ist die passive Replikation von Informationen entlang des Pfads.
Hierbei werden Ergebnislisten gespeichert und neue Anfragen nach den selben Dokumenten können
dann sehr schnell beantwortet werden, ohne dass die Dateianfrage weit in das Netzwerk gereicht
werden muss. Letztendlich hat sich jedoch keine der Verbesserungen durchgesetzt.
Skalierbarkeit von Gnutella
Die Graphstruktur des Gnutella-Netzwerks ist ein zufälliger Verbindungsgraph (siehe Abbildung
13.4). Der Grad des Graphen ist klein und der Durchmesser gering. Dies läßt sich anhand statistischer Untersuchungen nachweisen. Trotzdem ist die Suche nach Dateien im Netzwerk aufwändig.
Um eine Datei sicher in einem Netzwerk zu finden, muss das gesamte Netzwerk durchsucht werden.
Dies ist allerdings bei Gnutella auf Grund des TTL-Felds in den Nachrichten nicht möglich. Somit
wird immer nur ein Teilnetzwerk durchsucht, weiter entfernte Informationen werden dagegen nicht
berücksichtigt.
13.3.3
Gnutella 2, Kazaa, Morpheus
Um die Schwächen von Gnutella auszumerzen, wurde die Struktur zu einem sogenannten hybriden
Netzwerk umgewandelt und als Peer-to-Peer-Netzwerk Gnutella 2 veröffentlicht. Eine ähnliche
Struktur liegt auch den Peer-to-Peer-Netzwerken Kazaa und Morpheus zu Grunde.
Funktionsweise
Knoten mit großer Bandbreite werden zu sogennanten Super-Nodes ernannt. Diese unterhalten
ein Peer-to-Peer-Netzwerk im Stil von Gnutella. Normale Knoten werden als Client-Node an die
Super-Nodes gebunden. Dabei kann ein Client-Node mit mehreren Super-Nodes verbunden sein,
siehe Abbildung 13.5. Die Super-Nodes verwalten die Listen mit den an ihnen angebundenen
Client-Nodes. Dateianfragen von einem Client-Node werden dann nur durch das Netzwerk der
Super-Nodes gereicht [Zie05].
Diese Verfahrensweise entspricht nicht mehr dem Prinzip eines Peer-to-Peer-Netzwerks, da in
einem hybriden Netzwerk nicht mehr alle Knoten gleichrangig sind.
13.4. DATENSTRUKTUREN FÜR EIN PEER-TO-PEER-NETZWERK
Abbildung 13.4: Zufälliger Verbindungsgraph
93
Abbildung 13.5: Eine hybride Netzwerkstruktur
Bewertung
Die Vorteile der hybriden Netzwerkstruktur sind die verbesserte Skalierbarkeit und die Verringerung der Latenzzeiten. Durch die Einführung der Super-Nodes kann wesentlich besser nach Dateien
gesucht werden, da es einen bekannten Kreis an Peers gibt, die Indexlisten verwalten. Jedoch geht
dies einher mit der Abkehr eigentlichem Prinzip eines Peer-to-Peer-Netzwerks, in dem alle Teilnehmer gleichberechtigt sind.
Ein Nachteil des Netzwerks ist, dass es unzuverlässig ist. Es ist nicht sichergestellt, ob das
TTL-Feld einer Nachricht ausreicht, das gesamte Netzwerk der Super-Nodes zu durchsuchen. Da
hier letztendlich wieder die Gnutella-Netzwerkstruktur verwendet wird, kann auch dieses Teilnetz
groß und nicht mehr mit einer Nachricht durchdringbar sein. Des Weiteren verringert sich die
Nachrichtenlast nur bei den Client-Nodes, nicht aber bei den Super-Nodes. Ein weiterer Nachteil
ist, das sich Peers der Funktion als Super-Node verweigern können.
Skalierbarkeit von hybriden Netzwerken
Auch bei der hybriden Netzwerkstruktur hat der unterliegenden Graph einen geringen Durchmesser
(da die Verbindung der Super-Nodes untereinander einem Gnutella-Netzwerk entspricht). Auch der
Zusammenhang ist groß, aufgrund der Anzahl an Super-Nodes an die sich an Client gleichzeitig
binden kann.
Hybride Netzwerkstrukturen verbessern die Anfragebearbeitung. Trotzdem muss eine Anfrage
immer noch von allen Super-Nodes bearbeitet werden. Durch die hybride Struktur skalieren solche
Netzwerke nicht so schlecht wie Gnutella oder Napster, müssen unter Umständen aber immer noch
viele Millionen Anfragen pro Node verarbeiten.
13.4
Datenstrukturen für ein Peer-to-Peer-Netzwerk
Die Skalierbarkeit eines Netzwerks hängt von der schnellen Beantwortung zweier Fragen ab:
• Wo ist die Information gespeichert?
Napster kann durch seinen zentralen Server die gewünschten Informationen sehr schnell
finden. Im Gnutella-Netzwerk muss dagegen eine langwierige Suche auf allen Knoten durch-
94
KAPITEL 13. PEER-TO-PEER-NETZWERKE
Abbildung 13.6: Eine Hash-Table ist nur bedingt als Peer-to-Peer-Netzwerk einsetzbar
geführt werden. Dabei ist durch das Protokoll nicht sichergestellt, dass alle Knoten nach der
Information durchsucht werden.
• Wie kann man auf die Information zugreifen?
Durch die zentrale Struktur von Napster und einer hohen Teilnehmerzahl kann der Zugang
zum Server blockiert werden, wenn viele Anfragen in kurzen Intervallen erzeugt werden. Das
Gnutella-Netzwerk kann ebenfalls blockiert werden, wenn sehr viele Nachrichten erzeugt
und von den einzelnen Knoten weitergereicht werden müssen. Das Netzwerk wird dann mit
Nachrichten überflutet.
Für die Verwaltung von Daten in einem Peer-to-Peer-Netzwerk sind also effiziente Datenstrukturen erforderlich.
13.4.1
Hash-Table
Eine Hash-Table ist eine Datenstruktur, in der man anhand eines Schlüssels den passenden Eintrag
in logarithmischer Zeit wiederfinden kann. Für die Erzeugung der Schlüssel wird eine sogenannte
Hash-Funktion verwendet, welche aus den ursprünglichen Datum einen Schlüssel erzeugt. Eine
einfache Hash-Funktion ist zum Beispiel die Modulo-Funktion a mod p, welche als Ergebnis immer den Rest der Zahl a nach der Division durch p hat. Dabei kann es natürlich zu Kollisionen
kommen und für zwei unterschiedlichen Daten der gleiche Schlüssel berechnet werden. Es gibt
verschiedene Möglichkeiten, um in einer Hash-Table Kollisionen zu behandeln. Eine Möglichkeit
ist die Verwaltung von Daten mit gleichen Schlüsseln in einer verketten Liste.
Die Übertragung einer Hash-Table in ein Peer-to-Peer-Netzwerk ist in Abbildung 13.6 dargestellt. Jeder Peer ist ein Speicherplatz in der Hash-Table. Alle Peers sind in einer verketteten Liste
angeordnet. Um nach einem Datum x zu suchen, kann man nun den Schlüssel mit der bekannten
Hash-Funktion f (x) berechnen. Anhand des Ergebnisses weiß man nun, welcher Peer die Information gespeichert hat. Dadurch entsteht intelligentes Routing. Wenn der aktuelle Peer weit vom
Zielknoten entfernt ist, weiß er, welcher seiner Nachbarn näher am Ziel ist. Und irgendein Nachbar
des Nachbars wird dann den Zielknoten kennen (ähnlich dem Small-World-Phänomen [Sta67]).
Problematisch an diesem Ansatz sind jedoch die langen Wege, die durch eine große Anzahl
an teilnehmenden Peers entstehen können. Ein weiteres Problem ist, dass bei Eintritt eines neuen
Peers eine neue Hash-Funktion erforderlich ist, da nun mehr Speicherplätze zur Verfügung stehen.
Dies kann dazu verführen, dass alle gespeicherten Einträge neu zugeordnet werden müssen. Der
gleiche Fall tritt ein, wenn ein Teilnehmer das Netzwerk verlässt.
13.4.2
Distributed-Hash-Table
Die Problematik bezüglich des Einfügens und Entfernen von Peers in einer Hash-Table kann durch
Verwendung einer Distributed-Hash-Table gelöst werden. Ein Peer erhält ein Teil des Wertebereichs, auf den die Hash-Funktion abbildet. Die Daten werden wiederum gehasht und den Peers
zugeordnet, die den Wertebereich des jeweiligen Datum Schlüssels verwalten, siehe Abbildung 13.7.
13.5. CONTENT ADDRESSABLE NETWORK (CAN)
95
Abbildung 13.7: Zuordnung von Peers und Daten bei einer Distributed-Hash-Table
Wenn ein neuer Knoten im Netzwerk aufgenommen wird, erfolgt eine Aufteilung des Wertebereichs zweier benachbaarter Peers. In Abbildung 13.8 erhält einen neuer Peer (dargestellt als
schwarzer Kreis) einen Teilbereich der benachbarten Peers. Durch die Neuordnung des Wertebereichs müssen noch einige Datenelemente reorganisiert werden. Da die Umstrukturierung des
Wertebereichs aber nur einen kleinen Teil des gesamten Wertebereichs der Hash-Funktion betrifft,
muss auch nur ein kleiner Teil der gesamten Datenmenge neu organisiert werden. Dies ist der Vorteil gegenüber einer Hash-Table, da nun nur noch die direkten Nachbarn von solchen Operationen
betroffen sind, der Rest bleibt unberührt.
Wenn ein Peer das Netzwerk verlässt (siehe Abbildung 13.9), übergibt er seinen Wertebereich
an seine direkten Nachbarn. Wieder müssen nur wenige Datenelemente umorganisiert werden.
13.4.3
Fazit
Während sich Hash-Tables nicht optimal als Peer-to-Peer-Netzwerk einsetzen lassen, ist dieses
mit einer Distributed-Hash-Table einfach möglich. Jedes Datum kann einem bestimmten Peer
zugewiesen werden, und das Einfügen und Entfernen von Knoten erzeugt nur Veränderungen der
benachbarten Peers. In der Tat werden von vielen Peer-to-Peer-Netzwerken Distributed-HashTables verwendet. Allerdings fehlt noch eine Datenstruktur, die die einzelnen Knoten in einem
Netzwerk organisiert, so dass eine Kommunikation untereinander möglich ist.
13.5
Content Addressable Network (CAN)
Das Peer-to-Peer-Netzwerk CAN, vorgestellt in [RFH+ 01], baut auf dem Konzept von Hash-Tables
auf. Zusätzlich verwendet es Random Trees und ein Gitter als Datenstruktur.
Abbildung 13.8: Ein neuer Peer
(schwarzer Kreis) wird in das Netzwerk
aufgenommen
Abbildung 13.9: Ein Peer (grüner
Kreis) verlässt das Netzwerk; rot und
blau übernehmen jeweils einen Teil des
Wertebereichs
96
KAPITEL 13. PEER-TO-PEER-NETZWERKE
Abbildung 13.10: Peers werden in das CAN-Netzwerk aufgenommen
13.5.1
Aufbau
CAN verwendet eine Hash-Funktion, deren Bildbereich der zwei-dimensionale Raum [0, 1]2 ist.
Ist am Anfang nur ein Peer im Netzwerk vorhanden, erhält er die Verwaltung des kompletten
Bildbereichs. Kommt ein neuer Peer hinzu, muss er die Verwaltung eines Teilraums übernehmen.
Dazu wird der Bildbereich quer zur x-Achse in zwei Teile geteilt. Kommt ein weiterer Peer hinzu,
wählt dieser zunächst einen zufälligen Punkt (x, y) ∈ [0, 1]2 aus. Der für diesen Punkt zuständige
Peer wird kontaktiert und dessen Zone geteilt. Die Teilung erfolgt entweder entlang der x- oder
der y-Achse, je nachdem wie zuletzt die Zone geteilt wurde (erst y, dann x, dann wieder y, etc.).
Dieser Vorgang ist in Abbildung 13.10 grafisch veranschaulicht. Zwischen den Peers benachbarter
Rechtecke wird dann eine Netzwerkverbindung hergestellt.
Die erwartete Fläche eines Peers in CAN
Im Folgenden sei R(p) das Rechteck eines Peers p im CAN-Netzwerk. A(p) bezeichne die Fläche,
die das Rechteck des Peers p einnimmt. Zu Anfang hat das Quadrat, in den die Hash-Funktion
abbildet die Größe 1. Nach dem Einfügen von n Peers kann folgendes nachgewiesen werden:
Lemma 1 Die erwartete Fläche, die ein Peer p verwalten muss, beträgt
E[A(p)] =
1
n:
1
n.
Beweis: Seien 1, . . . , n die Peers. Für die Summer aller Teilflächen gilt:
n
P
A(i) = 1.
i=1
Da alle Peers in einer unbestimmten Reihenfolge eintreffen, gilt wegen Symmetrie für zwei
beliebige Peers i, j:
E[A(i)] = E[A(j)].
Daraus folgt
1=
n
P
i=1
A(i) = E
n
P
i=1
n
P
E [A(i)] = n · E [A(1)].
A(i) =
i=1
Dies gilt, da der Erwartungswert der Summe von Zufallsvariablen gleich der Summe der Erwartungswerte der einzelnen Zufallsvariablen ist, also
E[A(a) + A(b) + A(c) . . . A(n)] = E[A(a)] + E[A(b) + E[A(c)] + · · · + E[A(n)].
Da alle Erwartungswerte in diesem Fall gleich (= A(1)) sind, kann das auch als Produkt
ausgedrückt werden: n · E[A(1)].
2
Der Erwartungswert für die zu verwaltene Fläche ist jedoch nicht sonderlich aussagekräftig.
Lemma 2 Für Wahrscheinlichkeit PR,n , dass ein Rechteck R von keinem der n Peers geteilt wird,
gilt: PR,n ≤ e−nV (R) .
13.5. CONTENT ADDRESSABLE NETWORK (CAN)
97
Beweis: Betrachte ein Rechteck R der Fläche x = V (R). Die Wahrscheinlichkeit, dass ein Peer
nicht in diese Fläche fällt, ist
1 − x.
Die Wahrscheinlichkeit, dass n Peers nicht in R fallen, ist
(1 − x)n
da die Wahl des Punktes zufällig gleichverteilt erfolgt.
Nun gilt für alle m > 0:
1−
Damit folgt für diese Wahrscheinlichkeit
1 m
m
≤ 1e .
1
(1 − x)n = ((1 − x) x )nx ≤ e−nx
und damit das Lemma.
2
Wenn also einem Peer ein großes Rechteck zur Verwaltung erhält, ist die Wahrscheinlichkeit
expontentiell klein, dass dieses Rechteck nicht geteilt wird. Aber wie groß kann ein Rechteck sein,
das nicht geteilt wird?
Lemma 3 Mit Wahrscheinlichkeit (log n)n−c wird ein Rechteck der Größe
Wahrscheinlichkeit nicht geteilt.
2c(ln n)
n
mit hoher
Beweis: Aus PR,n ≤ e−nV (R) folgt für ein Rechteck Ri und der Fläche 2−i
PRi ,c2i ln n ≤ e−c2
i
ln nV (Ri )
= n−c .
Es genügen also c · 2i · ln n Peers um Ri mit Wahrscheinlichkeit 1 − n−c zu teilen. Diese kommen
nun hintereinander und können nach log 2c nln n Einfügeoperationen von Peers mit dieser Wahrscheinlichkeit auch ein Rechteck der Größe 2c lnnn teilen, da
log
n
2c ln n
P
log
c · 2i ln n = c · (ln n) ·
i=1
n
2c ln n
P
n
2i ≤ c · (ln n) · 2log c ln n = n.
i=1
2
Wenn m Elemente insgesamt gespeichert werden, erhält jeder Peer also maximal 2c(lnnn)m Elemente, während ein durchschnittlicher Peer m
n Elemente speichert. Also speichert jeder Peer mit
hoher Wahrscheinlichkeit höchstens 2c(ln n) mal mehr als ein durchschnittlicher Peer. Damit ist
die Aufteilung im CAN-Netzwerk im Durchschnitt einigermaßen gerecht.
13.5.2
Funktionsweise
Lookup
Für eine Suchanfrage wird zunächst der Ort durch Berechnung der Hash-Funktion bestimmt.
Danach kann mit dem Speicherort (= Ergebnis der Hash-Funktion) Kontakt aufgenommen werden.
Zwischen den Peers benachbarter Rechtecke bestehen Verbindungen (siehe Abbildung 13.11), so
dass die Anfrage in Richtung des ermittelten Orts weitergeleitet werden kann.
Angenommen, d bezeichne die Dimension des Quadrats, das CAN zu Grunde liegt. d = 1
repräsentiert eine Linie, d = 2 ein Quadrat, d = 3 einen Würfel, etc. Die erwartete Anzahl
1
Sprünge, bis die Anfrage ihr Ziel erreicht hat, beträgt dann n d .
98
KAPITEL 13. PEER-TO-PEER-NETZWERKE
Abbildung 13.11: Peers benachbarter
Rechtecke haben eine Verbindung
Abbildung 13.12: Darstellung der Aufteilung des Bildbereichs der CAN HashFunktion als Random Tree
Abbildung 13.13: Peer A hat das Netzwerk verlassen, Peer E bemerkt diesen Umstand und übernimmt das Rechteck von Peer A
Einfügen eines Peers
Wenn man das Einfügen in CAN betrachtet, dann erhält man einen Random Tree (siehe Abbildung
13.12). Zufl̈lig deswegen, weil bei jeder Einfügeoperation zufällig entschieden wird, wo das Blatt
eingefügt wird. Ein Random Tree hat eine erwartete Tiefe von 2 log n + O(1) und überschreitet
mit hoher Wahrscheinlichkeit, d.h. 1 − n−c nicht die Tiefe O(log n).
Das Einfügen von Peers in CAN funktioniert nun genauso wie das Einfügen in einen Random
Tree. Neue Blätter werden zufällig eingefügt. Dies passiert entlang der folgenden Vorgehensweise:
• Falls die aktuell gewählte Position ein interner Knoten ist (also über zwei Blätter verfügt),
gehe zufällig in den linken oder rechten Teilbaum.
• Falls die aktuelle gewählte Position ein Blatt ist, füge zwei Blatt an dieser Wurzel hinzu. Ein
Blatt wird von dem neuen Peer verwaltet, das andere von dem Peer, der bisher den oberen
Knoten verwaltet hat.
Entfernen eines Peers
Wenn ein Peer aus dem CAN-Netzwerk verschwindet, kündigt er das nicht vorher an. Daher testen
alle Peers regelmäßig, ob ihre Nachbarn noch im Netzwerk anwesend sind. Falls ein Peer feststellt,
dass einer seiner Nachbarn nicht mehr anwesend ist, übernimmt er die Verwaltung seines Rechtecks
13.5. CONTENT ADDRESSABLE NETWORK (CAN)
Abbildung 13.14: Fall 1: Peer D startet die Defragmentierung, Peer C übernimmt beide Zonen und vereint sie zu
einer
99
Abbildung 13.15: Fall 2: Peer E startet die Defragmentierung, Peer D übernimmt dessen kleinste Zone, Peer C
übernimt die Zone von Peer D
(siehe Abbildung 13.13). Es ist also für einen Peer möglich, mehr als nur ein Rechteck zu verwalten.
Allerdings führt häufiges Einfügen und Entfernen zur Fragmentierung. Mit der Zeit verwaltet ein
Peer anstatt eines größeren viele kleine Bildbereiche. Dieses Problem muss dezentral gelöst werden.
Defragmentierung
Um die Fragmentierung des Bildbereichs durch häufiges Einfügen und Entfernen von Peers zu
vermeiden, kann jeder Peer, der mehr als ein Rechteck verwaltet, eine Defragmentierung anstossen,
um Gebiete abzugeben. Die Defragmentierung geschieht wie folgt:
Der Peer löscht dessen kleinste Zone und sucht nach einem Peer, der dieses Gebiet
übernehmen kann. Dabei können zwei Fälle eintreten:
1. Fall: Nachbarzone im Baum ist ungeteilt. In diesem Fall sind beide Peers Blätter im CAN-Baum. Der Peer überträgt die Zone seinem Nachbarn (siehe Abbildung 13.14).
2. Fall Nachbarzone im Baum ist geteilt. In diesem Fall ist der andere Teilbaum
unterhalb der Wurzel weiter untereilt. Der Peer führt eine Tiefensuche im Nachbarbaum durch, bis zwei benachbarte Blätter (= Peers) gefunden wurden. Einem
der beiden Peers wird nun die Zone beider Blätter übertragen. Dem zweiten Peer
wird dann die ursprüngliche Zone übertragen (siehe Abbildung 13.15).
13.5.3
Bewertung
Die Vorteile von CAN sind seine Einfachheit und Robustheit aufgrund des stark zusammenhängenden Netzwerks. Der Zusammenhang kann durch die Anzahl der Dimensionen erhöht werden.
Die Datenmenge wird auf allen Peers balanciert. Der geringe Grad von O(d) stellt sicher, das ein
Peer nicht zuviele Informationen verwalten muss. Des Weiteren können im CAN-Netzwerk Nachrichten über verschiedene Wege zum Ziel gesendet werden. Hier existieren Ansatzmöglichkeiten
zur Optimierung von Routen.
Die Nachteile von CAN sind jedoch die zu erwartenden langen Wege, da der Durchmesser
bei konstanten Dimensionen des Raums polynomiell groß ist. Des Weiteren ist die Stabilität des
100
KAPITEL 13. PEER-TO-PEER-NETZWERKE
Netzwerks bei geringen Nachbarzahlen gefährdet. Hat ein Peer nur sehr wenige Nachbarn, kann
der Fall eintreten, dass beide aus dem Netzwerk verschwinden. Dann ist keine Anbindung mehr
an das restliche Netzwerk vorhanden.
13.6
Chord
Chord ist ein sehr effizientes Peer-to-Peer-Netzwerk welches mit einer komplexen Zeigerstruktur
und konsistentem Hashing arbeitet [SMK+ 01]. Die grundlegende Idee ist die Aufteilung des Bildbereichs einer Hash-Funktion auf verschiedene Peers über eine Ringstruktur.
13.6.1
Aufbau
Im Folgenden bezeichnet V die Knotenmenge (d.h. n = |V |) und K die Schlüsselmenge (d.h
k = |K|). Alle Peers sind im Chord-Netzwerk in einer Ringstruktur miteinander verbunden. Dieser
Ring umfasst den vollständigen Bildbereich, den die Hash-Funktion von Chord verwendet. Jeder
Peer auf den Ring verwaltet den Bildbereich von sich bis zum nächsten Peer. Zusätzlich verwaltet
jeder Peer Zeiger auf weitere Peers im Netzwerk, welche als Abkürzung beim Routing verwendet
werden.
Der Bildbereich der Distributed-Hash-Table umfasst die Zahlen Z2m = {0, 1, 2, . . . , 2m − 1}.
Dafür muss m ausreichend groß gewählt werden, so dass Kollisionen nur mit einer vernachlässigbaren Wahrscheinlichkeit auftreten. m ≥ max{2 log n, 2 log k} ist ausreichend. Die Datenstruktur
ist in Abbildung 13.16 dargestellt.
Chord arbeitet mit zwei Hash-Funktionen rV und rK :
• rV (b) bildet den Peer b auf das Intervall {0, . . . , 2m − 1} ab,
• rK (i) bildet den Index i auf das gleiche Intervall {0, . . . , 2m − 1} ab.
Die Zuordnung eines Schlüssels i auf einen Peer b erfolgt dann mit der Funktion
fV (i) = arg min(rV (b) − rK (i)) mod 2m .
b∈V
Jeder Knoten im Chord-Netzwerk verfügt nun über mehrere Zeiger. Zum einem hat er - weil alle
Peers in einem Ring angeordnet sind - jeweils einen Zeiger auf seinen Vorgänger und Nachfolger.
Des Weiteren hat jeder Peer m sogenannte Fingerzeiger, die auf andere Peers im Netzwerk zeigen
(siehe Abbildung 13.17). Diese werden mit der Funktion
f inger[i] := Der Knoten, der dem Wert rV (b + 2i ) folgt, mit i ∈ {0, . . . , m − 1}
bestimmt. Jeder dieser Finger ist im Prinzip ein Nachfolgezeiger, mit der die Hälfte, ein Viertel oder
ein Achtel, etc. des Rings übersprungen werden kann. Um den Speicherbedarf für die Fingerzeige
zu minimieren, werden nur unterschiedliche Zeiger gespeichert, da für kleine i die Ergebnisse der
Funktion immer gleich sind.
Lemma 4 Die Anzahl der unterschiedlichen Fingerzeiger für einen Knoten beträgt mit hoher
Wahrscheinlichkeit O(log n).
Theorem 2 Die Datenstruktur von Chord hat folgende Eigenschaften:
k
• Mit polynomieller Wahrscheinlichkeit 1 − n−c werden in jedem Knoten höchsten O( n log
n)
Schlüssel gespeichert.
• Wenn ein Knoten das Netzwerk verlässt oder ein neuer Knoten eingefügt wird, müssen mit
k
polynomieller Wahrscheinlichkeit höchstens O( n log
n ) Schlüssel bewegt werden.
Lemma 5 Der Abstand zwischen einem Knoten und dessen Nachfolger beträgt
13.6. CHORD
101
Abbildung 13.16: Konsistentes Hashing
in der Chord-Datenstruktur
• im Erwartungswert
Abbildung 13.17: Jeder Knoten verwaltet Fingerzeiger
2m
n ,
m
• mit hoher Wahrscheinlichkeit höchstens O(( 2n ) log n),
• mit hoher Wahrscheinlichkeit mindestens O
m
2m n
nc
=O
2m
nc
für eine Konstante c > 0.
In einem Intervall der Länge w 2n sind mit hoher Wahrscheinlichkeit
• höchstens O(w) Knoten, falls w = Ω(log n),
• höchstens O(w log n) Knoten, falls w = O(log n).
Lemma 6 Die Anzahl der Knoten, die einen Fingerzeiger auf den Knoten b besitzen, beträgt
• im Erwartungswert O(log n),
• mit polynomieller Wahrscheinlichkeit höchstens O(log n).
Lemma 7 Der Ausgrad im Chord-Netzwerk beträgt mit hoher Wahrscheinlichkeit O(log n). Der
Eingrad im Chord-Netzwerk beträgt mit hoher Wahrscheinlichkeit O(log2 n).
m
Beweis: Der minimale Abstand zweier Peers beträgt mit hoher Wahrscheinlichkeit 2nc . Damit
ist der Ausgrad mit hoher Wahrscheinlichkeit beschränkt durch c log n.
m
Der maximale Abstand zweier Peers beträgt O(log n 2n ). Jeder Peer, der mit einem seiner
Finger auf diese Linie zeigt, erhöht den Eingrad des nachstehenden Peers. Die Gesamtlänge der
m
2
Streckenabschnitte, wo solche Peers liegen, ist O(log2 n 2n ). Damit ist w = O(log2 n).
Peers, die einen großen Eingrad haben, haben auch einen sehr großen Abstand zum Vorgänger.
Des Weiteren gibt es Peers, die einen Eingrad von log 2 n haben, wobei der Ausgrad log n beträgt.
102
KAPITEL 13. PEER-TO-PEER-NETZWERKE
Abbildung 13.18: Verwendung der Fingerzeiger für effiziente Suche: p24 sucht nach dem Peer, der
Schlüssel k(83) verwaltet
13.6.2
Funktionsweise
Lookup
Um ein Datum im Chord-Netzwerk zu finden, wird zunächst anhand der Hash-Funktion der Schlüssel berechnet. Nun muß der Knoten gefunden werden, der den Schlüssel verwaltet. Als Ausgangspunkt einer Suchoperation dient der eigene Knoten im Netzwerk. Um die Suche möglichst effizient
zu gestalten, wird auf die Fingerzeiger zurückgegriffen, über die jeder Knoten verfügt. Der Suchalgorithmus von Chord lässt sich in Pseudocode wie folgt ausdrücken:
Chord-Suche(b,i)
begin
x ← rK (i)
while x ∈
/ [rV (b), rV (b.succ)] do
for i ← m − 1 downto 0 do
if x ∈ [rV (b.f inger[i]), rV (b.f inger[i + 1]))] then
b ← b.f inger[i]
fi
od
return(b)
end.
Zuerst wird versucht, den Sprung zu bestimmen, der dem Ziel am nähesten kommt, aber
noch vor ihm endet. Von dort ausgehen wird wieder versucht den Sprung zu bestimmen, der am
nächsten zum Zielknoten führt, ohne über ihn hinauszuspringen. Dies wird bis zum Erreichen des
Zielknotens fortgesetzt. Dabei wird bei jedem Sprung der Abstand zum Ziel halbiert.
Die Suche beginnt immer mit dem größten Fingerzeiger, also m−1. Wenn der gesuchte Schlüssel
nicht im verwalteten Intervall des Finger-Knotens und dessen Nachfolger liegt, wird rückwärts
durch die Liste mit Fingerzeiger gegangen. Wenn der gesuchte Schlüssel dann in dem Intervall
liegt, wird die Suche von dem Finger-Knoten am Anfang des Intervalls nach gleichem Schema
erneut gestartet.
Theorem 3 Die Suche benötigt mit hoher Wahrscheinlichkeit O(log n) Sprünge.
Beweis: Mit jedem Sprung wird die Entfernung zum Ziel mindestens halbiert. Zu Beginn ist der
Abstand höchstens 2m . Der Mindestabstand zwei benachbarter Peers ist mit hoher Wahrscheinm
2
lichkeit 2n . Damit ist die Laufzeit beschränkt durch c log n.
13.6. CHORD
103
Einfügen von Peers
Um einen Peer in das Netzwerk einzufügen, wird zunächst ein Zielgebiet gesucht. Die ausgehenden
Zeiger werden dann vom Vorgänger und Nachfolger übernommen und angepasst. Insgesamt müssen
die Zeiger um bis zu O(log n) Schritte entlang des Chord-Rings angepasst werden.
Theorem 4 Es sind mit hoher Wahrscheinlichkeit O(log2 n) Nachrichten ausreichend, um einen
Peer in das Chord-Netzwerk aufzunehmen.
Beweis: Um ein Zielgebiet für einen neuen Peer zu finden, sind O(log n) Nachrichten erforderlich.
Für das eigentliche Einfügen in den doppelt verketteten Chord-Ring, müssen nun konstant viele
Zeiger angepasst werden.
Für die Anpassung der i Fingerzeiger sind jeweils O(log n) Nachrichten erforderlich. Das begründet sich darin, dass in jedem Level nur O(log n) Knoten betroffen sind. Diese sind im Ring zusammenhängend. Um den ersten zu finden, sind wieder O(log n) Nachrichten erforderlich. Danach
können die Ringnachfolgerzeiger verwendet werden um in O(log n) Schritten jeden weiteren Knoten zu besuchen. Der Aufwand, für die eigentliche Anpassung eines Zeigers ist konstant. Hieraus
folgt, das O(log2 n) Nachrichten erforderlich sind, um einen Peer in das Netzwerk einzufügen. 2
13.6.3
Bewertung
Die Vorteile von Chord begründen sich in der Verwendung einer Distributed-Hash-Table zur Verwaltung der im Netzwerk gespeicherten Daten. Dadurch ist anhand des Schlüssels aus der HashFunktion bereits eine Ortsangabe ableitbar. Dies – und die Anordnung alle Peers in einer festen
Netzwerkstruktur – führt zu einer besseren Organisierung des gesamten Netzwerks als beispielsweise Gnutella.
Die Ring-Struktur erweist sich jedoch als Nachteil bei der Suche, wenn Peers dicht beieinander
liegen.
104
KAPITEL 13. PEER-TO-PEER-NETZWERKE
Literaturverzeichnis
[Gnu]
Gnutella Development Forum. The annotated gnutella protocol specification v0.4.
[MFK01]
M. A. Jovanovic, F. S. Annexstein, and K. A. Berman. Scalability Issues in large
Peer-to-Peer-Networks – a Case Study of Gnutella. Technical report, University of
Cincinnati, 2001.
[RFH+ 01] S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker. A scalable contentaddressable network. In Computer Communication Review, volume 31, pages 161–172.
Dept. of Elec. Eng. and Comp. Sci., University of California, Berkeley, 2001.
[Röt03]
Janko Röttgers. Mix, Burn & R.I.P. - Das Ende der Musikindustrie. Heise Verlag,
2003.
[SMK+ 01] Ion Stoica, Robert Morris, David Karger, Frans Kaashoek, and Hari Balakrishnan.
Chord: A scalable Peer-To-Peer lookup service for internet applications. In Roch Guerin, editor, Proceedings of the ACM SIGCOMM 2001 Conference (SIGCOMM-01),
volume 31, 4 of Computer Communication Review, pages 149–160, New York, August
27–31 2001. ACM Press.
[Sta67]
Stanley Milgram. The Small World Problem. Psychology Today, 5:60–67, 1967.
[Zie05]
Dr. Cai Ziegler. Smarte Schwärme – Die Technik hinter modernen Peer-to-Peer-Netzen.
c’t - Magazin für Computertechnik, 16:160–164, 2005.
105