Ein Peer-to-Peer-Benchmark-System. SimBench. Alexander Wolf. August 2009

Größe: px
Ab Seite anzeigen:

Download "Ein Peer-to-Peer-Benchmark-System. SimBench. Alexander Wolf. August 2009"

Transkript

1 Ein Peer-to-Peer-Benchmark-System SimBench Alexander Wolf August 2009

2 FernUniversität in Hagen Fakultät für Mathematik und Informatik Lehrgebiet Kommunikationsnetze Bachelor-Studiengang Informatik Erstgutachter: Prof. Dr.-Ing. habil. Herwig Unger Lehrgebiet Kommunikationsnetze Zweitgutachter: (unbekannt) Selbständigkeitserklärung Hiermit erkläre ich, dass ich die von mir dem Prüfungsauschuss der Fakultät für Mathematik und Informatik eingereichte Bachelorarbeit zum Thema SimBench - Ein Peer-to-Peer-Benchmark-System vollkommen selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Granada, den Alexander Wolf 2

3 Zusammenfassung Im Laufe der letzten Jahre entstanden verschiedene Peer-To-Peer-Protokolle mit unterschiedlichen Stärken und Schwächen. In dieser Arbeit werden theoretische Grundlagen zur vergleichenden Bewertung dieser Protokolle besprochen. Die analytische Bewertung dieser Protokolle ist aufgrund der verteilten Natur eines Peer-to-Peer-Systems nur schwer möglich (vgl. Conwell - Game of Life), der Ansatz der Arbeit konzentriert sich daher auf die Bewertung mit Hilfe eines Benchmarks. SimBench, so der Name des Benchmarks, zeichnet sich durch Normierung aus. Der Verlauf der Simulation kann in einer Konguration eingestellt werden, Metriken werden fest deniert. So können Benchmarks mit beliebigen Kombinationen aus Protokollen, Kongurationen und Metriken durchgeführt werden, deren Vergleichbarkeit so gewährleistet ist. SimBench wird in der Peer-to-Peer-Simulationsumgebung P2PNetSim umgesetzt. P2P- NetSim ist eine Software des Lehrgebiets Kommunikationsnetze zur Simulation von verteilten Netzwerken. Mit der Implementierung werden dann beispielhafte Benchmarks und Auswertungen durchgeführt, um die Möglichkeiten von SimBench zu demonstrieren.

4 Inhaltsverzeichnis 1 Einleitung Motivation Einführung Denition Peer-to-Peer Weitere Begrie Kategorien von Peer-to-Peer-Netzwerken Geschichte von Peer-to-Peer Evaluierung von Peer-to-Peer-Protokollen Gliederung der Arbeit Grundlagen Existierende Simulatoren GPS Neurogrid NS Overlay Weaver P2PRealm P2PSim PeerfactSim.KOM PeerSim Query-Cycle-Simulator P2PNetSim Zusammenfassung Vorschläge Benchmark für eine Simulation Der Begri Benchmark Abgrenzung Besonderheiten des Benchmarks bei einer Simulation Eigenschaften des Benchmarks Qualitätsmodell Eigenschaften eines Protokolls Metriken Gnutella Zusammenfassung SimBench Modellierung des Verhaltens Möglichkeiten der Modellierung Schichten der Modellierung Netzwerkebene

5 3.1.4 Overlayebene Benutzerebene Grenzen der Realitätsnähe Konkrete Modelle Komponenten Netzwerk Peers Dateisystem Lasterzeugung Reine Benchmark-Komponenten Denition von SimBench Konguration Metriken Implementierung P2PNetSim Grundidee Überblick Ablauf eines Benchmarks Überblick: Peer Überblick: Ablaufsteuerung Anforderungen Relevanz Reproduzierbarkeit Skalierbarkeit Vergleichbarkeit Einfachheit Peer-to-Peer-Protokolle AbstractPeer Nachrichten Sonde Protokolldateien Befehlskodierung Observer zur Nachrichtenbearbeitung Beispiel der Integration an Gnutella Benchmark XML-Generator Phasenbetrieb Kommandozentrale Datensammler Metriken Auswertung Validierung Anwendung Anwendungsbeispiele Validierung Topologie und Fluktuation

6 5.2.2 Befehlserzeugung und -ausführung Optimierung und Fehlersuche Skalierbarkeit Benchmark Auswertung Suchezienz Benchmark Auswertung Robustheit Benchmark Auswertung Fazit Abschluss Erfahrung mit P2PNetSim Fazit Ausblick Abbildungen 91 Tabellen 92 Literaturverzeichnis 93 6

7 1 Einleitung 1.1 Motivation Es gibt eine Vielzahl von Peer-to-Peer-Protokollen. Das macht einen Vergleich ihrer Eigenschaften nötig, durch Messungen im Live-System, in der Simulation oder durch Analyse. In vielen vorhandenen Peer-to-Peer-Simulatoren sind Messungen und Statistiken möglich. Diese sind oft kompliziert und ohne Programmierkenntnisse nicht ausführbar. Ein weiteres Manko ist die Vergleichbarkeit. SimBench wird konzipiert als ein systematischer, vergleichbarer und auf theoretischer Grundlage aufbauender Benchmark für eine Simulation. Dies soll mit dieser Arbeit entwickelt werden. Weitere Ziele sind das Aufstellen von gewünschten Kriterien eines Benchmarks und einer Simulation, die soweit wie möglich in SimBench umgesetzt werden sollen. Es gibt viele mögliche Zielgruppen für eine solche Entwicklung. Entwickler protieren bei der Erweiterungen und Implementierung neuer Protokolle, was nicht nur eine Struktur vereinfacht ist, sondern auch zielgerichteteres Arbeiten durch Messungen während der Entwicklung ermöglicht. Forschern nutzt die Vereinheitlichung der Messergebnisse und die Nachvollziehbarkeit des Benchmarks. Dem Anwender wird der Verlauf des Benchmarks vereinfacht, indem alle wesentlichen Einstellungen zu einer Simulation in einer graphischen Benutzeroberäche wählbar sind. 1.2 Einführung In der Einführung werden zuerst wichtige Begrie besprochen, dann ein Abriss der kurzen, aber ereignisreichen Geschichte von Peer-to-Peer gegeben. Es zeigt sich, dass aufgrund der Vielzahl der Protokolle ein Vergleich zwischen diesen nötig ist. Die Möglichkeiten, ein Peer-to-Peer-Protokoll mit einem anderen zu vergleichen, werden kurz beschrieben. Ein Benchmark in einer Simulation ist eine dieser Möglichkeiten Denition Peer-to-Peer Was ist ein Peer-to-Peer-System, und was nicht? Diese Frage ist leider nicht eindeutig zu beantworten. Obwohl der Begri Peer-to-Peer unter Informatikern intuitiv recht ähnlich verstanden wird, ist keine Denition bekannt, die alle Aspekte eines Peer-to- Peer-Systems und alle Anwendungen umfasst. Natürlich wurden bereits einige Versuche unternommen, den Begri schärfer zu beschreiben. So ist eine mögliche, jedoch recht allgemein gehaltene Denition die Folgende: 7

8 1.2. EINFÜHRUNG KAPITEL 1. EINLEITUNG In Peer-to-Peer-Systemen übernimmt jeder Knoten sowohl Client- als auch Server-Funktionen (als Servent bezeichnet), und trägt seinen Anteil an den Kosten des Systems, indem er seine eigenen Ressourcen, meist Rechenzeit, Speicherplatz oder Netzwerkbandbreite, beisteuert. ( [AH02]) Diese Denition betont den Unterschied zum klassischen Client-Server-System, in dem der Server die Hauptaufgabe übernimmt und die Clients bedient. Im Gegensatz dazu sind bei Peer-to-Peer die Aufgaben gleichmäÿiger über alle Teilnehmer verteilt. Eine andere Herangehensweise nimmt Andrew Oram in [Ora01]. Er schlägt einen Lackmus-Test vor, ob ein Netzwerk Peer-to-Peer ist oder nicht: Der Lackmus-Test für Peer-to-Peer-Netzwerke beruht auf der Beantwortung folgender Fragen: Sind variable Verbindungen und temporäre Netzwerkverbindungen die Norm? Sind die Kanten des Netzwerks autonom? D.h.: Unterstützt das System variable Verbindungen und temporäre Netzwerkadressen? Erlaubt es den Blattknoten im System signikante Autonomie? Auch diese Fragen sind recht allgemein, schlieÿen dafür keine Netzwerke aus, die allgemein anerkannt Peer-to-Peer sind. Eine weitere interessante Annäherung an den Begri bietet die Betrachtung der Prinzipien von Peer-to-Peer-Systemen. Folgende Prinzipien lassen sich laut [AH02] in Peer-to-Peer-Systemen ausmachen: Das Prinzip der Ressourcenteilung Die teilnehmenden Peers teilen sich die Ressourcen. Dabei sind sowohl physische Ressourcen wie Plattenplatz oder Bandbreite, als auch logische Ressourcen wie Dienste oder Informationen gemeint. Das Prinzip der Dezentralisierung Als Konsequenz der Ressourcenteilung gibt es keine zentrale Instanz mehr, das vermeidet single-point-of-failures oder bottlenecks. Das Prinzip der Selbstorganisation Die Knoten organisieren sich selbst auf Basis der Information, die sie über ihre Nachbarn haben. Man erkennt die Gemeinsamkeiten dieser Denitionen in wichtigen Punkten. Angemerkt sei, dass sich nach diesen Denitionen auch das Usenet und das konventionelle Telefonnetz als Peer-to-Peer-System auassen lassen, lange bevor der Begri "Peer-to-Peer" bekannt war (was durchaus eine legitime Betrachtungsweise ist). Ein Peer-to-Peer-System im Sinne dieser Arbeit ist ein System, welches die Prinzipien der angegebenen Denitionen erfüllt und das allgemein als Peer-to-Peer-System verstanden wird Weitere Begrie Im Bereich Peer-to-Peer haben sich einige Begrie eingebürgert, die nicht im allgemeinen Wortschatz der Informatik anzutreen sind. Um das Verständnis zu unterstützen, werden die Begrie kurz erklärt, die im Rest dieser Arbeit verwendet werden. 8

9 1.2. EINFÜHRUNG KAPITEL 1. EINLEITUNG Peer-to-Peer Peer-to-Peer ist eine verteilte Netzwerkarchitektur. Peer-to-Peer-Netzwerke werden auch in Anlehnung an das Englische als P2P networks bezeichnet. Der Begri wurde in Unterabschnitt näher betrachtet. Peer Ein Rechner im Peer-to-Peer-Netzwerk wird als Peer bezeichnet. Peer im Englischen heiÿt Ebenbürtiger, Gleichrangiger. Damit wird ausgedrückt, dass jeder Knoten sowohl Client- als auch Server-Funktionen übernimmt und seinen Anteil an den Kosten des Systems beiträgt, indem er seine eigenen Ressourcen, meist Rechenzeit, Speicherplatz oder Netzwerkbandbreite, beisteuert [AH02]. In dieser Arbeit wird, sofern nicht aus dem Kontext ersichtlich, der Begri Peer für einen simulierten Teilnehmer eines Peer-to-Peer-Netzwerks benutzt, während zur Abgrenzung davon die Begrie Knoten oder Rechnerknoten den physisch vorhandenen Rechner, auf dem die Simulation oder ein Teil davon läuft, meinen. Overlay Über dem Internet wird ein weiteres Netzwerk aufgespannt, das unabhängig bezüglich Adressierung, Routing und Topologie ist. Dieses neue Netzwerk überdeckt das Internet, weshalb es auch Overlay Netzwerk (engl. to overlay heiÿt überdecken, überlagern) genannt wird. Das überdeckte Netzwerk, also in diesem Fall das Internet, wird gelegentlich als Underlay-Netzwerk bezeichnet. Peer-to-Peer-Protokolle operieren vollständig auf dem Overlay-Netzwerk, direkte Nachbarn im Overlay können also im Internet topologisch weit entfernt liegen. Churn Peer-to-Peer-Netzwerke zeichnen sich durch eine hohe Fluktuation aus. Ständig betreten Knoten das Netzwerk oder verlassen es, oft fallen sie einfach aus, ohne sich abzumelden. Dieses Phänomen wird Churn genannt. Das englische Wort to churn bedeutet aufwühlen, umrühren, schäumen (und auch verbuttern). Damit ist recht anschaulich die Unruhe beschrieben, welche Churn in das Peer-to-Peer-Netzwerk bringt. Die Fluktuation ist eine typische Eigenschaft dieser Netzwerke und eine der gröÿten Herausforderungen. Small-World-Netzwerk In den späten 1960er Jahren prägte der Psychologe Stanley Milgram den Begri Kleine-Welt-Phänomen (engl. small world phenomenon). Er versendete einige Briefe an eine zufällig gewählte Gruppe von Personen aus Nebraska (etwa in der Mitte der USA). Sie wurden aufgefordert, den Brief, der letztlich einen Empfänger an der Ostküste der USA in Boston erreichen sollte, nur an persönliche Bekannte weiterzuleiten, die vermutlich näher an dieser Zieladresse wohnten. Diese sollten die Briefe nach dem gleichen Schema behandeln. Es zeigt sich, dass ein Brief den Empfänger in durchschnittlich fünf bis sechs Schritten erreichte. Dieses Phänomen wird populär mit dem Ausdruck jeder kennt jeden über sechs Ecken beschrieben. Interessanterweise wurde diese Struktur sozialer Netze ebenfalls in Computernetzwerken und Graphen beobachtet, insbesondere in bestimmten Peer-to-Peer-Netzwerken. DHT In den frühen Peer-to-Peer-Protokollen gab es keine Garantie, dass eine im Netzwerk vorhandene Datei auch wirklich gefunden wurde. Ein Lösung dieses Problems sind verteilte Hashtabellen (engl. Distributed Hash Tables, DHT), eine Datenstruktur, bei 9

10 1.2. EINFÜHRUNG KAPITEL 1. EINLEITUNG der die Daten über alle Knoten (in unserem Fall Peers) verteilt gespeichert werden. Der Schlüssel eines Datums wird zum Aunden desselben benötigt, er lässt sich mittels einer Hash-Funktion aus dem Datum eindeutig berechnen Kategorien von Peer-to-Peer-Netzwerken Um die Eigenschaften von Peer-to-Peer-Protokollen besser zu beschreiben, werden sie in Kategorien eingeteilt. Hierbei gibt es verschiedene Möglichkeiten; einen guten Überblick der Kategorisierung liefert [HD05]: Nach Strukturierungsgrad unterscheidet man zwischen unstrukturierten und strukturierten Peer-to-Peer-Netzwerken. Im ersten Fall verwalten die Peers keine Informationen über die Ressourcen anderer Peers. Bezüglich der Organisation werden keine Garantien gemacht, die entstehende Struktur kann nur durch stochastische Prozesse beschrieben werden. Unstrukturierte Peer-to-Peer-Netzwerke zeichnen sich durch Unabhängigkeit der einzelnen Peers und hohe Fehlertoleranz aus. Auf der Kehrseite sind sie wenig ezient und vorhersagbar. In strukturierten Peer-to-Peer-Netzwerken verwalten die Peers Informationen über Ressourcen Anderer. Dies ermöglicht zielorientierte Suche, erfordert jedoch zusätzlichen Aufwand für die Verwaltung der Information (z.b. Routingtabellen). Nach Hierarchiegrad Flache Hierarchien unterscheiden nicht zwischen Peers bezüglich ihrer Rolle im Gesamtsystem. In der frühen Literatur wird das als reines Peer-to-Peer bezeichnet, und prominenter Vertreter ist Gnutella. In hierarchischen Netzwerken existieren Rollen für die Peers. Das Extrembeispiel ist Napster, dessen gesamter Suchindex auf einem zentralen Rechner verwaltet wird. Diese Art von Netzwerken ist leichter wartbar und bietet bessere Suche, dafür weniger Fehlertoleranz und verteilte Verarbeitung. Nach Kopplungsgrad In stark gekoppelten Netzwerken existiert genau eine globale Gruppe von Peers im System, der alle Peers angehören. Beim Eintritt in die Gruppe erhält jeder Peer eine Rolle in Bezug auf die Gruppe, d.h. welche Daten er verwaltet, und wie Nachrichten behandelt werden. Die Schlüsselintervalle für Informationen sind mit jenen für die Peers identisch. Chord bzw. verteile Hashtabellen sind Beispiele für stark gekoppelte Netzwerke. Lose gekoppelte Netzwerke können getrennt oder mehrere Netze vereinigt werden Geschichte von Peer-to-Peer Entstehung Im frühen Internet waren die meisten angeschlossenen Rechner 24 Stunden am Tag unter einer festen IP-Adresse erreichbar. Sie besaÿen die Möglichkeit, nicht nur zu konsumieren, sondern auch selbst Dienste anzubieten. Es waren Rechner von Universitäten und 10

11 1.2. EINFÜHRUNG KAPITEL 1. EINLEITUNG Unternehmen, die unter Gleichen kommunizierten. Ebenso waren viele Dienste auf eine Kommunikation zwischen gleichberechtigten Partnern ausgelegt. Dem Usenet konnte sich jeder Rechner mit Netzwerkanbindung und geeigneter Software anschlieÿen und seinerseits wieder anderen den Zugang ermöglichen. Auch waren damals viele kleine Mailserver der Normalfall. Mit der Einführung des ersten Web-Browsers Mosaic 1994 und der danach folgenden explosionsartigen Popularität des Internet waren auf einmal Personalcomputer, die nur während ihrer Benutzung in Betrieb waren und sich über Wählleitungen mit dem Internet verbanden, die häugste Art von Rechnern. Die rapide ansteigende Zahl von Teilnehmern führte zu einer Verknappung von IP-Adressen, was dazu führte, dass sie von den Providern wiederverwendet wurden, ein Rechner bei einer Einwahl also eine neue, dynamisch vergebene IP-Adresse erhielt. Diese Personalcomputer waren also von auÿen nicht erreichbar und konnten keine Dienste (z.b. Informationen) anbieten. Die vorher erwähnten Beispiele Usenet und Mail wurden zentralisiert auf groÿen Servern der Provider, und die Teilnehmer installierten auf ihren Computern reine Clients und waren so auf ihr Dasein als reine Konsumenten reduziert. Für einige Jahre war das die vorherrschende Form, bis die erste Peer-to-Peer-Software Napster im Juni 1999 von Shawn Fenning (geb. 1980) veröentlicht wurde. Die ursprüngliche Aufgabe der Software war ein File-Sharing-System, was es ermöglichte, Dateien auf anderen Teilnehmern zu lokalisieren und herunterzuladen. Diese Form der direkten Kommunikation wurde schnell eine beliebte Tauschbörse, um Musikdateien zu tauschen. In der Folge gab es einige Streitigkeiten mit den Rechteinhabern und nach einem Kooperationsvertrag mit dem Unternehmen Bertelsmann wurde Napster in eine kommerzielle Plattform umgewandelt. Ironischerweise war Napster, was oft als das erste Peer-to-Peer- System bezeichnet wird, bis auf den reinen Datenaustausch von einem zentralen Server abhängig, also kein Peer-to-Peer-Protokoll im eigentlichen Sinne. Mit der Abschaltung dieses Servers brach das Netzwerk für alle angeschlossenen Rechner zusammen. Diese Verwundbarkeit führte dazu, dass das nächste Peer-to-Peer-Protokoll Gnutella als reines Protokoll konzipiert wurde, was von keinem zentralen Rechner abhängig war, sondern dessen Knoten sich vollständig autonom organisieren konnten. Peer-to-Peer war geboren. Weitere Entwicklung Mit dem Aufkommen von Napster und kurz danach Gnutella wurden den Begrien Peerto-Peer und Filesharing (Austausch von Dateien, oft unter Verletzung des Urheberrechts) starke mediale Aufmerksamkeit zuteil. Diese ersten Protokolle wurden von Privatpersonen entwickelt, doch die Idee wurde schnell von der Wissenschaft aufgegrien und weiterentwickelt. In relativ rascher Folge entstanden neue Protokolle mit anderen Eigenschaften. Die Entwickler von Gnutella hatten noch die zentrale Verwundbarkeit von Napster in Erinnerung, allerdings hatte Gnutella selbst einige Schwächen wie z.b. die Suche. Als erstes akademisches Protokoll entstand CAN ( [RFH + 01]), dann Chord ( [SMK + 01, SML + 03]), Pastry ( [RD01]) und Tapestry ( [ZKJ01, ZHS + 04]), Kademlia ( [MM02]), Koorde ( [KK03]), um einige der wichtigsten Vertreter zu nennen. Peer-to-Peer wurde aber auch als Konzept für andere Anwendungen interessant. Reines Filesharing teilt nur die Ressource der Netzwerkanbindung zwischen den Peers. Das Grid-Computing übernimmt dieses Prinzip der Ressourcenteilung. Hier werden lokal nicht benutzte Prozessorzyklen für parallele Berechnung genutzt, und so mit vielen handelsüb- 11

12 1.2. EINFÜHRUNG KAPITEL 1. EINLEITUNG lichen Personalcomputern die Rechenleistung weit über das Niveau der leistungsfähigen Groÿrechner hinaus gesteigert. Prominentestes Beispiel ist BOINC ( [BOI09]) und das darauf aufsetzende ( [set09]). Auch Peer-to-Peer-Streaming wird mit PPLive ( [ppl09]) bereits praktisch erfolgreich eingesetzt. In Spitzenzeiten nutzten das System über 1,5 Millionen Anwender gleichzeitig mit je 400kbps, was ohne Peer-to-Peer für den Anbieter theoretisch eine 600Gbit-Anbindung erfordert hätte ( [Hua07]). Eine weitere erfolgreiche Anwendung ist die Internet-Telefonie mit Skype, welches Ende 2006 über 7 Millionen Nutzer verband ( [MS07]). Zu diesen und anderen einzelnen Bereichen existieren mittlerweile eine Vielzahl von Protokollen und bei Webseiten für wissenschaftliche Arbeiten wie Citeseer ( [cit09]) sind tausende Untersuchungen zum Thema Peer-to-Peer zu nden Evaluierung von Peer-to-Peer-Protokollen Diese Erfolgsgeschichte des Konzepts Peer-to-Peer bringt jedoch die Notwendigkeit mit sich, einzelne Peer-to-Peer-Protokolle beurteilen zu können, welches für den jeweiligen Anwendungsbereich geeigneter ist. Um vorhandene Protokolle zu evaluieren und neue Protokolle und Algorithmen zu entwickeln, müssen ihre Eigenschaften verglichen werden. Die Frage, welches das bessere Protokoll ist, lässt sich auf verschiedene Weise beantworten: Analyse: Insbesondere vor der Implementierung eines Protokolls bietet sich die theoretische Herangehensweise an. Dabei wird ein Verhalten stochastisch beschrieben, beispielsweise die Wahrscheinlichkeit, eine Datei zu nden. Damit lässt sich das Verhalten präzise angeben, was jedoch in der Wirklichkeit von anderen Einüssen ungültig gemacht werden kann. Die analytische Herangehensweise genügt dank ihrer theoretischen Grundlagen noch am ehesten wissenschaftlichen Maÿstäben, insbesondere was die Nachvollziehbarkeit betrit. Live-Messungen: An existierenden Peer-to-Peer-Systemen lassen sich Messungen durchführen. Diese Methode bietet eine bessere Beurteilung von Peer-to-Peer-Systemen im Betrieb, jedoch kann der Ablauf der Operationen oder der Aufbau des Netzes nicht beeinusst werden. Damit lassen sich nur Situationen testen, die von alleine auftreten, und der Test ist oft schwer wiederholbar oder nachvollziehbar. Testumgebung (engl. testbed): Eine Testumgebung besteht aus mehreren physisch vorhandenen Rechnern und ihrer Vernetzung, auf dem die zu testende Software läuft. Ein Beispiel ist PlanetLab mit zur Zeit über tausend Knoten ( [pla09]), welches auch für Peer-to-Peer-Protokolle eingesetzt wird. Die Ausstattung und Anbindung der Testknoten ist sicher besser als in einer Live-Umgebung, da es sich häug um Universitätsrechner handelt. Mit einer Testumgebung kann ein Peer-to-Peer-Protokoll schon sehr wirklichkeitsnah getestet und bewertet werden. Nachteile sind die hohen Kosten für die Hardware, daraus resultierend die begrenzte Skalierbarkeit und die erwähnte optimale Umgebung (gute Anbindung der Knoten, hohe Verfügbarkeit, keine böswilligen Anwender). 12

