1x1 - Fachgebiet Komplexe und Verteilte IT-Systeme - TU Berlin

Vorlesung 

P2P Netzwerke 

1: Einführung 

Dr. Dominic Battré 

Complex and Distributed IT‐Systems 

dominic.battre@tu‐berlin.de 

berlin de

Inhalt 

● Vorstellung 

● Organisatorisches 

● Einführung in P2P Netzwerke 

15.04.2009 Dominic Battré ‐ P2P Netzwerke 

2

Vorstellung 

● /me stellt sich vor 

● Email: dominic.battre@tu‐berlin.de 

● Sprechstunde: 

Donnerstags, 14:00‐15:00 

15:00 

Raum E‐N 173 (Einsteinufer 17) 

● DU 

15.04.2009 Dominic Battré - P2P Netzwerke 3

Organisation 

● Webseite 

■ http://www.cit.tu‐berlin.de P2P 

■ Folien am Tag der Vorlesung morgens online 

● Vorlesung 

■ Donnerstags, 10:00 – 12:00, c.t., FR 0513 (*) 

● Übung 

* nur erste Woche, siehe Ankündigung auf Webseite 

■ Freitags, 14:00 – 16:00, c.t., FR 1063 

■ Voraussichtlich: 24.4., 4 85 8.5., 22.5., 56 5.6., 19.6., 

3.7. oder 10.7., 17.7. 


Mailingliste 

● Mail an cit‐p2p.ss09‐request@lists.tu‐berlin.de 

■ Subject: egal 

■ Inhalt: subscribe 

● Zweck 

■ Raumänderungen 

■ Terminänderungen 

■ Bekanntgabe, wenn Übungszettel/Folien verfügbar sind 


Prüfung 

● Die Veranstaltung hat 3 SWS (4 LP) für Studiengänge 

Informatik D + MSc, sowie Technische Informatik D + MSc 

● Schriftliche Prüfung durch Klausur (ca. 60min) 

■ nur bei ausreichender Teilnehmerzahl 

■ Termine? z.B. 23. Juli 2009 

■ Anmeldung über Sekretariat (Details im späteren Verlauf) 

● Diplom: Einbringung in Schwerpunktprüfung (Gebiet BKS) 

● Master: Modulprüfung (CIT 8) 

Info‐Veranstaltung BKS: 17.4.09, 16:00 Uhr, EN‐180 


Übungen 

● Präsenzübungen 

■ beginnen am 24. April 

■ Besprechung von Übungsblättern, Aufgaben, … 

● Übungsblätter 

■ wöchentlich 

■ freiwillig aber prüfungsrelevant 

■ werden korrigiert 

■ beliebige Gruppengröße 

■ programmieren und theoretisch 

■ wir schreiben einen P2P Chat 


Inhalte der Vorlesung (vorläufig) 

Einleitung 

• Was ist P2P? 

• Definition 

• Einsatzgebiete 

Unstrukturierte Netze 

• Napster 

• Gnutella 

• Super‐Peer Netzwerke 

• Small‐World Netzwerke etc. 

Fortgeschrittenes 

• Sicherheit 

Strukturierte Netze 

• Verteilte Hash‐Tabellen 

• Grundlagen 

• Chord, CAN, Pastry, Kademlia 

• Programmieren von DHTs 

• Gradoptimierte Netzwerke 

• SkipNet, P‐Grid 

• Lastverteilung in strukturierten Netzen 

Anwendungen 

• OceanStore 

• BabelPeers 

• Amazon 

• Multicast 

15.04.2009 Dominic Battré ‐ P2P Netzwerke 8

Ziele der Vorlesung 

● Verstehen, 

■ … was ein P2P Netzwerk ist 

■ … wie es sich von anderen Netzen unterscheidet 

■ … wann P2P Netzwerke sinnvoll sind 

■ … wie sie funktionieren 

■ … welche Topologien es gibt 

■ … welche Routing‐Algorithmen es gibt 

■ … wie Selbstorganisation funktioniert 

■ … wie Daten gespeichert werden 

■ … und wie diese Daten gefunden werden 

■ … welche Anwendungen ngen für P2P Netze e es gibt 

■ … wie P2P Netzwerke programmiert werden 

■ … wie P2P Netzwerke abgesichert werden 


Literatur 

● Bücher zu P2P: 

■ Peter Mahlmann, Christian Schindelhauer: 

P2P Netzwerke, Springer, 2007, 33 € 

■ Ralf Steinmetz, Klaus Wehrle: Peer‐to‐Peer Systems and 

Applications, Springer, 2005, 59 € 

■ Andy Oram: Peer‐to‐Peer: Harnessing the Power of Disruptive 

Technologies, O'Reilly, 2001, 25 € 

● Paper zu speziellen Themen 

■ wird jeweils beim Thema bekanntgegeben 


Internet Traffic (.de) nach Protokollen 

HTTP 10,71% 

Streaming 8,26% 

P2P 73,79% DDL 4,57% 

VoIP/Skype 

0,98% 

FTP 0,53% 

Mail 0,39% 

IM 0,34% 

NNTP 

Tunnel / 

Quelle: Ipoque 2007, Mhl Mahlmann 2008 

0,09% 

Encryption 0,34% 


P2P Traffic nach Netzen (.de) 

Quelle: Ipoque 2007, Mahlmann 2008 

Gnutella 3,72% 

eDonkey 28,59% 

BitTorrent 

66,70% 

Sonst. 0,99% 


BitTorrent Traffic nach Content (.de) 

TV 21,15% aBooks 1,41% 

Musik 7,78% 

P0rn 13,05% 

eBook 0,81% 

Spiele 5,77% 

Applikationen 

4,97% 

Filme 37,24% 

Quelle: Ipoque 2007, Mhl Mahlmann 2008 

Bilder 0,09% 

Anime 7,09% 

Musik 0,65% 


P2P Traffic im Internet 

Quelle: http://www.cachelogic.com/home/pages/studies/2005_07.php 

h /h / / t /2005 07 h 


Peer‐2‐Peer: Was ist das? 

● Peer‐2‐Peer (P2P) ist durch Filesharing bekannt geworden 

● Das Konzept ist schon viel älter und hat viel mehr Anwendungen: 

■ Skype 

■ Groove (Kollaborations‐Software) 

■ Coral lCache 

■ Datenmangement 

■ Bot Netze (z.B. Trojan.Peacomm) 

■ Amazon Warenkörbe 

● Was ist ein Peer? (Merriam‐Websters) 

1 : one that t is of equal standing with another : EQUAL; especially : one 

belonging to the same societal group especially based on age, grade, or status 

2 archaic : COMPANION 

3 a : a member of one of the five ranks (as duke, marquess, earl, viscount, or 

baron) of the British peerage b: NOBLE 1 

‐ peer adjective 


Definitionen 

● Wikipedia: 

■ "Kommunikation i unter Gleichen" 

● Gribble (2001): 

■ A distributed system in which participants rely on one another for 

services [...] Peers in the system can elect to provide services as well 

as consume them. 

● Yang/Garcia‐Molina (2002): 

■ Peer‐to‐peer (P2P) systems are distributed systems in which nodes 

of equal roles and capabilities exchange information and services 

directly with each other 

● Steinmetz/Wehrle (2004): 

■ [A Peer‐to‐Peer system is] a self‐organizing system of 

equal, autonomous entities (peers) [which] aims for the shared 

usage of distributed resources in a networked environment avoiding 

central services. 


Das P2P Prinzip 

● Keine 100% scharfe Definition! 

● Ein „Organisationsprinzip“: 

■ Jeder Rechner im Netzwerk erfüllt die gleichen Aufgaben 

■ Es gibt ki keine Unterscheidung zwischen Client und Server 

● Kernkonzepte (nicht immer alle erfüllt!) 

■ Selbstorganisation, kein zentrales Management 

■ Teilen von Ressourcen 

♦ Nutzung von Ressourcen am "Rand" des Netzwerkes 

■ Die Peers sind alle gleich 

■ Typischerweise sehr viele Peers 

■ Knoten kommen und gehen jederzeit jd ■ Peers sind autonom (eigene Entscheidung über Angebote) 

■ Adressierung auf Anwendungsebene 


Vorteile von P2P 

● Höhere Verfügbarkeit/Ausfallsicherheit: 

■ ki kein „singlepoint i of fil failure“ 

● Aktualität/Einfachheit des „Publizierens“: 

■ Zugriff auf unveröffentlichte Daten 

■ trotzdem Anonymität 

● Skalierbarkeit 

● Geteilte Ressourcen (Rechenleistung, Speicherplatz, Bandbreite) 

● Keine Zensur/Manipulation durch zentrale Instanz 

● Nachteile von zentralisierten Systemen: 

■ schlechte Abdeckung (‐‐> Akamai u.A. Content Delivery Networks) 

■ lange Updatezeiten 

■ Kosten für Betrieb des Systems 

■ Zentrale Instanz steuert (und manipuliert) die Inhalte 


Nachteile von P2P 

● Erhöhter Aufwand: 

■ Programmierung 

■ Fehlersuche 

■ Sicherheit 

■ Routing / Suche 

■ Replikation 

● Keine Verlässlichkeit ("nur" probabilistische Garantien) 

● Vertrauenswürdigkeit der Teilnehmer? 


Code Challenge Competition 


Vorlesung 

P2P Netzwerke 

2: Unstrukturierte Netze 




berlin de

Inhalt 

● Napster 

■ Erstes "P2P" Netzwerk 

■ Kein wirkliches P2P 

■ Enormes Medienecho Popularität für P2P 

● Gnutella 

■ Erstes "echtes" P2P Netzwerk 

■ Interessante Netzwerkeigenschaften 

● Eigenschaften von Gnutella 

■ Pareto‐Netzwerke 

■ Small‐World Netzwerke 

● Super‐Peer Netzwerke 


2


Einleitung 





• Napster 

• Gnutella 













Anwendungen 



• Amazon 

• Multicast 


Literatur 

● The Gnutella Protocol Specification v0.4 

● Mihajlo A. Jovanovic, Fred S. Annexstein, Kenneth A. Berman: 

"Scalability Issues in Large Peer‐to‐Peer Networks A Case Study 

of Gnutella". Technical report, University of Cincinnati, January 

2001. 

● Albert‐Laszlo Barabasi, Reka Albert: "Emergence of Scaling in 

Random Networks", Science, Vol 286, 1999. 

● Duncan J. Watts, Steven H. Strogatz: "Collective dynamics of 

'small‐world' networks", Nature, Vol 393, 1998. 

● Katharina A. Lh Lehmann, Michael Kaufmann: "Random 

Graphs, Small‐Worlds and Scale‐Free Networks", Peer‐to‐Peer 

Systems and Applications 

● Réka Albert, Hawoong Jeong, Albert‐László Barbási: "Error and 

attack tolerance of complex networks", Nature, Vol 406, 2000 


Napster 

● Netzwerk zum Tauschen von MP3‐Dateien 

● Geschichte: 

■ Mai 1999: Shawn Fanning (Northeastern 

University) gründet "Napster Online music service" 

■ Dezember 1999: Erster Rechtsstreit 

■ März 2000: University of Wisconsin: 

25% des IP Datenaufkommens sind Napster Pakete 

■ Dezember 2000: geschätzte 60 Millionen Anwender 

■ Februar 2001: US Circuit Court of Appeals: 

Napster weiß dass die Anwender Copyright‐Rechte verletzen: 

Napster wird geschlossen 

■ 2002: Bankrott 

■ September 2008: Aufkauf durch Best Buy 


Napster 

● Fokussiert: Einfache Anwendung (suche nach Musikdateien) 

● Suche über zentralen Server 

● Datenaustausch dezentral 

Registrierung, Suche 

Datenaustausch 

Napster 

Server 


Napster 

● Funktionsweise 

■ Verbinde mit Napster Server 

■ Hochladen der eigenen Dateiliste auf den Server 

■ Suche per Schlüsselwort‐Liste über den Server 

■ Wähle beste Antwort aus 

■ Direktverbindung mit Ziel‐Peer zum Download 

● Nachteile 

■ Zentraler Server 

♦ Single Point of Failure 

♦ Skalierbarkeit? 

■ Rechtliche Probleme 


Gnutella 

● Kein zentraler Server mehr 

● Peers werden Servents genannt 


Overlay‐Netzwerk 

● Gnutella ist sog. Overlay über dem Internet 


Problemstellungen 

● Bootstrapping 

■ Woher kenne ich Knoten im Netzwerk? 

■ Mit welchen Knoten verbinde ich mich? 

● Suche 

■ Wie finde ich Knoten, die Datei XYZ.MP3 anbieten? 

■ Wie finde ich den besten Knoten, der Datei XYZ.MP3 

anbietet? 

■ Der beste Knoten? 

♦ Verbindung? 

♦ Auslastung? 

♦ Qualität der Datei? 


Lösungen 

● Bootstrapping 

■ Allgemein bekannte Knoten (über Webserver) 

■ Liste mit bekannten Knoten von vorheriger Session 

■ Weitere Knoten über die Startknoten kennenlernen 

● Suche 

■ Flooding: Suche an alle Knoten weiterschicken 

■ Knoten merken sich IDs von gesehen Nachrichten, dies 

verhindert Schleifen 

■ TTL (Time to Live) begrenzt die Laufzeit einer Nachricht 


Gnutella Nachrichten 

Header für alle Nachrichten 

QUERY (0x80) 

Descriptor ID 

16 Bytes 

Min Speed 

2 Bytes 

Payload Descr. 1 Byte 

Search Criteria n Bytes 

TTL 

1 Byte 

QUERY HIT (0x81) 

Hops 

1 Byte 

Nb. of Hits 

1 Byte 

Payload Length 4 Bytes 

Port 

2 Bytes 

IP Address 

4 Bytes 

PING (0x00) 

Speed 

4 Bytes 

keine weiteren Felder 

Result Set: 

PONG (0x01) 

‐ File Index 4 Bytes 

Port 

2 Bytes 

‐ File Size 4 Bytes 

IP Address 

4 Bytes 

‐ File Name (+\0\0) n Bytes 

Nb. of shared Files 4 Bytes 

‐ … (weitere Result.) 

Nb. of shared KBytes 4 Bytes Servent Identifier 16 Bytes 


Abholen der Dateien 

● Direkte Verbindung zum Servent 

● Transfer durch HTTP 

● Wenn Servent hinter Firewall liegt: 

■ PUSH Nachricht über Gnutella routen 

PUSH (0x40) 

Servent Identifier 

File Index 

IP Address 

Port 

16 Bytes 

4 Bytes 

4 Bytes 

2 Bytes 


Routing in Gnutella 

Ping / Pong Query / Query Hit Push 

PING 

HIT 

QUERY 

PUSH 

PING 

PING 

PONG 


QUERY 

QUERY 


PUSH 

PUSH 

PING 

Push 

File 


Probleme von Gnutella 

● Hohe Netzwerklast 

● Flooding ist äußerst unstrukturierte Vorgehensweise: 

■ Ich frage fast jeden, ob er eine Datei liefern kann 

■ Begrenzung nur durch TTL 

● Durch TTL werden evtl. Dateien nicht gefunden 

● Gnutella‐Topologie hat nichts mit realer Topologie zu tun 

■ Zig‐Zack Zack Routen 

■ Daraus folgen hohe Latenzzeiten 


Eigenschaften von Gnutella 

● Was für ein Netzwerk wird aufgebaut? 

● Ist das Netzwerk rein zufällig? 

● Oder hat es bestimmte Eigenschaften? 

● Woher kommen diese Eigenschaften? 

● Gibt es sog. "Emergenz" bzw. "Selbstorganisation"? 


Gradverteilung 

Quelle: Jovanovic, Annexstein, Berman: 

Scalability Issues in Large Peer‐to‐Peer Networks – 

A Case Study of Gnutella 

log(Anzahl Peers mit Grad d) ) = c – k log(d) 


Gradverteilung 

● Allgemein: Power‐Law (Pareto‐Verteilung) 

Pr( X = x) 

= 

C 

k 

x 

Auch geschrieben als Pr( 

X 

= x) 

∝ 

x 

−k 

● Bei Gnutella: C=94, k=1.4 

● Was hat man davon? 

■ Power‐Law Netzwerke sind robust 

■ Es gibt viele Knoten mit kleinem Grad, deren Ausfall nicht so 

schlimm ist 

● Wie kommt das zustande? 

■ „Preferential Attachement“: die Reichen werden reicher 


Robustheit 

● Nimm ein Netzwerk mit 10.000 Knoten, 20.000 Kanten 

(durchsch. Grad=4) und entferne zufällig ausgewählte Knoten 

● Zufallsnetzwerk G(n, p): 

■ Entferne 5% der Knoten: Größte Komponente hat 9000 Knoten 

■ Entferne 18% der Knoten: Alle Komponenten zwischen 1 und 100 

Knoten 

■ Entferne 45% der Knoten: Nur Gruppen von 1 oder 2 Knoten 

überleben 

● Power‐law Netzwerk: 

■ Entferne 5% der Knoten: Nur isolierte Knoten brechen weg 

■ Entferne 18% der Knoten: Größte Komponente hat 8000 Knoten 

■ Entferne 45% der Knoten: Immernoch große Komponenten 

● Achtung: gilt nur für zufällige Ausfälle! 

Albert, et al. Error and attack tolerance of complex networks, Nature Vol 406, 2000 


● Barabási‐Albert‐Modell: 

Modell für 

Preferential Attachement 

■ Starte mit kleinem Netzwerk mit ein paar Kanten und Knoten 

■ Pro Schritte füge einen Knoten hinzu 

■ Füge m Kanten vom neuen zu den bestehenden Knoten mit 

einer Wahrscheinlichkeit hinzu, die Proportional zum Grad 

des Knoten ist 

● Effekt: Knoten verbinden sich mit bereits gut verbundenen 

Knoten mit höherer Wahrscheinlichkeit 


Milgram's Experiment 

● Wie sehen "reale" Netzwerke aus? 

● Soziales Netzwerk von Menschen: Wer kennt wen? 

● Milgram's Experiment (1967): 

■ Briefe an einen Freund von Milgram wurden an zufällige 

Personen in Kansas u. Nebraska verschickt 

■ "Routing‐Informationen": 

i " 

♦ Name der Zielperson 

♦ Ort (Boston) 

♦ Beruf (Börsenmakler) 

■ Anweisung: nur an Du‐Freunde weitergeben 

