University of Würzburg Informatik III (Distributed Systems) Prof. Dr. P. Tran-Gia www3.informatik.uni-wuerzburg.de Towards Efficient Simulation of Large Scale P2P Networks Compact Data Structures Andreas Binzenhöfer ITG-Fachgruppe “Cooperating and Scalable Networks” Aachen, Ericsson, J. Sachs,

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 2 Hintergrund P2P Mechanismen „verteiltes Telefonbuch“ 10  100  1000   … Extrem große Zahl an Benutzern zu simulieren Wie groß ist groß genug? Probleme bei Laufzeit und Speicher Lösungsansätze: - Geeignet abstrahieren - Effiziente Event Queue - Event Design Algorithmen

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 3 Inhalt  Einführung und Problemstellung  Queue Efficiency  Calendar Queue im P2P Umfeld  Event Efficiency  Kademlia Bucket Refreshes  State Efficiency  Process Handlers  Zusammenfassung

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 4 Verschiedene Möglichkeiten zur Optimierung Viel Speicher ↔ Viele Teilnehmer ↔ Viele Events

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 5 Queue Efficiency Optimieren der Zeit in der Queue

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 6 Problemstellung Hold Time = Enque + Deque Operation

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 7 Calendar Queue Day 1Day 2Day 3Day N d *  Gleiche Funktionsweise wie ein normaler Kalender  Ein Jahr besteht aus N d (=365) Tagen  Ein Tag besteht aus T d (=24) Zeiteinheiten  Einfügen in O(1) durch Berechnen des Index (modulo N d )  Herausnehmen durch Weiterhangeln von Tag zu Tag

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 8 Calendar Queue: Probleme Zu viele Tage: Dequeue Operation nicht mehr in O(1) Zu lange Tage:Enqueue Operation nicht mehr in O(1)

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 9 Calendar Queue in der Praxis  Ansätze zum dynamischen Anpassen der Parameter N d und T d  Bei P2P Simulationen in der Regel nicht nötig  Optimale Werte:  T d, so dass wenige Events pro Tag  N d, so dass Großteil der Events in einem Jahr Day 1Day 2Day 3Day N d *

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures Tage mit jeweils 100ms Aktueller Tag

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures Tage mit jeweils 1ms Aktueller Tag

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 12 Zwischenfazit  Hold Time in der Event Queue beeinflußt Skalierbarkeit  Calendar Queue  Leicht implementierbar  Muß für P2P nicht dynamisch angepaßt werden  Ähnliche Datenstrukturen existieren z.B. in C#  Praktische Erfahrungen decken sich nicht immer mit Theorie (ns2)

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 13 Event Efficiency Reduktion der Anzahl an Events

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures Kademlia: Strukturiertes P2P Overlay Eigener Hash: 0000 Ein Eintrag pro Bucket Nachbarschaft Entfernte Peers im Overlay Bucket mit Nachbarn Nicht mehr splitten

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 15 Kademlia Bucket Refreshes  Etwa log 2 (n) buckets pro peer  Refresh eines buckets, falls dieser mindestens eine Stunde lang nicht benutzt wurde  Beispiel: peer X bucket 1 bucket 2bucket 3 Time of next refresh

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 16 Kademlia Bucket Refreshes Refresh event moved every time peer uses bucket bucket i Naive Lösung ohne zusätzlichen Speicher: Obsolete refresh events are being skipped bucket i Naive Lösung mit zusätzlichem Speicher: Jeder bucket speichert den tatsächlichen Zeitpunkt des nächsten Refresh Zu zeitintensiv Zu viele unnötige Events

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 17 Kademlia Bucket Refreshes bucket i Optimierte Lösung (Laufzeit): Jeder bucket speichert den tatsächlichen Zeitpunkt des nächsten Refresh Optimierte Lösung (Speicher): bucket 1 bucket 2 bucket 3 current minimum log2(n)·n refresh events 1.7 Millionen für Nur noch n refresh events Bsp: Reduktion um Faktor 17

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 18 State Efficiency Kompakte Datenstrukturen

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 19 Process Handler  Vermeiden von redundanter Information paralleler Prozesse  Bsp. parallele Suche:  Jedes teilnehmende Peer speichert ähnliche Informationen  Gleiche Information liegt mehrmals im Speicher Day 1Day 2Day 3Day N d process handler R a = 3 xyz = 48

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 20 Process Handler  R a zählt die Anzahl der Pointer auf den Process Handler (Remaining access)  Prinzip: „Der letzte macht die Türe zu“  Vorteil: Einsparung redundanter Information Day 1Day 2Day 3Day N d R a = 3 xyz = 48 process handler

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 21 Beispiel Search Handler  Search Handler speichert  Initiator der Suche  Gesuchte ID  Zeitpunkt des Timeouts  Anzahl (positiver) Antworten  … process handler R a =3 sender=48 query=667 timeout=4567 answers=2

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 22 Welchen Einfluss hat die Overlay Größe? quantile 0.99-quantile quantile Chord size n search delay bound / E[T N ] E[T N ] = 50 ms c T N = 1

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 23 Welchen Einfluss hat die Overlay Größe? Aussage: Dokumentverlust hängt nicht von der Ringröße, sondern von der Bewegung im Overlay ab

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 24 Wie groß ist groß genug?  P2P Algorithmen entworfen um mit der Größe zu skalieren  Churn hat stärkeren Einfluss auf Leistungsparameter  Overlay muss allerdings groß genug sein  Vollvermaschung  Zipf Verteilung vieler Parameter  Komplettaustausch des Overlays  Für strukturierte P2P Netze ca ausreichend

University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 25 Q&A

University of Würzburg Dept. of Distributed Systems Prof. Dr. P. Tran-Gia Towards Efficient Simulation of Large Scale P2P Networks Compact Data Structures ITG Fachgruppentreffen Andreas Binzenhöfer, University of Würzburg Mai 2006 in Aachen