13 1.3. GLIEDERUNG DER ARBEIT KAPITEL 1. EINLEITUNG Simulation: Um Peer-to-Peer-Protokolle auch mit vielen Knoten evaluieren zu können, entwickelten Forscher Simulatoren. Je nach Qualität der Simulation lassen sich damit gute Aussagen über die Eigenschaften von Peer-to-Peer-Protokollen in einer Live-Umgebung machen. Die Simulation kann dabei abhängig von der Implementierung Millionen von Peers und mehr nachbilden, die Testumgebung selbst ist modellierbar. Dies kann natürlich bei schlechter Modellierung auch ein Nachteil sein. Gröÿter Nachteil der Simulatoren ist jedoch ihre Vielfalt: Bis heute gibt es hunderte verschiedener Simulatoren, die zum Teil nicht einmal öentlich oder gar namentlich bekannt sind. Ergebnisse aus unterschiedlichen Simulatoren sind jedoch nicht vergleichbar. Halten wir als Fazit fest, dass nicht mit jeder Methode alle Eigenschaften vergleichbar sind, die Methode also je nach gewünschtem Ziel gewählt werden muss. Die Simulation bietet viele Vorteile um Peer-to-Peer-Protokolle zu vergleichen und wird in dieser Arbeit weiter behandelt. 1.3 Gliederung der Arbeit In Kapitel 2 auf Seite 14 werden die Grundlagen behandelt. Zuerst stellt Abschnitt 2.1 einige existierende Peer-to-Peer-Simulatoren im Hinblick auf die Gewinnung von Messwerten vor, woraus in Unterabschnitt einige wünschenswerte Vorschläge abgeleitet werden. Dann wird in Abschnitt 2.2 der Begri Benchmark näher betrachtet, insbesondere werden die Besonderheiten, die für einen Benchmark in einer Simulation im Unterschied zu einem Live-System gelten, diskutiert (Unterabschnitt 2.2.3). In Unterabschnitt schlieÿlich werden Eigenschaften, die ein Benchmark für eine Simulation besitzen sollte kann, aufgezählt und beschrieben. Neben den Eigenschaften des Benchmarks selbst interessieren in Abschnitt 2.3 die zu bestimmenden Eigenschaften des Protokolls, diese werden in Unterabschnitt aufgezählt und deniert sowie einige Beispiele für Metriken gegeben (Unterabschnitt 2.3.2). Nachdem die Grundlagen geklärt sind, wird das theoretische Modell des Benchmarks SimBench in Kapitel 3 auf Seite 32 entwickelt. Realistisches Verhalten der Peer-to- Peer-Simulation ist wichtig für die Ergebnisse, dazu werden in verschiedenen Ebenen die jeweilige Dynamik besprochen und modelliert (siehe Abschnitt 3.1). Die Komponenten von SimBench werden in Abschnitt 3.2 aufgeführt und erklärt. Abschlieÿend erfolgt in Abschnitt 3.3 die formale Denition eines Benchmarks in SimBench. In Kapitel 4 auf Seite 48 werden dann einige ausgewählte Details der Implementierung besprochen, schlieÿlich das Konzept einschlieÿlich wichtiger Grundlagen implementiert. Es sind eine Reihe von verschiedenen Anwendungsmöglichkeiten für SimBench denkbar. Kapitel 5 auf Seite 74 liefert zum Abschluss dazu einige Beispiele für den Einsatz des neu erstellten Systems. 13

14 2 Grundlagen Als wichtige Grundlagen zum Entwurf von SimBench werfen wir in diesem Kapitel zuerst einen Blick auf andere Peer-to-Peer-Simulatoren, insbesondere im Hinblick auf ihre Eigenschaft, Protokolle zu vergleichen. Diese Betrachtung liefert einen Überblick auf den aktuellen Stand der Forschung. Danach wird der Begri Benchmark besprochen, hierzu erfolgt eine sprachliche Denition und Abgrenzung, sowie eine Erläuterung der Besonderheiten eines Benchmarks in einer Simulation. Zum Abschluss werden gewünschte Eigenschaften eines Benchmarks erklärt: Relevanz, Reproduzierbarkeit, Skalierbarkeit, Vergleichbarkeit und Einfachheit. Ein weiterer Teil dieses Kapitels befasst sich mit der Qualität von Peer-to-Peer-Protokollen. Welche Eigenschaften die Qualität eines Protokolls ausmachen und welche davon für einen Benchmark in Frage kommen, sind Fragen, die behandelt werden, sowie der Zusammenhang zwischen Qualität, Eigenschaften und Metriken. Schlieÿlich wird noch kurz die Arbeitsweise des Gnutella-Protokolls beschrieben, in welchem später beispielhaft einige Messungen mit SimBench ausgeführt werden. 2.1 Existierende Simulatoren Das Thema Peer-to-Peer ist oft untersucht worden, und in diesem Rahmen entstanden einige Peer-to-Peer-Simulatoren. Als erste Annäherung ist ein Überblick über existierende Simulatoren sinnvoll, mit Augenmerk auf statistische Funktionen, Sammeln und Auswerten von Daten über das Netzwerk oder einzelne Peers. Viele der existierenden Untersuchungen zum Thema Peer-to-Peer basieren auf der Simulation eines Protokolls oder sogar des gesamten Netzwerks. Die Betrachtung dieser Simulatoren wurde bereits Gegenstand eigener Untersuchungen, so resümiert [NBLR06], dass viele Simulatoren zu langsam, schlecht dokumentiert und kompliziert zu bedienen sind. Noch schlimmer wiegt, dass Ergebnisse häug nicht reproduzierbar sind: Unterschiedliche Simulationen liefern unterschiedliche Ergebnisse, so dass auch für ein- und dasselbe Protokoll nicht vergleichbare Ergebnisse ermittelt werden. In [NBL + 06] werden über 280 wissenschaftliche Arbeiten zum Thema Peer-to-Peer analysiert. Diejenigen, die ihre Ergebnisse aus Simulationen ermittelten, machen etwa zur Hälfte keine Angabe zum verwendeten Simulator, ein Groÿteil des Rests (60%) verwendet einen selbst geschriebenen Simulator, der Rest verteilt sich auf ein Dutzend Simulatoren. Das erschwert es, die Ergebnisse dieser Arbeiten untereinander zu vergleichen. Im Folgenden werden einige ausgewählte Simulatoren vorgestellt, die bereits einen gewissen Bekanntheitsgrad erlangt haben. Dabei wurde bei jedem Simulator nach einer Statistikfunktion, d.h. einer Möglichkeit simulierte Messwerte zu sammeln und auszuwerten, 14