● Ergebnis: durchschnittlich 6 Schritte bis zum Ziel! 

● (aber nur 3 von 60 Paketen kamen an) 



Quelle: http://en.wikipedia.org/wiki/File:Map_of_USA_with_state_names.svg 


● Wie ist das möglich? 


● These: Soziale Netzwerke haben folgende Eigenschaften: 

■ Großer Clustering‐Koeffizient 

■ Kleiner Durchmesser bzw. charakteristische Pfadlänge 

● Clustering‐Koeffizient eines Knotens: 

{( 

j, 

k) 

∈ E | j, 

k ∈ N( 

i) 

} 

{ j | ( i, 

j) 

∈ E} , d( 

i) 

N( 

) 

C ( i) 

= 

, N( 

i) 

= 

= i 

d 

( i 

)( 

d 

( 

i 

) − 

1) 

■ N(i) = Nachbarn von i 

■ d(i) = Ausgangsgrad 

● Clustering‐Koeffizient eines Graphen: avg(C(i)) 



● Wie ist das möglich? 

● These: Soziale Netzwerke haben folgende Eigenschaften: 

■ Großer Clustering‐Koeffizient 

■ Kleiner Durchmesser bzw. charakteristische Pfadlänge 

● Durchmesser: 

■ Längster kürzester Pfad zwischen zwei Knoten 

● Charakteristische Pfadlänge: 

■ Durchschnittlicher kürzester Pfad zwischen zwei Knoten 


Randnotiz: Erdös‐Nummer 

Paul Erdös (1913 – 1996) 

Berühmter Mathematiker 

Frage: Über wie viele Schritte ist jemand als Co‐Autor mit 

Paul Erdös verbunden? 

Beispiel: Odej Kao hat Erdös‐Nummer 4: 

Odej Kao ist Co‐Autor von Klaus H. Ecker 

Klaus H. Ecker ist Co‐Autor von Helmut Ratschek 

Helmut Ratschek ist Co‐Autor von Egbert Harzheim 

Egbert Harzheim ist Co‐Autor von Paul Erdös 


● Untersuchung von 2000: 

Eigenschaften von Gnutella 

Knoten Kanten Durch‐ 

messer 

Clustering Koeffizient 

charakteristische 

Pfadlänge 

Gnutella Gnutella Zufallsgr. Gnutella Zufallsgr. 

13.11.2000 992 2465 9 0.0351 0.0078 3.72 4.49 

16.11.2000 1008 1782 12 0.0109 0.0056 4.43 5.54 

20.12.2000 1077 4094 10 0.0652 0.0094 3.31 3.66 

27.12.2000 1026 3752 8 0.0630 0.0102 3.30 3.71 

28.12.2000 1125 4080 8 0.0544 0.0090 3.33 3.77 

● Ergebnis: Clustering‐Koeffizient deutlich größer als beim 

Zufallsgraph, charakteristische Pfadlänge ähnlich bis kleiner 


Watts und Strogatz 

● Netzwerk‐Modell von Watts und Strogatz: 

■ Starte mit einem Ring, jeder Knoten ist mit m/2 Nachfolgern 

verbunden 

■ Durchlaufe den Ring und ersetze mit Wahrscheinlichkeit p das 

Ziel einer Kante durch ein zufällig ausgewähltes neues Ziel 

■ Modelliert Übergang zwischen Ordnung und Chaos 

● Eine kleine Anzahl von zufälligen Links reicht aus, um den 

Durchmesser zu reduzieren 


Modell von 

Watts und Strogatz 

p=0 p=1 


Übergang bei Watts / Strogatz 

C: Clustering‐Koeffizient 

L: Charakteristische Pfadlänge 


Netzwerktypen 

● Small‐World Networks 

■ Hoher Clustering‐Koeffizient 

♦ Transitivität: wenn A B kennt und A C kennt, 

dann kennen sich B und C mit hoher W’keit 

♦ Viele kleine (beinahe‐) Cliquen 

■ Geringer Durchmesser 

● Power‐Law Networks / Scale‐Free Networks 

■ Wenige Knoten mit hohem Grad 

11.04.2009 Felix Heine ‐ P2P Netzwerke 30

● Gnutella hat: 

Zusammenfassung Gnutella 

■ Gradverteilung nach Power‐Law 

■ Einen hohen Clustering‐Koeffizienten 

■ Einen kleinen Durchmesser 

Gnutella erzeugt ein Small‐World‐Netzwerk 

mit Power‐Law Gradverteilung. 

Das passiert selbstorganisierend (emergent) 


Super‐Peer Netze 

● Idee: Kern‐Netz aus "Super‐Peers" 

● Die "normalen" Knoten sind per Client/Server angebunden: 

Super Peer 

Leaf Node 


Super‐Peer Netze 

● Nachteile: 

■ Nicht die reine Lehre 

■ Super‐Peers müssen hohe Last aushalten 

■ Wer ist Super‐Peer? 

● Vorteile: 

♦ Automatische Auswahl vs. Selbstbestimmung 

■ Weniger Fluktuation 

■ Kleineres Netzwerk 

■ Effizientere Suche 

■ Alle P2P‐Mechanismen lassen sich im Super‐Peer Netz 

anwenden 


Vorlesung 

P2P Netzwerke 

3: Verteilte Hash‐Tabellen 

Tabellen, Chord 




berlin de


Einleitung 





• Napster 

• Gnutella 













Anwendungen 



• Amazon 

• Multicast 


Inhalt 

● Konsistentes Hashing 

● Verteilte Hash‐Tabellen 

● Chord 


Literatur 

● Ion Stoica, Robert Morris, David Liben‐Nowell, David R. 

Karger, M. Frans Kaashoek, Frank Dabek, Hari Balakrishnan: 

"Chord: A Scalable Peer‐to‐peer Lookup Protocol for 

Internet Applications", IEEE/ACM Transactions on 

Networking, Vol. 11, No. 1, pp. 17‐32, February 2003. 

● Ion Stoica, Robert Morris, David R. Karger, M. Frans 

Kaashoek, Hari Balakrishnan: "Chord: A Scalable Peer‐topeer 

Lookup Service for Internet Applications", i MIT TR 819. 


Auffinden von Objekten 

● Gegeben: 

■ Eine Menge von Knoten 

■ Eine Menge von Objekten auf jedem Knoten 

● Grundfragen: 

■ Wo wird welches Objekt im Netzwerk gespeichert? 

■ Wie wird das Objekt gefunden? 

● Objekte? Was für Objekte? 

■ Dateien 

■ Verweise auf Dateien 

■ Dt Datenbanktabellen 

ktbll 

■ Einträge in Datenbanktabellen 

■ Informationen (unterschiedliche Syntax/Semantik) 


5

Napster vs. Gnutella 

● Bisher betrachtet: Napster und Gnutella 

● Napster: 

■ Objekt: Metadaten zu Dateien 

■ Speicherung und Suche über zentralen Server 

■ Probleme: keine Ausfallsicherheit, keine Skalierbarkeit 

● Gnutella: 

■ Objekt ist die Datei 

■ Suche: Breitensuche durch das Netzwerk 

■ Probleme: 

♦ Entweder: Flooding, d.h. das ganze Netzwerk wird mit Suchanfragen 

überflutet 

♦ Oder: Begrenzung des Suchhorizontes (Time to Live), dann werden 

nicht alle Treffer gefunden 


Napster vs. Gnutella 

Flooding 

Kom mmunikat tionsaufw wand 

O(N) 

O(log N) 

O(1) 

Verteilte 

Hash‐Tab 

Zentraler 

Server 

O(1) 

O(log N) 

Statusinformationen 

O(N) 


Konsistentes Hashing 

● Grundidee: Knoten als Zellen in einer Hashtabelle auffassen 

● Jedes Objekt hat einen Schlüssel 

● Hash‐Funktion bestimmt, welches Objekt auf welchen 

Knoten kommt 

● Problem: Umsortierung nach Knotenankunft 

0 

1 2 3 4 


Konsistentes Hashing 

● Wie realisiere ich eine Hash‐Funktion, so dass bei 

Vergrößerung / Verkleinerung der Tabelle möglichst wenig 

Objekte umsortiert werden müssen? 

● Idee: "Zwischenschicht einziehen": 

■ Extrem große Hash‐Tabelle, deren Größe nie geändert wird 

■ Jeder Zelle der kleinen Tabelle entspricht einer Menge von 

Zellen in der großen Tabelle 

■ Bei Größenänderungen der kleinen Tabelle werden nur 

wenige Objekte verschoben 

■ Größenordnung O(X/N): X Anzahl Objekte, N Anzahl Zellen in 

der kleinen Tabelle 


Verteilte Hashtabellen 

● Grundidee: 

■ Jedes Objekt im Netzwerk (z.B. Datei) bekommt eine ID 

■ Jeder Netzknoten ist verantwortlich für einen Bereich von ID‘s 

■ Das Netz ist so aufgebaut, dass der für eine ID 

verantwortliche Knoten schnell aufgefunden werden kann 

Objekte 

ID‐Raum 

Knoten 




■ Jedes Objekt im Netzwerk (z.B. Datei) bekommt eine ID 

■ Jeder Netzknoten ist verantwortlich für einen Bereich von ID‘s 

■ Das Netz ist so aufgebaut, dass der für eine ID 

verantwortliche Knoten schnell aufgefunden werden kann 

Objekte 

ID‐Raum 

Knoten 



● Wie sieht der ID‐Raum aus? 

■ Typisch: Ganzzahlig Numerisch, z.B. 0 bis 2 128 ‐1 

■ Jeder Knoten hat selbst eine ID aus dem Bereich 

■ Jeder Knoten ist verantwortlich für einen Bereich 

■ Der Raum ist zirkulär: 

0 = 2 128 mod 2 128 ¼ x 2 128 

¾ x 2 128 

½ x 2 128 








0 = 2 128 mod 2 128 ¼ x 2 128 

¾ x 2 128 

½ x 2 128 








0 = 2 128 mod 2 128 ¼ x 2 128 

¾ x 2 128 

½ x 2 128 



● Fragen: 

■ ID‐Raum 

♦ Aufbau 

♦ Verantwortlichkeit der Knoten 

■ Routing 

♦ Verbindungsstruktur der Knoten 

♦ Wie wird der verantwortliche Knoten gefunden? 

■ Dynamik 

♦ Integration eines neuen Knotens 

♦ Ausfall eines Knotens 

● Weitere Fragen: 

■ Lokalität 

■ Lastverteilung 

♦ Unterschiedliche Performance 

● Anwendungs‐Aspekte 

■ Was speichere ich? 

■ Bestimmung der Objekt‐ID 


● Speicherung 

Anwendungs‐Aspekte 

■ Alternativen: ti Dt Daten oder Index 

■ Daten: 

♦ Pro: Schneller Zugriff 

♦ Contra: Updates, Speicherbrauch hwegen Redundanz 

d 

■ Index: 

♦ Pro: Aktualität, Effizientere Verteilung 

♦ Contra: Ein Routing‐Schritt mehr 

● Wahl der Objekt‐ID 

■ Anwendungsabhängig 

gg 

■ So, dass der Suchende die ID bestimmen kann 

♦ Z.B. Hash des Objektnamens (Dateiname) 

■ Auch mehrere unterschiedliche IDs pro Objekt 

♦ z.B. Bücher: Titel, Autor, ISBN‐Nummer, Verlag, … 

♦ Oder noch feiner: jedes Wort im Titel, weitere Schlagwörter 

■ Spielt eine Rolle bei der Lastverteilung 


Chord 

● Knoten sind in einem Ring organisiert 

● Jeder Knoten ist für den Bereich vor und inkl. seiner 

eigenen ID zuständig 

● Knoten ID wird zufällig ausgewählt 

0 = 128 

105 

120 

18 

96 32 

40 

76 

64 

58 


Chord: Routing 

● Erster Ansatz: Successor‐Pointer 

● Jeder Knoten kennt seinen Nachfolger im Ring 

● Wie funktioniert das Routing? 

0 = 128 

105 

120 

18 

96 32 

40 

76 

64 

58 


Chord 

● Vorteil: Minimaler Knotenstatus 

● Probleme: 

■ Routing in O(N) Schritten 

■ Netz fällt auseinander, wenn ein Knoten ausfällt 

0 = 128 

105 

120 

18 

96 32 

40 

76 

64 

58 



● Nächster Ansatz: Vollständige Vernetzung 

● Routing in einem Schritt 

● Perfekter Zusammenhalt 

● Aber: Nicht skalierbar! 

0 = 128 

105 

120 

18 

96 32 

40 

76 

64 

58 



● Was wird gebraucht? 

● Jeder Knoten muss eine geringe Anzahl an anderen Knoten 

kennen 

● Z.T. direkt benachbarte Knoten, z.T. weit entfernte Knoten 

● Lösung: Jeder Knoten kennt den Knoten im Abstand 1, 2, 4, 

8, 16, 32, … 

● Routing‐Tabelle dazu heißt Finger‐Table 

● Und hat log(maxID) Einträge 


● Beispiel für Knoten 105: 

Finger‐Table Routing 

0 = 128 

105 

120 

18 

96 32 

40 

76 

64 

58 


Finger‐Table Routing 

● Beispiel für Knoten 105: 

Offset 1 2 4 8 16 32 64 

ID 106 107 109 113 121 9 41 

Tats. Knoten 120 120 120 120 18 18 58 

0 = 128 

105 

120 

18 

96 32 

40 

76 

64 

58 


Routing in Chord 

● Idee: Suche den Knoten in der Finger‐Table, der am dichtesten an 

der Zieladresse ist, aber nicht dahinter 

● Algorithmen: 

1 // ask node n to find the successor of id 

2 n.find_successor(id) 

3 if id in (n, successor] 

4 return successor; 

5 else 

6 n‘ = closest_preceding_node(id); 

7 return n‘.find_ successor(id); 

1 // search the local table for the highest predecessor of id 

2 n.closest_preceding_node(id) 

3 for i = m downto 1 

4 if finger[i] in (n, id) 

5 return finger[i]; 

6 return n; 


Knotenankunft 

● Jeder Knoten hat zusätzlich einen predecessor Zeiger 

● Neuer Knoten muss seinen Identifier n bestimmen 

● Neuer Knoten n muss einen Knoten o im Netz kennen 

● n fragt o nach successor(n) 

■ erhält damit seinen eigenen successor n' 

● n kontaktiert n', dadurch wird predecessor(n') aktualisiert 

p 

n 

n' 


Stabilisierungsprotokoll 

● Regelmäßige Kontrolle der successor / predecessor‐Pointer 

1 // called periodically. verifies n’s immediate 

2 // successor, and tells the successor about n. 

3 p.stabilize() 

4 n = successor.predecessor; 

5 if n in (p, successor) 

6 successor = n; 

7 successor.notify(p); 

p 

n 

n' 


Stabilisierungsprotokoll 

1 // called periodically. verifies n’s immediate 

2 // successor, and tells the successor about n. 

3 n.stabilize() 

4 x = successor.predecessor; 

5 if x in (n, successor) 

6 successor = x; 

7 successor.notify(n); 

1 // n' thinks it might be our predecessor. 

2 n.notify(n') 

3 if (predecessor is nil or n' in (predecessor, n)) 

4 predecessor = n'; 


Stabilisierung der 

Finger Pointer 

1 // called periodically. refreshes finger table entries. 

2 // next stores the index of the next finger to fix. 

3 n.fix_fingers() 

4 next = next + 1; 

5 if (next > m) 

6 next = 1; 

7 finger[next] = find_successor(n + 2^(next‐1) ); 



Finger Pointer 

Neuer Knoten (für k unbekannt) 

Alter Finger Pointer 

eines Knoten k 

Für Distanz 2 i p 2 

n ' 

p 

n 

k+2 i 

hierhin „sollte“ der 

Finger Pointer zeigen 

Ziele, bei denen 

Finger Pointer p 

genutzt würde 

Routing funktioniert auch mit defekter Finger‐Tabelle korrekt! 



Successor Pointer 

p 

n 

n' 

Routing fehlerhaft bei inkorrektem Successor Pointer! 

Ggf. sind Daten noch nicht von n' an n abgegeben worden! 

● Fehler sind nur kurzzeitig, müssen von Application Layer 

behandelt werden (z.B. wiederholte Anfrage/Einfügen) 


● Zufällige Wahl der ID's 

Wie groß werden die Bereiche? 

● Ideal: bei N Knoten hat jeder Knoten MAXID/N IDs zu 

verwalten 

● Wie sieht es wirklich aus? 

● Normiere Ringgröße auf 1 

● Ideale Bereichsgröße ist 1/N 

● Wahrscheinlichkeit, dass ein Bereich mehr als den Faktor 

log(N) größer ist, oder mehr als den Faktor N kleiner ist, ist 

sehr klein 



● Was ist "kleine" Wahrscheinlichkeit, was ist eine "hohe"? 

● Definition: 

■ Geringe Wahrscheinlichkeit: , c ≥ 1 

1 

N c 

■ Hohe Wahrscheinlichkeit: 1 − , c ≥ 1 

1 

N c 

Je größer das Netzwerk, desto dichter ist eine kleine 

Wahrscheinlichkeit bei 0, und eine hohe 

Wahrscheinlichkeit bei 1. 



1. Die Wahrscheinlichkeit, dass ein beliebiges Intervall kleiner 

ist als Ω(1/N 2 ), ist gering. 

2. Die Wahrscheinlichkeit, dass ein beliebiges Intervall größer 

als O(log N/N) ist, ist gering. 


Größe eines Intervalls: 

untere Schranke 

1 

Bt Betrachte das It Intervall 

I 

der Göß Größe 

hinter einem Knoten. 

2 

N 

E : Ereignis, dass Knoten i in dieses Intervallfällt 

i 

P 1 

⇒ ( E ) = i 2 

N 

E 

: Ereignis, 

dass irgendein Knoten in 

I 

fällt 

N 

N 

1 1 

⇒ P( 

E) 

= P( 

U 

i = 1 

Ei 

) ≤ ∑ P( 

E N 

i = i 

) = = 

1 

2 

N N 


Größe eines Intervalls 

Knoten 

beliebigem 

hinter 

) 

log 

1 

Größe 

der 

Intervall 

das 

Betrachte (N 

I 

1 

fällt 

Intervall 

in dieses 

Knoten 

dass 

Ereignis, 

: 

Knoten 

beliebigem 

hinter 

) 

log 

Größe 

der 

Intervall 

das 

Betrachte 

i 

E 

(N 

N 

I 

i 

fällt 

in 

nicht 

Knoten 

dass 

Ereignis, 

: 

) 

log( 

1 

) 

( 

I 

i 

E 

N 

N 

E 

P 

i 

i = 

⇒ 

fällt 

i 

K 

t 

ki 

d 

E i i 

) 

log( 

1 

1 

) 

( 

1 

) 

( 

I 

E 

N 

N 

E 

P 

E 

P 

i 

i 

− 

= 

− 

= 

⇒ 

) 

log( 

) 

log( 

1 

1 

) 

) 

log( 

(1 

)) 

log( 

1 

(1 

) 

( 

) 

( 

) 

( 

fällt 

in 

Knoten 

kein 

dass 

Ereignis, 

: 

N 

N 

N 

N 

E 

P 

E 

P 

E 

P 

I 

E 

N 

N 

N 

N 

N 

N 

i i − 

= 

− 

= 

= 

= 

⇒ 

I = 

1,44 

2) 

ln( 

1 

2) 

ln( 

) 

ln( 

) 

log( 

) 

log( 

) 

log( 1 

1 

1 

1 

) 

1 

(1 

) 

1 

(1 

N 

N 

e 

e 

m 

m 

N 

N 

N 

N 

N 

m 

N 

m 

≈ 

= 

= 

⎥ 

⎦ 

⎤ 

⎢ 

⎣ 

⎡ 

≤ 

⎥ 

⎦ 

⎤ 

⎢ 

⎣ 

⎡ 

− 

= 

− 

= 

23.04.2009 Dominic Battré ‐ P2P Netzwerke 35 

) 

( 

) 

( 

N 

e

Wieviele unterschiedliche Finger‐ 

Zeiger haben Knoten? 

● Betrachte wieder auf 1 normierten Ring 

● Finger‐Zeiger zeigen auf +½, +¼, +1/8, +1/16, … 

● Ab dem Finger dessen Ziel kleiner ist als die Intervallgröße, 

sind alle Finger Identisch (Nachfolger) 

● Als suchen wir die Finger für die gilt: 

⇔ 2 

x 

< 

1 1 

x 2 

2 

> N 

2 

x 

N ⇔ log2(2 

) < log 

⇔ x < 2log 

2 ( 

N 

) 

2 

2 

( N 

2 

) 

● also: O(log N) unterschiedliche Zeiger 


Wie schnell ist das Routing? 

● O(log N) Schritte mit hoher Wahrscheinlichkeit 

n 

● n möchte an Adresse k senden (zuständig ist ein Knoten z) 

● p sei der Vorgänger von k → Wie lange brauchen wir bis p? 

● n ≠ p → n sendet an nächsten Vorgänger von k in Finger 

Tabelle 

● Betrachte ein i, sodass p in [n+2 i‐1 , n+2 i ) 

● Intervall ist nicht leer (enthält p) → n sendet an ersten 

Knoten in dem Intervall (ist in Fingertabelle) bll) 

● D.h.: Überbrückte Distanz ist ≥ 2 i‐1 

p 

k 

z 



● O(log N) Schritte mit hoher Wahrscheinlichkeit 

n 

p 

k 

z 

● Betrachte ein i, sodass p in [n+2 i‐1 , n+2 i ) 

● Intervall ist nicht leer (enthält p) → n sendet an ersten 

Knoten in dem Intervall (ist in Fingertabelle) 

● Dh:Überbrückte D.h.: Distanz ist ≥ 2 i‐1 

● Aktueller Knoten ist in [n+2 i‐1 , n+2 i ) und p ebenfalls 

● Länge des Intervalls ist 2 i‐1 → Restdistanz bis p ≤ 2 i‐1 

● → Hälfte der Strecke bis p ist überbrückt 

Fortsetzung 



● In jedem Schritt wird die Restdistanz mind. halbiert 

● Startdistanz ist max. 1 (normierter Ring) 

Schritte 1 2 3 … log N 2 log N 

Restdistanz 1/2 1/2 2 1/2 3 … 1/2 log N =1/N 1/2 2log N = 1/N 2 

● Nach 2 log N Schritten ist die Restdistanz 1/N 2 

● Die Wahrscheinlichkeit, dass in einem solchen Intervall 

mehr als ein Knoten ist, ist gering 

● Routing erfolgt in O(log N) Schritten mit hoher 

Wahrscheinlichkeit 


Welche Finger zeigen auf mich? 

● Erwartungswert einfach: 

■ Erwartungswert des Ausgangsgrades O(log N) 

■ Daher Erwartungswert des Eingangsgrades g g O(log N) 

● Wahrscheinliche obere Schranke??? 



p 

k 

Position wo Distanz 

2 i auf k zeigen würde 

(für festes i) 

Für ein Interval der Länge p..k gibt 

es höchstens p..k Positionen, die 

einen Finger Pointer für die Distanz 

2 i auf k zeigen lassen würden –egal 

wie groß 2 i ist. 

Position wo Distanz 

2 i vor oder hinter 

k zeigen würde 

(für festes i) 



k ● Intervall p…k hat höchstens Länge 

p L = O(log(N)/ N) (m.h.Wkeit) 

● Anzahl Peers in Intervall der Länge L ist 

O( L / (1/N)) = O(log N) (m.h.Wkeit) 

(Kann mittels Chernoff Ungleichung 

g 

gezeigt werden, s. Mahlmann 07) 

● Routingtabellen haben höchstens 

Länge O(log N) 

(m.h.Wkeit) 

● → O(log(N)) * O(log(N)) = O(log 2 (N)) 

Knoten können auf k zeigen. 


Chord: Knotenausfall 

● Knoten bemerkt, dass ein Successor ausgefallen ist 

● Woher bekommt er neuen Successor? 

● Lösung: Liste von x Nachfolgern 

● Liste wird regelmäßig gegen den Uhrzeigersinn 

weitergegeben und aktualisiert 

● Wichtig: Routing ist korrekt, auch wenn Finger‐Pointer noch 

nicht korrigiert! 

● Was passiert bei hohem "Churn"? 


Chord: Hoher Churn 

● Beispiel: 

20 40 

60 

1 n.stabilize() 

2 x = successor.predecessor; 

3 if x in (n, successor) 

4 successor = x; 

5 successor.notify(n); 

30 50 

1 n.notify(n') 

2 if (predecessor is nil or n' in (predecessor, n)) 

3 predecessor = n'; 


Replika‐Knoten 

● Nach Knotenausfall wird der Nachfolger verantwortlich für 

den Bereich des ausgefallenen Knotens 

● Daher: Replikation der Daten auf Nachfolger 

0 = 128 

96 

105 

120 

Knoten Root R1 R2 

18 18 [121,18] [106,120] [77,105] 

40 [19,40] [121,18] [106,120] 

32 

58 [41,58] [19,40] [121,18] 

76 

58 

40 

76 [59,76] [41,58] [19,40] 

105 [77,105] [59,76] [41,58] 

120 [106,120] [77,105] [59,76] 

64 


Speichern von Daten 

● Jeder Knoten hat lokale Daten (z.B. Dateien) 

● Er publiziert diese Daten / Indizes im Netzwerk 

● Das ganze geht über sog. "Soft‐State State Updates" 

■ Daten haben auf dem Zielknoten ein Timeout 

■ Der Original‐Knoten muss sie regelmäßig erneuern 

● Wenn ein Knoten ausfällt, verschwinden seine Daten daher 

nach einiger Zeit 

● Der für ein Datum verantwortliche Knoten (Root‐Knoten) 

verteilt die Daten weiter an die Replika‐Knoten 


Datenfluss 

18 40 58 76 105 120 

Lokal 

Lokal Lokal Lokal Lokal Lokal 

Root 

Root 

Root 

Root 

Root 

Root 

Replika 

Replika Replika Replika Replika Replika 


Knotenankunft 

● Problem: Knoten bekommt Verantwortung für einen 

Bereich 

● Er hat aber noch keine Daten für diesen Bereich 

● Lösungsmöglichkeiten: 

■ Solange bis alle Daten vorhanden sind, werden Anfragen an 

alten Knoten weitergeleitet 

■ Erst ins Netzwerk einhängen, wenn die Daten da sind 

■ Problem ignorieren und auf Soft‐State Updates warten 


Erweiterung: DHash++ 

● Frank Dabek, Jinyang Li, Emil Sit, James Robertson, Frans M 

Kaashoek, Robert Morris: Designing a DHT for Low Latency 

and High Throughput, NSDI 04, pp. 85‐98 

? ? 


Erweiterung: DHash++ 

● Rekursives statt iteratives Routing (geringere Latenz wg. 

weniger Nachrichten, erlaubt auch effiziente Nutzung von 

TCP trotz Overhead des Handshakes) 

Iterativ: 

1 

3 5 

Rekursiv: 

1 

2 3 

2 

4 6 

4 

● Geringere Latenzen durch lokalitätsbasierte Auswahl der 

Finger Pointer (wird später in der VL behandelt) 

● Erasure Codes statt Replikation für geringeren 

Schreibaufwand (aber langsameres Lesen) 


Nachteile von DHTs 

● Ohne explizite Behandlung in der Anwendung: 

■ Keine Lokalität der Daten: Meier vs. Mayer 

■ Un‐exakte Suche unmöglich 

■ Bereichssuche unmöglich 

● Verwaltungsaufwand beim Knotenankunft/‐weggang 

■ Daher schlecht bei hoher Dynamik ("Churn") 


Interfaces zu DHTs 

● Zwei Sichtweisen: 

■ Pakete zu einer ID Routen 

■ Hashtabelle 

● Pakete Routen: 

■ send(destId, msg) 

■ msg receive() 

■ Best‐effort effort service 

● Hashtabelle 

■ put(key, value) 

■ value get(key) 


Zusammenfassung 

● DHTs verschieben Daten auf wohldefinierte Knoten 

● Dadurch ist effiziente Suche nach Daten möglich 

● Zur Zuordnung von Daten zu Knoten wird konsistentes 

Hashing verwendet 

● Fragestellungen für DHTs: 

■ Aufbau ID‐Raum 

■ Verbindungsstruktur 

■ Routing‐Mechanismus 

■ Dynamik: Knotenankunft / Knotenausfall 

● Interfaces zu DHTs 


Vorlesung 

P2P Netzwerke 

4: Content Addressable Network 




berlin de

CAN: Content Addressable Network 

● Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, 

Scott Shenker: "A Scalable Content‐Addressable Network", 

SIGCOMM’01, 2001. 

● Alternativer Ansatz: 

■ Adresse eines Knotens ist eine 2‐dimensionale Koordinate 

● Bereiche werden bei Knotenankunft geteilt 


CAN 

(0,1) (1,1) 

(0,0) (1,0) 


CAN 

(0,1) (1,1) 

(0,0) (1,0) 


CAN 

(0,1) (1,1) 

(0,0) (1,0) 


CAN 

(0,1) (1,1) 

(0,0) (1,0) 


CAN 

(0,1) (1,1) 

(0,0) (1,0) 


Verbindungsstruktur 

(0,1) (1,1) 

Achtung: 

d‐torus 

(0,0) (1,0) 


CAN 

● ID‐Raum ist 2‐Dimensional kontinuierlich [0,1)x[0,1) 

● Routing: 

■ Wenn Ziel in meine Zone fällt, bin ich fertig 

■ Sonst: Schicke Nachricht zu einem Nachbarknoten, der eine 

kleinere (euklidische) Distanz zum Ziel hat 

● Knotenankunft: 

■ Wähle zufällige ID aus [0,1)x[0,1) 

[ , ) 

■ Route Nachricht an diesen Punkt 

■ Gebiet des Ziel‐Peers wird geteilt 

■ Baue Verbindungen zu allen Nachbarn des alten Peers auf 


Analyse 

● Idealisiert: 2D‐Gitter 

● Nötige Routing‐Schritte 

■ O(sqrt(N)) 

( ● Anzahl Nachbarn 

■ 4 Nachbarn, also O(1) 

● Vergleiche mit Chord: 

■ beides O(log N) 

● Routing langsamer, aber viel weniger Verbindungen und 

damit weniger Verwaltungsaufwand! 

● Trotzdem robustes Netzwerk 


● Übungsaufgabe 

Wie groß werden die Zonen? 


CAN: Ausfall eines Knotens 

● Die Nachbarn entdecken, dass der Peer ausgefallen ist 

● Ziel: 

■ der Nachbar mit der kleinsten Zone soll den ausgefallenen 

Peer übernehmen 

● Daher: 

■ Jd Jeder Knoten startet einen Timer proportional zur Göß Größe der 

eigenen Zone 

■ Wenn der Timer abgelaufen ist, sendet er eine Nachricht an 

alle anderen Nachbarn 

■ Wer die Nachricht empfängt, stoppt seinen Timer 

■ Danach übernimmt er die Zone des ausgefallenen Peers 

● Kann zu Fragmentierung führen 


Fragmentierung 

(0,1) (1,1) 

(0,0) (1,0) 


Fragmentierung 

(0,1) (1,1) 

(0,0) (1,0) 


Defragmentierung Teil 1 

● Wenn ein Peer mehr als eine Zone hat: 

■ Versuche, kleinste Zone loszuwerden 

● Wenn die Nachbarzone ungeteilt ist (beide Knoten Blätter im 

Aufteilungsbaum): 

■ Übergib die Zone dem Nachbar 

A 

A 

C 

D 

C 

B 

D 

C 

B 


Defragmentierung Teil 2 

● Wenn die Nachbarzone aufgeteilt ist: 

■ Tiefensuche im Baum, bis zwei benachbarte Blätter gefunden 

wurden 

■ Fasse diese Blätter zusammen 

■ der freigewordene Peer übernimmt das Gebiet 

A 

A 

C 

D E 

C 

B 

D 

E 

C 

B 


Mehrdimensionales CAN 

● Analoge Konstruktion, aber d‐Dimensionaler Schlüsselraum 

● Bewirkt: 

■ Kürzere Routing‐Zeiten 

■ Mehr Nachbarn 

● Genauer: 

■ O(n 1/d ) Hops 

■ 2d Nachbarn, also O(d) Nachbarn 


Mehrere Realitäten 

● Es werden gleichzeitig mehrere CAN Netzwerke aufgebaut 

● Jedes heißt Realität 

● Beim Routing wird zwischen den Realitäten gesprungen 

(besonders am Anfang) 

● Bewirkt: Schnelleres Routing, Replikation, Robustheit 

C 

A 

B 

E 

H 

E 

G 

B 

D 

G 

D 

J 

F I J 

F 

A 

H 

I 

C 


Dimensionen vs. Realitäten 

Quelle: Ratnasamy, Francis, Handley, Karp, Shenker: 

A Scalable Content‐Addressable Network, SIGCOMM’01, 2001 


Dimensionen vs. Realitäten 

Quelle: Ratnasamy, Francis, Handley, Karp, Shenker: 

A Scalable Content‐Addressable Network, SIGCOMM’01, 2001 


Mehrfaches Hashing 

● Daten werden mehrfach abgespeichert 

■ indem man k unterschiedliche Hash‐Funktionen nimmt 

● Dadurch erhöht sich die Robustheit 

● Geringere Entfernungen 

■ Lookup nur zu nächster Kopie 


Überladen von Zonen 

● In jeder Zone werden mehrere Peers platziert 

● Alle Peers einer Zone kennen sich untereinander 

● Jeder kennt mindestens einen aus der Nachbarschaft 

● Bewirkt: Routing konstant schneller, Replikation 


Uniform Partitioning 

● Beim Join wird versucht, die Zonengröße besser 

auszugleichen 

● Jeder Peer kennt die Zonen seiner Nachbarn 

● Es wird die größte Zone geteilt 


Latenzen Berücksichtigen 

● Bisher haben wir Routing‐Performance nur in Hop‐ 

Distanzen im Overlay‐Netzwerk gemessen 

● Wie sieht es tatsächlich aus? 

● Beispiel: Routing mit 3 Hops im Overlay 

Knoten 

im P2P 

Overlay 

Logische 

Verbindung 

im Overlay 

Asien 

USA, 

New York 

Router 

im 

Internet 

Europa 

Internet 

Verbindung 

USA, 

Boston 


Latenzen 

● Die effektive Latenz im Routing hängt also von 2 Faktoren 

ab: 

■ Anzahl Hops 

■ Internet‐Latenzen der einzelnen Hops 

● Es kann also evtl. schneller sein, mehr Hops zu machen, die 

aber dafür lokaler sind 

● Dazu muss das Routing oder die Verbindungsstruktur eine 

gewisse Flexibilität haben 

● Bei Chord z.B. sind Struktur und Routen determiniert 

● CAN ist hier flexibler 


Latenzen 

● In CAN 3 Ansätze: 

■ Im Standard‐CAN den nächsten Hop mit bestem Verhältnis 

ID‐Distanz zu Latenz auswählen (statt maximaler ID‐Distanz) 

Proximity Route Selection (PRS) 

■ Beim Überladen von Zonen Verbindung mit dem "dichtesten" 

Knoten in der Nachbarzone eingehen 

regelmäßig die anderen Kandidaten prüfen, evtl. wechseln 

Proximity Neighbor Selection (PNS) 

■ ID nicht zufällig wählen, sondern anhand einer Lokalitäts‐ 

MtikP Metrik Position im Nt Netzwerk wählen 

Proximity Neighbor Selection (PNS) 


Netzwerk an Internet‐Topologie 

anpassen 

● m spezielle Peers dienen als "Landmarken" 

● Latenzzeiten zu diesen Landmarken werden gemessen 

● Liste der Latenzzeiten zu den Landmarken wird sortiert 

● Diese Sortierung bestimmt Position im CAN 

● Dadurch werden nahe Peers auch in CAN nah einsortiert 

● Vorteile: 

■ Gute Verringerung der Latenzzeiten 

● Probleme 

■ Wie wähle ich die Landmarken aus? 

■ Lastungleichgewichte 

■ Gefahr von Partitionierung 


CAN: Gesamt‐Evaluation 

Parameter 

bare bones 

CAN 

Dim. 2 10 

Realitäten 1 1 

Peer / Zone 0 4 

Hashfkt. 1 1 

Latenz‐Optimiertes Aus An 

Routing 

Uniform Partitioning Aus An 

Landmark Ordering Aus Aus 

knobs on full 

CAN 

Metrik 

bare bones 

CAN 

Pfadlänge 198 5 

Grad 4,57 27,1 

Peers 0 2,95 

knobs on full 

CAN 

IP Latenz 115,9 ms 82,4 ms 

Pfad Latenz 23,008 sec. 135,29 ms 

2 18 Knoten, Transit‐Stub Topologie 


CAN: Vorteile/Nachteile 

● Vorteile 

■ Einfaches Verfahren 

■ Balanciert die Datenmenge 

■ Kleiner Grad 

■ Netzwerk ist stark zusammenhängend, dadurch robust 

■ Kennt verschiedene Wege zum Ziel und kann dadurch Routen 

optimieren 

● Nachteile 

■ Lange Wege (polynomiell lang) 

■ Stabilität durch geringe Nachbarzahl gefährdet 


Vorlesung 

P2P Netzwerke 

5: Pastry 




berlin de


Einleitung 





• Napster 

• Gnutella 













Anwendungen 



• Amazon 

• Multicast 


Pastry und Tapestry 

● Pastry 

■ Antony Rowstron and Peter Druschel: "Pastry: Scalable, 

decentralized object location and routing for large‐scale peer‐ 

to‐peer systems" , IFIP/ACM International Conference on 

Distributed Systems Platforms (Middleware), 2001 

● Tapestry 

■ Kirsten Hildrum, John Kubiatowicz, Satish Rao, Ben Y. Zhao, 

"Distributed object location in a dynamic network.", SPAA, 

2002, pp. 41‐52 

● Grundlage: Routing nach Plaxton/Rajaraman/Richa 

■ C. Greg Plaxton, Rj Rajmohan Rj Rajaraman, A. W. Richa, 

"Accessing Nearby Copies of Replicated Objects in a 

Distributed Environment", SPAA, 1997, pp. 311‐320 


Grundidee: Präfix‐Routing 

● ID wird zur Basis 2 b dargestellt, 

■ z.B. b=4 bedeutet Hexadezimaldarstellung 

■ bei 160 Bit sind das 40 Ziffern 


Sende die Nachricht an den Knoten aus der 

Routing‐Tabelle, dessen gemeinsamer Präfix mit 

der Ziel‐ID maximale Länge hat. 

● Was für Einträge braucht man in der Routing‐Tabelle? 


Routing‐Tabelle 

Knoten 53411721, 10.000 Knoten 

b=3, d.h. Oktalziffern 

ID‐Länge 8 Ziffern, d.h. 3*8 = 24 Bit 

Präfix 0 1 2 3 4 5 6 7 

‐ 05113420 10421650 25661215 33561253 42604240 66353254 72621233 

5 50652006 51615413 52211242 54116142 55103005 56433314 57767105 

53 53021530 53110517 53242072 53351527 53557047 53654314 53740336 

534 53403564 53435054 53447620 53452243 53467746 53472422 

5341 53410425 

53411 

534117 

5341172 


● Beispiel: Graphische 

Darstellung eines Teils der 

Routing‐Tabelle eines 

Knotens mit der ID 021xxxx 

● Jeweils ein Zeiger in den 

Sektor 1xxx, 2xxx, 3xxx 

● Dann je ein Zeiger in die 

Sektoren 00xxx, 01xxx, 

03xxx 

● Dann je ein Zeiger in die 

Sektoren 020xxx, 022xxx, 

023xxx 

● etc. 



Probleme 

● Wie geht das Routing weiter, wenn man auf einen leeren 

Eintrag in der Routing‐Tabelle trifft? 

● Hier unterscheiden sich Pastry und Tapestry 

■ Frage: Sind die Routing‐Tabellen konsistent? 

■ d.h., gibt es für einen leeren Eintrag niemals einen passenden 

Knoten? 

■ Antwort von Pastry: Nicht konsistent 

■ Antwort von Tapestry: Konsistent 

● Entsprechend dieser Annahme unterscheidet sich das 

weitere Vorgehen 


Pastry 

● Zuordnung von Bereichen: 

■ Root‐Knoten ist der numerisch dichteste 

■ Aufpassen: der numerisch dichteste Knoten kann ein ganz anderes 

Präfix haben! 

■ Beispiel: Knoten 2700, Ziel 2777, nächster Knoten 3000 (Oktal) 

● Dh Daher: 

■ Pastry wechselt am Ende auf ein anderes Routing‐Verfahren 

■ Dazu wird ein Leaf‐Set verwendet, das die L dichtesten Knoten 

beinhaltet 

● Also: 

■ Mit Präfix‐Routing wird in die Nähe des Ziels gesprungen 

■ Die genaue Positionierung geht dann über das Leaf‐Set 


Vergleich mit Chord 

● In beide Richtungen routen (statt nur im Uhrzeigersinn) 

● Restdistanz pro Schritt durch 2 b teilen (statt halbieren) 

● Routing‐Einträge werden jeweils aus einem Intervall 

ausgesucht (statt deterministisch einen zu nehmen) 

● Verantwortlichkeiten werden anders definiert 


Pastry: Routing Algorithmus 

1 // Knoten A: Route Schlüssel D 

2 if LeafSet[‐L/2]

Pastry: Performance 

● Anzahl Einträge in der Routing‐Tabelle: O(log 2 

b N 

) 

● Routing‐Performance: 

O 

(log 2 N) 

b 

● Wenn Routing‐Tabellen leer: O 

( N 

/ 

L 

) 


Lokalität 

● Einträge in der Routing‐Tabelle können frei gewählt werden 

(entsprechend den Constraints) 

● Tabellen werden mit "nahen" Knoten befüllt 

● Art der Distanzbestimmung ist dabei offen gelassen 

● Anforderung: es muss eine Metrik sein 

● Die Befüllung der Routing‐Tabellen mit "nahen" Knoten 

wird durch den Join‐Algorithmus gewährleistet: 

■ Annahme dabei: neuer Knoten ist "nahe" zu seinem 

Bootstrap‐Knoten A 

■ Also sind die Knoten B, C, … auf dem Pfad auch "nahe" 

■ Daher ist die so konstruierte Tabelle schon relativ gut 


Ankunft eines Knoten 

● Route Nachricht an eigene ID id über bekannten Knoten A 

● Die Nachricht wird über Knoten B, C, … an Knoten Z 

geroutet 

● Jeder Knoten auf der Route schickt seine Routing‐Tabelle 

zurück 

● Daraus baue ich meine eigene Tabelle auf: 

■ Zeile 0 wird von Knoten A genommen 

■ Zeile 1 wird von Knoten B genommen 

■ … 

● Leaf‐Set wird von Knoten Z genommen 

● Alle jetzt bekannten Knoten werden informiert 


Varianten beim Einfügen 

● Einfache Variante SL (von vorheriger Folie): 

■ Jeweils eine Zeile auf dem Weg vom Join‐Knoten zum Ziel nehmen 

● Variante WT: 

■ Gesamten Status von jedem Knoten auf dem Weg zum Ziel nehmen 

● Variante WTF (in FreePastry implementiert): 

■ Eine Ebene weiter gehen, von allen so bekannten Knoten den 

Status holen 

● In den Varianten WT und WTF wird idjeweils die Lokalität geprüft 

(RTT‐Messungen) 

● Bei mehreren Möglichkeiten, eine Zelle zu füllen, wird jeweils 

der dichteste Knoten genommen 


Probleme beim Einfügen 

● Ich bin der erste Peer mit einem bestimmten Präfix 

● Dann müssen potentiell alle Knoten im Netz mich 

kennenlernen 

● Es lernen mich aber nur Teile des Netzwerkes kennen 

● Der Rest wird über den Reparaturmechanismus erledigt, 

korrektes Leaf‐Set erlaubt langsames aber korrektes 

Routing. 

Für korrektes Routing wird nur ein korrektes Leaf‐Set benötigt. 

Nur beim Leaf‐Set wird aktiv geprüft, 

ob Peers noch anwesend sind. 


● Auffüllen der Routing‐Tabelle: 

Ausfall eines Knoten 

● Um einen Eintrag R[l, d] zu ersetzen, wird zunächst ein 

Knoten R[l, i], i != d, gefragt. g Wenn dieser einen passenden 

Eintrag hat, wird er genommen. 

● Wenn nicht, wird ein Knoten R[l+1, i], gefragt, g etc. 

● Mit hoher Wahrscheinlichkeit wird so ein Knoten gefunden, 

der die Tabelle auffüllen kann 


Ausfall eines Knotens 

● Wenn ein toter Knoten im LeafSet bemerkt wird: 

● Kontaktiere den äußersten lebendigen Knoten im LeafSet, 

um das LeafSet wieder aufzufüllen 

Mein LeafSet 

Dieser Knoten 

füllt mein 

LeafSet auf 

‐4 ‐3 ‐2 ‐1 0 +1 +2 +3 +4 +5 +6 +7 +8 

LeafSet von 

Knoten 4 


Messungen 

● Hop‐Anzahl: 

● Parameter b=4, L=16 

● also log(N) = log 16 (N) 

● Gute Übereinstimmung Analyse / Messungen 

Quelle: Antony Rowstron and Peter Druschel: 

Pastry: Scalable, decentralized object location 

and routing for large‐scale peer‐to‐peer systems 


Messungen 

● Abweichung von der Hop‐Distanz: 


Pastry: Scalable, decentralized object location and routing for large‐scale peerto‐peer 

systems 

● Geringe Abweichung von erwarteter Hop‐Distanz 


Messungen 

● Messung des sog. Stretch: Verhältnis zum optimalen Routing 


Pastry: Scalable, decentralized object location and routing for large‐scale peerto‐peer 

systems 

● Latenz nur ca. 40% langsamer als direktes Internet‐Routing 


Routing Geschwindigkeit 

● Für die Reihe 0 gibt es pro Feld N/2 b Möglichkeiten 

● D.h. die Wahrscheinlichkeit, einen nahen Knoten zu finden, ist hoch 

● Für Reihe 1 gibt es pro Feld N/2 2b Möglichkeiten 

● Für Reihe 2 gibt es pro Feld N/2 3b Möglichkeiten 

● … 

● Für den Nachbarn im LeafSet gibt es nur eine Möglichkeit sehr weit 

entfernt 

● Daraus folgt: 

■ Die ersten Schritte Shitt sind dbillig 

■ Die letzten Schritte sind teuer 

Mehr Schritte sind nicht viel teurer, da die 

teuren Schritte immer anfallen! 


● Qualität der Routing‐Tabellen 

Messungen 


Pastry: Scalable, decentralized object location and routing for large‐scale peer‐ 

to‐peer systems 

b=4, L=16, 5.000 Knoten 


Messungen 

● Knotenausfall: von 5000 Knoten fallen 500 aus 


Pastry: Scalable, decentralized object location and routing for large‐scale peer‐ 

to‐peer systems 


Vergleich Tapestry/Pastry 

● Basieren beide auf Prefix‐Routing 

● Pastry 

■ "Lockeres Verfahren": Routing‐Tabellen müssen nicht korrekt 

sein 

■ Leaf‐Set reicht zum korrekten Routing 

■ Tabellen nur zur Beschleunigung 

■ In der Praxis besser einsetzbar 

● Tapestry 

■ Routing‐Tabellen werden immer korrekt gehalten 

■ Dadurch beweisbare Eigenschaften 

■ Daher theoretisch interessant 


Vorlesung 

P2P Netzwerke 

6: Kademlia 




berlin de


Einleitung 





• Napster 

• Gnutella 













Anwendungen 



• Amazon 

• Multicast 


Kademlia 

● Kademlia 

■ Petar Maymounkov and David Mazierès: "Kademlia: A Peerto‐peer 

information System Based on the XOR Metric", 1st 

International Workshop on Peer‐to‐peer Systems, 2002 


Kademlia 

● Populäre DHT (muTorrent, Ktorrent, Vuze, BitTorrent, 

Cspace, eDonkey 2000, MLDonkey, … siehe Wikipedia) 

● Geringer Wartungsaufwand für konsistente Routing 

Tabellen 

● Knoten haben genügend g Informationen und Flexibilität um 

Low‐Latency Pfade zu wählen 

● Parallele, asynchrone Anfragen, um Verzögerungen g durch 

Timeouts zu umgehen 

● Sehr Robust (u.A. gegen gg gewisse Denial of Service Angriffe) 


XOR Metrik 

● Distanz d(A, B) = A ⊕ B 

0 

1 

0 

1 0 

1 

0 1 0 1 0 1 0 

1 

000 001 010 011 100 101 110 111 

010 

100 

110 = 4 + 2 = 6 


XOR Metrik 

● Eigenschaften: 

■ d(X,X) = 0 

■ d(X,Y) = 0 → X=Y 

■ d(X,Y) = d(Y,X) → Anfragen kommen von Knoten, die in Routing Tabelle Tbll 

stehen können (→ Verbessern der Tabellen) 

■ d(X,Y) ≤ d(X,Z) + d(Z,Y) (,) 

■ Zu jedem Knoten gibt es genau einen Knoten mit Distanz d 

→ Routingpfade konvergieren am Ende 

→ Caching möglich 

■ Knoten im gleichen Unterbaum 

0 

1 

sind nah beieinander 0 1 0 1 

0 1 0 1 0 1 0 1 

000 001 010 011 100 101 

110 111 


Routing Tabelle 

000… 

1… 

0010… 

01… 

Quelle: Kademlia: A Peer‐to‐peer Information System Based on the XOR Metric 

Petar Maymounkov and David Mayières 



● Jeder Knoten kennt mindestens einen Knoten in jedem 

Unterbaum, sofern dieser Unterbaum einen Knoten enthält. 

● Knoten Id: 011001010011001 

● Unterbaum i: 01101… 

Präfix der 

Länge i 

(i+1)‐tes 

Bit geflippt 


Routing Beispiel 

● Routing von 0011… nach 1110… 






k‐Buckets 

● Ein k‐Bucket für jede Präfixlänge 0≤i

k‐Buckets 

● Bevorzugung alter Knoten verbessert Stabilität 

ne) 

noch onlin 

P(bei t + 60 n 

Knoten ist t Minuten online 




Nachrichten 

● PING 

■ Testet ob Knoten online ist 

● STORE 

■ Speichert Datum bei Knoten 

● FIND_NODE(160 NODE(160 Bit ID) 

■ Liefert die k nächstgelegenen bekannten Knoten 

(bezüglich XOR Metrik!) 

■ Aus einem k‐Bucket, wenn dieser voll ist; sonst aus mehreren 

● FIND_VALUE 

■ Wie FIND_NODE, aber liefert den Wert, wenn er bekannt ist 


Routing Protokoll – Single‐Threaded 

1 p.lookup(T) 

2 N = PriorityQueue(maximale Länge k) 

3 N.add(α nächste Knoten) 

4 solange nicht alle Knoten aus N erfolgreich gefragt: 

5 k = nächster, nicht gefragter Knoten aus N 

6 N' = k.FIND_NODE(T); 

7 wenn N' = {}: // Fehler 

8 lösche k aus N 

9 sonst: 

10 N = k nächste Knoten aus N und N' 

11 wenn N weniger als k Knoten enthält: 

12 markiere alle Knoten als ungefragt, goto 3 

13 liefere nächsten Knoten aus N 


Routing Protokoll –Multi‐Threaded 

(wie ich es implementieren würde ‐ Paper sehr ungenau) 

1 p.lookup(T) 

p( 2 N = PriorityQueue(maximale Länge k) 

3 N.add(α nächste Knoten) 

4 solange nicht alle Knoten aus N erfolgreich gefragt: 

5 warte, bis weniger als α Anfragen ausstehen 

6 p' = nächster, nicht gefragter Knoten aus N 

7 sende FIND_NODE(T) an p' 

8 wenn N weniger als k Knoten enthält: 

9 markiere alle Knoten als ungefragt, goto 3 

10 liefere nächsten Knoten aus N 

1 On FIND_NODE Time Out (k): 

2 Lösche k aus N 

1 On FIND_NODE Answer (k, N'): 

2 N = nächste k Knoten aus N und N' 


Routing Protokoll –Multi‐Threaded 

● Häufig α = 3 (sozusagen die Anzahl Worker Threads) 

● Geringere Latenz für höheren Netzwerkverkehr getauscht 

● Bevorzugt Routing durch Knoten mit geringer Latenz 

● Vermindert Verzögerungen, wenn Knoten offline gegangen 

sind 

● Korrektheit: s. Paper 


Datenspeichern 

● Store(key, value) 

■ Ermittle k nächste Knoten 

■ Sende STORE an jeden dieser Knoten 

● Softstate 

■ Neueinfügen jede Stunde 

● Lookup 

■ FIND_VALUE statt FIND_NODE 

■ Daten werden beim zuletzt gefragten Knoten, der sie nicht 

speicherte, repliziert 

■ Lebenszeit des Replikats: exponentiell antiproportional zu 

Anzahl Knoten zwischen aktuellem und zur ID nächsten 

Knoten 


Join 

● Neuer Knoten u kennt Knoten w 

● u fügt w in entsprechenden k‐Bucket ein 

● u macht Lookup nach sich selbst und gewinnt neue Knoten 

● u wählt sich zufällige IDs in leeren k‐Buckets und routet 

dorthin 

● Während dieser Vorgänge fügt sich u automatisch in k‐ 

Buckets bei anderen Knoten ein. 


Implementierungs Details 

● Pings werden nicht wirklich wie beschrieben verschickt (es 

wären zu viele) 

■ Pings werden verzögert, bis sinnvolle Nachricht geroutet 

werden muss 

■ Ein Replacement Cache hält Knoten, die ausgefallene Knoten 

kompensieren können 

● Statt Binärbaum: 2 b ‐ärer Baum, reduziert Tiefe 



● In echten Netzen erprobt 

● Robust 

● Logarithmisches Routing 

● Neuer Aspekt: Nebenläufige Anfragen 


Ranking nach scholar.google.com 

Netzwerk 

Chord (2001+2003) 7606 

CAN (2001) 5204 

Pastry (2001 + 2001) 5338 

Tapestry (2001) 1927 

Kademlia (2002) 929 

Referenzen nach scholar.google.com 


Vorlesung 

P2P Netzwerke 

7: Gradoptimierte Netzwerke 




berlin de


Einleitung 





• Napster 

• Gnutella 













Anwendungen 



• Amazon 

• Multicast 


Inhalt 

● Gradoptimierte Netzwerke (Überblick) 

■ Viceroy 

■ Distance Halving 

■ Koorde 


Grad vs. Durchmesser 

● Bisher meist O(log N) Grad und O(log N) Durchmesser 

● Geht der Grad kleiner, ohne den Durchmesser zu erhöhen? 

Grad 

g, 

Durchmesser 

d, 

Knotenanzahl 

N 

Nach 

Mit 

d 

x Hops erreiche ich maximal g 

Knoten 

Hops erreiche ich jeden Knoten im Netz 

x 

Also : g 

d 

= N 

Nach d aufgelöst :log( g d ) = log( N),d.h. 

d = 

log( 

N 

) 

log( g) 

Es folgt : mit g = log(N) ist bester Durchmesser d = 

log(N) 

log(log(N)) 

Mit konstantem Grad ist aber ein logarithmischer Durchmesser möglich! 


Netzwerke mit konstantem Grad 

● Viceroy: 

■ Dalia Malkhi, Moni Naor and David Ratajczak: "Viceroy: A 

Scalable and Dynamic Emulation of the Butterfly", ACM 

Symp. Principles of Distributed Computing, 2002 

? 


Viceroy 

● Idee: Butterfly‐Graph als Basis für P2P Netzwerke nehmen 

■ Resultiert in einem Netz mit konstantem Grad 

■ Ist aber ein relativ kompliziertes Verfahren 

● Interessante "Abfallprodukte": 

■ Wie schätze ich log(N)? 

■ Wie stelle ich besser verteilte Intervalle her? 

♦ Speziell: Maximal konstante Abweichung, also z.B. Länge des 

größten Intervalls ist max. 4 mal die Länge des kleinsten 

Intervalls 

♦ Lösung: Prinzip der mehrfachen Auswahl 


Butterfly‐Graphen 

Level 3 

Level 2 

Level 1 

Level 0 


Viceroy Verbindungsstruktur 

● Ein Ring mit allen Knoten 

■ successor, predecessor 

● Ein Ring pro Level 

■ nextonlevel, l prevonlevel 

l 

● Butterfly‐Kanten 

■ left: succ(l+1, s) 

■ right: succ(l+1, s+1/2 l ) 

■ up: succ(l‐1, s) 

● Notation: 

■ succ(s) ist Nachfolger von s 

in allgemeinem Ring 

■ succ(l, s) ist Nachfolger von 

s auf Level l Ring 

Quelle: Dalia Malkhi, Moni Naor and David Ratajczak: 

"Viceroy: A Scalable and Dynamic Emulation of the Butterfly" 


Routing in Viceroy 

● cur: Aktueller Knoten, x: Ziel 

● Routing in 3 Phasen 

● Phase 1: Gehe zu Level 1 

■ Solange dem up‐Pointer folgen, bis cur.level = 1 

● Phase 2: Nutzung der Butterfly‐Kanten 

■ Wenn der right‐Pointer existiert und nicht zu weit zeigt 

♦ Folge dem right‐Pointer 

■ Wenn der lf left‐Pointer existiert 

♦ Folge dem left‐Pointer 

■ Sonst mache mit Phase 3 weiter 

● Phase 3: Auf dem Ring suchen 

■ Folge dem successor‐Pointer, bis Ziel erreicht 


Knotenankunft 

● Wähle eine ID s zufällig 

● In allgemeinen Ring einfügen 

■ Suche per Routing succ(s) 

■ Passe Zeiger an (succ, pred, succ.pred, pred.succ) 

● Levelauswahl 

■ N0 = 1/distanz(s,succ(s)) ‐‐ Schätzung der Anzahl Knoten im Netz 

■ Wähle einen Level l aus [1,…,floor(log N0)] uniform zufällig 

● In Level‐Ring einfügen 

■ Schrittweise Suche über allgemeinen Ring 

■ Passe Zeiger an (nextonlevel, predonlevel, etc.) 

● Butterfly‐Kanten einfügen 

■ up := succ(l‐1, s) (Single‐Stepping) 

■ left := succ(l+1, s) (Single‐Stepping) 

■ right := succ(l+1, s+(1/2 

l+1 ) (Lookup, dann Single‐Stepping) Stepping) 


Abschätzung von log(N) 

● Sei d der Abstand zum Nachbarn 

● Wenn d=1/N, gilt log(N)=‐log(d) 

● Es gilt aber nur: 

■ 1/N 2 ≤ d ≤ log(N)/N mit hoher Wahrscheinlichkeit 

● Betrachte ‐log(d): 

■ Wenn d = 1/N 2 , dann ist ‐log(d) = ‐log(N ‐2 ) = 2log(N) 

■ Wenn d = log(N)/N, dann ist ‐log(d) = ‐log(log(N)*N ‐11 ) = 

log(N)‐log(log(N)) 

● Daher gilt: 

■ 2log(N) ≥ ‐log(d) ≥ log(N) ‐ log(log(N)) 

■ Also ist ‐log(d) eine gute Abschätzung für log(N) 


Prinzip der mehrfachen Auswahl 

● Problem: wie erreiche ich konstanten Ein‐Grad? 

● Dazu müssen die Intervalle besser angepasst sein 

● Bisher: Abweichungen sind: 

■ um Faktor N kleiner 

■ um Faktor log(N) größer 

● Ziel: 

■ Kleinstes Intervall ist 1/2N, größtes ist 2/N 

■ Also Abweichung um max. Faktor 4 (konstant) 

● Lösung: mehrfache Auswahl 

■ Wähle bei der Knotenankunft zufällig ceil(log(N)) IDs 

■ Positioniere den Knoten in der Mitte des größten Intervalls 



● Distance Halving: 

■ Moni Naor, Udi Wieder: "Novel Architectures for P2P 

Applications: the Continuous‐Discrete Approach", SPAA 2003 


Distance Halving 

● ID‐Bereich ist Intervall [0,1) 

● Diesmal nicht zyklisch! 

● Jeder Knoten bekommt ein Intervall nach dem Prinzip der 

mehrfachen Auswahl zugewiesen 

■ Also hat jeder Knoten ein Intervall der Größe 

1/2N ≤ I ≤ 2/N 

● Sei das Intervall des Knotens [I1, I2) 

● Für jedes I aus [I1, I2) hat der Knoten Zeiger auf 

I/2 sowie (1+I)/2 

● Es werden auch die Rückwärtskanten verwaltet! 

● Damit ist sowohl der Ein‐Grad aus auch der Aus‐Grad 

konstant! 


Distance Halving 

I1/2 = 0.15 

I2/2 = 0.2 02 

(1+I1)/2 = 

0.65 

(1+I2)/2 = 

0.7 

0 

I1=0.3 I2=0.4 

K2 K3 Intervall von 

K4,K5,K6 

Knoten K1 

Routing‐Tabelle Tbll von K1 enthält Kanten zu jd jedem 

Peer in den Ziel‐Intervallen, plus die Rückwärts‐ 

Kanten. Dies ergibt einen konstanten Grad! 

1 


Routing in DH 

● Wie erreiche ich vom Knoten I=[I1, I2) eine ID, die im 

Intervall von Knoten J=[J1, J2) liegt? 

● Verfolge die Links‐Kanten beider Knoten: 

■ I trifft auf I1, I1/2, I1/4, I1/8, … 

■ J trifft auf J1, J1/2, J1/4, J1/8, … 

● Irgendwann liegen beide Zeiger in einem Intervall: 

O.B.d.A. sei J 

1 

> I1 

J1 

Gesucht ist ein k mit : 

k 

2 

k 

J1 

− 

I 

1 

2 

2 

⇔ ≤ ⇔ 

k 

2 N J − I 

I1 

2 

− ≤ (maximale Intervallgröße) 

k 

2 N 

N 

k 

J 

1 

− 

I 

1 

≥ ⇔ 2 ≥ N ⇔ 

k ≥ 

log( 

N 

2 

2 

1 J 

1 

− 

I 

1 

Ab diesem k sind beide Pointer auf 

O(log N) Schritte benötigt! 

1 

1 

dem gleichen Knoten. D.h.es 

2 

) 

werden max. 


Routing in DH 

Start 

Ziel 

Dieses Verfahren kann zu Überlast auf den vorderen Knoten 

führen! 

Gibt es noch alternative Wege? 


Routing in DH 

1 Left‐Routing(Start, Ziel) 

2 if Start und Ziel benachbart then 

3 Leite Nachricht von Start nach Ziel 

4 else 

5 Neuer‐Start = Links‐Zeiger(Start) 

6 Neues‐Ziel = Links‐Zeiger(Ziel) 

7 Sende Nachricht von Start nach Neuer‐Start 

8 Left‐Routing(Neuer‐Start, Neues Ziel) 

9 Sende Nachricht von Neues‐Ziel nach Ziel 


Alternative Routen 

● Beobachtung: 

■ I/2‐J/2 = (I‐J)/2 

■ (1+I)/2‐(1+J)/2 ( ) = (I‐J)/2 

● D.h., egal ob ich einen Doppel‐Sprung nach Links oder nach 

Rechts mache: 

■ Die Restdistanz wird immer halbiert 

● Daher: 

■ Zur Lastbalancierung wird die Reihenfolge zufällig bestimmt 

■ zB:Recht z.B.: – Links – Links – Rechts – Links etc. 



● Koorde: 

■ M. Frans Kaashoek, David R. Karger: "Koorde: A simple 

degree‐optimal distributed hash table", Proceedings of the 

2nd International Workshop on Peer‐to‐Peer Systems (IPTPS 

'03), 2003 


Koorde 

● Betrachte folgende Operationen auf Bit‐Strings: 

■ Shuffle: Bits um eine Stelle zyklisch rotieren 

■ Shuffle‐Exchange: Bits um eine Stelle zyklisch rotieren, dabei 

ein Bit invertieren 

Shuffle 

Shuffle‐Exchange 

h 

1 0 1 1 0 1 0 1 1 0 1 1 0 1 0 1 

Exchange 

0 1 1 0 1 0 1 1 

0 1 1 0 1 0 1 0 


Koorde 

Jd Jede Bitfolge kann über 

Shuffle (‐Exchange) Operationen 

in jede andere Bitfolge übersetzt 

werden 

Quelle: Mahlmann, Schindelhauer 

Peer‐to‐Peer Netzwerke 


Der DeBruijn Graph 

SE 

100 

S 

S 

000 001 

SE 

SE 

S 

010 101 

SE 

S 

S 

S 

011 110 

SE 

SE 

SE 

111 

Der Graph ist verbunden und hat 

konstanten Ein‐ und Ausgrad! 


DeBruijn Graph als P2P Netz 

● Knoten werden auf Ring angeordnet (wie Chord) 

● Statt Chord‐Fingerzeigern werden DeBruijn‐Kanten 

eingesetzt 

000 

111 

001 

110 

010 

101 

011 

100 


Imaginäre Knoten 

● Peer‐to‐Peer Netzwerke haben selten genau 2 m Knoten 

● Im Beispiel m=4 ist Netz schon bei 16 Knoten voll 

● Daher m=128 oder m=160 

● Sei n tatsächliche Knotenanzahl im Netz, dann gibt es 

2 m – n virtuelle Knoten 

● Kanten auf virtuelle Peers werden auf vorangehenden 

echten Knoten umgebogen (dies ist der für den virtuellen 

Peer verantwortliche Knoten) 

● Äquivalent: Jeder Peer ist für die nachfolgenden virtuellen 

Peers zuständig 


Wohin zeigen die DeBruijn‐Kanten? 

Shuffle mit führender 0 Shuffle mit führender 1 

0 0 1 1 0 1 0 1 1 0 1 1 0 1 0 1 

0 1 1 0 1 0 1 0 

0 1 1 0 1 0 1 

ergibt (2*x) 

ergibt (2*x+1) mod 2 m 

1 

SE mit führender 0 SE mit führender 1 

0 0 1 1 0 1 0 1 1 0 1 1 0 1 0 1 

0 1 1 0 1 0 1 

1 

0 1 1 0 1 0 1 

0 

ergibt (2*x+1) 

ergibt (2*x) mod 2 m 


Wohin zeigen die DeBrujin‐Kanten? 

● Mit hoher Wahrscheinlichkeit zeigen 

2*x mod 2 m 

und 

2*x + 1 mod 2 m 

auf den selben realen Knoten. 

● Daher nur eine DeBrujin Kante pro Knoten 


Routing 

● Jeder Knoten p kennt 

■ Vorgänger 

■ Nachfolger 

■ Knoten 2*p mod 2 m , bzw. Knoten, der dafür verantwortlich ist 

● Datenzuordung wie bei Chord (Datum bei Nachfolger von ID 

gespeichert) ih ● Routing zwischen 2 m wird auf reale Knoten abgebildet 

■ Route über DB DeBrujin Kanten zu nächstem äht Knoten 

■ Erreichen in jedem Schritt Knoten, der für entsprechenden 

imaginären Knoten zuständig ist, oder 

■ Landen vor Knoten, der für entsprechenden imaginären 

Knoten zuständig ist, dann auf Ring Nachricht weiterleiten 


Routing in Koorde 

1 n.lookup(k, kshift, i) 

2 if k in (n, successor] 

3 return successor; 

4 else if i in (n, successor] then 

5 return d.lookup(k, (kshift o 0) mod 2^m, 

(i o topBit(kshift)) mod 2^m) 

6 else 

7 return successor.lookup(k, kshift, i) 

Erklärungen: 

n 

Aktueller Knoten 

k 

Key, zu dem geroutet wird 

successor Nachfolger von n auf dem Ring 

d 

Vorgänger von 2n (DeBruijn‐Kante) 

i 

Imaginärer DeBruijn‐Knoten 

kshift Anfangs kshift=k, dann immer weiter geshiftet 


Imaginärer Startknoten 

● Routing‐Schritte bisher: 

■ Anzahl Bits im Identifier (m) 

■ plus Anzahl successor‐Schritte 

● Wie erreiche ih ihl ich log(N) (N)Routing? 

● In der Wahl des imaginären Startknotens habe ich Freiheiten: 

■ die unteren Bits können frei gewählt werden 

■ Ich kann sie an die oberen Bits des Schlüssels anpassen: 

durch n vorgegeben 

frei 

i 

0 0 1 1 0 1 0 1 

k 

1 0 1 0 1 1 1 0 


Koorde 

0 15 1 

14 2 

13 3 

12 

4 

11 

5 

10 

6 

9 

8 

7 


Koorde 

0 15 1 

14 2 

13 3 

12 

4 

11 

5 

10 

6 

9 

8 

7 


Koorde 

0 15 1 

14 2 

13 3 

12 

4 

11 

5 

10 

6 

9 

8 

7 


Koorde 

15 0 1 Route von 13 nach 12: 

12 

14 2 

13 3 

4 

Quelle kann sein: 

1101 (13) 

1110 (14) 

Ziel ist 

1100 (12) 

11 

10 

5 

Imaginäre Route: 

1110 ‐> (SE) ‐> 1100 

14 ‐> 12 

6 

Tatsächliche Route: 

9 7 

13 ‐> 9 ‐> 11 (‐> 13) 

8 



● Gradoptimierte Netze: 

■ Bei Grad O(1) ist Durchmesser O(log(N)) erreichbar! 

● Ansätze: 

■ Viceroy: Butterfly‐Graph simulieren 

■ Distance Halving: Distanz in jedem Schritt halbieren 

■ Koorde: DeBruijn‐Graph simulieren 

● Bewertung: 

■ Interessante Ansätze, in der Praxis nicht erprobt 

■ Stabilisierung, Lokalität etc. schwierig bzw. nicht erforscht 

■ Höherer Grad für Zusammenhalt durchaus wünschenswert 

● "Abfallprodukte": 

■ Schätzung von log(N) 

■ Prinzip der mehrfachen Auswahl 


Vorlesung 

P2P Netzwerke 

8: SkipNet, P‐Grid 




berlin de

SkipNet 

● Nicholas J.A. Harvey, Michael B. Jones, Stefan Saroiu, 

Marvin Theimer, Alec Wolman: "SkipNet: A Scalable Overlay 

Network with Practical Locality Properties", Proceedings of 

USITS, 2003 

? 

● James Aspnes, Gauri Shah: "Skip Graphs" , Fourteenth 

Annual ACM‐SIAM Symposium on Discrete Algorithms, 

2003, pp. 384–393 

● William Pugh: "Skip Lists", Commun. ACM, 33:6, pp. 668‐ 

676, 1990 


Probleme mit DHTs 

● DHTs "zerhacken" die Daten (wie normale Hash‐Tabellen 

auch) 

● Daten "Meyer" und "Meier" landen auf völlig 

unterschiedlichen Knoten 

● Daher sind keine Bereichsanfragen möglich (z.B.: Alle Daten 

die mit "M" beginnen) 

● Eine Lösung dafür: SkipNet 

● SkipNet basiert auf der Idee der Skip‐Graphen, die 

wiederum auf Skip‐Listen basieren 


3

Skip‐Listen 

● Ausgangspunkt: Verkettete Liste, aufsteigend sortiert 

● Hier: direkt zu einem Ring verbunden 

● Suche ist in nur in linearer Zeit möglich 

● Zur Beschleunigung: Weiter entfernte Listenelemente 

"verzeigern" 

A C D G I L X 


Skip‐Listen 

● Elemente bekommen eine zufällige Höhe 

● Zusätzliche Verzeigerung in jeder Höhe 

A 

I 

A 

D 

I 

X 

A C D G I L X 


Skip‐Listen 

● Skip‐Liste als P2P Netzwerk? 

● Jedes Listenelement ist ein Knoten? 

● Wie route ich von C nach X? 

● Probleme: Knotenausfälle, Last 

A 

I 

A 

D 

I 

X 

A C D G I L X 


Skip‐Listen Skip‐Graphs 

● Idee: Durch weitere Verbindungen Zusammenhang stärken 

Höhe 

4 

A L 

3 

G C A L D 

2 

C 

G 

A D L I X 

1 

A C D G L I X 

0 

A C D G I L X 


Routing 

1 // route a msg by name ID 

2 RouteByNameID(msg) 

3 h = localNode.maxHeight 

4 while h >= 0 

5 nbr = localNode.RouteTable[h] 

l 6 if nbr.nameID in [localNode.nameID, msg.nameID] 

7 SendToNode(msg, nbr) 

8 return 

9 h = h ‐ 1; 

10 // h

Skip‐Net: Num‐ID 

A L 

0 1 

C G A L D 

0 1 0 

0 

1 

0 1 

0 0 1 1 0 

1 0 1 0 0 1 1 

0 0 0 0 1 0 1 

A C D G I L X 

C 

G 

A D L 

I 

X 

0 0 1 

1 

1 

0 1 

A C D G L I X 

0 0 0 0 

0 1 

1 

A C D G I L X 


In welche Ringe wird ein Knoten 

aufgenommen? 

● numID eines Knotens bestimmt die Ring‐Teilnahme 

● Zufällige Bitfolge (128 Bit) 

● Wird beim Start vom Knoten ausgewürfelt 

● Wie findet der Knoten die Ringe? 

■ Ein Knoten des Netzwerkes muss bekannt sein 

■ Dieser wird kontaktiert 

■ Über eine Nachricht wird ein Knoten gesucht, dessen numID 

möglichst weit mit der des neuen Knotens übereinstimmt 

■ Routing nach numID 


Routing nach numID 

● A will an 0111 routen 

Höhe 

4 

A 

L 

3 

000 001 010 011 

G C A L D 

2 

1 

00 

C G 

01 

A D L 

10 

I 

11 

X 

0 

A C D G L 

1 

I X 

0 

A C D G I L X 



● Statusinformationen: 

■ ringLvl (Anfangswert 0) 

♦ Auf welchem Level bewegt sich die Nachricht? 

■ startNode (Anfangswert nil) 

♦ Bei welchem Knoten begann der Durchlauf im aktuellen Ring? 

■ bestNode (Anfangswert nil) 

♦ Welcher Knoten ist der bisher dichteste? 

■ finalDestination (Anfangswert false) 

♦ Hat die Nachricht bereits den Zielknoten erreicht? 



1 // route msg via numeric ID 

2 RouteByNumericID(msg) 

3 if msg.numID == localNode.numID || msg.finalDestination 

4 DeliverMessage(msg) 

5 return 

6 if localNode == msg.startNode 

7 msg.finalDestination = true 

8 SendToNode(msg.bestNode) 

9 return 

10 h = CommonPrefixLen(msg.numID, localNode.numID) 

11 if h > msg.ringLvl 

g 

12 msg.ringLvl = h 

13 msg.startNode = msg.bestNode = localNode 

14 else if |localNode.numID‐msg.numID| < 

|msg.bestNode.numID‐msg.numID| 

15 msg.bestNode = localNode 

16 nbr = localNode.RouteTable[msg.ringLvl] 

17 SendToNode(nbr) 


IDs in SkipNet 

● Jeder Knoten hat eine Name‐ID und eine Num‐ID 

● Die Name‐ID ist frei wählbar, die Num‐ID ist eine gewürfelte 

Bitfolge 

● Die Name‐ID bestimmt die Reihenfolge im Root‐Ring 

● Die Num‐ID bestimmt, in welchen Ringen auf höheren 

Ebenen der Knoten partizipiert 

● Routing ist über beide IDs möglich 

● Name‐IDs können ungleich verteilt sein 


Hinzufügen von Knoten 

● Über bekannten Knoten wird Nachricht an die Num‐ID des neuen 

Knotens geschickt 

● Dieser kennt alle Ringe, in die der neue Knoten eingefügt wird 

● Einfügen von Oben nach unten 

1 While ( current Level > 0 ) 

2 If Name Id between current Node and next on level 

3 Insert between; 

4 current level = current level – 1; 

5 Else 

6 Forward to next node on current level 

● Aber: Die Nachbarn werden zunächst nur aufgesammelt 

● Am Ende wird in einer Operation überall der Insert durchgeführt 


Stabilisierung des Root‐Rings 

● Im Root‐Ring Liste von x Nachfolgern sammeln (z.B. x=8) 

● Wenn der Nachfolger ausfällt, ist der neue Nachfolger 

bekannt 

● Neuer Nachfolger wird über seinen neuen Vorgänger 

informiert 

● Liste der Nachfolger wird jeweils an den Vorgänger 

weitergegeben gg 


Stabilisierung der höheren Ringe 

● In den höheren Ringen ist nur jeweils ein Nachfolger 

bekannt 

● Wenn dieser ausfällt, ist der Ring zunächst defekt 

● Routing ist trotzdem möglich 

■ wie? 

● Ein höherer Ring wird repariert, indem der neue Nachfolger 

im niedrigeren Ring gesucht wird 

● D.h., die Ringe werden nacheinander "von unten nach 

oben" repariert 

● Alternative: Auch in höheren Ringen mehrere Nachfolger 

speichern 


Aufwand 

● Routing nach name ID: 

■ O(log N) 

● Routing nach num ID: 

■ O(log N) 

● Intuition: 

■ Die Zeiger in der Routing‐Tabelle sind exponentiell verteilt, 

daher wird in jedem Schritt die Hälfte der restlichen Distanz 

übersprungen 



● SkipNet: Strukturiertes P2P Netzwerk ohne Hashing 

● Daten werden sortiert auf einem Ring abgelegt 

● Zur schnelleren Suche wird der Ring rekursiv in Teilringe 

aufgeteilt 

● Knoten haben eine Name‐ID und eine numerische ID 

● Suche ist nach beiden IDs möglich 

● Name‐ID Suche durchläuft die Ringe von oben nach unten 

● Num‐ID Suche durchläuft die Ringe von unten nach oben 


P‐Grid 

● Karl Aberer, Anwitaman Datta, Manfed Hauswirth, Roman 

Schmidt: "Das P‐Grid‐Overlay‐Netzwerk: Von einem einfachen 

Prinzip zu einem komplexen System", Datenbank‐Spektrum 13, 

2005 

● Karl Aberer: "P‐Grid: A Self‐Organizing gAccess Structure for P2P 

Information Systems", Sixth International Conference on 

Cooperative Information Systems (CoopIS 2001), Trento, Italy, 

Lecture Notes in Computer Science 2172, Springer Verlag, 

Heidelberg, 2001. 

● www.p‐grid.org 


P‐Grid 


■ Shlü Schlüssel lwerden nicht ih gehasht 

h 

■ Schlüssel werden auf binäre Zeichenketten abgebildet (ASCII‐ 

/Huffman‐Kodierung) 

■ Routing erfolgt über einen Binärbaum 

0 1 

0 1 0 1 

0 1 0 1 0 1 0 1 

0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 


Aufbau von P‐Grid 

0 1 

Buckets mit jeweils 

gleichen Datenmengen 

Zugeordnete Peers 

0 1 0 1 

0 1 0 1 0 1 

0 1 0 1 0 1 

0 1 0 1 


Routing in P‐Grid 

● Die ID eines Peers ist seine eindeutige Kennung im Netz 

■ Kennung hat nichts mit der Position im Baum zu tun 

● Die Position wird dynamisch festgelegt und verändert 

● Die Position nennt sich der Pfad des Peers 

● Der Pfad ist eine binäre Zeichenkette beliebiger Länge 

● Für jedes Präfix seines Pfades hat der Peer einen (oder 

mehrere) Zeiger auf andere Peers mit 

■ gleichem Präfix aber dann anderer Fortsetzung 

(0 → 1, 1 → 0) 

■ falls so ein Peer existiert 

● Woran erinnert das? 

● Wie funktioniert das Routing? 



Peer‐Identifikation 

Datenschlüssel 

1 : 2 Routing‐Tabelleneintrag 

0 1 

00 01 

2 1* 

0 : 1 

1 00* 

1 : 2 

01 : 3 

7 00* 

1 : 6 

01 : 8 

010 

011 

4 010* 3 011* 

1 : 2 

00 : 7 

011 : 3 

5 010* 

1 : 6 

00 : 1 

011 : 4 

8 011* 

6 1* 

0 : 3 

1 : 6 1 : 2 Quelle: K. Aberer, et al.: 

00 : 1 00 : 1 "Das P‐Grid‐Overlay‐Netzwerk: Von einem 

011 : 8 010 : 5 einfachen Prinzip zu einem komplexen System" 



● Präfixrouting wie bei Pastry / Tapestry 

● Pfade können aber beliebig lang werden 

■ Maximale Routingtabellen‐Größe garantiert nicht mehr 

O(log N) 

● Routing ist trotzdem schnell: 

■ Zufällige Knoten werden für Routingtabelleneinträge gewählt 

■ Es können häufig mehrere Bits in einem Schritt aufgelöst 

werden 

● Bereichsanfragen erlaubt 


Aufbau von P‐Grid 


■ Knoten sind über unstrukturiertes Netz verbunden 

■ Neuer Index (P‐Grid Struktur) wird über dieses Netz gelegt 

● Bootstrapping: t Baum nur mit Wurzel, alle Peers und alle Daten Dt 

befinden sich in der Wurzel 

● Rekursive Aufteilung: 

■ Solange genügend Peers in einem Bucket: 

■ Teile Bucket in zwei Hälften (0‐Pfad, 1‐Pfad) 

■ Verteile Peers zahlenmäßig entsprechend der Datenmengen 

● Dann dynamische Operationen 

■ Peers kommen und gehen 

■ Daten kommen und gehen 

■ hier nicht weiter betrachtet 



Strukturierte P2P Netze 

● 

● 

● 

● 

● 

Chord 

■ log(N)‐Routing bei bil log(N)‐Grad 

■ Intuitiv und einfach, gut zum Einstieg 

CAN 

■ Fülle Interessanter Ideen, aber 

polynomielles Routing 

Pastry, Tapestry 

■ Ähnlich zu Chord, berücksichtigen 

Lokalität kl 

■ Pastry: Praktisch gut einsetzbar, 

Tapestry: Theorie interessant 

Kademlia 

■ Fehlertollerant, parallele Lookups 

Viceroy, Distance Halving, Koorde 

■ Gradoptimierte Netze 

■ Interessante Ansätze, aber nicht 

praxistauglich 

■ Wichtige Abfallprodukte 

● 

● 

SkipNet 

■ Interessante Alternative zum 

Hashing, aber keine Lokalität 

P‐Grid 

■ Präfix‐Ansatz ohne Hashing, 

Lokalität könnte berücksichtigt 

werden 

■ Konzept des Bootstrappings eines 

Netzwerkes 



Strukturierte P2P Netze 

● 

● 

● 

● 

● 

Chord 

■ log(N)‐Routing bei bil log(N)‐Grad 

■ Intuitiv und einfach, gut zum Einstieg 

CAN 

■ Fülle Interessanter Ideen, aber 

polynomielles Routing 

Pastry, Tapestry 

■ Ähnlich zu Chord, berücksichtigen 

Lokalität kl 

■ Pastry: Praktisch gut einsetzbar, 

Tapestry: Theorie interessant 

Kademlia 

■ Fehlertollerant, parallele Lookups 

Viceroy, Distance Halving, Koorde 

■ Gradoptimierte Netze 

Hashing 

■ Interessante Ansätze, aber nicht 

praxistauglich 

■ Wichtige Abfallprodukte 

● 

● 

SkipNet 

■ Interessante Alternative zum 

Hashing, aber keine Lokalität 

P‐Grid 

■ Präfix‐Ansatz ohne Hashing, 

Lokalität könnte berücksichtigt 

werden 

■ Konzept des Bootstrappings eines 

Netzwerkes 

Kein 

Hashing 


Vorlesung 

P2P Netzwerke 

9: Lastverteilung 




berlin de


Einleitung 





• Napster 

• Gnutella 













Anwendungen 



• Amazon 

• Multicast 


Inhalt Lastbalancierung 

● Welche Last balancieren? 

● Balancierungseigenschaften von DHTs 

● Techniken: 

■ I: Replikation, Bereichsgrenzen ändern 

■ II: Power of Two Choices 

■ III: Virtuelle Peers 

■ IV: Relokation 

● Erkennung von Ungleichgewichten 

■ Schätzverfahren 

● Lastbalancierung in SkipNet 


Literatur 

● John Byers, Jeffrey Cosidine, Michael Mitzenmacher: 

"Simple Load Balancing for Distributed Hash Tables", 

Second International Workshop on Peer‐to‐Peer Systems, 

2003 

● André Höing: "Lastbalancierung von Speicherbedarf und 

Anfragen in BabelPeers", Diplomarbeit, Universität 

Paderborn, 2006 

● Prasanna Ganesan, Mayank Bawa, Hector Garcia‐Molina: 

"Online Balancing of Range‐Partitioned Data with 

Applications to Peer‐to‐Peer Systems", Proceedings of the 

30th VLDB Conference, 2004 


Lastverteilung 

● Welche Ressource ist das Problem? 

■ Ressourcen: 

♦ Netzwerklast: Bandbreitenverbrauch 

♦ Speicherlast: Festplattenverbrauch / Hauptspeicher 

♦ Rechenlast: Verbrauch von CPU‐Zyklen 

■ Netzwerklast und Rechenlast sind momentbezogen 

■ Speicherlast ist dauerhaft 

■ Welche Last das Problem ist, ist anwendungsabhängig 

● Was soll erreicht werden? 

■ Ist die ideale Lastverteilung die Gleichverteilung? 

■ Oder eher angepasst gp an die Leistungfähigkeit g des Knotens? 


Lastverteilung beim Routen 

● Muss jeder Peer in etwa die gleiche Anzahl Nachrichten 

weiterleiten? 

● Normalerweise durch die Symmetrie des Netzwerkaufbaus 

gegeben 

● Probleme evtl. bei: 

■ Viceroy: höheren Schichten evtl. mehr belastet 

■ Skip‐Listen als P2P‐Netzwerk (daher Skip‐Graphen) 

p ■ Super‐Peer Netzwerken 

● Wird von meisten P2P Netzwerken sichergestellt und hier 

nicht weiter betrachtet 


Lastbalancierung von DHTs 

● DHTs haben folgende Annahme: 

■ Die Bereiche der Knoten sind ähnlich groß 

■ Prinzip der mehrfachen Auswahl 

■ Die Hashfunktion liefert jede ID mit gleicher 

Wahrscheinlichkeit 

■ Damit sind die Daten "gleichmäßig" über die Knoten verteilt 

● Probleme: 

■ "gleichmäßig" heißt nicht, dass alle genau gleich viele Daten 

haben 

■ Nicht jeder Knoten kann gleich viel speichern 

■ Evtl. sind die Daten nicht gleichverteilt (andere Hashfkt) 

■ Hot‐Spots: Schlüssel mit sehr vielen Daten 


Ungleiche Last 

● Beispiel‐Verteilung: 

Anzahl 

Elemente 

bzw. Größe 

bzw. Abrufe 

P1 P2 P3 P4 P5 

ID‐Raum 



● Beispiel‐Verteilung: 

Anzahl 

Elemente 

bzw. Größe 

bzw. Abrufe 

P1 P2 P3 P4 P5 

ID‐Raum 



● Ziel ist nicht mehr, dass jeder Knoten einen gleichen Teil vom IDbk 

bekommt 

Raum 

● Sondern: Gleich viel Last! 

■ dh:großer d.h.: ID‐Raum mit wenig Last 

■ oder kleiner ID‐Raum mit großer Last 

● Problem allerdings: 

■ Hot‐Spots, d.h. Schlüssel mit sehr viel Last 

■ Diese können nicht aufgelöst werden, wenn nur die ID‐Bereiche 

verschoben werden 

● Lösungsansätze 

■ Schlüssel eindeutig machen Range‐Queries 

■ Vergleiche mit P‐Grid Lösung, bzw. mit SkipNet 

■ Lösungen in der Anwendung: z.B. Datei in Blöcke aufteilen 


● Bereichsgrenzen anpassen 

Techniken I 

■ Besonders belastete Bereiche verkleinern 

■ Unausgelastete Bereiche vergrößern 

■ Kann Hot‐Spots an einer ID nicht ausgleichen 

■ Schiebt "Last‐Wellen" um den Ring 

■ Daher: wenig ausgelastete Knoten neu Positionieren 

Anzahl 

Elemente 

bzw. Größe 

bzw. Abrufe 

P1 P2 P3 P4 P5 

ID‐Raum 


Techniken I 

● Replikation 

■ Systemweiter Replikations‐Faktor 

♦ z.B. jedes Datum auf 4 Knoten 

♦ "Glättet" die Speicherlast, aber erhöht sie 

♦ wird allerdings sowieso benötigt 

♦ Wenn bei Abfragen zufällig ein Replika‐Knoten ausgewählt wird, 

wird auch Bandbreite / CPU balanciert 

♦ Allerdings immer nur begrenzt 

■ Replikation auf Anfragepfaden bei häufigen Anfragen 

♦ hier nicht ihtweiter bt betrachtet htt 


Techniken II: 

Power of Two Choices 

● Idee: Verwende mehrere Hash‐Funktionen h 1 bis h d 

● Speichern eines Datums mit Schlüssel k: 

■ Kontaktiere parallel alle Peers h 1 (k) bis h d (k) 

■ Speichere das Dt Datum auf dem am wenigsten ausgelasteten t Peer 

■ Speichere auf allen anderen Peers Verweise zum Datum 

● Beim Abrufen eines Datums mit Schlüssel k: 

■ Wähle ein i aus [1,d] zufällig 

■ Kontaktiere Peer h i(k) 

● Es kann alles balanciert werden: 

Speicher, CPU, oder Bandbreite 

● Alternative: keine Verweise speichern, sondern alle Fragen 

● Wichtig: 

■ Wit Weiterleitung lit muss billiger als selber machen sein 


Techniken III: 

Virtuelle Peers 

● Jeder physische Knoten hat mehrere virtuelle Peers 

● Naiv: 

■ Wenn Last zu hoch: Stoppe einige der Peers 

■ Wenn Last zu klein: Starte t neue Peers 

● Gesteuert: freie Knoten suchen sich überlastete Knoten 

■ Knoten finden sich durch Random Walk oder Verzeichnisse 

● Vorteile: einfach zu realisieren 

● Nachteile: 

■ Verwaltungsaufwand beim Starten / Stoppen 

■ Netz wird virtuell größer und damit langsamer 

■ Der Grad erhöht sich. Bei log(N) virtuellen Peers wird der Grad 

eines reellen Peer log²(N) 

● Auch hier können individuelle Hot‐Spots nicht aufgelöst werden 


Techniken IV: 

Relokation 

Netzwerk 

Wurzelknoten 

≈ 50.000 Daten 

Kind 1 Level 1 Kind 2 Level 1 

≈ 25.000 Daten 

≈ 25.000 Daten 


≈ 12.500 Daten 

≈ 12.500 Daten 

Quelle: André Höing 


Techniken IV: 

Relokation 

Wurzelknoten 





Lasterkennung I 

● Grundsätzliches Problem: 

■ Globale Informationen schätzen, ohne jeden Knoten zu 

fragen 

● Woher weiß ein Knoten, ob er Überlast hat? 

■ Gleichverteilung der ID‐Bereiche erkennen: 

■ Jeder Peer speichert 50 Keys zufällig im DHT 

■ Wer >>50 Keyserhält, hat einen zu großen Bereich 

■ Wer

Lasterkennung II 

● Knoten versenden 

Lastinformationen an 

andere Knoten 

■ Anzahl Daten 

■ Verbrauchte Bandbr. 

■ Mittlere Wartezeit 

StatusQueue (SS) 

● SampleSize (SS) 

■ Samplegröße 

● SampleFactor (SF) 

■ Multiplikator 

● Überlastet, wenn 

■ myLoad > SF * 

otherLoad 



Lastbalancierung in SkipNet 

● Knoten N i ist für Daten 

im Bereich [R i‐1 , R i ) 

verantwortlich 

● Die Bereiche haben 

beliebige Größe 

● Wichtig ist, dass die 

Datenmenge 

ausgeglichen ist 

Last 

● Die Bereichsgrenzen R i N 1 N 2 N 3 N 4 N 5 N 6 N 7 N 8 N 9 

werden ständig 

angepasst 

R 0 R 1 R 2 R 3 R 4 R 5 R 6 R 7 R 8 R 9 



● Operation NeighborAdjust: 

● Zwei benachbarte Knoten passen ihre Bereichsgrenzen an 

Last 

Last 

N 1 N 2 N 3 N 4 N 5 N 6 N 7 N 8 N 9 N 1 N 2 N 3 N 4 N 5 N 6 N 7 N 8 N 9 

R 0 R 1 R 2 R 3 R 4 R 5 R 6 R 7 R 8 R 9 R 0 R 1 R 2 R 3 R 4 R 5 R 6 R 7 R 8 R 9 



● Operation Reorder: 

● Ein leerer Knoten sucht sich eine neue Position 

Last 

Last 

N 1 N 2 N 3 N 4 N 5 N 6 N 7 N 8 N 9 N 1 N 3 N 4 N 5 N 2 N 6 N 7 N 8 N 9 

R 0 R 1 R 2 R 3 R 4 R 5 R 6 R 7 R 8 R 9 R 0 R 1 R 2 R 3 R 4 R 5 R 6 R 7 R 8 R 9 


Verfahren 

● Iteratives Vorgehen 

● Wir starten mit leerem Netzwerk 

● Bei jeder Insert‐ und jeder Delete‐Operation wird eine 

Balancierung ausgeführt 

● Betrachte Schwellenwerte: 

■ T 1 =c, T 2 =2c, T 3 =4c, T 4 =8c, T 5 =16c, etc. 

■ Genau dann, wenn die Last einen Knotens über einen 

Schwellwert kommt, wird Balancierung angestoßen 


Algorithmus 

1 // Rufe nach insert eines Datums auf N i auf 

2 AdjustLoad(Node N i ) 

3 Sei L(N i ) = x in (T m , T m+1 ] // hier bestimmen wir m (!) 

4 Sei N j der weniger belastete von N i‐1 und N i+1 

5 if L(N j )

Beispiel 

T i‐1 i =2 , wir führen AdjustLoad nur aus, wenn m≥3, damit T m‐2 definiert ist 

T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 250 K1 500 K2 750 K3 

1000 


Beispiel 

Einfügen: 9, 115, 1, 11, 19 

T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 250 K1 500 K2 750 K3 

1000 

Liegen in (T m , T m+1 ] = (T 3 , T 4 ] → Prüfen ob Nachbar Last ≤ T m‐1 = T 2 hat → Ja → NbrAdjust 


Beispiel 

NeighborAdjust 

T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 19 K1 500 K2 750 K3 

1000 


Beispiel 

Einfügen: 0, 2 

T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 19 K1 500 K2 750 K3 

1000 


Beispiel 


T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 11 K1 500 K2 750 K3 

1000 


Beispiel 


T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 11 K1 500 K2 750 K3 

1000 


Beispiel 


T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 11 K1 115 K2 750 K3 

1000 


Beispiel 

Einfügen: 13, 432, 40 

T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 11 K1 115 K2 750 K3 

1000 

Liegen in (T m , T m+1 ] = (T 3 , T 4 ] → Prüfen ob Nachbar Last ≤ T m‐1 = T 2 hat → Nein 

Hat Knoten mit geringster g Last ≤ T m‐2 = T 1 Daten? → Ja 


Beispiel 

Reorder 

T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 11 K1 115 K3 115 K2 

1000 

K3 gibt gesamte Last an Nachbarn K2 ab, sortiert sich neben K1, 

übernimmt Hälfte der Last von K1 


Beispiel 

NeighborAdjust(K2) 

T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 11 K1 40 K2 115 K3 

1000 


Beispiel 


T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 11 K1 40 K2 115 K3 

1000 


Beispiel 


T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 11 K1 40 K2 137 K3 

1000 


Beispiel 


T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 11 K1 40 K2 137 K3 

1000 


Beispiel 

Keine Balancierung! 

T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 11 K1 40 K2 137 K3 

1000 

Liegen in (T m , T m+1 ] = (T 3 , T 4 ] → Prüfen ob Nachbar Last ≤ T m‐1 = T 2 hat → Nein 

Hat Knoten mit geringster g Last ≤ T m‐2 = T 1 Daten? → Nein 


Beispiel 

Einfügen: 26, 78, 41, 110, 679, 49: 

T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 11 K1 40 K2 137 K3 

1000 


Beispiel 


T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 11 K1 49 K2 137 K3 

1000 


Beispiel 

Einfügen: 7, 69, 163, 197, 506, 6, 3, 8, 182, 173, 416, 133, 42, 

108, 18, 56, 556, 123 

T5 

m=4 

T4 

m=3 

T3 

T2 

T1 

0 K0 11 K1 49 K2 137 K3 

1000 

Je größer die Bereiche, um so seltener Balancierung 



● Durch lokale Entscheidungen wird globale Balancierung 

erreicht 

● Durch Anpassen der Bereichsgrenzen wird neue Last 

passend einsortiert 

■ Solange das Lastprofil gleich bleibt! 

● Beweisbar gutes Verfahren 

■ Kosten sind max. O(X) bei X eingefügten g Daten 

■ Garantiert, dass min i {L(N i )} ≤ 8 * max i {L(N i )} + c 0 

● Problem beim P2P‐Einsatz: Wie finde ich den am wenigsten 

belasteten Knoten? 

■ Lösung: Zweite SkipGraph‐Struktur, Struktur, nach Last sortiert 


Quantifizierung von Last 

Ungleichgewicht 

Knoten 1 2 3 4 5 6 

Schritt 1: ermitteln der Last 3 2 5 3 1 2 

Schritt 2: sortieren 1 2 2 3 3 5 

Schritt 3: akkumulieren 1 3 5 8 11 16 

100% 

Last 

Lorenz‐Kurve 

0% 

0% Knoten 

100% 


Quantifizierung von Last 

Ungleichgewicht 

Knoten 1 2 3 4 5 6 

Schritt 1: ermitteln der Last 3 2 5 3 1 2 

Schritt 2: sortieren 1 2 2 3 3 5 

Schritt 3: akkumulieren 1 3 5 8 11 16 

100% 

Last 

Gini‐Index = 

0% 

Fläche unter Dreieck, 

0% Knoten 100% immer 0.5 



● Last‐Arten: CPU, Speicher, Bandbreite 

● Automatische Balancierung von DHTs 

● Techniken: 

■ I: Bereichsgrenzen ändern, Replikation 

■ II: Power of Two Choices 

■ III: Virtuelle Peers 

■ IV: Relokation 

● Erkennung von Ungleichgewichten 

● Lastbalancierungng in SkipNet nach Ganesan et al. 


Vorlesung 

P2P Netzwerke 

10: Multicast 




berlin de

Inhalt 

● Application‐Layer Multicast 

● Scribe 

● SplitStream 

● BitTorrent 


Multicast 

● IP Multicast ist eine tolle Idee, aber 

■ kaum unterstützt 

■ daher nicht praktisch einsetzbar 

● Alternativen? 

● Application‐Layer Multicast! 


Application‐Layer Multicast 

P1 

R1 R2 P2 P1 R1 R2 P2 

P4 R4 R3 P3 P4 R4 R3 P3 

Max Stress = 1 Max Stress = 3 

Avg Stretch = 1 Avg Stretch = 1 

P1 

R1 R2 P2 P1 R1 R2 P2 

P4 R4 R3 P3 P4 R4 R3 P3 

Max Stress = 1 

Avg Stretch = 2 

Max Stress = 2 

Avg Stretch = 1,33 


Scribe: Literatur 

[1] M. Castro, P. Druschel, A‐M. Kermarrec, A. Rowstron: 

"SCRIBE: A large‐scale and decentralised application‐level 

multicast infrastructure", IEEE Journal on Selected Areas in 

Communications (JSAC) (Special issue on Network Support 

for Multicast Communications), 2002. 

[2] M. Castro, P. Druschel, A‐M. Kermarrec, A. Nandi, A. 

Rowstron, A. Singh: "SplitStream: High‐bandwidth 

multicast li in a cooperative environment", OSP'03,Lake 

Bolton, New York, October, 2003. 


Scribe: Basis 

● Baut auf Pastry auf 

● Multicast‐Kommunikation in Gruppen 

● Jede Gruppe hat eine ID grpID 

● Der Root‐Knoten für grpID in Pastry verwaltet die Gruppe 

● Join von Knoten n: 

■ Sende Nachricht JOIN an grpID 

■ Jeder Knoten auf dem Weg überprüft, ob er in der Gruppe ist 

■ Falls ja: Füge n zur Kinder‐Liste für grpID hinzu 

■ Nachricht htwird idnur weitergeleitet, t wenn der Knoten noch 

nicht in der Gruppe war 

● Es wird dadurch ein Baum für jede Gruppe aufgebaut 


Scribe und SplitStream 

0100 

1111 

1100 

1101 

Root‐Knoten 

für grpID 

1001 

Subscriber 

Subscriber, auch wenn sie selbst nicht 

am Topic interessiert sind ("Forwarder") 

0111 

Quelle: [1] 


Scribe und SplitStream 

1111 

Subscriber 

0100 

1100 

1101 

Root‐Knoten 

für grpID 

1001 

Subscriber 

Subscriber, auch wenn sie selbst nicht 

am Topic interessiert sind ("Forwarder") 

0111 

Quelle: [1] 


Scribe: 

Verlassen einer Gruppe 

● Leave von Knoten n aus Gruppe grpID: 

■ Wenn Kinder‐Liste leer ist, route Leave‐Message Richtung 

Root‐Knoten 

■ Sonst Markiere Gruppe nur als "verlassen" 

● Wenn eine Leave‐Nachricht von einem Kind empfangen 

wurde: 

■ Lösche Kind aus Kinder‐Liste 

■ Wenn Kinder‐Liste leer ist, und der Knoten selbst nicht in der 

Gruppe ist: 

♦ Sende Leave‐Nachricht an Parent und lösche die Gruppe lokal 


Scribe: 

Senden einer Nachricht 

● Kanonische Lösung: 

■ Nachrichten werden immer zur Wurzel geschickt 

■ Dazu wird das NodeHandle gecacht 

■ Wenn es falsch oder unbekannt ist, wird per Pastry‐Routing die 

Wurzel gesucht 

■ Von der Wurzel aus sendet jeder Knoten die Nachricht an seine 

Kind‐Knoten 

● Alternative: 

■ Verteilen der Nachricht htdirekt vom aktuellen Knoten aus 

■ Jede Nachricht beinhaltet eine Liste von Knoten, die die Nachricht 

bereits gesehen haben 

■ Die Nachricht wird an den Parent‐Knoten und an alle Kind‐Knoten 

verschickt 


Scribe: 

Reparatur 

● Die Wurzel sendet regelmäßig "Heartbeat"‐Nachrichten 

● Normale Nachrichten sind implizit Heartbeats 

● Wenn der Heartbeat vom Parent‐Knoten ausbleibt, sendet 

er eine neue JOIN‐Nachricht 

● Dadurch wird der Baum repariert 

● Die Wurzel repliziert ihren Zustand (wie gewohnt) über das 

Leafset 

● Ein neuer Root‐Knoten übernimmt direkt nach dem Ausfall 

der Wurzel das Verteilen und Aussenden der Heartbeats 


Scribe 

0100 

1111 

1100 

1101 

1001 

0111 

Quelle: [1] 


Scribe 

0100 

1111 

1100 

1101 

1001 

0111 

Quelle: [1] 


Scribe: Probleme 

● Innere Knoten des Baumes müssen weiterleiten 

● Blattknoten müssen nur empfangen 

● Für Baum mit Fanout f, i inneren Knoten, b Blättern gilt: 

■ (f‐1) ∙ i + 1 = b 

■ Anteil an inneren Knoten ca. 1/f 

● Last der inneren Knoten: 

■ Ausgangs‐Bandbreite f‐mal der Datenstrom 

● Sehr ungleiche Lastverteilung im Baum 

● Lösung: SplitStream 


■ Aufteilen des Datenstroms in mehrere Teilströme 

■ Für jeden Teilstrom einen eigenen Baum aufbauen 


SplitStream 

1 

3 5 

2 8 

4 6 

7 

Quelle: [2] 


SplitStream 

1 

3 5 

2 8 

4 6 

7 

Quelle: [2] 


SplitStream 

1 

3 5 

2 8 

4 6 

7 

Quelle: [2] 


SplitStream 

● Datenstrom mit Bandbreite B wird verteilt 

● Der Datenstrom wird in k Stripes eingeteilt 

● Für jeden Stripe wird ein eigener Baum aufgebaut 

● Es muss nicht jeder Knoten alle Stripes empfangen 

■ Warum macht das Sinn? 

● Jeder Knoten kann seine Upload‐ und Download‐Bandbreite 

in Schritten von B/k kontrollieren 

● Dadurch Berücksichtigung von: 

■ Knoten mit unterschiedlicher h Bandbreite 

■ Ungleiche Up‐ und Download‐Bandbreite 


Aufbau der Bäume 

● Jeder Stripe bekommt eigene ID 

● Die ID's unterscheiden sich in der höchsten Ziffer 

● Jeder Empfänger‐Knoten meldet sich bei allen Stripe‐IDs an 

● Zu jeder ID wird ein eigener Scribe‐Baum aufgebaut 

● Je dichter ein Knoten an der Wurzel ist, desto länger ist der 

gemeinsame Präfix 

● Ideal für diese Konstruktion ist: k = 2 b 

● Jede Route von einem Knoten zu einer Stripe‐ID stellt im ersten 

Schritt Übereinstimmung in der ersten Stelle sicher 

● Die weitere Route verläuft nur über Knoten mit der gleichen 

ersten Stelle 

● Alle Bäume haben also disjunkte Mengen innerer Knoten 


Aufbau der Bäume 

Peer mit Präfix 0 Peer mit Präfix 1 

A 

A 


Kontrolle der Bandbreite 

● Die eingehende Bandbreite entspricht der Menge der 

abonnierten Stripes, oder 

● max. 1, wenn kein Stripe abonniert wurde, aber der Knoten 

innerer Knoten eines Stripe‐Baumes ist 

● Aber: die ausgehende Bandbreite könnte überschritten werden 

● Methode in Scribe zur Kontrolle: 

■ Wenn ein Knoten einen neuen Kind‐Knoten K bk bekommt, tder die 

Bandbreite überschreitet: 

■ Sende dem Knoten bisherige Kind‐Liste 

■ Der Knoten versucht sich bei dem Kind mit der geringsten Latenz 

anzumelden 

■ Dies wird rekursiv fortgesetzt 

● Diese Methode führt in SplitStream zu Problemen! (Blatt Knoten 

kann evtl. kein Kind annehmen, weil er in anderem Baum innerer 

Knoten und damit ausgelastet ist) 


Kontrolle der Bandbreite 

● Jeder Knoten nimmt jedes neue Kind zunächst an 

● Wenn seine Bandbreite überschritten wird: 

■ Selektiere das Kind mit dem kürzesten gemeinsamen Präfix 

■ Hänge diese Kind ab 

● Das verwaiste Kind muss sich einen neuen Parent‐Knoten suchen 

■ Zunächst rekursiver Versuch, sich bei den anderen Kindern des 

alten Parent‐Knoten einzuhängen 

■ Dbi Dabei werden nur Kinder mit zum Stripe passenden Päfi Präfix genutzt tt 

■ Sonst nutze die "Spare capacity group" 

● Spare Capacity Group 

■ Scribe‐Gruppe in der alle Knoten mit freien Kapazitäten sind 


Wie verwende ich SplitStream? 

● Jeder einzelne Stripe könnte "Aussetzer" haben: 

● Reparaturzeiten nach Knotenausfall, Umorganisation, etc. 

● Daher: Einsatz von fehlertoleranter Kodierung 

■ Empfang aller k Stripes ist nicht nötig 

■ Ausfall einzelner Stripes kann kompensiert werden 


BitTorrent: Literatur 

[1] Bram Cohen: "Incentives Build Robustness in BitTorrent", 

2003. 

[2] Ashwin R. Bharambe, Cormac Herley, Venkata N. 

Padmanabhan: "Analyzing and Improving BitTorrent 

Performance", Microsoft Research Technical Report MSR‐ 

TR‐2005‐03, 2005. 


BitTorrent 

Web‐Server mit 

.torrent‐Datei 

Seeder 

Seeder 

Leecher 

Leecher 

Tracker 

Seeder 

Leecher 

Leecher 


BitTorrent: Funktionsweise 

● Ein Peer lädt eine Torrent‐Datei von einem Webserver 

■ Dateiinfos: Name, Länge etc. 

■ URL des Trackers 

■ SHA1‐Werte der Dateiblöcke 

● Es muss mind. einen Seeder anfänglich geben 

● Ein Peer meldet sich beim Tracker an 

● Der Tracker schickt eine zufällige Auswahl an Peers (ca. 40) 

● Der Peer baut Direktverbindungen zu diesen Peers auf 

● Der Peer lädt jetzt die Datei blockweise von seinen Nachbar‐ 

Peers runter 

● Wenn ein Peer weniger als 20 Nachbarn hat, holt er neue vom 

Tracker 


BitTorrent: Details 

● Versendung der Blöcke über TCP‐Verbindungen 

● Jeder Block wird in Sub‐Blöcke aufgeteilt (16 KB) 

● Diese werden im Pipelining‐Verfahren verschickt 

● Bevor ein neuer Block angefordert wird, werden erst 

fehlende Sub‐Blöcke von alten Blöcken angefordert 

● Welches Paket wird als nächstes angefordert? 

■ Zufällige Auswahl genügt nicht 

■ Coupon Collector Problem 


Coupon Collector’s Problem 

● Datei besteht aus m Teilen 

● Jeder Peer hat genau einen zufällig ausgewählten Teil 

■ Es müssen Ω(m ( log m) Peers teilnehmen, damit mit 

konstanter Wahrscheinlichkeit jeder Teil verfügbar ist 

● Verteilt man m Teile auf m Peers, 

■ haben 1/e der Peers gar keine Teile 

■ einige Peers O(log m) Teile 

● Ungleichgewicht 


BitTorrent: Details 

● Welches Paket wird als nächstes angefordert? 

■ "Random First Piece": Erstes Paket wird zufällig gewählt 

♦ Um schnell an Daten zum Weiterverteilen zu kommen 

♦ Sobald erstes Paket vollständig, wechsel zu Rarest First 

■ "Rarest First": Paket, welches am wenigsten repliziert ist 

unter den bekannten Peers 

■ "Endgame Mode": Am Ende alles von überall anfordern 


BitTorrent: Tit for Tat 

● Wie verhindere ich, dass jemand nicht weiterverteilt? 

● Grundsätzliche Idee: 

■ Ich schicke nur denen etwas, die auch selbst etwas 

weiterverteilen 

● Probleme: 

■ Peers, die noch nichts zum Verteilen haben 

■ Peers, die eine schlechte Anbindung haben, und von denen 

daher niemand etwas runterladen möchte 

■ Woher bekomme ich die Informationen? 


BitTorrent: Choking 

● Eine Verbindung kann aktiv oder passiv sein (choking, keine Anfragen 

werden beantwortet) 

● Es sind immer nur 4 Verbindungen aktiv (unchoking) 

● 3 werden über die besten Download‐Raten bestimmt 

■ 20 sec. rollierender Durchschnitt 

● Alle 10 sec. werden die aktiven Verbindungen neu gewählt 

■ wegen TCP ramp up 

● Zusätzlich: Ein "Optimistic Unchoke" 

■ Eine zufällige Verbindung wird aktiviert 

■ Für neue Peers und solche mit schlechter Upload‐Bandbreite 

■ Rotiert alle 30 sec. 

● Wenn keine Pakete mehr ankommen 

■ Mehr als ein Optimistic Unchoke 

● Wenn Download komplett 

■ Wähle aktive Peers mit höchster erzielbarer Upload‐Rate 



● Problemstellung: Multicast, d.h. Verteilung von Daten an eine 

große Empfängergruppe 

● IP‐Level Multicast wäre optimal 

● hat sich aber nicht durchgesetzt 

t 

● Daher: Application‐Level Multicast 

● Mit P2P gut zu realisieren 

● Prinzip: Baumförmige Struktur aufbauen 

● Probleme: Fairness sowie gute Ausnutzung der vorhandenen 

Kapazitäten 

● Lösungen: Daten in mehrere Teile zerhacken, für jeden Teil 

eigenen Baum aufbauen 

● Systeme: Scribe, SplitStream, BitTorrent 


Vorlesung 

P2P Netzwerke 

11: Sicherheit 




berlin de

Inhalt 

● Sicherheit 

■ Grundlagen 

■ Modell 

■ Ziel 

● Vergabe von Node‐ID's 

● Sicheres Befüllen von Routing‐Tabellen 

● Sicheres Routing 

■ Fehler‐Test für das Routing 

■ Redundantes Routing 


Sicherheit: Grundlagen 

● In P2P können alle bekannten Sicherheits‐Technologien zum 

Einsatz kommen: 

■ Symmetrische und asymmetrische Kryptographie 

■ Public‐Key Verfahren 

■ Digitale Unterschriften 

■ Zertifikate 

■ CA‐Hierarchien 

● Es gibt aber zusätzliche Problemen gegenüber Client/Server 

Systemen 

● Das ist Thema dieser Vorlesung: 

■ Spezifische Sicherheitsprobleme von P2P Netzwerken 


Literatur 

● Emil Sit and Robert Morris: "Security Considerations for 

Peer‐to‐Peer Distributed Hash Tables", 1st International 

Workshop on Peer‐to‐Peer Systems, 2002. 

● John R. Douceur: "The SbilAtt Sybil Attack", 1tI 1st International 

ti Workshop on Peer‐to‐Peer Systems, 2002. 

● Miguel Castro, Peter Druschel, Ayalvadi Ganesh, Antony 

Rowstron, Dan S. Wallach: "Secure routing for structured 

peer‐to‐peer p overlay networks", Proc. of the 5th Usenix 

Symposium on Operating Systems Design and 

Implementation, 2002. 

● Nikita Borisov: "Computational Puzzles as Sybil Defenses", 

Sixth IEEE International Conference on Peer‐to‐Peer 

Computing, 2006. 


Modelle 

Böse 

Server 

(z.B. für Online‐ 

Banking) 

Gut 

Internet 

Der eigene 

Rechner 

Client 

(z.B. das eigene 

Notebook) 


● System mit N Knoten 

Modell 

● Anteil von 0 ≤ f ≤ 1 bösen Knoten 

● Böse Knoten verhalten sich beliebig und operieren in 

Koalitionen von max. cN Knoten. 

● Allgemein: c ≤ f, wenn c 

= f dann sind alle bösen Knoten 

eine große Koalition 

● Unterscheide: 

■ Network‐Level Kommunikation 

■ Overlay‐Level Kommunikation 

● Grund‐Absicherung durch Kryptographie 


Was soll erreicht werden? 

● Ein bösartiger Knoten könnte Daten, für die er verantwortlich ist: 

■ Modifizieren, Löschen, alte Kopien ausliefern, etc. 

● Er könnte geroutete Pakete löschen, ändern, etc. 

● Daher: 

Sicheres Routing 

Sicheres Routing stellt sicher, dass eine Nachricht, h die 

ein gutartiger Knoten an den Schlüssel k sendet, mit 

hoher Wahrscheinlichkeit alle gutartigen Replika‐ 

Knoten für k erreicht. 


Schritte zum 

sicheren Routing 

● Sicheres Vergeben von Knoten‐IDs 

■ Verhindere, dass ein Angreifer seine Knoten‐ID selbst 

auswählen kann 

● Sicheres Bestücken der Routing‐Tabellen 

■ Stelle sicher, dass der Anteil von bösartigen Knoten in jeder 

Routing‐Tabelle nicht größer ist als der Anteil bösartiger 

Knoten im gesamten Netzwerk 

● Sicheres Weiterleiten von Nachrichten 

■ Stelle sicher, dass mindestens eine Kopie einer Nachricht 

jeden gutartigen Replika‐Knoten für einen Schlüssel erreicht 


Angriffe I: Besetzen einer ID 


Angriffe II: Sybil 


Angriffe II: Sybil 

● Ermöglicht: 

■ Zusammenhang des Netzwerkes stören 

■ Mehrheitsabstimmungen sabotieren 

■ Anfragen im Netz beobachten 

■ Netzwerk absichtlich verlangsamen 

■ DDoS Angriffe 


Node‐ID Vergabe: Angriffe 

● Koalition besetzt bestimmtes ID‐Gebiet (inkl. aller Replika‐ 

Knoten) 

■ Koalition kann dann ein bestimmtes Datenelement 

kontrollieren 

● Koalition aus Knoten versucht, alle Einträge in der Routing‐ 

Tabelle eines Opfers zu füllen 

■ Koalition kontrolliert dann sämtliche ausgehenden 

Nachrichten des Opfers (Eclipse‐Attacke) 

● Sybil Attacken: Einzelner Knoten nimmt über viele virtuelle 

Knoten unter vielen IDs am Netzwerk teil 

■ Gleiche Angriffe wie oben, aber auch ohne Koalition 


Sichere Node‐ID Vergabe 

● Externe Infrastruktur mit Certificate Authorities 

● CA wählt eine zufällige Knoten‐ID 

● Es wird ein Zertifikat erstellt mit: 

■ Öffentlichen Schlüssel des Knotens 

■ ID des Knotens 

■ IP‐Adresse des Knotens 

● Einbindung der IP‐Adresse nötig 

■ Sonst könnten Zertifikate zwischen unterschiedlichen Knoten 

getauscht werden, um sicherzustellen, dass der Knoten 

überall latenzmäßig lokal erscheint 

■ Bereitet Schwierigkeiten bei DHCP 

● Fälschung von IP‐Adressen Rückweg testen 


Abwehr der Sybil‐Attacke 

● Ein Knoten könnte sich immer noch sehr viele Zertifikate mit 

vielen il unterschiedlichen h Knoten‐IDs besorgen 

● Lösung 1: Zertifikate müssen bezahlt werden 

● Lösung 2: Zertifikate an Objekte der realen Welt binden (Person, 

Organisation) 

● Lösung 3: (umstritten, aber auch ohne Zertifikat möglich) 

■ Ausgabe eines Challenge, dessen Beantwortung Rechenzeit kostet 

■ Muss regelmäßig wiederholt werden 

■ Verschwendet aber CPU‐Zeit 

■ Wie berücksichtige ich Heterogenität? 

■ Aber: Heterogenität Ht itätführt immer zu Angriffsmöglichkeiten 

it 

■ Beispiel: finde x, sodass SHA‐1(SHA‐1(ipaddr, x), nodeId) genau p 

führende Nullen hat 


Computational Puzzles 

7 

n(1), c n(1) 

1 

8 

Puzzle: 

Zu gegebenem Y 

berechne X, s.d. 

H(X || Y) = Z 

und Z hat p führende Null‐Bits 

2 

n(2): Sequenznummer 

c n(2) : Challenge zur Seq.‐Nummer 

r n(2) : Zufallszahl 

3 

dabei ist: 

c n(2) = H( 1 || n(1) || c n(1) || 

3 || n(3) || c n(3) || 

r n(2) || c n(2)‐1 ) 

n(3), c n(3) 

6 

4 

Die Challenges werden periodisch 

neu berechnet und ihre Aktualität ist 

für jeden Knoten nachprüfbar! 

5 


Eclipse‐Angriff 


Routing‐Tabelle: 

Eclipse Attacke 

● Versuche, die Links eines Peers auf böse Peers umzulegen 

● Damit wird das echte Netz vor einem attackierten Peer 

verborgen, er sieht nur noch böse Peers 

● Das geht um so einfacher, je mehr Freiheiten ein Knoten 

hat, seine Nachbarn auszuwählen: 

■ Gnutella: Nachbarn können beliebig gewählt werden 

■ Pastry: Nachbarn können eingeschränkt gewählt werden 

■ Chord: Nachbarn sind vollständig determiniert 

● Dementsprechend ist Gnutella am anfälligsten 


Beispiel 

● Immer wieder Suche neuer Nachbarn aus den Nachbarlisten der 

aktuellen Nachbarn (insgesamt X Knoten) 

● Anteil böser Knoten ist f, Anteil guter ist g=1‐f 

● Böser Knoten schickt nur böse Knoten als potentielle Nachbarn 

● Guten Knoten mit zufälligen Nachbarn schickt mit W‘keit f einen 

bösen Knoten und mit W’keit g einen guten Knoten 

● Nach einer Runde Updates aller Routingtabelleneinträge t i t enthält 

Tabelle eines guten Knoten nur noch Anteil von 

■ g*g guter Knoten und 

■ f * 1 + g * f = f * (1+g) böser Knoten 

● Der Anteil guter Knoten ist also von g auf g² gesunken! 

● Der Anteil ilböser Knoten itjttd ist jetzt deutlich größer! 

● Beispiel: 90% gutartiger Knoten wird zu: 

■ 81%, 66%, 43%, 19%, 3% 


Routing‐Tabelle: Abwehr 

● Je beschränkter die Routing‐Tabelle, desto schwerer der Angriff 

● Beispiel: Bei Chord gibt es für jeden Eintrag der Routing‐Tabelle bll 

nur einen passenden Knoten 

● Daher ist Chord per se gut gewappnet 

● Diese Abwehrstrategie verhindert aber PNS 

● Lösung: Zwei Routing‐Tabellen 

■ Eine beschränkte Tabelle 

♦ pro Eintrag nur eine Möglichkeit 

♦ In Pastry‐Knoten i, Eintrag auf Ebene l, Ziffer d: 

dichtester Knoten zu einer ID p mit 

p hat gemeinsames Präfix der Länge l mit i 

p hat Ziffer d an Position l+1 

p hat die nächsten Ziffern wieder identisch mit i 

■ Eine unbeschränkte Tabelle 

♦ Ausnutzung von Lokalität 


Befüllen der beschränkten 


● Einfache, aber teure Methode: 

■ Sicheres Routing nutzen, um Einträge neu zu füllen 

● Menge von Boot‐Knoten verwenden 

■ Groß genug, dass mindestens ein gutartiger Knoten enthalten ist 

● Routing‐Tabellen von allen Boot‐Knoten holen 

● Jeden Slot mit dem besten Knoten füllen, der die 

Bedingungen erfüllt 

● Von diesen Knoten wiederum die Tabellen holen 

● Einträge dann eventuell durch bessere Knoten ersetzen 

● Stabilisierung: 

i 

■ Regelmäßige Kommunikation mit den Nachbarn 


Sicheres Routing 

● Die bisherigen Maßnahmen garantieren: 

■ Jede beschränkte Routing‐Tabelle beinhaltet nur einen Anteil von f 

bösartigen Knoten 

● Aber: ein bösartiger Knoten auf einer Route ist genug! 

■ Er könnte behaupten, dass er der Root‐Knoten ist 

■ Er könnte die Nachricht stillschweigend löschen 

■ Er könnte sie an einen anderen (falschen) Knoten weiterleiten 

● Wahrscheinlichkeit für erfolgreiches Routing: (1‐f) h‐1 

■ h ist dabei die Anzahl Knoten auf dem Pfad 

● Der Root‐Knoten selbst könnte bösartig sein 

■ Verwendung von Replika‐Knoten 


Sicheres Routing: Lösung 

● Mit hoher W’keit soll mindestens eine Kopie der Nachricht 

jeden Replikaknoten des Zieles erreichen 

● Zunächst Standard‐Routing nutzen (für Effizienz, d.h. 

Ausnutzung von Lokalität) 

● Der Root‐Knoten antwortet mit einer Menge von Replika‐ 

Knoten 

● Jetzt wird ein Fehlertest angewendet 

● Wenn der Fehlertest anschlägt: 

■ Verwende redundantes Routing 

■ Es werden mehrere Kopien der Nachricht auf verschiedenen 

Routen an die unterschiedlichen Replika‐Knoten gesendet 

■ Dies ist teuer, aber die Erfolgswahrscheinlichkeit ist höher 


Fehler‐Test für das Routing 

● Wenn keine Antwort nach einem Timeout 

zurückkommt, antwortet der Test positiv 

● Sonst: Eingabe für den Test ist der Ziel‐Schlüssel plus 

eine Menge von potentiellen Replika‐Knoten 

● Beobachtung: 

■ Die durchschnittliche Dichte von Knoten pro ID‐Distanz ist 

höher als die durchschnittliche Dichte von bösartigen Knoten 

● Daher wird verglichen: 

■ Dichte der Knoten in der Nachbarschaft des aktuellen Knoten 

■ Dichte der Replika‐Knoten 

● Wenn ein Knoten nur bösartige Knoten aus seiner Koalition 

zurückliefert, ist die Dichte geringer als die normale Dichte 


Fehler‐Test für das Routing 

Korrekte Menge von Replika‐Knoten 

B: Bösartiger Knoten 

G: Gutartiger Knoten 

B 

G B G G B G G G B G G B G 

Von bösartigem Knoten zurückgelieferte Menge 

Dichte ist itviel ilgeringer 


Exkurs: Nonce 

● Nonce = Number used once, Schutz vor Replay Attacks 

Client 

Server 

getNonce() 

nonce 

login(username, cnonce, 

hash(cnonce+nonce+password)) 

token 

Quelle: Wikipedia 


Redundantes Routing I 

● p sendet r Nachrichten über verschiedene Nachbarn an das 

Ziel x. 

● Jede Nachricht beinhaltet ein nonce. 

● Es wird nur die beschränkte Tabelle verwendet. 

● Wenn ein Knoten die Nachricht erhält, x im LeafSet enthält, 

schickt er sein NodeId‐Zertifikat und das nonce, 

unterschrieben mit seinem Privaten Schlüssel, zurück. 

● Der Original‐Knoten sammelt die zu x dichtesten Node‐ID‐ 

Zertifikate in einer Liste N, aber nur wenn sie gültig 

g 

unterschieben sind. Alle stehen zunächst auf "Pending". 


Redundantes Routing II 

● Nach einem Timeout oder nachdem r Antworten kamen, 

sendet der Knoten die Liste N an jeden Knoten, der noch 

auf "Pending" steht und setzt ihn auf "Done". 

● Jeder Knoten leitet die Originalnachricht an Nachbarn 

weiter, die nicht in der Liste stehen. Ansonsten sendet er 

eine Bestätigung, dass es keine weiteren Knoten gibt. Die 

neuen Knoten kommen auch auf die Liste. 

● Wenn von jedem Knoten eine Bestätigung erhalten wurde, 

oder 3 Runden vorbei sind, wird aus N die Menge der 

Replika‐Knoten lk gebildet. bld 



● P2P hat besondere Sicherheitsanforderungen im Vergleich 

zu Client/Server 

● "Standard"‐Sicherheitsmaßnahmen sind notwendig, aber 

nicht hinreichend 

● Man muss immer mit bösartigen Knoten rechnen 

● Das gesamte Netzwerk soll auch dann noch funktionieren, 

wenn ein gewisser Anteil der Knoten bösartig ist 

● Typische Angriffe: 

■ Sybil: Viele virtuelle Knoten 

■ Eclipse: Verdecken des Netzes durch bösartige Knoten 

● Abwehrmaßnamen sind möglich, aber teuer

1x1 - Fachgebiet Komplexe und Verteilte IT-Systeme - TU Berlin

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?