15 2.1. EXISTIERENDE SIMULATOREN KAPITEL 2. GRUNDLAGEN gesucht. Wie sich herausstellt, ist dies der Schwachpunkt vieler Simulatoren. Dies deckt sich mit den Beobachtungen von [NBL + 06], Neuentwicklung in dieser Hinsicht in den letzten Jahren gab es nur bei PeerSim ([JMJV09]) und PeerfactSim.KOM ([KKM + 07]). Bei den anderen existiert oft überhaupt kein Mechanismus, um statistische Daten während oder nach des Simulationslaufs zu sammeln, oder für ein solches Verhalten muss das Simulatorprogramm selbst erweitert werden GPS GPS ist ein BitTorrent-Simulator in Java. Er erlaubt zwar Modellierung der Underlay- Topologie, skaliert dafür nur schlecht (von den Autoren getestet: 512 Knoten). Er wurde für das BitTorrent-Protokoll entwickelt, und enthält viele gute Ansätze, allerdings liegt die Entwicklung seit Jahren brach. GPS konzentriert sich auf die Simulation und bietet keine Messungen ([YA05]) Neurogrid Ein in Java geschriebenes auf Nachrichten basierendes Projekt zum Vergleich von Suchprotokollen ([[Jos03]). Neurogrid wird vom Autor als Peer-to-Peer-Bookmarking-System vorgestellt. Neurogrid bietet keine Simulation von Churn oder Fehlern im Netzwerk bzw. Fehlverhalten von Peers. Der Simulator bietet hohe Skalierbarkeit, berücksichtigt dafür nicht die Struktur des zugrunde liegenden Netzes. Statistische Daten können von den simulierten Knoten eingesammelt werden, eine Auswertung müsste selbst implementiert werden. Die letzte Aktualisierung der Programmversion war im Jahr NS-2 NS-2 ([ns-09]) ist ein Netzwerk-Simulator in C++, der fast das ganze OSI-Modell simuliert und dort viele nennenswerte zugehörige Protokolle implementiert hat, beispielsweise von untersten Schichten (Routingprotokolle) über Transportschicht (TCP, UDP) bis zur Anwendungsschicht (http, ftp). Durch diese hohe Detailtiefe ist NS-2 nur für kleine Netzwerke (mit einigen hundert Knoten) geeignet. Es existiert eine Weiterentwicklung PDNS ([RP09]), die verteilt und parallel rechnend simuliert, aber nicht gut skaliert. Auf diesem simulierten Netzwerk können Peer-to-Peer-Protokolle aufgesetzt werden. Der Aufwand ist dabei einer echten Implementierung vergleichbar. Die Realitätsnähe ndet sich auch in möglichen Messwerten. Daten aus allen Schichten und Protokollen, z.b. Latenz, Bandbreite, Fehlerrate, Pakete, Knoten, Routingtabellen uvm. können entweder während der Simulation angezeigt oder in Dateien geschrieben werden, um danach mit externen Tools analysiert oder visualisiert (z.b. mit nam, Network Animator) zu werden Overlay Weaver In [Shu09] ndet sich ein Toolkit zur einfachen Entwicklung und zum Test von Peer-to- Peer-Protokollen in Java. Overlay Weaver unterstützt einschränkend nur strukturierte 15

16 2.1. EXISTIERENDE SIMULATOREN KAPITEL 2. GRUNDLAGEN Overlays, die wichtigsten (Chord, Kademlia, Tapestry) sind bereits implementiert. Nach aktuellen Angaben skaliert die Simulation bis auf einige hunderttausend Knoten, zusätzlich kann die Simulation verteilt und parallel auf mehreren Rechnern erfolgen. Dies ist jedoch nicht dokumentiert. Es ist keine Ausgabe von Statistiken oder Messwerten implementiert, allerdings ein Mechanismus vorhanden, um Daten von jedem Knoten einzusammeln (Befehl listnodes). Das Frontend beherrscht die Visualisierung des Overlay-Netzwerks P2PRealm [KVK + 06] stellt mit P2PRealm einen Simulator zur Optimierung von neuronalen Netzen zur Verfügung, der nach Analyse einer Reihe vorhandener Simulationen entstand und auf Performanz optimiert ist. Mittels des Tools P2PDisCo kann die Simulation auf mehreren hundert Rechnern parallel ausgeführt werden und skaliert dabei nach Autorenangaben fast linear. Nach Simulationslauf kann die Topologie des optimierten Netzes ausgegeben und in externen Tools (P2PStudio, [KVA + 06]) ausgewertet werden P2PSim P2PSim wurde 2006 am MIT entwickelt und ist ein Simulator in C++ für kleine strukturierte Overlays ([p2p09]). Es können einfache Messwerte (z.b. Bandbreite insgesamt / pro Knoten, Anzahl Knoten, erfolgreiche bzw. nicht erfolgreiche Lookups) in einem Format ausgegeben werden, das zur Weiterverarbeitung in externen Tools gedacht ist (durch Tabulator getrennte Werte). Für weitere Messungen muss P2PSim erweitert werden, was durch die lückenhafte Dokumentation erschwert wird PeerfactSim.KOM Im Rahmen des QuaP2P-Projektes der Universität Darmstadt ([qua09]) entstand der Simulator PeerfactSim.KOM ([KKM + 07]). Er ist auf Geschwindigkeit optimiert und arbeitet mit Nachrichten unter Einbeziehung der Netzwerkebene. Bei einfachen Peer-to- Peer-Protokollen (Gnutella) skaliert er bis zur Gröÿenordnung 10 6 simulierte Peers, bei komplexeren wie Kademlia bis Eine verteilte und parallel berechnete Simulation wird nicht unterstützt. Beim Abspielen einer denierten Simulation werden viele Messwerte mitgeschrieben und können mit einem Tool Schritt für Schritt visualisiert werden. Auch der Export in ein gnuplot 1 -kompatibles Format wird unterstützt

17 2.1. EXISTIERENDE SIMULATOREN KAPITEL 2. GRUNDLAGEN PeerSim PeerSim ([JMJV09]) ist ein Teil von BISON (Biology-Inspired Techniques for Self-Organization in Dynamic Networks). Er ist in Java geschrieben und wurde speziell für epidemische Protokolle entwickelt. PeerSim konzentriert sich auf extreme Performanz und simuliert daher keine Underlay-Funktionen. Die Simulation skaliert bis zu einigen Millionen Knoten, lässt sich jedoch nicht verteilt durchführen. Er lässt sich sowohl im ereignisbasierten als auch im zyklusbasierten Modell ausführen. PeerSim bietet umfangreiche Klassen an, mit denen Messwerte und Informationen über das Netzwerk ermittelt werden können. Neben direkten Messwerten gibt es auch Auswertungen des Netzwerkgraphen wie Eingangs-/Ausgangsgrad, Ermittlung des Zusammenhangskoezienten, etc., die direkt eingesetzt werden können. Mit der in [DLTM08] vorgeschlagenen Erweiterung kann PeerSim die Simulation verteilt und parallel berechnen. Theoretisch ist die Anzahl der simulierten Peers so nur durch die physische Hardware begrenzt, praktisch wurden auf 16 Rechnern bereits 100 Millionen Chord-Peers erfolgreich simuliert, Simulationen mit 5 Milliarden Peers sind in Planung. Der Ansatz Distributed PeerSim ist viel versprechend, jedoch noch recht neu. Insbesondere existieren für die Erweiterung noch keinerlei Benchmarks oder Statistiken Query-Cycle-Simulator Wie der Name schon sagt handelt es sich hier ([SCK03]) um einen zyklusbasierten Simulator. Er wurde 2002 von der Universität Stanford entwickelt und ist in Java geschrieben. Die Akzentuierung des Entwurfs liegt auf der Anwendung Filesharing, daher verfügt er über eine ausgefeilte Modellierung der Verteilung von Dateien nach Kategorie und Popularität und gutartigen wie bösartigen Peers, die sich an echten Messwerten orientiert. In der Simulation können einige Messwerte visualisiert werden, so die Zahl der falsch bzw. richtig beantworteten Anfragen, der Netzwerkgraph, der Eigentrust-Graph, Verbindungen und kürzeste Pfade. Zusätzlich können pro Knoten Statistiken gesammelt werden P2PNetSim Auf der Grundlage von P2PNetSim wird in dieser Arbeit der Benchmark SimBench entwickelt. P2PNetSim ist am Lehrgebiet Kommunikationsnetze der Fernuniversität in Hagen entstanden und in Java geschrieben. Die Flexibilität beim Einsatz des Simulators ermöglicht nicht nur die Analyse von Peer-to-Peer-Protokollen, sondern auch anderer Anwendungsgebiete wie Untersuchung ansteckender Krankheiten oder sozialer Netzwerke. Die Simulation kann auf mehrere Rechenknoten verteilt erfolgen, die dann parallel arbeiten. Dadurch skaliert P2PNetSim bis zur Simulation von über einer Million Peers ( [FC009]). Als einziger der vorgestellten Simulatoren ist P2PNetSim proprietär, eine Open-Source- Version ist jedoch in Planung. Da er sich noch in einer frühen Phase der Entwicklung bendet, wird der Simulator ohne Peer-to-Peer-Protokolle geliefert, es ist keine Auswahl von Strategien möglich (z.b. zu Churn oder Verhalten des Benutzers) und es werden keine statistischen Daten gesammelt. P2PNetSim ist die Grundlage dieser Arbeit, in der einige dieser für einen Benchmark wichtigen Punkte bearbeitet werden. 17

18 2.1. EXISTIERENDE SIMULATOREN KAPITEL 2. GRUNDLAGEN Zusammenfassung Fast alle vorgestellten Programme sind diskrete ereignisbasierte Simulatoren (das heiÿt ein Scheduler synchronisiert Nachrichten, die zwischen simulierten Peers übertragen werden sollen), bei den wenigen zyklusbasierten Ausnahmen wurde es erwähnt. Viele davon wurden bereits nach kurzer Zeit nicht mehr aktiv weiterentwickelt (vgl. Tabelle). Obwohl fast alle vorgestellten Simulatoren Open-Source sind (unter den Lizenzen GPL oder Apache) und nach 2001 geschrieben wurden, ist die Software mit oder ohne Quelltext einiger Simulatoren bereits nur noch schwer zu nden. Der Schwerpunkt der Simulatoren ist sehr unterschiedlich gesetzt. Während z.b. NS-2 ein Netzwerk in groÿer Detailtreue abbildet, hat er keine Unterstützung zur Implementierung von Peer-to-Peer-Protokollen. Benutzerverhalten, Dateidownload, verteilte Hashtabellen (DHT), Fluktuation (Churn) usw. müssen selbst implementiert werden. Fertig umgesetzte Protokolle existieren auÿer für NS-2 für alle anderen Simulatoren, sowie Unterstützung für Churn in ihrer Grundausstattung. Eine vermutete Ursache für die Vielfalt sind Unzulänglichkeiten existierender Simulatoren, was viele Forscher dazu veranlasst, ihr eigenes System zu entwickeln. Der hier interessanteste Punkt ist jedoch die Unterstützung für einen Benchmark, und das ist gleichzeitig der Schwachpunkt in der aktuellen Forschung: Zur Ermittlung von Messwerten ist manchmal überhaupt keine Möglichkeit angeboten, gelegentlich ist ein Mechanismus angedacht, muss jedoch selbst programmiert werden. Werden jedoch verschiedene selbst programmierte Messungen eingesetzt, können sogar die Ergebnisse von Experimenten unter dem gleichen Simulator nicht vergleichbar sein. Es gibt keine einheitlichen Metriken und kein einheitliches Messverfahren. Bei Messungen in existierenden Peer-to-Peer-Netzen wurden teilweise widersprüchliche Ergebnisse erzielt. In Artikeln, die Ergebnisse mittels Simulatoren ermitteln, wurden Hunderte von Simulatoren benutzt. Zum groÿen Teil entwickelten die Forscher eigene Simulatoren oder gaben nicht an, welcher Simulator benutzt wurde ([NBL + 06]). Das macht die Ergebnisse schwer nachvollziehbar und somit auch kaum vergleichbar Vorschläge Aus dieser Zusammenfassung lassen sich folgende Vorschläge für einen Simulator und den darauf basierenden Benchmark ableiten: Wünschenswert wäre eine von möglichst vielen Forschern gemeinsame genutzte Simulationsumgebung oder verschiedene Simulatoren, deren Ergebnisse miteinander vergleichbar sind. Hierzu müssen diese natürlich die unterschiedlichen Anforderungen der Forscher erfüllen. Es muss einen Prozess in Richtung Standardisierung der Benchmarks geben. Messverfahren, Metriken, Qualitätsmerkmale sollten auch über die einzelne Untersuchung hinaus vergleichbar sein. Die Ergebnisse der Simulation sollten einfach und ohne Eingrie in den Quelltext des Simulators zu ermitteln sein, um für statistische Analyse zur Verfügung zu 18

19 2.1. EXISTIERENDE SIMULATOREN KAPITEL 2. GRUNDLAGEN Messwerte/ Statistiken Auswertung GPS nein gering nein Java keine keine Neurogrid nein hoch ( ) nein Java minimal keine NS-2 ja gering nein C++ ja ja Overlay ja mittel (10 5 ) ja Java programmierbar keine Aktiv Skalierbarkeit verteilt Programmiersprache Weaver PeerfactSim.- ja sehr hoch (10 6 ) nein Java ja ja KOM P2PNetSim ja sehr hoch (10 6 ) ja Java - - P2PRealm nein mittel (10 5 ) ja Java Topologie Visualisierung mit Tool P2PSim nein gering nein C++ minimal Visualisierung mit Tool PeerSim ja sehr hoch (10 6 ) nein Java ja ja PlanetSim ja mittel (10 5 ) nein Java Topologie Visualisierung mit Tool nein gering nein Java keine keine Query-Cycle- Simulator Tabelle 2.1: Überblick über Simulatoren 19

20 2.2. BENCHMARK FÜR EINE SIMULATION KAPITEL 2. GRUNDLAGEN stehen. Dabei soll die Reproduzierbarkeit des Simulationslaufs zur späteren Überprüfung möglich sein, indem z.b. der Zustand des Simulators gesichert werden kann, oder der Simulationslauf von Pseudo-Zufall oder einem Skript gesteuert wird. Eine groÿe Entwicklerbasis, um die Simulationsumgebung weiterzuentwickeln, ist hierbei hilfreich. Open-Source hat das Potenzial, eine Gemeinschaft (Community) zu mobilisieren. Allein die Verfügbarkeit des Quelltextes genügt dabei nicht: Auch viele Open-Source-Simulatoren sind bereits in der Versenkung verschwunden. Honung auf positive Aufwärtsspirale: Viele Untersuchungen mit einem bestimmten Simulator steigern dessen Bekanntheitsgrad und lassen ihre Ergebnisse in den Simulator zurückieÿen, sie verbessern so Qualität und Funktionalität der Anforderungen. Die Kriterien zur Tauglichkeit eines möglichst generischen Peer-to-Peer-Simulators für den wissenschaftlichen Einsatz herauszuarbeiten ist ein interessantes und bisher wenig bearbeitetes Forschungsfeld (siehe [NLB + 07]). 2.2 Benchmark für eine Simulation Benchmark ist ein Begri, der unter Informatikern häug intuitiv verwendet wird. Zur Entwicklung eines Benchmarks ist die genauere Betrachtung dessen, was ein Benchmark eigentlich ist, eine wichtige theoretische Grundlage des weiteren Vorgehens. Eine grundlegende sprachliche Denition wird in Unterabschnitt festgelegt. Es zeigt sich, dass der Begri Benchmark seit Jahrhunderten für Vergleichstests benutzt wurde. Da der Benchmark automatisiert eingesetzt werden soll, grenzen wir den Begri noch ab von der Verwendung in sonstigen Fachgebieten auÿerhalb der Informatik (Unterabschnitt 2.2.2). Ein Benchmark in einer Simulation unterscheidet sich von aktiven oder passiven Messungen im Internet, dies wird in Unterabschnitt diskutiert und ergänzt durch spezielle Eigenschaften, die ein solcher Benchmark haben sollte (Unterabschnitt 2.2.4) Der Begri Benchmark Als erster Schritt werden einige Denitionen angegeben, um sich dem Begri und der Bedeutung von Benchmark anzunähern. Die beiden am häugsten benutzten englischen Wörterbücher Oxford English Dictionary (OED) und Merriam-Webster English Dictionary denieren das englische Wort benchmark wie folgt: Main Entry: bench mark Pronunciation: \"bench- märk\ Function: noun Date: circa usually bench mark : a mark on a permanent object indicating elevation and serving as a reference in topographic surveys and tidal observations 2 a: a point of reference 20

21 2.2. BENCHMARK FÜR EINE SIMULATION KAPITEL 2. GRUNDLAGEN from which measurements may be made b: something that serves as a standard by which others may be measured or judged c: a standardized problem or test that serves as a basis for evaluation or comparison (as of computer system performance) Merriam-Webster English Dictionary, [mer09] benchmark noun 1 a standard or point of reference. 2 a surveyor's mark cut in a wall and used as a reference point in measuring altitudes. Oxford English Dictionary, [ask09] Übersetzt kann ein Benchmark also sein: eine Vergleichsmarke in der Geographie oder zur Höhenmessung, ein Referenzpunkt für Messungen, ein Standard, an dem andere gemessen oder beurteilt werden, ein standardisiertes Problem oder Test als Basis zur Evaluierung oder zum Vergleich. Ein Benchmark ist nach dieser Denition eindeutig ein Vergleich. Einzelne Messungen oder Statistiken machen noch keinen Benchmark aus, da das wesentliche Element des Vergleichs fehlt. Ein weiterer wichtiger Punkt ist der Standard- oder Referenzpunkt, der deniert werden muss und an dem der Vergleich erfolgen kann. Es gibt eine Vielzahl von deutschen Übersetzungen für das englische benchmark, unter anderem: Übersetzungen: Abrisspunkt, Bewertung, Bezugsmarke, Bezugsnorm, Bezugspunkt, Festpunkt [Vermessungswesen], Maÿstab, Orientierungswert, Richtwert [Statistik], Richtgröÿe, Vergleichslauf, Vergleichstest [Ausschnitt aus Ergebnissen von leo.org] Auch diese Übersetzungen bestätigen die erste Annäherung. Wesentlich sind hier Übersetzungen mit Bezug- oder Vergleich-, in denen wieder der vergleichende Charakter eines Benchmarks zum Ausdruck kommt. Erklärungen aus dem Informatikbereich, mit denen die erste Denition abgeschlossen werden soll, festigen diese Vorstellung: [Ein] Benchmark [ist ein] standardisiertes Verfahren, mit denen faire Leistungsvergleiche unter realistischen Einsatzbedingungen möglich sind. Diese Verfahren heiÿen Benchmarks, was am besten mit Bezugsmarke übersetzt wird. Problematisch bei solchen Messverfahren ist es, einerseits die Neutralität von Messungen und Ergebnisdarstellungen sowie andererseits die Praxisrelevanz der Benchmarks sicherzustellen. [Böt06] 21

22 2.2. BENCHMARK FÜR EINE SIMULATION KAPITEL 2. GRUNDLAGEN Ein Peer-to-Peer-Benchmark ist also ein Vergleich verschiedener Peer-to-Peer-Protokolle oder verschiedener Implementierungen oder unterschiedlicher Algorithmen eines Protokolls. Da Peer-to-Peer-Systeme eine Vielzahl von Eigenschaften aufweisen, lässt sich solch ein Vergleich nur bezüglich bestimmter Qualitäten dieser Protokolle durchführen. Hierzu müssen die Qualitäten bestimmt und quantiziert werden Abgrenzung Benchmarks existieren für eine Reihe von Anwendungsgebieten. Benchmarks aus anderen Fachgebieten wie der Geologie oder der Betriebswirtschaftslehre werden aus oensichtlichen Gründen von der Denition ausgeschlossen. Des Weiteren wird noch unterschieden zwischen quantitativen und qualitativen Benchmarks, letzteres kann z.b. die Bewertung der Benutzbarkeit einer Applikation durch einen Anwender sein. Durch diese subjektive Bewertung wird zwar eine vergleichbare Kennzahl gewonnen, diese Kennzahlen sind jedoch nicht maschinell erfassbar. Im Sinne dieser Arbeit ist ein Benchmark beschränkt auf quantitativ und automatisiert in Experimenten erfassbare Werte Besonderheiten des Benchmarks bei einer Simulation Ein herkömmlicher Benchmark in Peer-to-Peer-Netzen gewinnt seine Daten entweder passiv durch Messungen an Knotenpunkten des Internets (z.b. Backbone-Router bei einem zentralen Carrier) oder aktiv durch präparierte Clients, die tatsächlich oder vorgeblich am Peer-to-Peer-Netzwerk teilnehmen. Beide Methoden haben jedoch Einschränkungen bezüglich der Betrachtung des gesamten Netzes, die in einer Simulation nicht gegeben sind. Passive Messung an Knotenpunkten Hierzu werden an Knotenpunkten des Internets Messsonden aufgestellt, z.b. ein Router mit Statistikfunktion. Von allen IP-Paketen, die den Router passieren, werden nach speziellen Filtern die passenden ausgewählt. Der Filter vergleicht im einfachsten Fall die Portnummer des Pakets mit den Standardports des zu überwachenden Protokolls. Auch eine Analyse des Inhalts des Paketes ist möglich (evtl. ist am Aufbau das Protokoll unabhängig von der Portnummer erkennbar), aber aufgrund der hohen Zahl der Pakete an Knotenpunkten oft nicht praktikabel. Diese Methode liefert bei passender Wahl der Knotenpunkte einen guten Überblick über einen Ausschnitt des real existierenden Peer-to-Peer-Netzes. Für eine gesamte Betrachtung eines weltweiten Netzes ist die Wahl der Knotenpunkte und die Installation von Sonden sehr aufwendig und nicht praktikabel. Oensichtlich können nur übertragene Pakete gemessen werden, nicht jedoch innere Zustände der Peers. Wenn nur nach Portnummer geltert wird, entgehen dieser Methode alle Clients, die nicht auf Standardports arbeiten. Es wird angenommen, dass dieser Faktor vernachlässigbar ist. 22

23 2.2. BENCHMARK FÜR EINE SIMULATION KAPITEL 2. GRUNDLAGEN Aktive Messung mit Sonden-Peers Clients des zu untersuchenden Protokolls werden speziell angepasst oder neu implementiert. Diese Clients verbinden sich dann mit dem Peer-to-Peer-Netzwerk, führen einige Operationen durch (z.b. Ping, Suche), gewinnen so Informationen über ihre Nachbarschaft und schreiben alle relevanten gewonnenen Messwerte mit. Damit lässt sich ein einzelner Peer detailliert untersuchen. Gemessen werden kann jede Information, über die der Sonden-Peer verfügt (ankommende und abgehende Pakete, sowie innerer Zustand des Peers) - jedoch auch nur diese. Ein Überblick über das Peer-to-Peer-Netzwerk ist nur bis zur Sichtweite des Sonden-Peers möglich, insbesondere Kommunikation zwischen dritten Peers oder ihr innerer Zustand sind nicht direkt messbar. Benchmark einer Simulation Ein Benchmark in einer Simulation kann sowohl globale Informationen über das Netzwerk nutzen als auch innere Informationen der teilnehmenden Peers und bietet daher eine vollständigere Sicht. Die Daten der passiven Messungen werden durch die globale Sicht der Simulation ermöglicht. Dabei ist es unerheblich, ob diese Daten passiv ermittelt werden oder die Peers sie aktiv zur Verfügung stellen. Die Daten der aktiven Messungen werden unterstützt, da jeder Peer entsprechend modiziert werden kann, zu bestimmten Zeitpunkten vordenierte Operationen durchzuführen. Da ohne diese Operationen in der Simulation wenig passiert (auÿer Operationen zum Aufbau der Netztopologie), ist die Unterscheidung zwischen aktiver und passiver Messung in der Simulation nicht weiter relevant. Die Beschränkungen der Simulation liegen in ihrer Qualität. Insbesondere die Netzwerkebene wird aus Performancegründen häug nicht nachgebildet, was eine direkte Messung von Paketen unmöglich macht. Weiter ist die Modellierung des Netzwerkverhaltens (Verhalten im Normalbetrieb wie Routen sowie Störungen, z.b. Ausfälle) und des Benutzerverhaltens (bspw. Operationen wie Initiieren einer Suche, Verhaltensmodell wie böswilliger Anwender) maÿgeblich für die Qualität des Benchmarks verantwortlich. Der Aspekt der Modellierung wird in Abschnitt 3.1 vertieft. Mängel in der Qualität können durch sorgfältige Implementierung minimiert werden. Diese Parameter liegen in der Hand des Anwenders Eigenschaften des Benchmarks Aus der grundlegenden Eigenschaft eines Benchmarks, ein vergleichender Test zu sein, lassen sich einige Forderungen nach wünschenswerten Eigenschaften ableiten. In diesen Forderungen sind die Abgrenzung und die Tatsache, dass es sich um eine Simulation eines verteilten Systems handelt, bereits berücksichtigt. Der Benchmark in der Simulation sollte für die Anwendung relevant sein, reproduzierbare Ergebnisse liefern und dabei wie die Simulation selbst skalieren. Die ermittelten Ergebnisse sollen vergleichbar sein, und trotz all dieser Forderungen sollte der Benchmark so einfach wie möglich bleiben. Im Folgenden werden diese Eigenschaften kurz erklärt. 23

24 2.2. BENCHMARK FÜR EINE SIMULATION KAPITEL 2. GRUNDLAGEN Relevanz Die gemessenen Werte sollten realistisch sein. Insbesondere sollte das simulierte Verhalten des Netzes und des Benutzers im Normalbetrieb typisch sein für den gewählten Anwendungsbereich. Ebenso sollten erzeugte Fehler im System typisch sein [CBMM08]. Für die Simulation bedeutet das eine hinreichende Realitätsnähe, die praktisch durch Modellierung der verschiedenen Schichten (Benutzerschicht, Netzwerkschicht) umgesetzt werden kann. Reproduzierbarkeit Die Ergebnisse des Benchmarks sollen reproduzierbar, also wiederholbar und nachvollziehbar, sein. Das bedeutet, der Benchmark setzt sich aus einer Folge von Experimenten zusammen, die relativ unabhängig voneinander ausgeführt werden können, und die einen denierten Anfangszustand und eine Folge von Ereignisse besitzen. Zu jeder neuen Messung wird das System in diesen denierten Anfangszustand zurückversetzt [CBMM08]. Insbesondere in der Simulation ist die Forderung nach Reproduzierbarkeit gut zu erfüllen, wenn sie bei der Implementierung berücksichtigt wird. Skalierbarkeit Im Kontext eines verteilten Systems, genauer einer verteilten Simulation, muss der Benchmark selbst ebenfalls skalierbar sein. Hier ist [OPH03] zu erwähnen, welches das Konzept des dezentralisierten Benchmarks einführt. Insbesondere betrit dies zwei Komponenten: die Steuerung des Testablaufs und das Einsammeln der Messwerte. Die Steuerung des Testablaufs wird weiter unterteilt in Lasterzeugung (engl. load injection, Erzeugung normaler Betriebslast) und Störungsgeneration (engl. fault injection, Erzeugung von Störungen im System). Folglich müssen diese beiden Komponenten in einer verteilten Simulation ebenfalls verteilt implementiert werden. Diese Anforderung ist zwar nicht so wichtig wie in echten verteilten Systemen, da die Simulation nicht notwendig in Echtzeit ablaufen muss, aber wünschenswert. Die Metriksammlung kann prinzipiell online erfolgen, d.h. die Daten werden ermittelt, während der Benchmark läuft, oder oine, wobei jeder Knoten seine Daten speichert und am Ende der Simulation werden alle Daten eingesammelt. In Live-Systemen könnte der Online-Ansatz die Messwerte stören, aber der Benchmark hängt nicht von den Knoten ab, die am Ende des Laufs noch leben, um Daten von ihnen einzusammeln. In der Simulation lässt sich das jedoch trennen, so dass die Nachrichten zum Sammeln der Messwerte nicht in die statistischen Daten einieÿen, sofern das Problem in der Implementierung berücksichtigt wurde. Ferner können Daten, die online ermittelt werden, während des Laufs schon besser aggregiert werden (z.b. Summe, Minimum etc. über alle Knoten). Damit ist der Online-Ansatz bei einem Benchmark in einer Simulation vorzuziehen. Bei verteilten Systemen mit hoher Fehlertoleranz muss der Benchmark diese Eigenschaft ebenfalls besitzen, im Simulator lässt sich jedoch die Komponente, die für die Datensammlung zuständig ist, von den Störungen trennen. 24

25 2.3. QUALITÄTSMODELL KAPITEL 2. GRUNDLAGEN Vergleichbarkeit Die Ergebnisse des Benchmarks sollten übertragbar und vergleichbar sein. Insbesondere sollen Ergebnisse innerhalb des selben Simulators, z.b. für unterschiedliche Protokolle, möglichst direkt miteinander vergleichbar sein. Dazu muss die theoretische Grundlage des Benchmarks gut ausgearbeitet und standardisiert sein. Schwieriger zu erfüllen ist die Vergleichbarkeit zwischen verschiedenen Simulatoren. Mit genauen Denitionen des Benchmarks bietet sich selbst dazu die Möglichkeit, sofern das grundlegende Modell der Simulatoren vergleichbare Ergebnisse liefert (wenn also z.b. beide diskrete ereignisorientierte Simulatoren sind und bzgl. der Netzwerkschicht ähnliche Daten liefern). Prinzipiell kann innerhalb des Simulators die Funktionsweise eines anderen Simulators simuliert werden. Ob der wahrscheinlich hohe Aufwand dazu im Verhältnis zum erhoten Ergebnis steht, müsste untersucht werden und soll in dieser Arbeit nicht weiter berücksichtigt werden. Einfachheit Die Denition des Benchmarks sollte ersichtlich und nachvollziehbar das Merkmal beschreiben, das bewertet werden soll. Das macht Einfachheit zu einer wünschenswerten Eigenschaft des Benchmarks. Komplexität erhöht die Wahrscheinlichkeit für Fehler, das ist ein weiterer Grund für Einfachheit. Einfachheit bezieht sich auf alle Schichten: die Denition des Benchmarks, aber auch auf den Ablauf des Tests und die Implementierung selbst. Die Forderung der Einfachheit steht in Konkurrenz zur Forderung der Relevanz: Je realitätsnäher und detaillierter die Testszenarien sind, desto komplexer werden sie (trade-o ). Im Zweifelsfall ist dabei der Einfachheit der Vorzug zu geben: Jeder Benchmark soll so einfach wie möglich und so relevant wie nötig entworfen werden. 2.3 Qualitätsmodell Ein Benchmark soll verschiedene Merkmale erfassen und damit die Qualität eines Peer-to- Peer-Systems bestimmen, genauer gesagt eine bestimmte Qualität, wobei Qualität hier synonym zu Eigenschaft verstanden wird. In diesem Abschnitt wird diskutiert, welche Eigenschaften eines Protokolls für einen Benchmark in Frage kommen und wie sie deniert sind. Eigenschaften sind noch abstrakt und werden zuerst beschrieben und dann durch Metriken konkretisiert. Metriken wiederum werden durch Messwerte beschrieben. Dazu werden einige Beispiele gegeben. Der grundsätzliche Zusammenhang zwischen Eigenschaft, Metrik und Messwert wird in Abbildung 2.1 auf Seite 31 veranschaulicht. Ein Benchmark prüft eine Eigenschaft, welche durch eine oder mehrere Metriken beschrieben wird. Metriken können aus genau einem Messwert bestehen oder aus mehreren Messwerten zusammengesetzt sein. 25

26 2.3. QUALITÄTSMODELL KAPITEL 2. GRUNDLAGEN Eigenschaften eines Protokolls In Peer-to-Peer-Systemen lässt sich eine Vielzahl von Eigenschaften und möglichen Metriken ausmachen. Die Güte jeder Eigenschaft wird durch einen oder mehrere Messwerte bestimmt, um durch diese Werte eine Quantizierung vornehmen zu können. Zur Vergleichbarkeit von Eigenschaften über verschiedene Protokolle sollte diese Zuordnung x sein, d.h. die in einer Messung denierten zugeordneten Metriken sollten in allen vergleichenden Messungen identisch sein. Um ein einheitliches Verständnis der grundlegenden Eigenschaften zu fördern, werden diese deniert sowie einige beispielhafte Messwerte gegeben, mit denen die Eigenschaft quantiziert werden kann. Ansätze für mögliche Eigenschaften Ein Benchmark dient dazu, bestimmte Eigenschaften in einem Produkt zu messen und diese dann zu vergleichen. Im speziellen Fall handelt es sich um Peer-to-Peer-Protokolle. Es liegt also nahe, sich zuerst an existierenden Aufzählungen von Eigenschaften und Kriterien zu orientieren. Allgemeine Ansätze zur Softwarequalität (z.b. ISO 9000) sind auf den Bereich Peer-to- Peer nicht anwendbar. Viel versprechender sind Qualitätskriterien verteilter Systeme, die in vielen Punkten wegweisend und grundlegend für Peer-to-Peer-Systeme sind. Hier nennt Coulouris in [CDK05] die Merkmale Oenheit, Nebenläugkeit, Skalierbarkeit, Sicherheit, Fehlertoleranz und Transparenz. Jede dieser Eigenschaften fasst eine Reihe von Merkmalen zusammen, und diese Eigenschaften können sehr gut auf den Peer-to-Peer-Bereich angewendet werden. In diesem spezielleren Bereich sind bereits eine Reihe von Listen von gewünschten Eigenschaften entstanden. Beispiele sind: Rollensymmetrie, Dezentralisierung, Selbstorganisation, Autonomie, Zuverlässigkeit und Verfügbarkeit ( [HD05]), Verteilungsgrad, Skalierbarkeit, Suchbarkeit, Bandbreitenezienz, Robustheit, Verschlüsselung und Anonymität ( [Göt05]), Handhabbarkeit, Informationskohärenz, Erweiterbarkeit, Fehlertoleranz, Sicherheit, Schutz (gegen politische Verfolgung) und Skalierbarkeit ( [Sch04]). Es fällt auf, dass die verschiedenen Autoren unterschiedliche Schwerpunkte setzen und andere Merkmale überhaupt nicht erwähnen. Dies kann durch die Spezialisierung der Forschung (unterschiedliche Anforderungen der Anwendungen) und die Dynamik der noch vergleichsweise jungen Informatikdisziplin Peer-to-Peer begründet sein. Eine einheitliche Einteilung von Eigenschaften existiert noch nicht. Beispiele Eine Taxonomie der Eigenschaften ist noch nicht bekannt, stellvertretend werden ein paar wichtige Eigenschaften vorgestellt, die sich gut in einem Benchmark untersuchen lassen: 26

27 2.3. QUALITÄTSMODELL KAPITEL 2. GRUNDLAGEN Verwaltungskosten Wie aufwendig ist der Betrieb des Netzwerks im Normalbetrieb? Wie viele Ressourcen werden verbraucht bei Vorgängen wie Join oder Ausfall eines Peers? Suchezienz Diese Eigenschaft kann sich beziehen auf die Korrektheit der Suche: Wird eine Antwort auf eine Suchanfrage (Lookup) geliefert, wird die richtige Antwort geliefert? Dies ist insbesondere in unstrukturierten Peer-to-Peer-Netzwerken interessant und wird im Folgenden als Sucherfolg bezeichnet. Ebenfalls Bestandteil der Suchezienz ist die Dauer, bis eine Antwort auf eine Suchanfrage eintrit. Die Antwort kann dabei positiv (Datum gefunden), negativ (Datum nicht gefunden) oder gar nicht (ein Timeout, ebenfalls negativ zu werten) sein. Lastverteilung beschreibt gewissermaÿen die Gerechtigkeit eines Peer-to-Peer-Protokolls bezüglich der Aufteilung der Ressourcen wie Speicherplatz oder Rechenzeit, das heiÿt das Verhältnis der Belastung von zentralen zu entfernten Peers, oder die Verteilung der Last insgesamt. Skalierbarkeit bezeichnet die Fähigkeit eines Peer-to-Peer-Netzwerks, sich an eine quantitativ wachsende Anzahl von Peers und/oder Daten anzupassen. Die Skalierbarkeit ist von besonderer Bedeutung für Peer-to-Peer-Protokolle und unterscheidet sich von den vorigen Eigenschaften, da sie für sich allein keine Eigenschaft darstellt. Ein vorhandener Benchmark wird stattdessen mehrfach mit einer vergröÿerten Menge an Peers und/oder einer gröÿeren Datenmenge durchgeführt. Diese neue Eigenschaft wird dann als Skalierbarkeit einer Eigenschaft, z.b. Skalierbarkeit der Suche, bezeichnet. Wenn ein Protokoll bezüglich einer für den Anwendungsbereich nötigen Eigenschaft nicht hinreichend genug skaliert, sagt man vereinfacht: das Protokoll skaliert nicht. Robustheit (oder Fehlertoleranz, hier synonym) beschreibt die Eigenschaft eines Peerto-Peer-Netzwerks, auch unter hoher Last und bei Fehlern (z.b. Ausfällen der Netzwerkstruktur, Nicht-Einhalten des Protokolls) ein speziziertes Leistungsniveau zu erhalten. Ähnlich wie Skalierbarkeit bezieht sich die Robustheit auf eine andere Eigenschaft, die unter Fluktuation (Churn), Simulationen von Fehlern oder Spitzenbelastung ermittelt und dann Robustheit der Eigenschaft genannt wird. Sonstige Eigenschaften Ausgenommen vom Benchmark sind Eigenschaften, für die keine messbaren Werte gefunden werden können. Eigenschaften von Softwarequalität und Merkmale, die für eine Bewertung einer Implementierung sicher eine Rolle spielen, sind Benutzerfreundlichkeit (bequem, intuitiv), Wartungsfreundlichkeit (modular, transparent), Erweiterbarkeit (stabil, dokumentiert) und Anpassbarkeit (portabel, exibel). Diese Merkmale sind nicht leicht quantitativ und noch schwerer automatisiert per Benchmark zu erfassen und werden deshalb hier nicht weiter verfolgt. Das gilt auch für Sicherheit (im Sinne von security), was oft unterteilt wird in Integrität, Vertraulichkeit, Verbindlichkeit (Nicht-Zurückweisbarkeit), Authentizität und Anonymität. Alle diese Eigenschaften sind nicht für einen Benchmark geeignet: Es lässt sich keine Messung durchführen, um festzustellen, ob ein Peer-to-Peer-Protokoll höhere Sicherheit als ein anderes besitzt. Eine solche Bewertung soll analytisch erfolgen. 27

28 2.3. QUALITÄTSMODELL KAPITEL 2. GRUNDLAGEN Ebenfalls im Bereich der Sicherheit angesiedelt, jedoch gut für einen Benchmark geeignet sind gezielte Angrie, deren Auswirkungen gemessen werden können. [AJB00] entwickelt hierzu ein interessantes Szenario, bei dem ein Prozentsatz von gezielt ausgewählten Knoten entfernt wird, und die Auswirkungen auf das Netzwerk gemessen werden. Im Sinne der hier entwickelten Kategorisierung ist ein solcher Angri als Szenario unter der Eigenschaft Robustheit einzuordnen Metriken Eine Metrik ist eine fest denierte Kenngröÿe, die die Ergebnisse verschiedener Messungen vergleichbar macht. Die Qualitäten, die untersucht werden sollen, müssen quantiziert werden. Dazu müssen zu jeder Eigenschaft eine oder mehrere Metriken gefunden werden, die diese Eigenschaft dann beschreiben. So wird die Eigenschaft in Zahlen ausgedrückt und kann über verschiedene Protokolle verglichen werden. Im Peer-to-Peer-Bereich können dabei auch Metriken deniert werden, die deutlich komplexer sind als herkömmliche Netzwerkmetriken. Beispielsweise muss eine Metrik, die die Topologie des Netzes beschreibt, komplexe Eigenschaften eines Graphen in vergleichbare Zahlen umsetzen (z.b. Gradverteilung, durchschnittliche Pfadlänge, usw. vgl. [New03]). Eine Metrik kann direkt einem Messwert entsprechen, oder sich aus mehreren Messwerten zusammensetzen. Messwerte sind direkt ermittelbare Werte für denierte Messgröÿen. Beispiele hierfür sind der Eingrad/Ausgrad (Anzahl der Nachbarn) eines Knoten oder die Antwortzeit auf eine Anfrage. Zusammengesetzte Metriken Die Zusammensetzung von Metriken soll an einem Beispiel verdeutlicht werden: Angenommen, zur Verfügung stehen zwei Messwerte Latenz und Bandbreite. Die Latenz ist die Zeit, die ein Paket zwischen Verlassen des einen Knotens bis zum Eintreen am Zielknoten benötigt, also die Zeit vom Absenden bis zum Empfang einer Nachricht zwischen zwei Knoten, und wird in Millisekunden gemessen. Bandbreite ist die Geschwindigkeit, mit der Daten zwischen zwei Knoten maximal übertragen werden können, gemessen in Bytes pro Sekunde. Um nun die Qualität der Übertragung verschiedener Protokolle zu beurteilen, könnte hier eine Metrik aus Latenz und Bandbreite zusammengesetzt werden, in der diese beiden Messwerte mit einer entsprechender Gewichtung eingehen. Das macht die Evaluierung der Ergebnisse leichter, denn statt mehreren Zahlen oder Graphen muss jetzt nur noch eine Zahl bzw. ein Graph betrachtet werden, um die Eigenschaft zu beurteilen. Allerdings bringt die Zusammensetzung auch Probleme mit sich. Die Problematik wird bei der Betrachtung zweier unterschiedlicher Anwendungen deutlich: Für eine Echtzeitanwendung wie Internettelefonie (Skype, SIP), bei der sich schon Verzögerungen von wenigen hundert Millisekunden subjektiv störend auf die Teilnehmer auswirken, spielt die Latenz eine groÿe Rolle. Die Bandbreite hingegen kann ignoriert werden, sofern nur genug Bandbreite zur Übertragung von Sprache zur Verfügung steht. Reicht die Bandbreite nicht einmal für einen einfachen Audio-Codec, spielt die Latenz keine Rolle mehr, da das System unbenutzbar ist. 28

29 2.3. QUALITÄTSMODELL KAPITEL 2. GRUNDLAGEN Für eine Filesharinganwendung hingegen, bei der sehr groÿe Dateien übertragen werden, ist selbst eine hohe Latenz von vielen Sekunden zu Beginn fast bedeutungslos, eine hohe Bandbreite bewirkt jedoch den Unterschied, ob der Download Stunden oder vielleicht sogar Tage dauert. An diesem Beispiel wird klar, dass eine Metrik für die Übertragung von Internettelefonie nicht auf Filesharing anwendbar ist und umgekehrt. Folglich muss eine Metrik speziell für jede Anwendung entworfen werden. Darstellung einer Metrik In gängigen Benchmarks für Subsysteme von Computern wie Grakkarten oder ganze Computersysteme wird oft die Leistung eines Systems in einer einzelnen Zahl ausgedrückt. Ein Beispiel für solch eine Kennzahl sind PassMark-Punkte des Benchmarks PassMark 2 oder 3DMark 3, z.b. diese Grakkarte hat 900 3D-Mark-Wert oder dieser Computer hat 1234 PassMark-Punkte (ein solcher Wert fasst dann verschiedenste Eigenschaften und Systeme zusammen, wie die Graphik, den Prozessor, Netzwerkeigenschaften, etc.). So wird suggeriert, dass sogar Laien die Leistungsfähigkeit verschiedener Systeme einfach damit evaluieren könnten, indem sie das Benchmark-Programm auf einem Systemen laufen lassen und die resultierende Zahl vergleichen. Hierzu enthält der Benchmark im Allgemeinen eine Datenbank mit Vergleichswerten unterschiedlicher Systeme. Es wäre nun recht praktisch, dieses Verfahren analog auf Peer-to-Peer-Systeme anzuwenden, und damit Aussagen zu erhalten wie Kazaa ist 70% skalierbar oder um Protokolle mit einer allgemeinen Peer-to-Peer-Metrik vergleichen zu können: Ihr Peer-to- Peer-Protokoll hat 1700 P2PMark-Punkte, damit ist es besser als Gnutella mit 1000 und Chord mit 1500 Punkten. Das Problem hierbei ist die Abhängigkeit von der Anwendung. Im Beispiel aus Unterabschnitt wird bereits klar, dass eine Metrik zwar zusammengesetzt werden kann, ihre Aussagekraft aber stark von der Anwendung abhängt. Ein anderes Gegenbeispiel ist eine Suchmetrik, die aus prozentualem Sucherfolg und der Suchzeit zusammengesetzt ist: Bei strukturierten Peer-to-Peer-Protokollen wie Chord spielt der Sucherfolg keine Rolle (da ein Datum immer gefunden wird), damit sind strukturierte nicht mit unstrukturierten Protokollen wie Gnutella vergleichbar. Mit einem Parameter, der die Wertigkeit angibt, mit der Zeit und Erfolg in die Metrik mit einieÿen, kann der Eekt nicht beseitigt werden: Der Messwert Sucherfolg ist bei unstrukturierten Protokollen wichtig, bei strukturierten bedeutungslos. Nur eine speziell für den Anwendungsfall konstruierte Suchmetrik kann so diese beiden Arten von Protokollen vergleichen. Abgesehen von der geringen Aussagekraft und der Uneinheitlichkeit der Bewertung verschiedener Protokolle führten die oben genannten Benchmarks für Hardware zu dem Eekt, dass Hersteller ihre Produkte speziell für populäre Benchmarks optimieren, wobei die tatsächliche Leistung nur eine untergeordnete Rolle spielt. Hier wird klar, dass auch im Hardwarebereich Benchmarks keine vollständige Evaluierung einer Komponente ermöglichen. Für genaue Aussagen müssten auch hier die Metriken speziell für die Anwendung entworfen werden - und das schlieÿt eine allgemeingültige Metrik aus

30 2.4. GNUTELLA KAPITEL 2. GRUNDLAGEN Eine Metrik für Peer-to-Peer-Systeme wird in Abhängigkeit von einer anderen Gröÿe dargestellt. Beispielsweise interessiert bei einer Suche, wie ezient sie in Abhängigkeit von der Anzahl der Knoten oder der Daten funktioniert. Eine Angabe als einzelne Kenngröÿe ist hier nicht sinnvoll, sondern die Metrik wird in einer Verteilungsfunktion meist graphisch dargestellt. 2.4 Gnutella Das Gnutella-Protokoll wurde im Jahr 2000 von Frankel und Pepper entwickelt ( [Cli01]). Das Ende von Napster als freie Plattform zum Dateientausch durch die Abschaltung des zentralen Napster-Servers war noch in frischer Erinnerung, und daher ist Gnutella konzipiert als ein Peer-to-Peer-Protokoll völlig ohne zentrale Strukturen und extrem robust gegen Angrie oder Fehler. Betritt ein neuer Knoten das Netzwerk, sendet er zu einem bekannten Peer eine Ping- Nachricht. Diese Nachricht wird von jedem Peer mit einer Pong-Nachricht beantwortet und an dessen Nachbarn weitergeleitet (Broadcast). Als Antwort darauf erhält der neue Peer eine Reihe von Pong-Nachrichten, die er in einer Liste möglicherweise aktiver Gnutella-Clients verzeichnet. Der Prozess, bei dem ein Peer eine Nachricht an alle anderen Nachbarn weiterreicht, heiÿt Fluten (engl. ooding). Die Grundlage des entstehenden Graphen ist also zufällig, abhängig davon, welche Nachbarn gerade erreichbar sind und welche Nachbarn sie ihrerseits wiederum haben. Es gibt keine zentrale Kontrollinstanz und das Verhalten der einzelnen Benutzer ist nicht koordiniert. Trotzdem unterliegt die Struktur des Graphen gewisse Gesetzmäÿigkeiten, so folgt z.b. die Verteilung der Grade der Knoten der Pareto-Verteilung und der Graph besitzt Small-World-Eigenschaften. Auch die Suche nach einem Datum ist bei Gnutella mit Fluten gelöst. Ein Peer sendet seine Suchanfrage (Nachricht vom Typ Query) an alle seine Nachbarn, diese reichen die Anfrage weiter an ihre Nachbarn, und so weiter, bis eine voreingestellte Lebensdauer der Nachricht erreicht ist. Jeder Peer, der eine Datei mit den gewünschten Suchkriterien besitzt, sendet eine Query-Hit-Nachricht. Der ursprüngliche Peer kann diese Datei nun direkt herunterladen. ( [MS07]). Ein Nachteil von Gnutella ist nun, dass jeder Peer nur Suchergebnisse aus seiner unmittelbaren Nachbarschaft erhält. Ist die gesuchte Datei nur einen Nachbarn weiter entfernt vorhanden, wird sie nicht gefunden. Man könnte den Radius der Suche einfach vergröÿern, wenn sich dadurch nicht noch das zweite Problem verschärfen würde: Der Vorgang des Flutens bei Such- und Ping-Nachrichten ist für die Robustheit von Gnutella verantwortlich, sorgt aber für hohe Belastung des Netzwerks durch eine hohe Anzahl an Nachrichten. Das Fluten ist vorteilhaft für Netzwerke mit starker Fluktuation: Jeder Peer ist aktuell über seine gesamte Umgebung informiert. Ist die Umgebung nicht so dynamisch, würden auch weniger Informationen genügen. Für beide Probleme gibt es verschiedene Ansätze. Eine relativ einfache Lösung ist das Konzept der Random-Walks bei der Suche: Anstelle eine Suchanfrage an alle Nachbarn weiterzuleiten, wählt jeder Peer nur einen einzigen Nachbarn zufällig für die Weiterleitung aus. Damit vervielfältigen sich die Nachrichten nicht und die maximale Suchtiefe 30

31 2.5. ZUSAMMENFASSUNG KAPITEL 2. GRUNDLAGEN Benchmark Benchmark Eigenschaft Eigenschaft Metrik Metrik Metrik Messwert Messwert Messwert Abbildung 2.1: Zusammenhang zwischen Benchmark, Qualitäten und Messwerten kann wesentlich höher gewählt werden. Andererseits sind so die Informationen über die unmittelbare Nachbarschaft unvollständig. Das ursprüngliche Gnutella und die Erweiterung der Random-Walks wird Objekt verschiedener Benchmarks in Kapitel 5 auf Seite Zusammenfassung Verschiedene Simulatoren bieten Möglichkeiten, mehr oder weniger aufwendig Messwerte und statistische Daten zur Simulation zur ermitteln, allerdings erschwert die Uneinheitlichkeit der Simulatoren und mangelnde Vorgaben, die Ergebnisse zu vergleichen. Daraus wurden wichtige Eigenschaften für eine Simulation, die als Grundlage für den Benchmark dient, abgeleitet. Denn ein Benchmark ist ein vergleichender Test, um Eigenschaften verschiedener Peer-to- Peer-Protokolle zu bewerten. Dabei soll der Benchmark relevant bezüglich des gewählten Anwendungsbereichs sein, nachvollziehbare Ergebnisse, d.h. gut reproduzierbare und vergleichbare Ergebnisse, liefern, selbst gut skalieren, und trotzdem relativ einfach sein. Das Qualitätsmodell deniert den Zusammenhang zwischen einem Benchmark und den zu ermittelnden Messwerten. Die Qualität oder Eigenschaft, die bestimmt werden soll, wird durch Metriken ausgedrückt. Metriken wiederum werden durch Messwerte gebildet, so dass sich die Qualität beziern lässt (siehe Abbildung 2.1 auf Seite 31). Dieser Zusammenhang wird für jeden Benchmark individuell deniert, gilt dann aber als feste Zuweisung, so dass der Benchmark auf verschiedene Protokolle angewendet werden kann. Durch die Quantizierung und die feste Zuweisung wird der in Unterabschnitt erhobenen Forderung nach Vergleichbarkeit Genüge getan. Eine allgemeingültige Metrik, die als einzelne Zahl ausgedrückt wird (P2PMark), ist nicht möglich. Eine Metrik wird dabei im Allgemeinen in Abhängigkeit von einer anderen Gröÿe (wie der Anzahl der Knoten) ausgedrückt, so dass sich eine Verteilungsfunktion ergibt. Konkrete Beispiele für Metriken nden sich in Unterabschnitt

32 3 SimBench Nachdem in Kapitel 2 auf Seite 14 geklärt wurde, was ein Benchmark ist, und was er messen kann, wird jetzt speziell auf SimBench eingegangen. Der erste Teil (Abschnitt 3.1) beschreibt die Modellierung des Verhaltens während des Simulationsablaufs. In Abschnitt 3.2 werden diese Modellierungsebenen in Komponenten abgebildet. Für einen Benchmark müssen diese Komponenten teilweise konguriert werden, um die Nachvollziehbarkeit zu gewährleisten. Die Konguration ist Teil der Denition von SimBench, welche dieses Kapitel in Abschnitt 3.3 abschlieÿt. 3.1 Modellierung des Verhaltens Der einfachste Fall ist eine statische Simulation, d.h. eine gegebene Anzahl von Peers und eine Menge von Daten, die sich dann austauschen. Diese isolierte Betrachtung und Messung eines Protokolls unter Laborbedingungen kann schon wichtige Hinweise liefern. Darüber hinaus ist für den Benchmark auch realistisches Verhalten wesentlich. Peer-to- Peer-Netzwerke zeichnen sich durch eine hohe Dynamik aus, beispielsweise durch Unbeständigkeit in Bezug auf die teilnehmenden Peers, aber auch auf fehlerhaftes Verhalten. Ein Algorithmus ist nur für echte Peer-to-Peer-Netzwerke geeignet, wenn er sich nicht nur unter Idealbedingungen sondern auch unter der typischen Fluktuation wie erwartet verhält. Es folgen also noch einige Betrachtungen zur realitätsnahen Modellierung einer Peer-to-Peer-Simulation. Je realistischer die Simulation, desto besser die Ergebnisse, gilt zwar nur mit Einschränkungen, die in Unterabschnitt behandelt werden. Trotzdem muss der Modellierung des Systems und seines Verhaltens besonderes Augenmerk geschenkt werden. Aus diesem Grund werden im Folgenden verschiedene Dynamiken betrachtet, die im idealen Modell nicht auftreten, jedoch in der Wirklichkeit. Mathematische Modelle für das Verhalten von Peer-to-Peer-Systemen im Internet wurden schon oft Gegenstand der Forschung [CLL02, SGG03, BSV03]. Diese (und andere) Arbeiten haben über einen längeren Zeitraum Peer-to-Peer-Systeme in freier Wildbahn beobachtet. Ihre Messergebnisse unterscheiden sich zum Teil erheblich je nach Peer-to-Peer-Protokoll, d.h. realistische Aussagen sind nur für das Protokoll möglich, das in der Arbeit behandelt wird. Aus diesem Grund wird eine Schnittstelle für SimBench entwickelt, für die sich verschiedene Modelle nachträglich implementieren lassen. Für diese Schnittstelle werden dann einige einfache Modelle exemplarisch umgesetzt Möglichkeiten der Modellierung Die Simulation soll so modelliert werden, dass sie sich möglichst realitätsnah verhält. Benutzt man die Ergebnisse anderer Untersuchungen, beispielsweise die Länge der Sitzungen betreend, bieten sich zwei Möglichkeiten: Die von den anderen Untersuchungen 32

33 3.1. MODELLIERUNG DES VERHALTENS KAPITEL 3. SIMBENCH ermittelten Daten können direkt in die Simulation einieÿen (die Sitzungslängen werden genau so implementiert, wie die Untersuchung es ermittelte), oder es wird ein mathematisches Modell gefunden, das die ermittelten Daten möglichst ähnlich abbildet. Der erste Ansatz hat den Nachteil, nicht besonders exibel zu sein. Mit einem mathematischen Modell stellt man fest, dass die Verteilung der Sitzungslängen einem gewissen Schema folgt, z.b. der Normalverteilung, und lässt die Sitzungen zufällige Längen haben, die alle zusammen normalverteilter Wahrscheinlichkeit folgen. Dieser Ansatz ist einfacher zu implementieren und bietet vielfältige Möglichkeiten für unterschiedliche Kongurationen, die alle dem gleichen Modell folgen. Deshalb wird der Ansatz der mathematischen Modellierung hier weiter verfolgt. Vorsicht ist geboten bei Extremwerten, die nicht Teil der ursprünglichen Untersuchung waren: Möglicherweise liefert das mathematische Modell hier unrealistische Werte. Eine Alternative ist das vereinfachte Modell: Anstatt die Wirklichkeit möglichst genau nachzubilden, kann man beispielsweise bei der Untersuchung der Auswirkungen von Fluktuation (Churn) auf das Peer-to-Peer-Protokoll einfach in jedem Simulationsschritt eine bestimmte zufällige Zahl (innerhalb gewisser Grenzen) von Peers anweisen, das Netzwerk zu betreten oder zu verlassen. Dabei ist es oft nicht nötig, dass ihre Sitzungslänge einer bestimmten Verteilung folgt, sondern nur, dass Churn stattndet. Häug genügt das vereinfachte Modell, welches vor allem die Forderung der Einfachheit unterstützt Schichten der Modellierung Es gibt verschiedene Ansätze, die das Gesamtsystem in Teilbereiche unterteilen, um die Modellierung zu vereinfachen. Dependability Benchmarks unterscheiden Workload und Faultload. Workload ist die Last auf das System im Normalbetrieb, im Fall von Peer-to- Peer beinhaltet das den Aufbau und die Organisation des Peer-to-Peer-Systems sowie vom Benutzer angestoÿene Vorgänge, solange das Gesamtsystem noch ideal fehlerfrei arbeitet. Faultload wird die Last genannt, wenn zu diesem Normalbetrieb zusätzlich Fehler (z.b. Ausfall einer Ressource) generiert werden. [CBMM08] Ein anderer Ansatz nennt die drei Teilmodule Lasterzeugung (Erzeugung normaler Last), Metriksammlung (Einsammeln der Daten) und Störungsgeneration (Erzeugung von Fehlfunktionen) ([OPH03]). Der hier gewählte Ansatz ist eine Unterteilung vergleichbar dem TCP-Schichtenmodell. Im Folgenden wird das gesamte Peer-to-Peer-System in Ebenen unterteilt, für die jeweils Parameter bestimmbar sind, die die Dynamik ausmachen. Ein solcher Ansatz, der das System in drei Schichten teilt, veranschaulicht gut die Ebenen, auf denen die Modellierung stattnden muss, und wird deshalb im Folgenden gewählt. Die Unterteilung in Netzwerk, Overlay und Benutzer kommt der Simulation entgegen. Zum einen lässt sich die Implementierung an diesem Modell orientieren, zum anderen existiert kein Anwender in der Simulation. Deshalb wird keine explizite Anwendungsschicht eingeführt, diese wird mit der Benutzerebene zusammen betrachtet Netzwerkebene Die Netzwerkebene wird von vielen Faktoren mitbestimmt, die ihre Ursache in der physischen Technik und Topologie haben. Für eine realistische Simulation sollte die Netzwerk- 33

34 3.1. MODELLIERUNG DES VERHALTENS KAPITEL 3. SIMBENCH Netzwerk (Simulator) Overlay (Protokoll) Benutzer (Fluktuation, Dateien, Strategie) Abbildung 3.1: Schichten der Modellierung ebene nicht statisch sein und optional sollten Fehlfunktionen simuliert werden können. Diese Faktoren bestimmen teilweise wesentlich die resultierende Peer-to-Peer-Struktur und das Verhalten. Die Faktoren lassen sich grob in zwei Gruppen einteilen: Die Topologie des Underlay-Netzes selbst, sowie Fehler und Ausfälle im Underlay. Topologie Im Allgemeinen werden die Peers nicht gleichmäÿig verteilt sein, sondern Cluster bilden (Städte), die über wenige Leitungen miteinander verbunden sind. Zwischen und innerhalb der Cluster bestehen wiederum Unterschiede in der möglichen Bandbreite. Zu diesem Thema existieren bereits umfangreiche Forschungsergebnisse, die genutzt werden können. Ein Ergebnis dieser Forschung sind die Implementierungen sogenannter Topologiegeneratoren. Ein konkretes Modell sind die Small-World-Graphen, die sich mit dem Algorithmus von Watts und Strogatz modellieren lassen. Topologiegenerator Ein Topologiegenerator ist ein Programm, das auf Erzeugung von realistischen Netzwerkstrukturen spezialisiert ist. Meist enthält er dazu verschiedene Algorithmen für verschiedene Arten von Netzwerken. Topologiegenerator werden wie folgt klassiziert: Ad-Hoc-Modelle (die auf Schätzungen basieren) und messungsbasierte Modelle. causality-oblivious (reproduzieren die Verteilung nach einem Potenzgesetz) und causality-aware (Modellierung möglicher Ursachen, z.b. Netzwerk wächst, neue Knoten erscheinen). Erwähnenswert ist hier der universelle Topologiegenerator BRITE 1, welcher geographische Verteilung, Clustering, Bandbreitenunterschiede berücksichtigt und damit eine realistische Netzwerktopologie aufbauen kann. BRITE arbeitet messungsbasiert und nach Angaben der Autoren somit genauer als andere Generatoren. BRITE kann als Grundlage zur Topologiegenerierung eingesetzt werden. Diese Implementierung (oder die eines anderen Topologiegenerators) verspricht höhere Realitätsnähe, allerdings zum Preis erhöhter Komplexität. Zu beachten ist ferner, dass sich die zugrunde liegende Netzwerkstruktur von der Struktur des Overlay unterscheidet. Da der Simulator P2PNetSim auÿerdem das 1 34

35 3.1. MODELLIERUNG DES VERHALTENS KAPITEL 3. SIMBENCH Algorithmus 3.1 Algorithmus von Watts-Strogatz do { Lege einen regulären Graphen an mit n Knoten, die mit den k nächsten Nachbarn verbunden sind ( k/2 auf j e d e r S e i t e ). Hierbei s e i n >> k >> ln (n) >> 1 } p := b e l i e b i g aber f e s t aus [ 0, 1 ] for ( Kante : Kantenmenge ) { Mit Wahrscheinlichkeit p wird die Kante mit einem z u f ä l l i g gewählten Knoten neu verbunden. } Underlay-Netzwerk nicht detailliert nachbildet, wird der Ansatz mit einem Topologiegenerator hier nicht weiter verfolgt. [HPSS02] bietet einen Vergleich gängiger Generatoren und wie weit die erzeugte Topologie realistisch ist. Small-World-Modellierung Um zur Erzeugung der Topologie des Peer-to-Peer-Netzwerks ein relativ einfaches aber dennoch realistisches Modell zu besitzen, wurde der Algorithmus von Watts und Strogatz gewählt (siehe Listing 3.1). Ausgehend von einem regulären Graphen wird jede Kante mit einer Wahrscheinlichkeit p neu verbunden. Dabei erlaubt der Parameter p, die Struktur des entstehenden Graphen von einem regulären Graphen (p=0) bis zu einem Zufallsgraphen (p=1) zu variieren, wie in Abbildung 3.2 auf Seite 35 veranschaulicht. Mittlere Werte für p führen zu einem Graphen mit Small-World- Eigenschaften ( [WS98]). Eine Alternative zum Modell von Watts-Strogatz bietet das Modell von Barabasi und Albert ( [BA99]), dessen charakteristische Pfadlängen, d.h. der durchschnittlichen Abstand zweier Knoten im Graphen, in einem Vergleich bessere Übereinstimmung mit der gemessenen charakteristischen Pfadlänge des Gnutella-Netzwerks liefert ( [Jov01]). Auf die Umsetzung wurde hier aus Komplexitätsgründen verzichtet. Abbildung 3.2: Entstehende Struktur bei Watts-Strogatz (aus [WS98]) 35

36 3.1. MODELLIERUNG DES VERHALTENS KAPITEL 3. SIMBENCH Störungen Ein Netzwerk ist nicht statisch, sondern unterliegt Einschränkungen, und Fehler können auftreten. Folgende Punkte sind Beispiele, die ein existierendes Netzwerk von seinem Ideal unterscheiden: Verbindungen, Router, Leitungen fallen aus. Nachrichten gehen verloren oder werden verstümmelt (Peer-to-Peer-Protokolle basieren oft auf dem verbindungslosen und unzuverlässigen Protokoll UDP). Es kann mehrere Verbindungen zu einem Ziel geben; Pakete nehmen unterschiedliche Wege. Bandbreite, Latenz: eine Verbindung kann schnell oder langsam sein (Latenz - Ping-Zeiten - oder Throughput - bps). Unterschied Upstream- zu Downstream-Geschwindigkeit (das in privaten Haushalten verbreitete DSL ist meist asymmetrisch). Peers hinter NAT-Routern sind von auÿen nicht erreichbar, können nur selbst Verbindungen initiieren. Diese Punkte können die Realitätsnähe der Simulation beeinussen Overlayebene Die Overlayebene ist die Ebene des Peer-to-Peer-Protokolls. Das Verhalten der Overlayebene wird maÿgeblich durch die Protokolldenition vorgegeben: Als Mittler zwischen der Netzwerkebene und der Benutzerebene reagiert sie auf Eingaben von beiden Seiten mit den denierten Aktionen. Wird z.b. von der Benutzerebene eine Suchanfrage gestartet, führt sie die Overlayebene durch. Trit eine Suchanfrage über das Netzwerk ein, kümmert sich ebenfalls die Overlayebene um die passende Reaktion. Eine hinreichende Modellierung erfolgt durch die Implementierung des Peer-to-Peer-Protokolls Benutzerebene Die Benutzerebene wird hier nicht getrennt von der Applikationsebene betrachtet. Auf dieser Ebene werden die Entscheidungen getroen, wann und wie lange ein Peer sich mit dem Peer-to-Peer-Netzwerk verbindet und welche Operationen er ausführt, insbesondere Suche und Download. In Abbildung Abbildung 3.3 auf Seite 37 wird der Verlauf der Benutzeraktivitäten während der Lebenszeit eines Peers beschrieben: Zuerst betritt der Peer das Netzwerk. Zu diesem Zeitpunkt ist der Peer noch neu, d.h. eine frische Installation einer Peer-to-Peer-Anwendung ohne Informationen über das Netzwerk. Als nächstes beginnt er mit Aktivitäten wie eigene Daten zu publizieren, nach Daten zu suchen und diese herunterzuladen. Nach Abschluss beendet er die Verbindung mit dem Netzwerk, um zu einem späteren Zeitpunkt den Zyklus erneut zu beginnen. Das Benutzerverhalten äuÿert sich also in folgenden Bereichen: 36

37 3.1. MODELLIERUNG DES VERHALTENS KAPITEL 3. SIMBENCH 1. Arrive 2. Publish items 3. Perform lookups 4. Disconnect 5. Rejoin Abbildung 3.3: Verlauf der Benutzeraktivitäten nach [PKL + 08] Peer-Fluktuation Der Peer hat eine Lebenszeit, in der er sich mehrmals mit dem Peer-to-Peer-Netzwerk zum Download verbindet und wieder trennt. Dabei kann es sich (je nach Protokoll) um einen kontrollierten Shutdown (leave) handeln, d.h. der Peer meldet sich ordnungsgemäÿ ab, oder um einen Ausfall (fail), bei dem der Peer einfach verschwindet. Dateimodell Jeder Peer verfügt über einen Satz von Dateien und wird von Zeit zu Zeit die Operationen Suche und Download anstoÿen. Dabei ist die Verfügbarkeit nicht gleichmäÿig verteilt: beliebte Dateien haben eine höhere Verfügbarkeit. Zusammen mit Verfügbarkeit muss also für Untersuchungen der Suche die Beliebtheit modelliert werden, diese liefert die Objekte, die gesucht werden. Strategie [PKL + 08] schlägt die Klassizierung der Strategie des Benutzer in altruistisch, strategisch oder böswillig vor: Ein altruistischer Benutzer teilt freiwillig seine Ressourcen länger als nötig, ein strategischer Benutzer teilt die minimal nötigen Ressourcen (z.b. so lange, bis sein eigener Download vollständig ist), während ein böswilliger Benutzer mutwillig versucht, das Netzwerk zu stören (Freerider, Hacker) Grenzen der Realitätsnähe Generell gilt also, dass eine Simulation umso näher an der Realität ist, je mehr Eigenschaften der wirklichen Umgebung berücksichtigt worden sind. Sehr detaillierte Modellierung 37

38 3.1. MODELLIERUNG DES VERHALTENS KAPITEL 3. SIMBENCH ist jedoch nicht immer und oft nur bis zu einem gewissen Grad sinnvoll. Die Problematik betrit zwei Einschränkungen: Rechenkapazität und Komplexität. Die erste oensichtliche Einschränkung betrit Rechenzeit und Speicherplatz von Computern: Je mehr Objekte der wirklichen Welt und ihr Verhalten modelliert werden, desto aufwendiger wird die Simulation, und desto mehr Einschränkungen gelten für die Gröÿe des simulierten Peer-to-Peer-Netzes und seine simulierte Lebensdauer. Doch auch schon diesseits der praktischen Berechenbarkeit gilt eine weitere Einschränkung: Je mehr Objekte und deren Verhalten in der Simulation modelliert werden, desto komplexer wird das Gesamtsystem. Das erschwert das Verständnis der Zusammenhänge und macht das System anfälliger für Fehler, die sich z.b. in einzelnen Parametern eingeschlichen haben, oder falsche Schlüsse bezüglich der Abhängigkeiten. Die Implementierung solcher komplexen Systeme ist nicht trivial, es können sich Fehler einschleichen. Durch Sorgfältigkeit in der Planung des Systems kann diese Wahrscheinlichkeit nur verringert, nicht jedoch ausgeschlossen werden. Nicht in jedem Fall ist eine möglichst realitätsnahe Modellierung des Netzwerkverhaltens gewünscht, also eine hohe Komplexität notwendig. Es besteht die Möglichkeit, dass das modellierte Netzwerkverhalten irrelevant ist, das heiÿt, die zu untersuchenden Protokolle werden davon nicht signikant in ihrer Funktion beeinträchtigt. So können Netzwerktopologie und -fehlverhalten uninteressant sein für einen Forscher, der sich auf die Arbeitsweise eines Protokolls konzentrieren will, um z.b. dessen Korrektheit zu zeigen. Wünschenswert wäre eine möglichst universelle Simulation, die auf einfachen Prinzipien aufbaut. Mathematische Modelle wie Wahrscheinlichkeitsverteilungen versuchen, gemessene Werte nachzubilden und vereinfachen so den Ablauf schon erheblich gegenüber einer direkten Implementierung von gemessenen Werten. Dennoch erhöht diese Herangehensweise die Komplexität immer noch stark gegenüber einer statischen Simulation, bringt also auch Nachteile mit sich. Es muss für den Einzelfall eine Abwägung der Vor- und Nachteile einer komplexen gegen eine möglichst einfache Simulation stattnden Konkrete Modelle Um herauszunden, wie diese einzelnen Aspekte nun konkret modelliert werden können, bietet sich eine Orientierung an wissenschaftlichen Arbeiten an, die real existierende Peerto-Peer-Systeme untersucht haben. So haben unter anderem [CLL02] und [GDS + 03] die Dateiverteilung gemessen. Die Verteilung folgt den meisten Autoren zufolge den Potenzgesetzen. Auch die Operationen auf Dateien wurden bereits untersucht, [GDS + 03] folgen Suche und Download einer Beliebtheit, die mit der Zipf-Verteilung modelliert werden kann, bei [PKL + 08] wird eine Exponentialverteilung als Grundlage dieser Operationen gefunden. Das genaue Modell wird noch diskutiert. Es lässt sich jedoch sagen, dass die Beliebtheit einer Datei zu einer hohen Verbreitung und häuger Suche nach dieser Datei führt, während seltene Dateien auch wenig gesucht werden. Andere Arbeiten fanden Ergebnisse bezüglich der Länge einer Sitzung ( [BSV03], [SR06], [GFJ + 03]). Auch hier herrscht noch keine Einigung, welches mathematische Modell der tatsächlichen Verteilung am nächsten kommt. Die verschiedenen Arbeiten kommen zu unterschiedlichen Ergebnissen, die noch diskutiert werden. Wahrscheinlich ist das Modell vom Peer-to-Peer-Protokoll abhängig, aber 38

39 3.2. KOMPONENTEN KAPITEL 3. SIMBENCH Komponenten Ebenen Netzwerkebene Netzwerk Lasterzeugung Störung Overlayebene Peer Benutzerebene Dateisystem Lasterzeugung Betrieb Sonde Benchmark Datensammler Abbildung 3.4: Zuordnung der Ebenen auch von anderen Faktoren wie der Wahl der Messmethode. Es lässt sich jedoch sagen, dass die Wahl des passenden Modells auf den durchzuführenden Benchmark groÿen Ein- uss haben kann. Folglich muss SimBench die Möglichkeit bieten, mit unterschiedlichen Modellen zu arbeiten. Da die Implementierung des Benchmarks im Fokus dieser Arbeit liegt, ist die Wahl eines konkreten Modells nicht das Kernthema. Vielmehr soll versucht werden, eine Schnittstelle zu schaen, mit der zuerst ein einfaches Modell umgesetzt wird. Für weitergehende Untersuchungen soll diese Schnittstelle die Möglichkeit bieten, dieses einfache Modell bei Bedarf mit anderen für den Anwendungsfall passenderen Modellen zu ersetzen. 3.2 Komponenten Nach der Betrachtung, wie das Verhalten von Peer-to-Peer-Netzwerken in verschiedenen Ebenen eingeteilt und modelliert werden kann, sollen diese Überlegungen praxisrelevant in Komponenten übertragen werden, welche dann implementiert werden können. Abbildung 3.4 auf Seite 39 verdeutlicht den Zusammenhang zwischen den im vorigen Abschnitt 3.1 entwickelten Modell und den im Folgenden vorgestellten Komponenten: Zur Netzwerkebene gehören das vom Simulator gestellte Netzwerk sowie Störungen auf dieser Ebene. Das Dateisystem sowie die Betriebslast sind der Benutzerebene zugeordnet. Der Peer ndet sich primär in der Overlayebene, hat aber Berührungspunkte mit allen Ebenen, da er eine zentrale Komponente ist. Einige Komponenten (Sonde, Datensammler) sind nur für den Benchmark nötig und haben keine Entsprechung in der Modellierung. 39

40 3.2. KOMPONENTEN KAPITEL 3. SIMBENCH Netzwerk Das Netzwerk im Normalverhalten wird von der Simulationsumgebung P2PNetSim simuliert. Nicht in der Simulation enthalten ist die detaillierte Simulation der Netzwerkschichten, insbesondere die verschiedenen Protokolle (TCP, UDP, IP, ICMP...) und Störungen werden nicht simuliert. Diese müssen bei Bedarf auf der Ebene der Peers simuliert werden. Insgesamt ist die Komponente Netzwerk wohl die, bei der es am wenigsten initialen Implementierungsaufwand und späteren Anpassungsaufwand gibt Peers Die Peers sind Implementierungen der Peer-to-Peer-Protokolle und verhalten sich gemäÿ ihren Spezikationen. Ihre Hauptaufgabe ist es, Anweisungen von der Benutzerebene und Nachrichten von der Netzwerkebene entgegen zu nehmen und dem Protokoll entsprechend zu reagieren. Zusätzlich, da es sich um eine Simulation handelt, zeigen die Peers auf Anweisung ein bestimmtes Verhalten der Netzwerkebene (Störungen, Paketverlust) und Benutzerebene (Join, Lookup, aber auch Ausfall, falsche Antworten). Ein Peer ist dabei immer eine passive Komponente und reagiert nur auf Anweisungen. Ist ein Peer-to-Peer-Protokoll einmal umgesetzt, und kann der Peer auch auf Anforderung ein deniertes Verhalten zeigen, sind in der Komponente Peer keine weiteren Änderungen oder Kongurationen nötig. Der einzige Parameter, der hier gewählt werden muss, ist die maximale Anzahl von Peers für einen Simulationslauf im Benchmark Dateisystem Zur Vereinfachung wird ein einziges globales Dateisystem deniert. Dieses enthält alle im Peer-to-Peer-System vorhandenen Dateien mit einer Häugkeit und Beliebtheit gemäÿ einer denierbaren Verteilung, z.b. Normalverteilung. Ein solches Dateisystem kann die initial erzeugten Dateien entsprechend ihrer Verteilung auf Anfrage liefern. Somit bietet es sowohl Unterstützung für strukturierte Protokolle (indem das Dateisystem z.b. in die DHT geschrieben wird), als auch zur Generierung von lokalen Dateisystemen für unstrukturierte Protokolle, wobei die Einhaltung der Verteilungsfunktion systemweit gewährleistet ist. Für die Operationen im laufenden Betrieb kann das Dateisystem nach zu suchenden Dateien befragt werden. Abhängig vom Benchmark kann das Dateisystem konguriert werden: Die Anzahl und Verteilung der Dateien sollten je nach Testfall gewählt werden. Hierzu bietet SimBench mehrere Verteilungsfunktionen. Die Gleichverteilung ist der nahe liegende Fall einer einfachen Modellierung. Die Normalverteilung folgt bereits dem Schema, dass nur wenige Dateien sehr beliebt sind. In Abbildung 3.5 auf Seite 41 ist ein Beispiel aus der Implementierung des Dateisystems von SimBench zu sehen, in dem ein Dateisystem aus 100 Dateien angelegt wurde. Aus diesem wurde dann je hunderttausend Mal eine zufällige Datei nach verschiedenen Verteilungen selektiert wurde. Man erkennt deutlich die typischen Kurven der Verteilungen. 40

41 3.2. KOMPONENTEN KAPITEL 3. SIMBENCH Abbildung 3.5: Verteilung von Selektionen auf 100 Dateien. Die tatsächliche Verteilung ist durch Punkte dargestellt. Formal: Das globale Dateisystem Γ wird deniert als ein Paar (n, v) N V, wobei n N die Anzahl der Dateien im Dateisystem bezeichnet. Eine Datei wird durch ihren Index eindeutig identiziert und besitzt die Attribute Dateiname und Gröÿe. v V ist eine Funktion, die eine Folge aus den vorhandenen Dateien gemäÿ einer bestimmten Verteilung liefert. In der derzeitigen Implementierung ist V = {f gleich, f normal }, es lassen sich also Gleichverteilung oder Normalverteilung wählen. Beispiel: Γ = (100, f normal ) bezeichnet ein Dateisystem aus 100 Dateien, die in normalverteilter Folge geliefert werden Lasterzeugung Die Simulation muss sich dynamisch verhalten. Dazu werden die Peers angewiesen, sich auf eine bestimmte Weise zu verhalten. Das ist Aufgabe der Lasterzeugung. Sie ist zuständig für Erzeugung von normaler Betriebslast, aber auch Störungen (fault injection). Die Lasterzeugung muss für jeden Benchmark individuell konguriert werden. Formal: Lasterzeugung ist eine Funktion Ω : N Σ n, die jedem Simulationsschritt eine Menge von n N Anweisungen zuordnet. Σ ist die Menge der Anweisungen. Eine Anweisung σ Σ ist ein Tripel (p, c, a), wobei p ein Peer aus der Menge aller Peers der Simulation ist, c C ein konkreter Befehl (z.b. C = {join, lookup}) und a ein Argument für den Befehl. Dies wird intern durch eine Kodierung der Befehle als Zeichenkette realisiert, siehe hierzu Unterabschnitt Betriebslast Fluktuation Fluktuation (Churn) entsteht, wenn Peers dem Netzwerk beitreten (Join), respektive es verlassen (Leave). Zur Untersuchung von Skalierbarkeit wird das initiale Wachstum, bei dem Peers nur dem Netzwerk beitreten, ohne es zu verlassen, ermöglicht. 41

42 3.2. KOMPONENTEN KAPITEL 3. SIMBENCH SimBench bietet ein vereinfachtes Modell, in dem zu jedem Simulationsschritt m Peers das Netzwerk betreten und n Peers es verlassen. Der Anwender wählt zwei Zahlen min C und max C, so dass m und n zufällig erzeugt werden mit min C m max C und min C m max C (m, n, min C, max C N). Operationen sind Suche (Query, Lookup) nach Dateien sowie ihr Download. Bei strukturierten Protokollen kommen noch Speicherung einer Datei (Store) sowie Löschen (Delete) hinzu. SimBench bietet zwei Modelle an: 1. Einfache Verteilung: alle Dateien werden mit gleicher Wahrscheinlichkeit gesucht. 2. Normalverteilung: wenige Dateien sind sehr beliebt und werden auch oft gesucht. Zu jeder Operation kann der Anwender wählen, wie oft sie in jedem Simulationsschritt ausgeführt wird, ebenfalls durch zwei Schranken min O und max O, innerhalb derer die tatsächliche Anzahl ermittelt wird. Dazu kann zu jeder Operation die Verteilung für die Parameter gewählt werden. Störungen Alle Arten von Operationen, die nicht der normalen Betriebslast zuzuordnen sind, sind Störungen. Dabei werden sowohl Störungen der Netzwerkebene als auch Störungen der Benutzerebene subsumiert. Ein Ausfall von Peers oder Leitungen, Missbrauch oder Angri eines Benutzers oder Nichteinhalten des Protokolls sind Beispiele für Störungslast. Als beispielhafte Implementierung wird die Simulation eines Ausfalls umgesetzt, bei dem n% der Peers zu einem Zeitpunkt t ausfallen. n und t sind vom Benutzer bestimmbare Werte. Ausgefallene Peers können nicht mehr dem Netzwerk beitreten und senden keine Statistiken mehr Reine Benchmark-Komponenten Neben den in Abschnitt 3.1 aufgeführten Ebenen ist es noch nötig, die Messwerte zu ermitteln und zu erfassen. Dazu benutzt jeder Peer eine Sonde, um die Werte zu ermitteln. Am Ende jedes Simulationsschritts werden die Werte aller Peers zentral gesammelt und gespeichert. Die Zahl der gesammelten Messwerte kann recht groÿ werden (#Messwerte #P eers #Simulationsschritte), deshalb werden die Daten vor der Speicherung aggregiert. Beispielsweise wird ein bestimmter Messwert von allen Peers je Simulationsschritt summiert, so dass sich eine einzige Zahl je Simulationsschritt für jeden Messwert ergibt. Um die erfassten Daten weiter zu minimieren, sollten vor dem Simulationslauf nur die Metriken gewählt werden, d.h. die Messwerte, die erfasst werden sollen, sowie die anzuwendenden Aggregationen auf jeden Messwert. Auÿer der Wahl der Metrik ist keine weitere Konguration nötig, die Komponenten passen sich von alleine an. 42

43 3.2. KOMPONENTEN KAPITEL 3. SIMBENCH Sonden Die Aufgabe des Benchmark ist es, Messdaten auf den Peers zu ermitteln. Dazu benötigt er eine generische Sonde, die in Peers eingebaut werden kann. Die Sonde hält Zähler vor, in denen Messwerte mitgeschrieben werden. Dazu werden bestimmte Methoden bei einem aufgetretenen Ereignis aufgerufen. Da wir uns in einer Simulation benden, werden keine passiven Messungen durchgeführt (z.b. ein Router, der Pakete & Verzögerungen zählt, vgl. Unterabschnitt 2.2.3), sondern bei Ereignissen werden Messwerte erfasst. Ein Ereignis in diesem Sinne ist z.b. Join, welches einen Zähler für Peers, die online sind erhöht. Ein weiteres Beispiel ist sende Nachricht. Bei diesem Ereignis werden mehrere Zähler erhöht: für alle Nachrichten, Nachricht vom Typ x, gesendete Bytes, und andere. Eine Anpassung der Komponenten Sonde kann optional erfolgen, wenn weitere Messwerte ermittelt werden sollen, ansonsten sollte die Sonde unverändert in verschiedene Arten von Peers eingebaut werden können. Datensammler Während die Sonde die Messwerte für einzelne Peers erfasst, müssen diese Daten noch aggregiert (z.b. Summe, Durchschnitt) und gesammelt werden. Hierzu wird eine zentrale und skalierbare Datensammlung benötigt. Da es sich bei P2PNetSim um eine verteilte Simulation handelt, muss auch auf jedem Rechenknoten eine Instanz des Datensammlers laufen, damit dieser nicht zum Flaschenhals wird ( [OPH03]). Die Komponente Datensammler soll sich möglichst unabhängig an die von der Sonde gelieferten Messwerte anpassen, ohne weitere Anpassungen bei verschiedenen Benchmarks oder Protokollen zu benötigen. Kommandozentrale Die Kommandozentrale ist das Kernstück der Dynamik der Simulation. Hier werden Befehle für die Peers generiert, passende Peers ausgewählt, und die Befehle verteilt. In der grundlegenden Implementierung soll die Kommandozentrale die Befehle zufällig nach den Eingaben des Anwenders generieren. Die Wahl eines Peers erfolgt dann nach einfachen Kriterien, so soll ein Peer nur einen Befehl pro Simulationsrunde erhalten und der Online- Status soll passen (z.b. muss ein Peer für einen Suchbefehl online sein). Es kann passieren, dass keine passenden Peers vorhanden sind, in dem Fall wird der Befehl verworfen. Eine völlig andere Herangehensweise ist das Abspielen eines Simulationsskripts, in dem Befehle und Peers für jeden Simulationsschritt verzeichnet sind. Eine solche Kommandozentrale verteilt einfach die Befehle des Skriptes an die angegebenen Peers. Hierzu müssen die Peers in der Lage sein, sich gemäÿ den Anweisungen der Kommandozentrale zu verhalten. Die eigentliche Funktionalität liegt also in den Peers, die Kommandozentrale kümmert sich ausschlieÿlich um die Verteilung der Befehle. 43

44 3.3. DEFINITION VON SIMBENCH KAPITEL 3. SIMBENCH 3.3 Denition von SimBench Schlieÿlich kann der Benchmark deniert werden: In SimBench besteht ein einzelner Benchmark b B aus einer Konguration k K und zu erfassenden Metriken M b M. Ein solcher Benchmark kann auf verschiedene Protokolle angewendet werden Konguration Bestandteile der Konguration: Die Gesamtzahl der Peers p N wird als Zahl angegeben. Die Anzahl und Verteilung der Dateien ist ein Paar aus einer natürlichen Zahl d und einer Funktion aus der Menge der Verteilungsfunktionen V = {f gleich, f normal }. Das globale Dateisystem enthält dann d Dateien und liefert sie gemäÿ der Verteilung. Das initiale Wachstum kann sein (vgl. Abbildung 3.6 auf Seite 44): Statisch bzw. kein Wachstum: Alle Peers treten dem Netzwerk im ersten Simulationsschritt bei. Linear: In jeder Runde tritt eine wählbare feste Anzahl n an Peers dem Netzwerk bei, bis alle Peers verbunden sind. Polynomial: Es ist ein n wählbar, so dass in jeder Runde r genau r n Peers dem Netzwerk beitreten. Am Ende jeder Runde r sind also rn(n+1) 2 Peers online, bis die maximale Zahl erreicht ist. Abbildung 3.6: Anzahl der Online-Peers bei unterschiedlichem initialen Wachstum mit anschlieÿendem Churn 44

45 3.3. DEFINITION VON SIMBENCH KAPITEL 3. SIMBENCH Fluktuation bzw. Churn wird durch zwei Grenzen min C und max C deniert. In jeder Runde werden j Peers aufgefordert, dem Netzwerk beizutreten und l Peers, es zu verlassen, wobei j und l zwei Zahlen zwischen min C und max C sind, die unabhängig voneinander ermittelt werden. Für jede Operation aus der Menge der Operationen {join, leave, lookup, store} werden zwei Grenzen min O und max O festgelegt, innerhalb derer die Anzahl ermittelt wird, wie oft diese Operation je Simulationsschritt ausgeführt wird. Störungen beschränken sich auf den Ausfall von n% der Peers in einem Simulationsschritt t. Die Dauer der Simulation (Simulationsschritte) ist eine Zahl l N. Konkrete Beispiele für Kongurationen nden sich unter Kapitel 5 auf Seite Metriken Konkrete Metriken gibt es viele. In einer Vielzahl von Arbeiten nden sich bereits Metriken für Peer-to-Peer-Systeme, und darüber hinaus lassen sich neue Metriken ernden, da die Metriken für Peer-to-Peer-Systeme deutlich komplexer sein können als herkömmliche Netzwerkmetriken. [RM07] bietet hier einen guten Überblick über vorhandene Metriken. So kann zur Beurteilung eines Protokolls die Pfadlänge, die Anzahl der Alternativen zu einem Ziel / Nachbarn / Datum, Fragmentierung des Graphen, usw. von Bedeutung sein. Zur Vereinfachung werden solche Topologiemetriken nicht behandelt. Bei der Implementierung von SimBench soll Wert darauf gelegt werden, dass der Benchmark schnell und einfach mit neuen Messwerten und Aggregationen erweitert werden kann. Die Hauptarbeit ist hier dementsprechend das Gerüst für den Benchmark. Prinzipiell können alle Werte erfasst werden, die ein Peer als Zahlen darstellen kann. Die derzeit implementierten Messwerte sind Tabelle 4.1 zu entnehmen. Messwerte werden pro Peer ermittelt. Um die dabei anfallende Datenmenge zu verringern, werden die Messwerte über alle Peers aggregiert. Diese Aggregationen folgen den Prinzipien, leicht erstellbar und universell für alle Messwerte einsetzbar zu sein wobei natürlich nicht alle Kombinationen von Messwerte und Aggregation sinnvoll sind. Derzeitige Aggregationen sind in Tabelle 4.2 zu nden. Es bleibt dann noch, aus diesen Messwerten und Aggregationen für den jeweiligen Anwendungsfall nützliche Metriken zusammenzusetzen. Eine beliebig aber fest aus Messwerten komponierte Metrik sichert die Nachvollziehbarkeit und Vergleichbarkeit eines Benchmarks zwischen unterschiedlichen Simulationen. Speicherbedarf Der Speicherbedarf ist eine Metrik, um den Entwurf oder die Implementierung der Peers auf Optimierungspotenzial oder Fehler bezüglich ihres Speicherverbrauchs zu untersuchen. Die Summe des Speicherverbrauchs aller Peers wird in Beziehung zum zeitlichen Verlauf der Simulation gesetzt. 45

46 3.3. DEFINITION VON SIMBENCH KAPITEL 3. SIMBENCH Verwaltungskosten Diese Metrik zählt alle Verwaltungsnachrichten, d.h. solche Nachrichten, die zum Aufbau und Betrieb des Peer-to-Peer-Netzwerks selbst benötigt werden. Bei Gnutella sind das beispielsweise alle Nachrichten vom Typ Ping oder Pong, bei strukturierten Protokollen wie Chord sind das die Nachrichten zum Aufbau und zur Instandhaltung des Rings sowie zusätzlich für zu bewegende Schlüssel auf Dateien, wenn ein neuer Knoten hinzukommt bzw. ein Knoten entfällt. V erwaltungskosten = sum(#messages ping) + sum(#messages pong ) sum(#peers online ) Diese Zahl kann dann in Relation zur Gesamtzahl an Peers gesetzt werden, und der entstehende Graph lässt Rückschlüsse auf Eigenschaften wie die grundlegende Skalierbarkeit des Protokolls zu. Suchmetriken Nach der grundlegenden Skalierbarkeit ist eine gut funktionierende Suche eine weitere wichtige Eigenschaft von Peer-to-Peer-Protokollen. Dazu passende Metriken sind die Anzahl der Nachrichten für eine Suche, bei unstrukturierten Protokollen der Sucherfolg (d.h. der Anteil erfolgreicher Suchen in Prozent), Anzahl Nachrichten für eine Suche (Suchaufwand), oder der Suchlatenz (Dauer, bis Ergebnis eintrit (Simulationsschritte)). Mit diesen Metriken lassen sich Eigenschaften wie Ezienz der Suche (Wie funktioniert die Suche im Normalbetrieb?), aber auch Robustheit der Suche (Wie funktioniert die Suche unter Störungen?) messen. Sucherfolg Sucherfolg drückt in Prozent die Quote aller Suchanfragen aus, die mindestens ein Ergebnis geliefert haben. Sucherfolg wird in Relation gesetzt zur Verbreitung des gesuchten Datums. Die Dateiverbreitung beziert - ebenfalls in Prozent - den Anteil aller Peers, die diese Datei in ihrem lokalen Dateisystem besitzen. Die Metrik setzt sich folgendermaÿen aus Messwerten zusammen 2 : Sucherf olg = sum(#lookups success ) sum(#lookups success ) + sum(#lookups fail ) Dateiverbreitung = avg(#f iles) Dabei bezeichnen #lookups success bzw. #lookups fail die Anzahl der erfolgreich bzw. ergebnislos beendeten Suchanfragen und #f iles die Anzahl der Dateien eines Peers. sum() bzw. avg() sind Aggregationen und berechnen die Summe bzw. den Durchschnitt der Messwerte über alle Peers. Zur Ermittlung der Dateiverteilung wird dem globalen Dateisystem nur eine einzige Datei zugewiesen. Die durchschnittliche Anzahl von Dateien pro Peer entspricht dann der Verbreitung dieser Datei. 2 An Stelle der Summe aus erfolgreicher und fehlgeschlagener Suche könnte hier auch die Zahl der gegebenen Suchbefehle genommen werden kann. Eine solche Metrik wäre aber schwerer auszuwerten, da das Ergebnis eines Suchbefehls zeitversetzt eintrit. 46

47 3.3. DEFINITION VON SIMBENCH KAPITEL 3. SIMBENCH Suchaufwand Der Aufwand einer Suche wird gemessen an der Anzahl der Nachrichten, die für die Suche generiert werden. Neben dem Aufwand für eine einzelne Suche interessiert besonders die Skalierbarkeit bezüglich der Suche. Deshalb wird dieser Wert ins Verhältnis gesetzt zu der Anzahl der Peers, die gerade online sind. Suchaufwand = sum(#messages lookup) + sum(#messages result ) sum(#peers online ) #messages lookup ist der Messwert für die Anzahl von Suchanfragen, mit dem Index result ergibt wird die Anzahl der Suchantworten angesprochen. #peers online ist die Zahl der Peers, die sich im Zustand online benden. Suchlatenz Der Zeitraum zwischen dem Versenden eines Suchbefehls und dem Eintreen des ersten Suchergebnisses wird als Latenz bezeichnet und oft in Millisekunden gemessen, hier jedoch in Ermangelung eines Zeitmaÿes die Anzahl der Hops, die die Anfrage plus Antwort zurückgelegt haben. Die Suchlatenz ist also die doppelte Entfernung zum nächsten Peer mit dem gesuchten Datum, wenn Suchnachricht und Antwort den gleichen Pfad nehmen. Diese Metrik besteht aus dem einen Messwert der Latenz und wird als kumulierte Verteilungsfunktion (CDF) dargestellt. 47

48 4 Implementierung 4.1 P2PNetSim Da die Vorgabe dieser Arbeit war, den Benchmark auf Grundlage der Simulationsumgebung P2PNetSim zu entwickeln, werden im Folgenden die für SimBench wichtigen Aspekte besprochen. Dies dient dem Verständnis der Beschreibung der Implementierung der Erweiterungen. P2PNetSim ist ein verteilt und parallel rechnender Simulator. Auf jedem Knoten läuft je ein Simulator, auf dem Hauptknoten der Simulations-Controller, welcher die Simulatoren koordiniert. Jeder Simulator wiederum ist für die Peers auf seinem Knoten zuständig. Bildlich dargestellt ergibt das einen dreistugen Baum, dessen Wurzel der Controller ist. In der ersten Ebene hängen die Simulatoren am Controller und in der zweiten Ebene an jedem Simulator die Peers. Die Peers können ihrem Simulator Nachrichten zukommen lassen in Form einer Instanz der Klasse PeerEvent. Das ist im Wesentlichen eine Menge von Paaren aus Zeichenketten von Name und Wert. Zu jedem Simulationsschritt kann jeder Peer ein PeerEvent liefern und jeder Simulator erhält alle PeerEvents seiner Peers. Zur Verarbeitung der Menge der PeerEvents auf dem Simulator kann die Klasse LocalEventHandler überschrieben werden. Ebenfalls in jedem Simulationsschritt sendet jeder Simulator eine Menge von PeerEvents an den Controller. Diese können in einer Erweiterung der Klasse GlobalEventHandler verarbeitet werden. In der Voreinstellung werden alle PeerEvents einfach durchgereicht. Schlieÿlich übergibt der Controller ein einziges SimulationEvent, mit dem sich Nachrichten im Frontend anzeigen lassen. Mittels des SimulationEvents kann die Simulation bei Bedarf auch angehalten oder zurückgesetzt werden. Die Gegenrichtung ist schon schwieriger. Beide EventHandler können nur über einen PeerProxy auf jeden Peer zugreifen 1. Jeder Peer besitzt einen Satz von sogenannten Parametern (Paaren aus Zeichenketten von Name und Wert). Ein PeerProxy bietet Methoden an, um auf die Parameter eines Peers lesend und schreibend zuzugreifen. Eine direkte Möglichkeit, vom GlobalEventHandler aus die LocalEventHandler zu kontaktieren, ist nicht bekannt. Die Simulation wird von einer XML-Datei gesteuert. In ihr nden sich Angaben zu den Knoten der Simulatoren und des Controllers (Rechnername oder IP-Adresse und Port), zu den verwendeten Klassen für GlobalEventHandler und LocalEventHandler sowie die 1 Zusätzlich kann ein LocalEventHandler direkt eine Referenz auf einen lokalen Peer erhalten, um direkt auf dessen Methoden und Variablen zuzugreifen. Diese Methode ist jedoch noch recht neu und nicht dokumentiert. Deshalb stand die Information zum Zeitpunkt der Erstellung des Benchmark-Kerns nicht zur Verfügung und die gesamte Kommunikation zu den Peers erfolgt über PeerProxy. Die Datenmenge vom Controller zu den Peers ist jedoch recht klein, so dass dies keine Einschränkung bedeutet. 48

49 4.1. P2PNETSIM KAPITEL 4. IMPLEMENTIERUNG Zuteilung der Peers und ihrer Klassen zu den Simulatoren. Ferner lassen sich noch Peer- Parameter und sogenannte Konstanten (global verfügbare Paare aus Zeichenketten von Name und Wert) festlegen. Zu Beginn der Simulation werden nun die XML-Datei geladen und Controller sowie Simulatoren entsprechend initialisiert. Dann werden in jedem Simulationsschritt zuerst die Peers, dann die LocalEventHandler und zum Schluss der GlobalEventHandler ausgeführt. Die Reihenfolge der Ausführung innerhalb der Peers oder LocalEventHandler kann dabei variieren. Peers können anderen Peers Nachrichten senden, die frühestens zu Beginn des nächsten Schritts zur Verfügung stehen. Am Ende eines Simulationsschritts verfügt der GlobalEventHandler über die Informationen der Peers aus dem aktuellen Schritt. Erhalten die Peers vom GlobalEventHandler neue Parameter, können diese zu Beginn des nächsten Schritts bearbeitet werden. Für den Peer bedeutet das, dass zu Beginn der Ausführung des nächsten Simulationsschritts alle im vorigen Schritt gesendeten Nachrichten und gesetzten Parameter verfügbar sind. Die Reihenfolge des Eintreens der Nachrichten ist zwar nicht deterministisch, was sich aber durch einfache Sortierung beheben lässt. Aufgrund dieser Informationen arbeitet er den Schritt ab, beantwortet Nachrichten und kann am Ende ein PeerEvent erzeugen und zurücksenden. Sobald der LocalEventHandler ausgeführt wird, stehen ihm bereits die PeerEvents aller Peers zur Verfügung. Gleiches gilt für den GlobalEventHandler. Wurden diese abgearbeitet, beginnt ein neuer Simulationsschritt mit den neuen Parametern und Nachrichten. In der Richtung vom Peer zum GlobalEventHandler lassen sich die Informationen noch im gleichen Simulationsschritt auswerten. Informationen vom GlobalEventHandler zum LocalEventHandler zum Peer würden diesen wegen der Reihenfolge der Ausführung jedoch mit zwei Schritten Verspätung erreichen. Zur Ergänzung sei gesagt, dass Informationen über die interne Arbeitsweise von P2PNet- Sim für diese Arbeit nicht zur Verfügung standen. Die Diplomarbeit, mit der P2PNetSim entstand, entspricht laut Angaben des Lehrstuhls längst nicht mehr dem aktuellen Stand der Entwicklung, und neuere Dokumente existierten nicht. Sofern nicht im Quick Start Guide enthalten, wurden diese Informationen daher durch Mutmaÿungen und Experimente herausgefunden, in der Honung, dass die getroenen Annahmen korrekt sind. Dies betrit beispielsweise die Übermittlung von Befehlen und Messdaten, welche sämtlich vor der Übertragung über das Netzwerk in eine Zeichenkette im 7-Bit-ASCII-Format konvertiert und vom Empfänger wieder dekodiert werden. Von den verschiedenen Möglichkeiten, von den EventHandlern aus die Peers zu kontaktieren werden die Befehle über einen Parameter an die Peers gesendet. Die Peers wiederum liefern ihre Messdaten mit einem PeerEvent an die LocalEventHandler. Diese Wahl hat im Verlauf der Implementierung und Anwendung keine groÿen Nachteile oenbart. Eine weitere Herausforderung bestand darin, tief greifende Änderungen im Simulationsablauf umzusetzen und dabei nur die Schnittstellen von P2PNetSim zu nutzen, was sich dem Entwickler als Black-Box (d.h. ohne Einblick oder Eingrismöglichkeit in die interne Funktionsweise) präsentiert. Wahrscheinlich ist dabei Redundanz entstanden: Beispielsweise ist die Anzahl der Peers oder Gröÿe der Nachrichten in P2PNetSim vermutlich bereits bekannt. Da es aber keine Schnittstelle gibt, um auf diese Informationen zuzugreifen, müssen sie von SimBench von Grund auf neu berechnet werden. Das hat - neben dem erhöhten Implementierungsaufwand und der doppelten Berechnung während einer Simulation - den zusätzlichen Nachteil, dass bei zukünftigen Änderungen daran gedacht 49

50 4.2. GRUNDIDEE KAPITEL 4. IMPLEMENTIERUNG werden muss, die entsprechenden Stellen sowohl in P2PNetSim als auch in SimBench anzupassen. Ohne Einblick und Eingri in P2PNetSim gibt es dafür keine andere Lösung. 4.2 Grundidee Um Messwerte von den Peers einzusammeln, lassen sich prinzipiell zwei Arten von Messwerten unterscheiden, die in einem Benchmark relevant sein können: Informationen über alle Peers und die zwischen ihnen ausgetauschten Nachrichten und interne Informationen der Peers (z.b. Anzahl der Nachbarn, Dauer einer Anfrage). Ein oensichtlicher erster Ansatz, um Informationen der ersten Art zu ermitteln, besteht darin, die zentrale Stelle im Simulator zu suchen, die bei einem bestimmten Ereignis abgearbeitet wird, und an dieser Stelle den Zähler anzubringen. Sollen Nachrichten, die zwischen Peers ausgetauscht werden, gezählt werden, bestimmt man die dafür zuständige Methode und wertet dort die Nachricht aus. Sofort erhält man eine einfache Messsonde. Analog funktioniert der Ansatz für die Modellierung des Netzwerks: Soll ein Peer z.b. oine sein, werden an der gleichen Stelle (d.h. Nachrichtenaustausch) empfangene Nachrichten ignoriert anstatt verarbeitet. Naheliegend wäre es jetzt, den Simulator selbst dafür zu nutzen, denn alle Nachrichten und Peers sind dem Simulator bereits bekannt und müssen von ihm intern behandelt werden - an dieser Stelle könnte man nun einfach statistische Daten einsammeln. Da P2PNetSim nicht als Quelltext zur Verfügung steht, sucht man nun die Stelle, die der gewünschten am nächsten ist. Beim Nachrichtenaustausch ist das in der Klasse Peer die Methode zum Senden bzw. die zum Empfangen von Nachrichten. Diese Informationen müssen dann noch gesammelt und an eine zentrale Stelle übermittelt werden und liefern schon recht gute Informationen als Grundlage eines Benchmarks. Interne Informationen können nur in den Peers selbst ermittelt werden. Wenn der obige Mechanismus bereits implementiert ist, können diese Informationen auf die gleiche Weise übermittelt werden. Dabei werden alle Messwerte gleich behandelt, so dass sich neue Messungen leicht integrieren lassen. Es gilt nun, die eingesammelten Daten zu aggregieren, um die zu übertragende Datenmenge zu verkleinern. Dazu werden eine Reihe von Aggregationen angeboten. Wieder sollten die Aggregationen austauschbar sein. Diese Standardisierung von Messwerten und Aggregationen ermöglicht es, dass jeder Messwert mit jeder Aggregation kombiniert werden kann. Mehr zu den Messwerten und Aggregationen ndet sich in Unterabschnitt Aus den aggregierten Messwerten lassen sich dann Metriken zusammensetzen. Schlieÿlich kommt noch die bereits beschriebene Dynamik ins Spiel. Zu Beginn der Entwicklung eines Peer-to-Peer-Protokolls ist es oft vorteilhaft, wenn sich gezielt einzelne Funktionen des Protokolls betrachten lassen, und zwar ohne störende Einüsse durch eine dynamische Umgebung. So können diese Funktionen isoliert betrachtet und daraus genauere Messwerte gewonnen werden. Da Peer-to-Peer-Netzwerke meist von starker Dynamik geprägt sind, sollte sich das Protokoll ab einer gewissen Entwicklungsstufe jedoch zusätzlich in einer realistischeren Umgebung bewähren. Hierzu können verschiedene Kongurationen erstellt werden - aber auch um unterschiedliche Aspekte zu untersuchen oder verschiedene Modelle zu vergleichen. Auch Kongurationen sind standardisiert, und unterschiedliche Kongurationen können mit festen Metriken kombiniert werden. 50

51 4.3. ÜBERBLICK KAPITEL 4. IMPLEMENTIERUNG 4.3 Überblick Um einen allgemeinen Überblick über die Komponenten und ihr Zusammenspiel zu bekommen, erfolgt zuerst ein Überblick über einen Ablauf einer Simulation aus der Sicht des Anwenders, anschlieÿend über die zentralen Klassen der Implementierung Ablauf eines Benchmarks Wie stellt sich ein Benchmark in SimBench für den Anwender dar, und welche Schritte müssen ausgeführt werden, um von der Denition eines Benchmarks mit Konguration und Metriken zu den Daten zu kommen? Dieser Ablauf ist Abbildung 4.1 auf Seite 51 zu entnehmen. Er ist bewusst grob gehalten, um den Überblick zu erleichtern. Vor dem eigentlichen Benchmark sollten Implementierungen der zu vergleichenden Protokolle existieren sowie passende Metriken dazu deniert sein. Simulation XML-Erstellung EventHandler Simulationsende Start des Benchmarks Befehlszentrale Auswertung Peer Abbildung 4.1: SimBench-Ablauf XML-Erstellung Zuerst kann über eine graphische Benutzerschnittstelle eine XML- Datei für P2PNetSim erstellt werden (siehe Unterabschnitt 4.6.1). Wichtige Einstellungen sind - neben der Einstellungen für P2PNetSim - die Konguration der Simulation (z.b. das Peer-to-Peer-Protokoll und durchzuführende Operationen) sowie die Metriken, die erfasst werden sollen. Start des Benchmarks Mit der erstellten XML-Datei wird P2PNetSim gestartet. Dabei müssen die Klassendateien, die in der XML-Datei deniert werden (Peer, GlobalEvent- Handler,...) natürlich vorhanden sein. 51

52 4.3. ÜBERBLICK KAPITEL 4. IMPLEMENTIERUNG Simulationsschritte Die Simulation läuft in Schritten ab, bis ein in der Konguration denierter Schritt erreicht ist oder der Anwender die Simulation unterbricht. In jedem Schritt der Simulation führen für SimBench wichtige folgende Komponenten ihre Operationen durch: Für jeden Simulationsschritt: Peer Behandelt eingehende Befehle und Nachrichten, pegt das Overlay- Netzwerk gemäÿ den Spezikationen. In diesem Schritt anfallende Messwerte und Statistiken werden übermittelt. Peers werden genauer in Unterabschnitt behandelt. Befehlszentrale Legt neue Befehle für die Peers fest, die im darauf folgenden Simulationsschritt behandelt werden. Einzelheiten nden sich in Unterabschnitt EventHandler sammelt die Messwerte und Statistiken aller Peers, fasst sie zusammen, und schreibt sie sowohl in eine externe Datei als auch zur Kontrolle für den Anwender in die Registerkarte Controller Output im Frontend von P2PNetSim. Unterabschnitt verrät mehr über die Übergabe der Messwerte. Auswertung Die im Simulationslauf erhobenen Daten und Messwerte wurden in Dateien geschrieben und können jetzt ausgewertet werden. So kann der Netzwerkgraph mit graphviz ( [gra09]) visualisiert werden, für die Messwerte ist gnuplot ( [gnu09]) geeignet, aber auch sogenannte Tabellenkalkulationsprogramme wie Microsoft Excel ( [exc09]) sollten dieses Format problemlos lesen können. Die Dateien mit den statistischen Daten werden in einem generischen Format (Feldtrennung durch Tabulator) geschrieben und lassen sich so einfach nachbearbeiten und mit einer Vielzahl von Werkzeugen auswerten Überblick: Peer AbstractPeer ist die zentrale Klasse, von der alle Implementierungen eines neuen Protokolls abgeleitet werden sollten. Die Klasse ist ein Observable, um Observer zur Nachrichtenbearbeitung nutzen zu können. Mehr zu AbstractPeer ndet sich in Unterabschnitt MessageObserver ist der Vater aller Observer zur Nachrichtenbearbeitung. Mehr zum Observerkonzept steht in Unterabschnitt AbstractMessage ist die Grundlage für Nachrichten eines spezischen Protokolls. NeighborList verwaltet die Nachbarn des Peers. Der Datentyp für den Identikator eines Nachbarn kann dabei in der konkreten Implementierung festgelegt werden. 52

53 4.3. ÜBERBLICK KAPITEL 4. IMPLEMENTIERUNG Abbildung 4.2: Klassen des Peers DateiSystem repräsentiert das Dateisystem eines einzelnen Peers. AbstractStatistik ist die Grundlage für eine Sonde (siehe Unterabschnitt 4.5.3), um einem Peer die Meldung von Messwerten zu ermöglichen. Zur Erfassung weiterer Messwerte kann sie abgeleitet werden Überblick: Ablaufsteuerung SimBenchGlobalEventHandler steuert den Ablauf der Simulation durch eine Instanz der Klasse CommandCenter und sammelt Messwerte der LocalEventHandler ein. SimBenchLocalEventHandler sammeln Messwerte der Peers ein, aggregieren sie, und leiten sie an den GlobalEventHandler weiter. CommandCenter ist die Klasse der Kommandozentrale (siehe Unterabschnitt 4.6.3) und zuständig für das Erzeugen einer Folge von Befehlen für die Peers. Die Modelle für das Verhalten der Peers benden sich hier. GlobalFileSystem Das globale Dateisystem enthält alle in der Simulation möglichen Dateien. In dieser Klasse nden sich die Implementierungen für Modelle zur Verteilung dieser Dateien. 53

54 4.4. ANFORDERUNGEN KAPITEL 4. IMPLEMENTIERUNG Abbildung 4.3: Klassen der Ablaufsteuerung StatCollector Diese Klasse wird von beiden EventHandlern genutzt, um Messwerte einzusammeln und zu aggregieren. Dazu besitzt sie die Fähigkeit, sich selbst als ASCII- Zeichenkette zu serialisieren sowie die Messwerte von solcherart serialisierten weiteren Instanzen von StatCollector zu verschmelzen. Die Arbeitsweise wird in Unterabschnitt erläutert. 4.4 Anforderungen Nun werden einige Eigenschaften des Benchmarks (vgl. Unterabschnitt 2.2.4) wiederholt und geprüft, wie diese als Anforderungen in der Implementierung berücksichtigt werden. Wie sich zeigt, ist SimBench für die getroenen Anforderungen geeignet Relevanz Relevanz verlangt, dass sich die Peers und das Netzwerk typisch verhalten. Dieses Verhalten wird durch die Modellierung der verschiedenen Schichten (vgl. 3.1) erreicht. Da eine Reihe von Ansätzen existiert, das Verhalten von Benutzern und Netzen zu modellieren, wird eine modulare Struktur gewählt, in der die verschiedenen Ansätze umgesetzt werden können. Die eigentliche Modellierung eines realistischen Peer-to-Peer-Systems ist zwar eine wichtige Voraussetzung eines Benchmarks, jedoch zu umfangreich, um in dieser Arbeit ausführlich behandelt zu werden. Mit Hilfe der Erweiterungen von SimBench existieren jedoch die Grundlagen und Schnittstellen, um weitere Werkzeuge zu entwickeln, die den Ablauf einer Simulation noch realistischer modellieren Reproduzierbarkeit Reproduzierbarkeit betrit den gesamten Ablauf des Benchmarks: Wie das Netzwerk aufgebaut wird, reguläre Operationen, die Peers durchführen und Fehlverhalten. Es sind zwei Möglichkeiten bekannt, den Ablauf reproduzierbar zu machen: 54

55 4.4. ANFORDERUNGEN KAPITEL 4. IMPLEMENTIERUNG Ablaufsteuerung durch Skripte, die das Verhalten der Peers zu bestimmten Zeiten festlegt. Dabei ist sowohl Einzelschrittsteuerung als auch eine Steuerung durch Bedingungen denkbar. Mit dieser Steuerung lässt sich ein gewünschtes Verhalten zielgenau herbeiführen. Der Nachteil dieser Methode ist der Aufwand bei der Erstellung der Skripte. Entfernen des Zufalls durch Seeding des Pseudo-Zufallszahlengenerators. Das Eintreten von bestimmten Ereignissen (wie Join, Suche oder Download) wird durch Wahrscheinlichkeiten gesteuert. Durch Einsatz eines Zufallszahlengenerators, dessen Saat (engl. seed) wählbar ist, kann für mehrere Experimente die gleiche pseudozufällige Zahlenfolge erzeugt werden. Wird die Simulation mit gleicher Konguration und der gleichen Saat erneut gestartet, wird eine gleiche Folge von Ereignissen produziert. Verbindet man beide Möglichkeiten, erhält man ein mächtiges Werkzeug, um den Ablauf der Simulation zu steuern. Zuerst wird durch geeignete Wahl der Parameter ein pseudozufälliger Ablauf einer Simulation gewählt. Das dabei entstehende Protokoll kann sofort als Skript verwendet werden, also angepasst wieder von SimBench ausgeführt werden. So können bestimmte Situationen, die gemessen werden sollen, zielgerichtet herbeigeführt werden. Beispielsweise kann dafür gesorgt werden, dass Suchanfragen erfolgreich sind, indem vor der Suche die gesuchte Datei im System gespeichert wird Skalierbarkeit Dezentrale Systeme benötigen dezentrale Benchmarks [OPH03] beschreibt recht gut die Herausforderung. Da P2PNetSim eine auf mehrere Knoten verteilte Simulation ist, sollen rechen- oder speicherintensive Aufgaben nicht einer einzigen Zentralstelle überlassen werden. Die Hauptaufgaben sind Einsammeln der Messwerte und Verteilen der Aufgaben. Während die Simulation theoretisch immer weiter skalierbar ist durch Einsatz zusätzlicher Rechenknoten, wäre eine einzige zentrale Steuerstelle schnell an der Grenze ihrer Leistungsfähigkeit (Flaschenhals). Hierzu werden alle ermittelten Messwerte zunächst von jedem LocalEventHandler gesammelt und aggregiert, bevor sie an den GlobalEventHandler weitergeleitet werden. Das bedeutet zum einen eine Parallelisierung der Sammlung und Aggregation selbst, zum anderen ist die übertragene Datenmenge von einem Simulator zum Controller unabhängig von der Anzahl der Peers auf dem Simulator konstant. Dieser Vorgang wird genauer in Unterabschnitt erläutert. Eine Einschränkung besteht bei der Generierung und Verteilung von Befehlen: dies erfolgt nur am bzw. vom GlobalEventHandler aus. Diese Einschränkung ist praktisch jedoch nicht sehr relevant, da die Rechenzeit zur Befehlserzeugung minimal ist, und die zu übertragenden Daten sehr klein sind Vergleichbarkeit Auch die Vergleichbarkeit wird unterstützt: Sie ist gewährleistet, wenn zum Messen einer Eigenschaft stets dieselbe Denition verwendet wird. Durch Angabe einer Konguration zu einem Benchmark wird dieser nachvollziehbar und somit vergleichbar. Das Ändern einzelner Werte in der Konguration lässt es zu, bestimmte Eigenschaften gezielt 55

56 4.5. PEER-TO-PEER-PROTOKOLLE KAPITEL 4. IMPLEMENTIERUNG zu variieren, ohne den Rest der Simulation zu beeinussen. Die Ergebnisse zweier solcher Benchmarks können so direkt verglichen werden. Dies ist der Fall beim Vergleich einer bestimmten Implementierung eines Protokoll. Beim Vergleich verschiedener Peerto-Peer-Protokolle gilt als Einschränkung, dass diese Tatsache in der Denition und der Implementierungen berücksichtigt werden muss. Die letzte Stufe der Vergleichbarkeit, ein Vergleich über verschiedene Simulatoren, wird nicht angestrebt Einfachheit SimBench bietet verschiedenen Benutzergruppen Einfachheit: Für den Anwender ist Sim- Bench einfach zu bedienen, der Ablauf der Simulation kann durch ein Frontend gesteuert werden, ebenso können die Statistiken gewählt werden. Die gesamte Konguration eines Benchmarks ist menschenlesbar in einer XML-Datei gespeichert. Dem Entwickler wird die Arbeit durch den relativ einfachen Entwurf erleichtert, so dass SimBench leicht erweitert werden kann. Ein Rahmenwerk zur Implementierung vereinfacht die Entwicklung neuer Protokolle, die zudem sofort in den Benchmark eingebettet sind, ohne dass dies bei der Entwicklung mehr Aufwand verursacht. 4.5 Peer-to-Peer-Protokolle Vor dem eigentlichen Benchmark müssen die zu testenden Peer-to-Peer-Protokolle implementiert werden. SimBench soll möglichst viele Protokolle unterstützen. Das Ziel ist ein generischer Benchmark, der in unterschiedliche Protokolle eingebaut werden kann. Um das zu unterstützen, werden einige abstrakte Klassen implementiert, so dass davon abgeleitete Klassen gleich über ein Dateisystem, Nachbarn, eine Statistik und Funktionalität zum Ablauf der Simulation verfügen. P2PNetSim stellt in der Klasse Peer die zwei Methoden congure() zum Initialisieren und dosim() für jeden Simulationsschritt zur Verfügung. So können neue Peer-to-Peer- Protokolle zwar sehr exibel umgesetzt werden, doch diese Freiheit wird für reine Peerto-Peer-Protokolle möglicherweise nicht benötigt und bedeutet in dem Fall zusätzlichen Aufwand. SimBench erweitert deshalb die Klasse Peer in der Klasse AbstractPeer, die der neuen Implementierung von Anfang an einen Rahmen gibt und zusätzliche und für Peer-to-Peer-Protokolle grundlegende Funktionalität bietet. Sie stellt sicher, dass neu entwickelte Peers die Anforderungen des Benchmarks erfüllen. Da von Anfang an Messwerte ermittelt und ausgewertet werden können, erleichtert das das Erkennen von Fehlern im Rahmen der Qualitätskontrolle AbstractPeer AbstractPeer ist die Vaterklasse, von der jede konkrete Peer-to-Peer-Implementierung abgeleitet werden sollte. Dadurch erbt der Peer automatisch eine Reihe von Funktionalitäten und wird in die SimBench Kommando- und Statistikstruktur eingebettet. AbstractPeer bietet also einen Rahmen und vereinfacht so zusätzlich die Implementierung der eigentlichen Peers. Der allgemeine Ablauf eines Simulationsschritts ist in Abbildung 4.4 auf Seite 57 dargestellt. Im einzelnen bedeutet das für den Peer: 56

57 4.5. PEER-TO-PEER-PROTOKOLLE KAPITEL 4. IMPLEMENTIERUNG Start dosim() Befehlsbearbeitung Befehl gefunden? Ja Nein Befehl ausführen Nachrichtenbearbeitung Message vorhanden? Ja Nein Message bearbeiten Overlay reparieren Statistik Message entfernen Statistik sammeln Statistik senden Abbildung 4.4: Ablauf eines Simulationsschritts im Peer Zur Befehlsbearbeitung steht für jeden Befehl eine Methode zur Verfügung, die gerufen wird, sobald der Peer den entsprechenden Befehl erhält. Dazu werden die Parameter des Befehls übergeben. Der abgeleitete Peer ist ein Observable und hat alle Methoden, um mit dem Observerkonzept (siehe Unterabschnitt 4.5.6) zu arbeiten. Die Observer selbst sind Teil des Peers und daher abhängig vom Protokoll. Der Peer hat einen Online-Zustand, der beim Empfang und Senden von Nachrichten berücksichtigt wird. Ist der Peer nicht mit dem Netzwerk verbunden, werden alle eintreenden und ausgehenden Nachrichten verworfen. Darüber hinaus kann er auch ausfallen, dann sendet er keine statistischen Daten mehr. Einfache Messwerte werden bereits mitgeschrieben. Dies betrit gesendete und empfangene Nachrichten sowie Art und Anzahl erhaltener Befehle, den Online- Status und die Uptime, ferner auch die Anzahl verwalteter Dateien. Spezielle Messwerte können nachträglich implementiert werden. Listing 4.1 zeigt einen minimalen funktionstüchtigen Peer. Zur vollen Implementierung eines Protokolls müssen diese Methoden gemäÿ den Spezikationen sowie alle dazu nötigen Elemente wie Klassen für Observer und Nachrichten ausformuliert werden. 57

58 4.5. PEER-TO-PEER-PROTOKOLLE KAPITEL 4. IMPLEMENTIERUNG Algorithmus 4.1 Ein minimaler Peer public c l a s s MiniPeer extends AbstractPeer { protected void r e p a i r O v e r l a y ( ) {} protected boolean commandjoin ( ) { return true ; } protected boolean commandleave ( ) { return true ; } protected boolean commanddelete ( S t r i n g q u e r y S t r i n g ) { return true ; } protected boolean commandfail ( ) { return true ; } protected boolean commandlookup ( S t r i n g q u e r y S t r i n g ) { return true ; } protected boolean commandstore ( S t r i n g s t r ) { return true ; } } Nachrichten Eigene Klassen für Nachrichten sollten von der Klasse AbstractMessage abgeleitet werden. Ratsam ist, die Klassen der Nachrichten klein zu halten, da sie häug erzeugt und gespeichert werden. Das kann z.b. durch eine eigene Klasse für jeden Nachrichtentyp erreicht werden. Von Interesse ist noch die Methode getsize(), welche die Gröÿe der aktuellen Nachricht liefert. Sie kann in der Basisklasse auf den Wert des Headers (abhängig vom Peer-to-Peer- Protokoll) gesetzt werden, in den Söhnen wird dieser Wert dann auf die zusätzliche Gröÿe für die jeweilige Payload addiert. Auf den Rückgabewerten dieser Methode basieren die Messwerte für Nachrichtengröÿen von SimBench Sonde Basis einer Sonde für jeden Peer ist die Klasse AbstractStatistik. Sie enthält Methoden, die bei bestimmten Ereignissen (z.b. Peer geht online, Befehl wird ausgeführt) gerufen werden. Die vordenierten Methoden werden von AbstractPeer automatisch beim Eintritt eines Ereignisses gerufen. Weitere Messdaten werden durch Implementierung einer passenden Methode ermittelt; dabei besteht so eine Methode oft nur aus dem Erhöhen eines oder mehrerer Zähler unter verschiedenen Bedingungen. Von AbstractStatistik abgeleitete Klassen können vom Peer auch dazu verwendet werden, seinen Status abzufragen, beispielsweise seinen Online-Zustand oder den Zeitpunkt der letzten Änderung desselben Protokolldateien P2PNetSim bietet zwei Protokolle an: Das Status-Log (wird im Frontend von P2PNetSim in der Registerkarte (engl. tab) Simulation Log angezeigt) und das Simulations-Log (angezeigt unter Event Log). Dazu existieren Methoden, mittels derer die beteiligten Klassen ihre Nachrichten schreiben können. Da SimBench ein umfangreiches Programm ist und dementsprechend Logeinträge erzeugt, sollen nur die Teile protokolliert werden, die aktuell benötigt werden. Hierzu wurde ein Mechanismus implementiert, der sich an den Funktionen LogFacility (welche Komponenten sollen protokollieren) und LogLevel (ab welchem Schweregrad soll protokolliert werden) des UNIX-Syslog ( [Ger09]) orientiert. Eingestellt werden können die Komponenten und die Schwere in der Klasse Cong.java. 58

59 4.5. PEER-TO-PEER-PROTOKOLLE KAPITEL 4. IMPLEMENTIERUNG LogFacility ist die Herkunft des Logeintrags, d.h. die Komponente, die protokolliert werden soll. Dabei lassen sich die Facilities einzeln und unabhängig voneinander in der Klasse Cong.java aktivieren. Die Komponenten orientieren sich am Entwurf von Sim- Bench und sind z.b. GlobalEventHandler, Peer oder Query für Logeinträge der entsprechenden Komponente. LogLevel bezeichnet die Schwere des Logeintrags. Es existieren die LogLevel DEBUG, VERBOSE, INFO, WARN, ERROR, und FATAL, wobei ihre Bedeutung analog zum Syslog-LogLevel ist, z.b. ist WARN für Warnungen und FATAL für Fehler, die zum Programmabbruch führen. Wird in der Klasse Cong.java ein bestimmter LogLevel eingestellt, werden dieser Level und alle höheren mitgeschrieben. So wäre ein LogLevel für den Betrieb INFO, er schreibt alle Nachrichten mit Schwere INFO, WARN, ERROR oder FATAL. Zur Entwicklung kann DEBUG gewählt werden, was alle anderen Level mit einschlieÿt. Status-Log Das Status-Log enthält alle Nachrichten aller Komponenten in folgendem Format: 23. }{{} Simtime P [ P } {{ } } {{ eer} Sender LogF acility. } INF {{ O} ] :... LogLevel }{{} Logeintrag Zu Beginn jeder Zeile steht der Simulationsschritt, danach kommt die Quelle des Eintrags. In eckigen Klammern folgen durch Punkt getrennt der Name der LogFacility und des Log- Levels. Nach dem ersten Doppelpunkt steht dann die eigentliche Nachricht. Durch diese Vereinheitlichung kann die Protokolldatei automatisch bearbeitet werden. Ein Auszug aus einem Status-Log ist in Abbildung 4.5 auf Seite 59 zu sehen. Dabei beinhaltet das Status-Log alle Informationen zum Ablauf der Simulation in der Reihenfolge, in der die entsprechenden Ereignisse eintreten. 38. CommandCenter [ CommandCenter. INFO ] : sendcommand : Peer036#STORE#f i le_ 19 : 19: / 3 2 [ Query.VERBOSE ] : g n u t e l l a. o b s e r v e r s. QueryObserver : TTL a b g e l a u f e n um / 3 2 [ Ping.VERBOSE ] : g n u t e l l a. o b s e r v e r s. PingObserver : TTL a b g e l a u f e n um / 3 2 [ Peer. INFO ] : got command : Peer005#LOOKUP#f i l e _ : : / 3 2 [ Peer. INFO ] : Executing : Lookup / 3 2 [ Query. INFO ] : s c h i c k e neue query b r o a d c a s t f i l e _ : : / 3 2 [ Peer. INFO ] : Command executed : Peer005#LOOKUP#f i l e _ : : / 3 2 [ Ping.VERBOSE ] : g n u t e l l a. o b s e r v e r s. PingObserver : TTL a b g e l a u f e n um / 3 2 [ Query.VERBOSE ] : s c h i c k e query b r o a d c a s t <i d :QUERY: / 3 2 hops : 1 t t l : 3 s r c : / 3 2 from : / 3 2 to : / 3 2 : "QUERY">: f i l e _ : : / 3 2 [TCP. INFO ] : g n u t e l l a. o b s e r v e r s. TcpObserver : TCPREPLY: Ok <i d :TCPCONNECT : / 3 2 hops : 1 t t l : 3 s r c : / 3 2 from : / 3 2 to : / 3 2 : "TCPCONNECT">: CONNECT / 3 2 [TCP. INFO ] : g n u t e l l a. o b s e r v e r s. TcpObserver : TCPREPLY: Ok <i d :TCPCONNECT : / 3 2 hops : 1 t t l : 3 s r c : / 3 2 from : / 3 2 to : / 3 2 : "TCPCONNECT">: CONNECT / 3 2 [ Peer.ERROR] : O f f l i n e : Msg wird i g n o r i e r t : <i d : PING : / 3 2 hops : 4 t t l : 0 s r c : / 3 2 from : / 3 2 to : / 3 2 : "PING"> / 3 2 [ Query.VERBOSE ] : g n u t e l l a. o b s e r v e r s. QueryObserver : TTL a b g e l a u f e n um / 3 2 [ Peer. INFO ] : adding new n e i g h b o r / 3 2 : 3 9 : o f f Abbildung 4.5: Auszug aus einem status.log 59

60 4.5. PEER-TO-PEER-PROTOKOLLE KAPITEL 4. IMPLEMENTIERUNG Simulations-Log Das Simulations-Log enthält alle Befehle, die an die Peers im Lauf der Simulation geschickt wurden, beginnend mit den ersten Schritten wie anfängliches Verteilen von Dateien auf die Peers. Auf die Weise kann genau nachvollzogen werden, welcher Peer in welchem Schritt welchen Befehl erhielt. Diese Datei wird auÿerdem in einem Format geschrieben, welches leicht wieder eingelesen werden kann (siehe 4.5.5). So kann das Simulations-Log die Grundlage für ein Skript sein, in dem sämtliche Operationen aus dem Simulationsablauf verzeichnet sind. Ein Beispiel für diese Datei ist Abbildung 4.6 auf Seite Peer061#JOIN#n u l l 1 Peer044#STORE#f i l e _ : : ; f i l e _ : : ; f i l e _ : : ; f i l e _ : : ; f i l e _ : : ; f i l e _ : : ; f i l e _ : : ; f i l e _ : : ; f i l e _ : : [... ] 30 Peer076#FAIL#n u l l 30 Peer041#FAIL#n u l l 31 Peer011#STORE#f i l e _ : 770: Peer020#LEAVE#n u l l 31 Peer077#LEAVE#n u l l 31 Peer060#JOIN#n u l l 31 Peer004#LOOKUP#f i l e _ 1 6 : 1 6 : Peer068#LOOKUP#f i l e _ : 191: Peer021#STORE#f i l e _ : 754: Peer042#DELETE#f i l e _ : 297: Peer069#LEAVE#n u l l Abbildung 4.6: Auszug aus einem simulation.log Befehlskodierung Da keine Dokumentation über die interne Arbeitsweise von P2PNetsim verfügbar ist, ist unklar, welche Art von Daten eine Konstante oder ein PeerEvent enthalten darf. Es wird deshalb angenommen, dass Zeichenketten im Format 7-Bit-ASCII problemlos an allen Stellen verwendet und übertragen werden können. Deshalb kann jeder Befehl aus der Klasse PeerCommand in dieses Format umgewandelt und aus diesem Format erzeugt werden. Ein angenehmer Nebeneekt davon ist, dass dieses Format gut menschenlesbar ist. Ein kodierter Befehl besteht aus folgenden Bestandteilen: P} eer087 {{ } # ST } ORE {{ } #[file_83 : 83 : 8300; file_647 : 647 : 64700] } {{ } Bezeichner Befehl P arameter Die einzelnen Teile eines Befehle sind durch das Raute-Zeichen (#) getrennt. Der erste Teil, der Bezeichner, ist der Identikator des Peers, an den der Befehl gesendet wird. Danach folgen der eigentliche Befehl (hier: STORE) und zum Schluss der oder die Parameter des Befehls, falls solche benötigt werden. Im Beispiel würde ein Peer angewiesen, die zwei Dateien le_83 und le_647 mit den angegebenen Datei-Identikatoren und Gröÿen zu speichern. Join- oder Fail-Befehle sind Beispiele für Befehle ohne Parameter. Intern werden Befehle in einer eigenen Klasse dargestellt, dazu verfügt die zugehörige Klasse PeerCommand über Konstruktoren und Methoden zur Hin- und Rückwandlung der Befehlsformate, um also sowohl aus einer solchen Zeichenkette einen Befehl in der internen Darstellung zu dekodieren, als auch einen Befehl in dieser Kodierung auszugeben. Die Vorteile dieser Darstellung sind: 60

61 4.5. PEER-TO-PEER-PROTOKOLLE KAPITEL 4. IMPLEMENTIERUNG Durch das menschenlesbare Format kann der Anwender genau nachvollziehen, welche Operationen in der Simulation ausgeführt werden. Die Übermittlung des Befehls kann an Stellen erfolgen, an denen nur Zeichenketten übergeben werden können. Aktuell wird ein Befehl an einen Peer als Parameter übergeben (RemotePeer.setParam() und getparam() bzw. Peer.setParameter() und getparameter()). Zusätzlich kann der Befehl unverändert in die Logdatei geschrieben werden. Das Konzept kann auf viele interessante Weisen erweitert werden. Möglichkeiten der Erweiterung sind z.b., initiale Befehle auch in der XML-Konguration festzulegen, und die in einer Simulation gespeicherten Befehle als Skript wieder einzuspielen. Damit können dann sehr ligran der Ablauf einer Simulation gesteuert und genau die Befehle oder Situationen herbeigeführt werden, die untersucht werden sollen. Die unmittelbar folgenden Operationen der Simulation können vom Anwender kontrolliert werden, denn die Parameter eines Peers enthalten den nächsten Befehl. Alle Parameter eines Peers werden im Frontend von P2PNetSim unter der Überschrift Properties angezeigt. Eine interessante Anwendung dieses Konzepts ist die Entwicklung einer Skriptsprache für Simulationen: Die Status-Protokolldatei (siehe Unterabschnitt 4.5.4) kann als Grundlage für eine Simulationsbeschreibung dienen (natürlich kann das Skript auch vollständig von Hand erstellt werden). Neue Befehle werden an der Stelle eingefügt, an der sie ausgeführt werden sollen, vorhandene Befehle können entfernt oder modiziert werden. So kann ein zufällig erzeugter Ablauf einer Simulation gezielt beeinusst werden. Hierbei müssen für jeden Befehl eine Simulationszeit und ein Zielpeer angegeben werden. Der einzige Parameter, der derzeit verfügbar ist, ist eine Dateispezikation (siehe Unterabschnitt 3.2.3) für die Suche, das Speichern und Löschen von Dateien. Eine Datei wird hierbei als ein Tripel name; id; groesse geschrieben. Die Klasse FileCommandCenter bietet die Möglichkeit, zu Beginn der Simulation ein erstelltes Skript zu laden, siehe hierzu Unterabschnitt Observer zur Nachrichtenbearbeitung Um auf eingehende Nachrichten zu reagieren, wird das Entwurfsmuster Observer verwendet. Der Peer ist das Observable und wird von mehreren Observern beobachtet, für jede Operation ein eigener. Jede Nachricht wird an alle laufenden Observer gereicht. Der zuständige Observer bearbeitet die Nachricht, alle anderen verwerfen sie. Dieser Entwurf bietet einige Vorteile: Jeder Observer behandelt für sich und gekapselt die entsprechende Operation. Das erhöht die Einfachheit sowie die Übersicht und erleichtert die Implementierung, auch und gerade von Spezialfällen. Jeder Observer verfügt über die genauen Daten der Operation, einschlieÿlich der Nachrichten. So kann ein Observer prüfen, ob eine Antwort auch zur Anfrage passt (z.b. durch Vergleich der Nachrichten-Identikatoren). Das Observer-Konzept ist vergleichbar performant zur Alternative, nämlich Listen von Nachrichten, die in einer Schleife durchlaufen werden, um zu prüfen, ob eine eingehende Nachricht behandelt werden muss. 61

62 4.5. PEER-TO-PEER-PROTOKOLLE KAPITEL 4. IMPLEMENTIERUNG Zur Behandlung aller Situationen können drei Arten von Observern unterschieden werden: Passive Observer sind permanent vorhanden. Dabei startet ein Peer zu Beginn einige permanente Observer, um auf Anfragen anderer Peers zu antworten. Gnutella beispielsweise benötigt einen PongObserver, der eingehende Ping-Nachrichten bearbeitet sowie ein QueryHitObserver, zuständig für Lookup-Nachrichten. Ferner läuft noch, falls im Peer-to-Peer-Protokoll TCP-Verbindungen vorgesehen sind, ein TcpObserver, um Verbindungsanfragen anderer Peers zu beantworten. Observer für entfernte Operationen werden von den passiven Observern initiiert. So wird z.b. eine Lookup-Anfrage vom QueryHitObserver nicht nur beantwortet, sondern auch entsprechend dem Protokoll weitergereicht, bei Gnutella wäre das ein Broadcast. Jede weiter gesendete Anfrage führt zu einer möglichen Antwort, auf die ein Observer für entfernte Operationen wartet. Observer für lokale Operationen werden gestartet, wenn ein Peer eine lokale Operation wie einen Lookup-Befehl auslöst. Diese Observer werden im Gegensatz zu den anderen Arten nicht vom Peer-to-Peer-Protokoll deniert, sondern werden bei simuliertem Benutzer- oder Fehlverhalten benötigt. Der Observer sendet eine entsprechende Nachricht an die Nachbarn und wartet einige Simulationsschritte auf Antwort (Zeitüberschreitung = Timeout). Danach beendet er sich, und weitere nach dem Timeout eintreende Antworten werden verworfen. Treen zur Anfrage passende Antworten ein, kann der Observer entsprechende Aktionen auslösen, z.b. dem Peer Bescheid sagen, dass Suchergebnisse eingetroen sind. Um einen neuen Observer zu implementieren, kann die Klasse MessageObserver abgeleitet werden. Initialisierung ndet im Konstruktor statt, die Arbeit in der update()- Methode. Alle Observer sind recht klein gehalten, und ihre Arbeitsweise ist schnell zu erfassen Beispiel der Integration an Gnutella Abbildung 4.7 auf Seite 63 zeigt, welche Klassen abgeleitet wurden, um das Peer-to- Peer-Protokoll Gnutella in das beschriebene Rahmenwerk von SimBench zu integrieren. Dabei beschränkt sich die Implementierung auf den Aufbau und die Wartung des Overlays, die Reaktion auf Ereignisse (Nachrichten, Befehle), sowie die Erfassung zusätzlicher gewünschter Messwerte. Die Gnutella-spezischen Klassen sind in der Abbildung grün markiert. Im Folgenden werden diese Klassen beschrieben: GnutellaPeer enthält das Protokoll. Insbesondere werden hier die Methoden implementiert, um das Overlay zu warten und auf Befehle der Kommandozentrale zu reagieren. Die Behandlung von eingehenden Nachrichten erfolgt in den entsprechenden Observer- Klassen. 62

63 4.5. PEER-TO-PEER-PROTOKOLLE KAPITEL 4. IMPLEMENTIERUNG Abbildung 4.7: Klassen der Gnutella-Implementierung GnutellaStatistik erweitert die abstrakte Statistik um einige spezische Methoden zur Erfassung der einzelnen Nachrichtentypen sowie der Ping- und Pong-Befehle, welche nur in Gnutella vorkommen. GnutellaNeighborList Die einfache Nachbarschaftsliste wird erweitert, so dass GnutellaNeighborList neben den Nachbarn zusätzlich eine Liste sogenannter inaktiver Peers verwaltet. Das sind Peers, von denen seit längerer Zeit keine Nachricht mehr kam. Die Verwaltung der beiden Listen erfolgt transparent: Wird ein Peer aus der Nachbarschaftsliste entfernt, wird er automatisch in die Liste der inaktiven Peers aufgenommen. Zusätzlich werden die Listen periodisch bereinigt. GnutellaMessage Gnutella hat eigene Nachrichtentypen, die auf der Klasse Gnutella- Message aufbauen. Diese wird als Erweiterung der Klasse AbstractMessage implementiert. Jede Nachricht hat neben den Gnutella-spezischen Attributen auch eine Gröÿe, die je nach Typ berechnet wird. Nachrichtenbearbeitung Die Bearbeitung der Nachrichten erfolgt über Observer. Dieser Teil ist in Abbildung 4.8 auf Seite 64 vergröÿert dargestellt. Dabei ist jedem Nachrichtentyp ein Observer zugewiesen. Observer erweitern die Klasse MessageObserver. Die Namenskonvention ist so gewählt, dass ein Observer zuständig ist für das Versenden von Nachrichten des gleichen Namens. Ein PongObserver z.b. wartet auf eingehende Ping- Nachrichten, um sie mit einem Pong zu beantworten. Ein QueryObserver versendet eine Query-Nachricht und wartet auf die Antwort. Die Unterscheidung zwischen den verschiedenen Observertypen wird in der Klasse GnutellaPeer getroen: Permanente Observer werden beim Initialisieren eines Peers gestartet, 63

64 4.6. BENCHMARK KAPITEL 4. IMPLEMENTIERUNG temporäre Observer beim Senden einer entsprechenden Nachricht. Näheres dazu steht in Unterabschnitt Abbildung 4.8: Nachrichten und Observer von Gnutella Erweiterungen In späteren Beispielen werden verschiedene Varianten des Gnutella- Protokolls (Suche mit Fluten des Netzwerks bzw. Random-Walks) gemessen. Dazu wurden einige Methoden aus GnutellaPeer in Ableitungen der Klasse überschrieben. So konnten gezielt einzelne Funktionalitäten verändert werden, wobei die übrige Implementierung beibehalten wurde. Auÿerdem lassen sich so verschiedene Versionen eines Protokolls auch parallel einsetzen und testen. 4.6 Benchmark Auch wenn die Modellierung der Dynamik wesentlicher Bestandteil von SimBench ist, so sind einige Komponenten nicht dem Ebenenmodell zuzuordnen. Diese Komponenten wurden in Abschnitt 3.2 einer eigenen Ebene Benchmark zugeordnet und werden im Folgenden beschrieben XML-Generator Grundlage für die Einstellungen von P2PNetSim wie auch von SimBench ist die XML- Datei. Neben den Einstellungen für P2PNetSim werden noch alle Angaben der Kon- guration hier gespeichert und im Simulationslauf genutzt. Jeder Benchmark benötigt hierbei eine eigene Konguration (oder auch mehrere). Da die Erstellung der XML-Datei eine Aufgabe ist, die so mühevoll wie monoton ist und häug anfällt, wurde hierfür eine graphische Benutzerschnittstelle implementiert. Darin lassen sich alle Einstellungen zum Benchmark vornehmen, die Erstellung der XML-Datei und der Start von P2PNetSim geschehen dann einfach auf Knopfdruck. Da viele Einstellungen verändert werden können, sind sie in verschiedenen Registerkarten aufgeteilt: Allgemein Oben werden allgemeine Angaben gemacht: Name und Pfad der XML-Datei für die Ausgabe sowie Angabe einer Klasse für die Peers. 64

65 4.6. BENCHMARK KAPITEL 4. IMPLEMENTIERUNG Abbildung 4.9: XML-Generator von SimBench Darunter werden die Einstellungen zur Erzeugung des Netzwerkgraphen vorgenommen. Knoten ist die Anzahl der Peers, Kanten die Zahl der initialen Verbindungen im regulären Graphen. Beta(p) ist die Wahrscheinlichkeit der Kantenverlegung (siehe dazu die Beschreibung des Algorithmus von Watts und Strogatz in Unterabschnitt 3.1.3). Seed ist die Saat für den Zufallszahlengenerator: Gleiche Einstellungen mit gleicher Saat ergeben immer den gleichen Graphen. Auÿerdem ist der Seed die Grundlage für die Befehlsgenerierung. Wird eine wirklich zufällige Simulation gewünscht, kann ein Seed zufällig erzeugt werden. Um den Vergleich von Protokolldateien zu vereinfachen, können Peers alle eingehenden Nachrichten vor der Bearbeitung sortieren. Ohne diese Funktion ist die Reihenfolge des Eintreens der Nachrichten nicht determiniert. Der Algorithmus ist für ungerichtete Graphen; gibt man den Kanten eine Richtung, lassen sich spezielle Graphen wie Ringgraphen erzeugen. Es lassen sich noch Bandbreitenbegrenzungen für einen prozentualen Anteil aller Peers einstellen (experimentell!). Controller Die Einstellungen zum Controller sind hier, wie debug, Host, Port, die Klassen für GlobalEventHandler und LocalEventHandler sowie die beiden Protokolldateien Simulation- und Status-Log und ein Snapshot-Verzeichnis. Alle diese Einstellungen sind von P2PNetSim bekannt und dort beschrieben. Falls mehr als ein Simulator zur Verfügung steht, lassen sich unten die Einstellungen für Hostname bzw. IP-Adresse und Port eines jeden Simulators vornehmen. Dabei werden alle Peers gleichmäÿig auf die Simulatoren aufgeteilt. 65

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten Prof. Dr. P. Tran-Gia Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten 4. Würzburger Workshop IP Netzmanagement, IP Netzplanung und Optimierung Robert Henjes, Dr. Kurt Tutschku

Mehr

Dezentralisiertes Quality-of-Service Monitoring

Dezentralisiertes Quality-of-Service Monitoring Dezentralisiertes Quality-of-Service Monitoring Mai 2013 netidee Zwischenbericht Dieses Dokument informiert über den aktuellen Stand des Netidee 2012 Projektes Dezentralisiertes Quality-of-Service Monitoring.

Mehr

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer Verteiltes Backup Einleitung Grundlegende Backup Techniken Backup in Netzwerken Client/Server Peer-to-Peer Einleitung Backup: Das teilweise oder gesamte Kopieren der in einem Computersystem vorhandenen

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

Dezentralisiertes Quality-of-Service Monitoring

Dezentralisiertes Quality-of-Service Monitoring Dezentralisiertes Quality-of-Service Monitoring Dezember 2013 netidee Endbericht Dieses Dokument informiert über den Abschluss des Netidee 2012 Projektes Dezentralisiertes Quality-of-Service Monitoring.

Mehr

Kademlia A Peer-to-peer Information System based on the XOR Metric

Kademlia A Peer-to-peer Information System based on the XOR Metric Kademlia A Peer-to-peer Information System based on the XOR Metric Martynas Ausra 12.5.2007 Zusammenfassung Das Kademlia-Protokoll wurde im Jahr 2002 an New York University von Petar Maymounkov und David

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011 Lastenheft swp11-4 3. Mai 2011 Zielbestimmungen In der heutigen Geschäftswelt stehen mittelständische Unternehmen vor dem Dilemma, einerseits interne und externe Kommunikation in angemessener Weise gewährleisten

Mehr

Organic Computing. Rolf Wanka Sommersemester 2008 26. Juni 2008. rwanka@cs.fau.de. Organic Computing: Peer-to-Peer-Netzwerke

Organic Computing. Rolf Wanka Sommersemester 2008 26. Juni 2008. rwanka@cs.fau.de. Organic Computing: Peer-to-Peer-Netzwerke Organic Computing Peer-to to-peer-netzwerke Rolf Wanka Sommersemester 2008 26. Juni 2008 rwanka@cs.fau.de P2P-Netzwerke aktuell Juni 2004 Quelle: CacheLogic 2005 Über 8 Mio. aktive Teilnehmer an Peer-to-Peer-Netzwerken

Mehr

Algorithmen für Peer-to-Peer-Netzwerke Sommersemester 2004 04.06.2004 7. Vorlesung

Algorithmen für Peer-to-Peer-Netzwerke Sommersemester 2004 04.06.2004 7. Vorlesung Algorithmen für Peer-to-Peer-Netzwerke Sommersemester 2004 04.06.2004 7. Vorlesung 1 Kapitel III Skalierbare Peer to Peer-Netzwerke Tapestry von Zhao, Kubiatowicz und Joseph (2001) Netzw erke 2 Tapestry

Mehr

Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS

Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS Dezember 007 Dipl.-Ing. Stefan Abu Salah Dipl.-Ing. Achim Marikar QoS (Quality of Service): Sicherstellung der Qualität Zeitkritische

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Scheinaufgabe im Fach Web Engineering

Scheinaufgabe im Fach Web Engineering Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Scheinaufgabe im Fach Web Engineering Thomas Thüm 07. August 2006 Matrikel: 171046 Lehrveranstaltung: Web

Mehr

Peer-to-Peer-basierte kollaborative Spam-Erkennung und Filterung

Peer-to-Peer-basierte kollaborative Spam-Erkennung und Filterung Der folgende Seminarbericht dient als Grundlage für die Studien-/Diplomarbeit über ein P2P basiertes Spambekämpfungssystem. Für die Studien/Diplomarbeit besonders relevante Stellen sind fett markiert.

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

Mehr

Peer-to-Peer Netzwerke in der Praxis

Peer-to-Peer Netzwerke in der Praxis Peer-to-Peer Netzwerke in der Praxis Alexander Bach 18. Juni 2010 1 Einleitung Inzwischen gibt es im Internet sehr viele und auch sehr unterschiedliche Peerto-Peer Netzwerke, die zu ebenso unterschiedlichen

Mehr

Schichtenmodell. Informatik Fortbildung Kommunikation in Rechnernetzen. IFB Speyer 14.-16. November 2011. Dr. Michael Schlemmer

Schichtenmodell. Informatik Fortbildung Kommunikation in Rechnernetzen. IFB Speyer 14.-16. November 2011. Dr. Michael Schlemmer Schichtenmodell Informatik Fortbildung Kommunikation in Rechnernetzen IFB Speyer 14.-16. November 2011 Dr. Michael Schlemmer ISO-OSI Schichtenmodell Moderne Kommunikationssysteme sind komplex: Gestalt

Mehr

Internet Routing am 14. 11. 2006 mit Lösungen

Internet Routing am 14. 11. 2006 mit Lösungen Wissenstandsprüfung zur Vorlesung Internet Routing am 14. 11. 2006 mit Lösungen Beachten Sie bitte folgende Hinweise! Dieser Test ist freiwillig und geht in keiner Weise in die Prüfungsnote ein!!! Dieser

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 8 10. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Das Skype Peer-to-Peer VoIP System

Das Skype Peer-to-Peer VoIP System Das Skype Peer-to-Peer VoIP System Vladislav Lazarov lazarov@in.tum.de Voice-over-IP Internet Telefonie oder Voice over IP: Telefonieren über Computernetzwerke, die nach Internet-Standards aufgebaut sind

Mehr

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Cloud-Computing Seminar Hochschule Mannheim WS0910 1/23 Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Fakultät für Informatik Hochschule

Mehr

Laptop a location aware peer-to-peer overlay network Chi-Jen Wu, De-Kai Liu and Ren-Hung Hwang

Laptop a location aware peer-to-peer overlay network Chi-Jen Wu, De-Kai Liu and Ren-Hung Hwang Albert-Ludwigs-Universität Freiburg SS 2009 Institut für Informatik Lehrstuhl für Rechnernetze und Telematik Seminararbeit Laptop a location aware peer-to-peer overlay network Chi-Jen Wu, De-Kai Liu and

Mehr

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE DOKUMENTATION MAAS - MONITORING AS A SERVICE DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE Dokumentation MaaS - Monitoring as a Service Inhalt 1. MaaS - Monitoring as Service... 3 1.1 Einleitung...

Mehr

Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse

Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse Peter Hillmann Institut für Technische Informatik Fakultät für Informatik Peter.Hillmann@unibw.de Peter Hillmann 1 Gliederung 1. Motivation

Mehr

1. Einleitung. 1.1. Ausgangssituation

1. Einleitung. 1.1. Ausgangssituation 1. Einleitung In der vorliegenden Arbeit wird untersucht, welche Faktoren den erfolgreichen Ausgang eines Supply-Chain-Projektes zwischen zwei Projektpartnern beeinflussen. Dazu werden zum einen mögliche

Mehr

Tinytag Funk- Datenlogger- Software

Tinytag Funk- Datenlogger- Software Tinytag Funk- Datenlogger- Software Seite: 1 Tinytag Funk- Datenlogger- Software Tinytag Explorer ist die Windows- basierte Software zum Betrieb eines Tinytag Funk- Systems. Die Anwender können ihre Daten

Mehr

Lastenheft. Auftraggeber IBR Abteilung ALG

Lastenheft. Auftraggeber IBR Abteilung ALG Lastenheft Auftraggeber IBR Abteilung ALG Versionsübersicht Version Datum Autor Status Kommentar 1.0 9. 2. 2011 Auftraggeber 1.1 1. 4. 2011 Auftraggeber Ergänzung Miniflur, Personenerkennung 1.1.1 6. 4.

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

[DIA] Webinterface 2.4

[DIA] Webinterface 2.4 [DIA] Webinterface 2.4 2 Inhalt Inhalt... 2 1. Einleitung... 3 2. Konzept... 4 2.1 Vorteile und Anwendungen des... 4 2.2 Integration in bestehende Systeme und Strukturen... 4 2.3 Verfügbarkeit... 5 3.

Mehr

Peer-to-Peer- Netzwerke

Peer-to-Peer- Netzwerke Peer-to-Peer- Netzwerke Christian Schindelhauer Sommersemester 2006 14. Vorlesung 23.06.2006 schindel@informatik.uni-freiburg.de 1 Evaluation der Lehre im SS2006 Umfrage zur Qualitätssicherung und -verbesserung

Mehr

Last- und Stresstest. Überblick. Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung

Last- und Stresstest. Überblick. Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung Methoden und Werkzeuge zur Softwareproduktion WS 2003/04 Karsten Beyer Dennis Dietrich Überblick Einleitung / Motivation Stresstest Lasttest Tools The Grinder Zusammenfassung 2 Motivation Funktionstest

Mehr

EDI CONNECT. für Microsoft Dynamics NAV. Auf einen Blick:

EDI CONNECT. für Microsoft Dynamics NAV. Auf einen Blick: Seite 1 PROTAKT Speziallösung EDI Connect Auf einen Blick: EDI CONNECT für Microsoft Dynamics NAV Elektronischer Datenaustausch ganz effizient und einfach über Ihr Microsoft Dynamics NAV System. Vollständige

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

Peer-to-Peer (P2P) Grundlagen

Peer-to-Peer (P2P) Grundlagen Semantische Analyse des Internet (9) Peer-to-Peer (P2P) Grundlagen Markus Gräser, 8.6.2004 Gliederung Definition Geschichte P2P-Netzwerk-Architekturen Anwendungsgebiete Populäre File-Sharing Systeme Technische

Mehr

Can ISPs and P2P Users Cooperate for Improved Performance? nach Vinay Aggarwal, Anja Feldmann, Christian Scheideler

Can ISPs and P2P Users Cooperate for Improved Performance? nach Vinay Aggarwal, Anja Feldmann, Christian Scheideler Albert-Ludwigs-Universität Freiburg SS 2009 Institut für Informatik Lehrstuhl für Rechnernetze und Telematik Seminararbeit Can ISPs and P2P Users Cooperate for Improved Performance? nach Vinay Aggarwal,

Mehr

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

Protokoll 1. 1. Frage (Aufgabentyp 1 Allgemeine Frage):

Protokoll 1. 1. Frage (Aufgabentyp 1 Allgemeine Frage): Protokoll 1 a) Beschreiben Sie den allgemeinen Ablauf einer Simulationsaufgabe! b) Wie implementieren Sie eine Einlass- Randbedingung (Ohne Turbulenz!) in OpenFOAM? Geben Sie eine typische Wahl für U und

Mehr

Internet Mapping: from Art to Sience Peer-to-Peer Seminar Ausarbeitung

Internet Mapping: from Art to Sience Peer-to-Peer Seminar Ausarbeitung Albert-Ludwigs-Universität Freiburg SS 2009 Institut für Informatik Lehrstuhl für Rechnernetze und Telematik Seminararbeit Internet Mapping: from Art to Sience Peer-to-Peer Seminar Ausarbeitung Patrick

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

Heterogenes Speichermanagement mit V:DRIVE

Heterogenes Speichermanagement mit V:DRIVE Heterogenes Speichermanagement mit V:DRIVE V:DRIVE - Grundlage eines effizienten Speichermanagements Die Datenexplosion verlangt nach innovativem Speichermanagement Moderne Businessprozesse verlangen auf

Mehr

PageRank-Algorithmus

PageRank-Algorithmus Proseminar Algorithms and Data Structures Gliederung Gliederung 1 Einführung 2 PageRank 3 Eziente Berechnung 4 Zusammenfassung Motivation Motivation Wir wollen eine Suchmaschine bauen, die das Web durchsucht.

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie

Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie Wolfgang Ginolas Fachhochschule Wedel 21. September 2009 Wolfgang Ginolas (Fachhochschule Wedel) 21. September 2009 1 / 14 Einleitung

Mehr

Michael Dimov: Peer-to-Peer Technologie Vortrag im Rahmen eines Seminars

Michael Dimov: Peer-to-Peer Technologie Vortrag im Rahmen eines Seminars Michael Dimov: Peer-to-Peer Technologie Vortrag im Rahmen eines Seminars 2003 Michael Dimov, info@dimovdesign.de Seite 1 Überblick 1. Einführung in P2P 2. Problematik beim P2P Design 3. Drei Fallbeispiele

Mehr

Exploration des Internets der systemorientierte Ansatz. Aktivierender Unterricht mit der Lernsoftware Filius

Exploration des Internets der systemorientierte Ansatz. Aktivierender Unterricht mit der Lernsoftware Filius Exploration des Internets der systemorientierte Ansatz Aktivierender Unterricht mit der Lernsoftware Filius Dr. Stefan Freischlad 26.03.2012 1 Agenda 1.Unterricht zu Internetworking 2.Einführung zur Konzeption

Mehr

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Hintergrund Bei komplexen Baugruppen ergeben sich sehr hohe Anforderungen an die Tolerierung der einzelnen

Mehr

Diplomanden- und Doktorandenseminar. Implementierung eines Gnutella-Clients für IPv6

Diplomanden- und Doktorandenseminar. Implementierung eines Gnutella-Clients für IPv6 Diplomanden- und Doktorandenseminar Implementierung eines Gnutella-Clients für IPv6 1. Motivation 2. IPv6 3. Gnutella 4. Portierung Frank Sowinski 17.12.2002 Motivation Gute Gründe für IPv6 Das Anwachsen

Mehr

Hochschule Bremen. Rechnerstrukturen Labor WS 04/05 I7I. Thema: Grafikkarten. Laborbericht. Datum 18.01.2005

Hochschule Bremen. Rechnerstrukturen Labor WS 04/05 I7I. Thema: Grafikkarten. Laborbericht. Datum 18.01.2005 Hochschule Bremen Rechnerstrukturen Labor I7I Thema: Grafikkarten Laborbericht Datum 18.01.2005 Carsten Eckert(83912) (72497) Fazit Für unseren Praxisteil zum Vortrag Grafikkarten haben wir uns entschieden,

Mehr

Software Wildpackets AiroPeek NX

Software Wildpackets AiroPeek NX Software Wildpackets AiroPeek NX Seite 1 / 5 Wildpackets - AiroPeek NX Netzwerkanalyse Software für WLAN nach IEEE 802.11 a/b/g mit integrierten Expertensystem. Möchten Sie ein größeres Wireless LAN fit

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

Echtzeitverhalten durch die Verwendung von CPU Stubs: Eine Erweiterung von Dynamic Performance Stubs. Echtzeit 2009

Echtzeitverhalten durch die Verwendung von CPU Stubs: Eine Erweiterung von Dynamic Performance Stubs. Echtzeit 2009 Echtzeitverhalten durch die Verwendung von CPU Stubs: Eine Erweiterung von Dynamic Performance Stubs Echtzeit 2009 Peter Trapp, 20.11.2009 Übersicht 1 Einleitung 2 (Übersicht) 3 (Framework) 4 Methodik

Mehr

End to End Monitoring

End to End Monitoring FACHARTIKEL 2014 End User Experience Unsere Fachartikel online auf www.norcom.de Copyright 2014 NorCom Information Technology AG. End User Experience - tand quantitativer Betrachtung. Vor allem aber, -

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Strukturierte Peer-to-Peer Netze

Strukturierte Peer-to-Peer Netze Strukturierte Peer-to-Peer Netze Distributed Operating Systems Konrad Miller 06.07.2009 Ein Großteil der Folien ist von der Vorlesung: Protokollanalyse Selbstorganisierender

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. Java Connection Architecture Teil 3

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. Java Connection Architecture Teil 3 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Connection Architecture Teil 3 CICS Transaction Gateway el0100 copyright W. G. Spruth,

Mehr

The integration of business intelligence and knowledge management

The integration of business intelligence and knowledge management The integration of business intelligence and knowledge management Seminar: Business Intelligence Ketevan Karbelashvili Master IE, 3. Semester Universität Konstanz Inhalt Knowledge Management Business intelligence

Mehr

Zeichnen von Graphen. graph drawing

Zeichnen von Graphen. graph drawing Zeichnen von Graphen graph drawing WS 2006 / 2007 Gruppe: D_rot_Ala0607 Christian Becker 11042315 Eugen Plischke 11042351 Vadim Filippov 11042026 Gegeben sei ein Graph G = (V; E) Problemstellung V E =

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

Visuelle Simulation eines Radiosity Algorithmus und ihre Anwendung in Lernprozessen

Visuelle Simulation eines Radiosity Algorithmus und ihre Anwendung in Lernprozessen Visuelle Simulation eines Radiosity Algorithmus und ihre Anwendung in Lernprozessen Abschlussvortrag zur Diplomarbeit von Jörg Karpf Graphische Datenverarbeitung, Institut für Informatik 3. September 2009

Mehr

Kompakte Graphmodelle handgezeichneter Bilder

Kompakte Graphmodelle handgezeichneter Bilder Kompakte Graphmodelle handgezeichneter Bilder Einbeziehung in Authentizierung und Bilderkennung Inhaltsverzeichnis Seminar Mustererkennung WS 006/07 Autor: Stefan Lohs 1 Einleitung 1 Das graphische Modell.1

Mehr

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer Kommunikation I 1 Klausur Kommunikation I Sommersemester 2003 Dipl.-Ing. T. Kloepfer Bearbeitungsinformationen Aufbau der Klausur Die Klausur ist wie folgt aufgebaut: Die Klausur ist in 18 Aufgaben unterteilt.

Mehr

Pflichtenheft und Angebot für ein Lohnabrechnungssystem basierend auf Open Source Komponenten

Pflichtenheft und Angebot für ein Lohnabrechnungssystem basierend auf Open Source Komponenten - 1 - Musterfirma ANGEBOT AN Beispielkunde z.hd. Frau Beispiel Projekt - Accounting - Beispielstraße 1 11111 Beispielstadt KUNDENNUMMER IHR AUFTRAG VOM ANGEBOTSNUMMER DATUM beispiel01 31.03.2015 2015-10

Mehr

Rechnernetze Übung 8 15/06/2011. Schicht 7 Schicht 6 Schicht 5 Schicht 4 Schicht 3 Schicht 2 Schicht 1. Switch. Repeater

Rechnernetze Übung 8 15/06/2011. Schicht 7 Schicht 6 Schicht 5 Schicht 4 Schicht 3 Schicht 2 Schicht 1. Switch. Repeater Rechnernetze Übung 8 Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juni 2011 Schicht 7 Schicht 6 Schicht 5 Schicht 4 Schicht 3 Schicht 2 Schicht 1 Repeater Switch 1 Keine Adressen 6Byte

Mehr

Kapitel 6 Internet 1

Kapitel 6 Internet 1 Kapitel 6 Internet 1 Kapitel 6 Internet 1. Geschichte des Internets 2. Datenübertragung mit TCP/IP 3. Internetadressen 4. Dynamische Zuteilung von Internetadressen 5. Domain-Namen 6. Internetdienste 2

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com Merkblatt: HSM Version 1.01 Systemvoraussetzungen, Setup und Trouble Shooting Kontakt: pdfsupport@pdf-tools.com Besitzer: PDF Tools AG Kasernenstrasse 1 8184 Bachenbülach Schweiz www.pdf-tools.com Copyright

Mehr

1. Normen für Unternehmen

1. Normen für Unternehmen 1. Normen für Unternehmen Normen sind gut für ein Missverständnis und schlecht für ein Verständnis. Um diesem Wortspiel einen konkreten Inhalt zu geben, seien zwei Thesen angeführt: Das Missverständnis

Mehr

visionapp Remote Desktop (vrd) & mremote

visionapp Remote Desktop (vrd) & mremote visionapp Remote Desktop () & Tool-Vergleich Produktinformation www..de visionapp Remote Desktop und im Überblick In diesem Tool-Vergleich werden die wesentlichen Merkmale der visionapp Remote Desktop

Mehr

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08 PIWIN II Kap. 3: Verteilte Systeme & Rechnernetze 1 PIWIN II Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II Vorlesung 2 SWS SS 08 Fakultät für Informatik Technische

Mehr

Test nichtfunktionaler Anforderungen in der Praxis am Beispiel einer netzzentrierten Anwendung. Test nichtfunktionaler Anforderungen Agenda

Test nichtfunktionaler Anforderungen in der Praxis am Beispiel einer netzzentrierten Anwendung. Test nichtfunktionaler Anforderungen Agenda Test nichtfunktionaler in der Praxis am Beispiel einer netzzentrierten Anwendung Februar 2011 Test nichtfunktionaler Agenda 1. 2. 3. 4. 5. 6. TAV Tagung Februar 2011 Julia Remmert Public Wincor Nixdorf

Mehr

Adaptive Choice-Based-Conjoint: Neue Möglichkeiten in der Marktforschung

Adaptive Choice-Based-Conjoint: Neue Möglichkeiten in der Marktforschung Adaptive Choice-Based-Conjoint: Neue Möglichkeiten in der Marktforschung MAIX Market Research & Consulting GmbH Kackertstr. 20 52072 Aachen 0241 8879 0 www.maix.de Inhalt Einleitung Grundlagen zur Conjoint

Mehr

Scaling IP Addresses. CCNA 4 version 3.0 Wolfgang Riggert,, FH Flensburg

Scaling IP Addresses. CCNA 4 version 3.0 Wolfgang Riggert,, FH Flensburg Scaling IP Addresses CCNA 4 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von Rick Graziani, Cabrillo College Vorbemerkung Die englische Originalversion finden Sie unter : http://www.cabrillo.cc.ca.us/~rgraziani/

Mehr

Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses

Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses Gunter Grieser, Simon Spielmann, Guido Schuh, Boris Kötting, Ralf Leonhard AGENDA Das Projekt Unser

Mehr

Router 1 Router 2 Router 3

Router 1 Router 2 Router 3 Network Layer Netz 1 Netz 2 Netz 3 Router 1 Router 2 Router 3 Router 1 Router 2 Router 3 Netz 1, Router 1, 1 Netz 1, Router 1, 2 Netz 1, Router 2, 3 Netz 2, Router 2, 2 Netz 2, Router 2, 1 Netz 2, Router

Mehr

sedex-client Varianten für den Betrieb in einer hoch verfügbaren

sedex-client Varianten für den Betrieb in einer hoch verfügbaren Département fédéral de l'intérieur DFI Office fédéral de la statistique OFS Division Registres Team sedex 29.07.2014, version 1.0 sedex-client Varianten für den Betrieb in einer hoch verfügbaren Umgebung

Mehr

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN CLOUD-ENTWICKLUNG: BESTE METHODEN 1 Cloud-basierte Lösungen sind auf dem IT-Markt immer weiter verbreitet und werden von immer mehr

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme Fakultät für Mathematik, Informatik und Naturwissenschaften Forschungsgruppe Softwarekonstruktion Diplomarbeit Entwurf eines generischen Prozessleitstandes für Change Request Systeme Development of a Generic

Mehr

Messsystemanalyse (MSA)

Messsystemanalyse (MSA) Messsystemanalyse (MSA) Inhaltsverzeichnis Ursachen & Auswirkungen von Messabweichungen Qualifikations- und Fähigkeitsnachweise Vorteile einer Fähigkeitsuntersuchung Anforderungen an das Messsystem Genauigkeit

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik - Arbeitsheft

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik - Arbeitsheft Lösungen zu ---- Informations- und Telekommunikationstechnik - Arbeitsheft Handlungsschritt Aufgabe a) Die TCP/IP-Protokollfamilie verwendet logischen Adressen für die Rechner (IP- Adressen), die eine

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

Mehr

Entwurfsmethode für service-orientierte Architekturen im dezentralen Energiemanagement

Entwurfsmethode für service-orientierte Architekturen im dezentralen Energiemanagement Entwurfsmethode für service-orientierte Architekturen im dezentralen Energiemanagement Tanja Schmedes Betriebliches Informationsmanagement OFFIS Institut für Informatik tanja.schmedes@offis.de MKWI 2008

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Peer to Peer. ENGL Bernhard 0120956 PRAXMARER Stefan 0120383 COLOSIO Markus 0120160

Peer to Peer. ENGL Bernhard 0120956 PRAXMARER Stefan 0120383 COLOSIO Markus 0120160 Peer to Peer ENGL Bernhard 0120956 PRAXMARER Stefan 0120383 COLOSIO Markus 0120160 Inhalt Einführung Peer to Peer vs. Client/Server Informationssuche Technik Filesharing Programme Rechtssituation Client-Server-Architektur

Mehr

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

Repeatable Benchmarking Mahout

Repeatable Benchmarking Mahout Studienarbeitsexposé Repeatable Benchmarking Mahout Entwicklung eines Lasttest-Rahmenwerkes für Apache Mahout von: Oliver Fischer Institut für Informatik Humbold-Universität zu Berlin Matrikelnummer: 19

Mehr

Grundsätzliches. Grundsätzliche Überlegungen zu Netzwerken Stand : Juli 2006

Grundsätzliches. Grundsätzliche Überlegungen zu Netzwerken Stand : Juli 2006 Grundsätzliches Grundsätzliche Überlegungen zu Netzwerken Stand : Juli 2006 Netzanforderungen und - probleme Radikale Designänderungen während des Baus / der Gestaltung von Netzwerken, daher unberechenbare

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

1 Einleitung. Software Engineering. Vorgehensweisen

1 Einleitung. Software Engineering. Vorgehensweisen 1 Noch ein Buch über Software Engineering? Warum nicht! Wir folgen einem Prinzip, das zur Lösungsfindung in den verschiedensten Domänen Einzug gehalten hat: die Betrachtung aus verschiedenen Blickwinkeln.

Mehr

Daniel Heß. Donnerstag, den 16. November 2006. Verein zur Förderung der privaten Internet Nutzung e.v. Wie funktioniert das Internet? dh@ping.

Daniel Heß. Donnerstag, den 16. November 2006. Verein zur Förderung der privaten Internet Nutzung e.v. Wie funktioniert das Internet? dh@ping. Daniel Heß Verein zur Förderung der privaten Internet Nutzung e.v. Donnerstag, den 16. November 2006 Was ist Ein globales Netzwerk von Computern und Kommunikationsgeräten Quelle für eine fast unendliche

Mehr

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND init.at informationstechnologie GmbH - Tannhäuserplatz 2 - A-1150 Wien - www.init.at Dieses Dokument und alle Teile von ihm bilden ein geistiges Eigentum

Mehr

Was ist Language Based BPM? Eine kurze Erklärung Version 1.0

Was ist Language Based BPM? Eine kurze Erklärung Version 1.0 Was ist Language Based BPM? Eine kurze Erklärung Version 1.0 Dieses Dokument wurde verfasst von Dr. Jürgen Pitschke, BCS-Dr. Jürgen Pitschke, www.enterprise-design.eu Diese Unterlagen können frei für nicht-kommerzielle

Mehr

Internet/Intranet nutzbringend angewandt!?!

Internet/Intranet nutzbringend angewandt!?! Internet/Intranet nutzbringend angewandt!?! Maik G. Seewald Agenda 1. Einleitung und Ziel der Präsentation 2. Internet u. Web Based Computing eine Erfolgsgeschichte 3. Architektur web-basierter Anwendungssysteme

Mehr

Zuverlässige Informationsbereitstellung in energiebewussten ubiquitären Systemen (ZeuS)

Zuverlässige Informationsbereitstellung in energiebewussten ubiquitären Systemen (ZeuS) Zuverlässige Informationsbereitstellung in energiebewussten ubiquitären Systemen () Vergleich von Ansätzen zur Netzwerkanalyse in drahtlosen Sensornetzen Joachim Wilke,, Markus Bestehorn, Zinaida Benenson,

Mehr

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr