Daedalus – Ein P2P-Shared-Memory- System für

Transcription

Diplomarbeit
Daedalus – Ein P2P-Shared-MemorySystem für Ubiquitous-Computing
Christian Keller
christian@wohlfrei.de
Februar 2006
Humboldt-Universität zu Berlin
Mathematisch-Naturwissenscha�liche Fakultät II
Institut für Informatik
Lehrstuhl für Rechnerorganisation und Kommunikation
Gutachter:
Prof. Dr. Miroslaw Malek
n.a.
Betreuer:
Dipl.-Inf. Peter Ibach
(ibach@informatik.hu-berlin.de)
Abstract
Das in dieser Arbeit vorgestellte verteilte Peer-to-Peer-Speichersystem für
Ubiquitous-Computing – Daedalus – ermöglicht das Verändern von gespeicherten
Datenobjekten. Dabei wird die Konsistenz der Daten gesichert, in dem ein
stochastisches Locking-Verfahren verwendet wird, welches den speziellen
Bedingungen von Peer-to-Peer-Netzen und Ubiquitous-Computing Rechnung
trägt.
Daedalus verteilt die Last auf die teilnehmenden Knoten nicht gleichmäßig
sondern sozial. Das heißt, je leistungsfähiger ein Knoten ist, desto mehr Aufgaben
übernimmt er. Besonders leistungsschwache Knoten können so vollkommen
passiv von Daedalus profitieren.
Trotz stochastischem Locking nimmt die Last eines leistungsstarken Knotens
nur linear zu. Anders als in vielen vergleichbaren Systemen, jedoch nicht mit der
Gesamtzahl aller partizipierenden Knoten sondern nur mit der Zahl der Knoten,
die sich für ein bestimmtes Datenobjekt interessieren. Dadurch wird die Last eines
Knotens nur in seltenen Fällen sehr groß werden.
Der Daten- und Zeitoverhead der für die Verwaltung nötig ist, macht ein
Dataclustering für die Proof-of-Concept-Implementation in MagicMap sinnvoll.
Sta� jede Information als eigenständigen Wert in Daedalus zu speichern, bietet es
sich an ähnliche Informationen zu einem Datenobjekt zusammenzufassen wobei
die Schreibzugriffe auf ein Datenobjekt minimiert werden.
Inhaltsverzeichnis
1 Einführung .....................................................................................................................1
2 Distributed-Shared-Memory-Systeme .......................................................................3
2.1 Freenet ...............................................................................................................5
2.2 OceanStore ........................................................................................................6
2.3 Ivy ......................................................................................................................9
2.4 JuxMem ...........................................................................................................12
2.5 Zusammenfassung ........................................................................................14
3 Peer-to-Peer-Frameworks...........................................................................................15
3.1 Chord...............................................................................................................16
3.2 JXTA.................................................................................................................18
3.3 Tapestry ...........................................................................................................22
4 Daedalus.......................................................................................................................24
4.1 Anforderungen...............................................................................................24
4.2 Konzeption von Daedalus ............................................................................27
4.3 Gruppeneintri� ..............................................................................................29
4.4 Lesen der Ressource ......................................................................................30
4.5 Stochastisches Locking..................................................................................30
4.6 Schreiben der Ressource ...............................................................................32
4.7 Verlassen der Gruppe....................................................................................33
5 Evaluierung..................................................................................................................34
5.1 Skalierbarkeit..................................................................................................34
5.2 Performanz .....................................................................................................35
5.3 Fehlermodell...................................................................................................41
5.4 Verfügbarkeit..................................................................................................43
5.5 Responsivität ..................................................................................................44
5.6 Datenoverhead ...............................................................................................45
I
6 Die Implementation ....................................................................................................47
6.1 MagicMap als Umgebung ............................................................................47
6.2 Schni�stelle zu MagicMap ...........................................................................49
6.3 Clustering der Daten .....................................................................................51
6.4 Daedalus als MagicMap-Modul ..................................................................52
6.5 Alternative Lösungen....................................................................................61
7 Zusammenfassung und Ausblick ............................................................................63
8. Literaturverzeichnis...................................................................................................66
II
Abbildungsverzeichnis
Abbildung 2.1: Die Verteilung der Daten in OceanStore .........................................9
Abbildung 2.2: Das JuxMem-Netzwerk....................................................................12
Abbildung 2.3: Einordnung von Peer-to-Peer-Shared-Memory-Systemen .........14
Abbildung 3.1: Chord-Netzwerk ...............................................................................18
Abbildung 3.2: JXTA-Kommunikation .....................................................................21
Abbildung 3.3: Anfragen in Tapestry........................................................................23
Abbildung 4.1: Der Lockingmechanismus ...............................................................31
Abbildung 5.1: Zeiten bis der Knoten mit dem JXTA-Netzwerk verbunden ist 37
Abbildung 5.2: Zeit vom Gruppeneintri� bis zur Erlangung der Ressource......38
Abbildung 5.3: Zeiten zum Ermi�eln von ungecachten Ressourcen ...................40
Abbildung 5.4: Zeiten beim Verändern der Ressource...........................................40
Abbildung 5.5: Median und Durchschnitswert der ermi�elten Zeiten ...............41
Abbildung 6.1: Die MagicMap-Architektur.............................................................48
Abbildung 6.2: Verteiltes Messen und Berechnen in MagicMap ..........................49
Abbildung 6.3: Die Interaktion in MagicMap..........................................................51
Abbildung 6.4: Datenobjekte für MagicMap ...........................................................52
Abbildung 6.5: Beispielha�e Gruppenhierarchie....................................................53
Abbildung 6.6: Das Hello-Paket.................................................................................54
Abbildung 6.7: Das Welcome-Paket ..........................................................................55
Abbildung 6.8: Das Request-Paket ............................................................................56
Abbildung 6.9: Das Resource-Paket ..........................................................................57
Abbildung 6.10: Das Bye-Paket..................................................................................57
III
Abbildung 6.11: Das Mutex-Request-Paket .............................................................58
Abbildung 6.12: Das Mutex-Response-Paket...........................................................59
Abbildung: 6.13: Das Validation-Request-Paket......................................................59
Abbildung 6.14: Das Validation-Paket ......................................................................60
Abbildung 6.15: Das Error-Paket ...............................................................................60
Abbildung 6.16: Das Manager-Request-Paket .........................................................61
IV
Tabellenverzeichnis
Tabelle 1.1: Eigenscha�en der Peer-to-Peer-Shared-Memory-Systeme..................... 3
Tabelle 2.1: Mögliche Ivy Logeinträge ......................................................................... 11
Tabelle 4.1: Parameter von Daedalus ........................................................................... 28
Tabelle 5.1: Lasten für Manager durch Nachrichten.................................................. 34
Tabelle 5.2: Daedalus-Performanz ................................................................................ 39
Tabelle 5.3: Folgen von Fehlern..................................................................................... 42
Tabelle 5.4: Responsivität einer Gruppe ...................................................................... 45
Tabelle 5.5: Paketgrößen von Daedalusnachrichten................................................... 46
V
1 Einführung
Mobile Nutzer können gegenwärtig nur eingeschränkt auf Netzdienste zugreifen.
So ist zwar das Lesen von Nachrichten mit heutigen Geräten unproblematisch, das
aktive Partizipieren an Systemen wie Wikis, Foren oder öffentlichen Kalendern
einer Arbeitsgruppe erfordert jedoch meist mehr Ressourcen und kann sehr hohe
Kosten verursachen. Zudem sind sie auf die Unterstützung stationärer Geräte
angewiesen, etwa Servern, die die Kalenderdaten speichern und ausliefern. Es ist
nicht möglich, dass ein Nutzer unterwegs einen Kalender anlegt, auf den andere
mobile Nutzer zugreifen können, wenn er nicht zuvor einen Server installiert hat.
Dies hat zur Folge, dass mobile Szenarien die Flexibilität einschränken.
Ein weiteres Beispiel für mobile Geräte, die auf Daten möglichst flexibel zugreifen wollen, ist MagicMap [34], ein Positionierungsdienst, der mi�els Triangulation und Trilateration zu Sendern die Entfernung und den Winkel und somit die
Position zu ihnen berechnen kann [18]. MagicMap speichert diese Messwerte auf
einem Server. Ist dieser Server nicht erreichbar, so kann das gesamte System nicht
funktionieren.
Eine Abhilfe verspricht die Peer-to-Peer-Technik, die es Geräten erlaubt, ohne
Server Dienste zu nutzen und anzubieten. Gelingt es auf dieser Basis, ein verteiltes
Speichersystem zu etablieren, das den Gegebenheiten mobiler Geräte entspricht,
ermöglicht dies mobilen Nutzern eine Ad-hoc-Zusammenarbeit. So ist es denkbar,
dass Kalenderapplikationen ihre Daten in diesem Speichersystem ablegen und so
für andere Nutzer sichtbar machen. Darüber hinaus sind Wikis oder Foren denkbar, in denen die Beiträge verteilt gespeichert werden.
Verteilte Speichersysteme sind bereits seit etlichen Jahrzehnten Gegenstand
der Forschung. Bisher lag dabei jedoch das Augenmerk auf Klient-Server-Anwendungen, bei denen die Zahl der Server gering war, die Server zuverlässig und
nahezu immer erreichbar waren. Solche Gegebenheiten sind jedoch nicht immer
verfügbar, zum einen weil sie hohe Kosten verursachen und zum anderen einen
hohen Administrationsaufwand bedeuten. In den letzten zehn Jahren gewannen
Peer-to-Peer-Netze an Beliebtheit und gerieten zunehmend in den Fokus der Forschung. Peer-to-Peer-Netze unterscheiden sich von herkömmlichen Netzen, in
dem jeder Netzwerkknoten prinzipiell jede Rolle einnehmen kann. Dies hat zur
Folge, dass auch wenig zuverlässige Knoten als Server für andere Knoten agieren.
Diese geringe Zuverlässigkeit entsteht durch die kurzfristige Teilnahme am Netz,
schlechte Verbindungen innerhalb des Netzes und durch eine o�mals mangelhafte Administration der Knoten. Durch das hohe Maß an Redundanz, die durch eine
Vielzahl von Knoten möglich ist, kann ein Mangel an Zuverlässigkeit der Einzelkomponenten jedoch aufgehoben werden.
Peer-to-Peer-Netze bieten gegenüber klassischen Klient-Server-Netzen eine
1
Vielzahl von Vorteilen. Sie erlauben es, Ad-hoc-Netzwerke zu erzeugen, ohne dass
hohe Kosten für die Infrastruktur entstehen. Dadurch können sie auch in Szenarien
eingesetzt werden, in denen aus anderen Gründen keine Infrastruktur vorhanden
ist, etwa in Krisen- oder Katastrophengebieten. Dadurch, dass sie auch dann zuverlässig sein können, wenn die Knoten schlecht administriert werden, können diese
Netze auch von Menschen genutzt werden, die nicht über das nötige Know-How
verfügen. Zudem ermöglicht ein weitgehend wartungsfreies System den Au�au
von autonom agierenden Netzwerken, die ohne weiteren Einfluss von außen eine
bestimmte Aufgabe lösen.
Gegenwärtig werden Peer-to-Peer-Netze größtenteils zum Austausch von unveränderlichen Daten genutzt. Dabei wird eine Datei einmal veröffentlicht und vielfach gelesen. Derzeit existieren einige Systeme, die auch das Verändern von Daten
ermöglichen und somit ein viel größeres Maß an Anwendungen ermöglichen.
Jedoch hat keins der in Kapitel 2 vorgestellten Verfahren größere Resonanz außerhalb der Forschung gefunden. Dies liegt nicht zuletzt an den Einschränkungen,
die diese Systeme treffen müssen, um effizient arbeiten zu können. So sind diese
Systeme für Ubiquitous-Computing-Szenarien kaum geeignet, da sie von relativ
leistungsstarken Knoten und vergleichsweise langandauernden Verbindungen
ausgehen.
In Ubiquitous-Computing-Szenarien wie etwa NOMADS [36] stellen mobile und
eingebe�ete Systeme eine große Herausforderung dar. NOMADS stelt ein Netzwerk von mobilen Knoten dar, die sich selbstständig an ihre Gegend anpassen.
Sie verfügen nur über wenige Ressourcen, wie Speicher, Rechenleistung, Netzanbindung und Akkuleistung, sodass viele aufwendige Verfahren nicht performant
angewendet werden können. Darüber hinaus sind diese Knoten nur für kurze Zeit
aktiv am Netz beteiligt, um ihre Lebensdauer zu erhöhen.
Ein Peer-to-Peer-Shared-Memory-System für Ubiquitous-Computing muss
daher ein Kompromiss sein. Anforderungen, wie Zuverlässigkeit, Ressourcen
sparen und Performanz schließen sich in weiten Teilen aus. Um ein hohes Maß
an Zuverlässigkeit zu erreichen, ist viel Redundanz nötig, was nur auf Kosten der
Ressourcen und der Performanz möglich ist. Dementsprechend bedeutet Ressourcen sparen ein Verzicht auf Redundanz und damit Zuverlässigkeit. Performanz
schließlich benötigt viele Ressourcen, wie CPU-Leistung oder Bandbreite, die in
mobilen Systemen nur begrenzt vorhanden ist.
In dieser Arbeit wird Daedalus vorgestellt, ein Peer-to-Peer-Shared-MemorySystem, welches speziell den Anforderungen des Ubiquitous-Computings Rechnung trägt. Der dazu notwendige Kompromiss besteht darin, dass Geräte mit vielen Ressourcen die Verwaltungsaufgaben übernehmen, während ressourcenarme
Geräte On-Demand agieren können. Während die Knoten entlastet werden, steigt
die Last des Netzwerks, jedoch ist dieses in den meisten Szenarien erheblich besser
ausgesta�et, da auf die bestehende stationäre Infrastruktur zurückgegriffen wer-
2
den kann. Tabelle 1.1 verdeutlicht die Unterschiede zu den bereits bestehenden
Peer-to-Peer-Shared-Memory-Systemen.
Freenet
Ivy
OceanStore
JuxMem
Daedalus
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Kein externes Wissen
nötig
Hohe Dynamik mobiler
Geräte
Übliche Peerto-Peer Netzgrößen
Leistungsklassen
Locking
Schreibzugriffe
In den folgenden beiden Kapitel wird zunächst einen Einblick in bereits bestehende Verfahren für Peer-to-Peer-Shared-Memory-Systeme und Peer-to-Peer-Frameworks gegeben. In den Kapiteln 4 und 5 wird die Funktionsweise von Daedalus
erläutert und bewertet. Anschließend wird im Kapitel 6 als Proof-of-Concept gezeigt, wie sich Daedalus in MagicMap integrieren kann.
x
x
x
Tabelle 1.1: Eigenscha�en der Peer-to-Peer-Shared-Memory-Systeme. Nur wenige Systeme bieten ein Locking zum Schutz vor Inkonsistenzen oder kommen
ohne globales Wissen aus. Für sehr dynamische Netze wurde keines der bisherigen Systeme konzeptioniert.
2 Distributed-Shared-Memory-Systeme
Während Distributed-Shared-Memory-Architekturen schon seit einigen Jahrzehnten Gegenstand der Forschung sind, sind Systeme, die auf Peer-to-Peer-Techniken
au�auen, erst in den letzten Jahren in den Fokus der Wissenscha� gerückt. Obwohl die grundlegenden Prinzipien von Peer-to-Peer bereits vor 20 Jahren in Systemen wie DNS oder UseNet zum Tragen kamen, wurden sie erst mit Napster [40]
Ende der 90er Jahre des letzen Jahrhunderts allgemein bekannt.
Peer-to-Peer-Systeme [37] zeichnen sich dadurch aus, dass jeder Teilnehmer in
einem solchen Netz gleichberechtigt ist. Jeder Knoten ist gleichzeitig sowohl Klient als auch Server. Dieser Umstand bringt eine Reihe von Vor- und Nachteilen mit
sich. Vorteile sind eine bessere Verteilung der Last, eine bessere Zuverlässigkeit
3
für das Gesamtsystem durch den Wegfall von Single-Point-of-Failures und möglicherweise eine Kostensenkung, da keine dezidierten Server mehr nötig sind und
somit auch Administrationsaufgaben entfallen. Jedoch sind die einzelnen Knoten
sehr unzuverlässig, sie können jederzeit das Netzwerk verlassen oder durch Fehler
Daten verändern. Die besonderen Eigenscha�en von Peer-to-Peer-Shared-Memory
sind also die große Zahl von Replikanten sowie die geringe Zuverlässigkeit und
hohe Dynamik der einzelnen Replikanten. Dies steht im Widerspruch zu den Annahmen, die konventionelle Distributed-Shared-Memory-Systeme über ihre Umgebung treffen. Deswegen ist es nötig, für Peer-to-Peer-Shared-Memory-Systeme
neue Verfahren zu entwickeln, die mit dieser Umgebung besser umgehen können.
Der Großteil der Peer-to-Peer-Systeme, die zum Austausch von Daten entwickelt wurden, geht dabei davon aus, dass ein Datenobjekt einmal geschrieben aber
vielfach gelesen wird. Es ist in diesen Systemen nicht vorgesehen, dass die Daten
verändert werden können. Eine Änderung würde ein neues Datenobjekt erzeugen,
das keinen Bezug zu der vorhergehenden Version hä�e. Dies erklärt sich anhand
des Szenarios, für das viele dieser Systeme geschaffen wurden: es besteht keine
Notwendigkeit für die Nutzer einer Peer-to-Peer-Tauschbörse wie Kazaa, die einmal vorhandenen Daten zu verändern, da diese weder die Musik noch die Filme
geschaffen haben.
Für die Systeme, die eine Veränderung der Daten zulassen, gibt es im Wesentlichen drei Ansätze. Bei Freenet [15] kann nur der ursprüngliche Autor einer
Ressource diese verändern. Dies wird durch die Verwendung von asynchroner
Verschlüsselung erreicht. Systeme wie OceanStore [41], Ivy [21] und P-Grid [42]
vertrauen darauf, dass nur eine verhältnismäßig geringe Zahl von Veränderungen
vorgenommen wird, so dass es nicht zu Konflikten kommt. Schließlich verwenden
einige Systeme wie JuxMem [23] Mutual-Exclusion-Verfahren, um diese Konflikte
zu vermeiden.
Die Mechanismen, die Schreibkonflikte verhindern sollen, stellen ein großes Problem für die Skalierbarkeit eines Algorithmus dar. Sollen Konflikte „byzantinisch"
gelöst werden, indem durch ein hohes Maß an Redundanz bis zu einem Dri�el
fehlerha�e Knoten toleriert werden können, so sind N2 Nachrichten nötig [10],
wobei N die Zahl der Knoten in dem Peer-to-Peer-Netz ist. Da in gegenwärtigen
Peer-to-Peer-Netzen Millionen Teilnehmer gleichzeitig agieren, ist ein quadratischer Ansatz hier nicht vertretbar. Aber auch Ansätze mit einem linearen Bedarf
an Nachrichten stoßen in der Praxis leicht an ihre Grenzen, da die Bandbreite in
üblichen Peer-to-Peer-Netzen beschränkt ist. Es haben sich zwei verschiedene
Ansätze etabliert, mit diesem Problem umzugehen. Die einfachste, zum Beispiel
von JuxMem verwendete, Lösung ist es, sich auf entsprechend kleine Peer-to-PeerNetze zu beschränken. Der andere Ansatz schränkt die Menge der Knoten ein, die
sich über die Verhinderung von Schreibkonflikten abstimmen. Letzteres wird beispielsweise bei OceanStore praktiziert, wo ein Inner-Ring, also eine kleine Gruppe
der Knoten, für die Annahme von neuen Versionen zuständig ist.
4
2.1 Freenet
Freenet [13][15] ist ein Peer-to-Peer-System, das von dem Iren Ian Clarke im Jahre
1999 entwickelt wurde. Ihm ging es dabei besonders um die Verhinderung von
Zensur und den Schutz der Anonymität der Nutzer. Um diese Ziele zu erreichen,
muss sichergestellt werden, dass Informationen so lange wie möglich im Netz bestehen bleiben, damit Minderheiten nicht benachteiligt werden. Weiterhin muss
es unmöglich sein, ein bestehendes Datenobjekt zu verändern, um Daten zu überschreiben, und es muss unmöglich sein, Informationen über die Teilnehmer im
Netz zu sammeln.
Um diese Ziele zu erreichen, wurde ein besonderer Suchalgorithmus entwickelt. Ein zentraler Server, der wie bei Napster sämtliche Dateien verwaltet, kam
wegen einer möglichen Anfälligkeit für Zensurmaßnahmen nicht in Frage. Die
Dateien werden in der Nähe von Anfragern gespeichert und von Knoten, die weit
von ihnen entfernt sind, gelöscht. Dadurch wird es unmöglich, die Herkun� einer
Datei festzustellen.
In Freenet werden Dateien anhand von Schlüsseln identifiziert, die durch HashFunktionen erstellt werden. So gibt es zum einen den Keyword-Signed-Key (KSK),
der von einem kurzen, die Datei beschreibenden Text abgeleitet wird. Wie bei allen anderen Schlüsseln auch, die von Freenet verwendet werden, handelt es sich
hierbei um einen asynchronen Schlüssel. Der öffentliche Schlüssel wird zur Identifizierung der Datei genutzt, indem er gehasht wird, der private Schlüssel wird zur
Signierung der Datei verwendet, sodass eine minimale Integritätsüberprüfung
sta�finden kann. Minimal, weil jeder Knoten, der den beschreibenden Text kennt,
auch den privaten Schlüssel rekonstruieren kann.
Da sich alle Dateien einen globalen Namensraum teilen müssen und es so unweigerlich zu Konflikten kommen kann, wenn zwei Dateien die gleiche Beschreibung verwenden, gibt es einen zusätzlichen Signed-Subspace-Key (SSK). Dieser ermöglicht private Namensräume für die Dateien jedes einzelnen Knotens und wird
zufällig generiert. Der öffentliche Schlüssel wird ebenso wie der KSK gehasht,
danach mit dem KSK verknüp� und schließlich noch ein weiters Mal gehasht. Der
private Schlüssel wird ebenso wie der des KSK dafür genutzt, um die Datei zu
signieren. Dadurch, dass dieser Schlüssel zufällig generiert wurde, ist ein deutlich
höheres Maß an Datensicherheit erreichbar.
Da für das Erzeugen von Dateien die privaten Schlüssel benötigt werden, ist
eine Veränderung nur durch den ursprünglichen Autor der Datei möglich, andere
Knoten können nur lesend auf diese Datei zugreifen. Daraus ergibt es sich, dass
sich das Problem der Konsistenz von Dateien in Freenet nicht stellt. Damit aber
verschiedene Versionen einer Datei existieren und voneinander unterschieden
werden können, existiert noch ein dri�er Schlüssel, der Content-Hash-Key (CHK).
Dieser wird durch das Hashen des Dateiinhaltes erzeugt, und gibt jeder Datei
5
einen pseudo-eindeutigen Schlüssel. Zudem werden die Dateien noch mit einem
zufällig generierten Schlüssel verschlüsselt.
Damit nun andere Knoten die Datei anfordern können, veröffentlicht der Knoten den beschreibenden Text zusammen mit dem öffentlichen SSK. Zusätzlich
wird noch der CHK und der Entschlüsselungsschlüssel veröffentlicht. Um eine
veränderbare Datei zu speichern, wird diese mit ihrem CHK gespeichert und
danach eine indirekte Datei, im Namensraum des Knotens, die nur den CHK der
ursprünglichen Datei enthält. Andere Knoten können nun auf die Datei in zwei
Schri�en zugreifen: zuerst werten sie die indirekte Datei aus, um an den CHK, der
eigentlichen Datei, zu kommen, mithilfe dessen sie dann die gewünschte Datei anfordern können. Um nun diese Datei zu verändern, wird die neue Version zunächst
unter ihrem CHK gespeichert. Danach wird eine neue indirekte Datei erstellt, die
auf die neue Version verweist. Erhält ein Knoten diese neue Datei, so kann er anhand der Signatur feststellen, dass die Datei valide und neuer ist, und kann so die
alte Version durch die neue ersetzen. Die Knoten, die den CHK der alten Version
kennen, können auf diese aber weiterhin zugreifen.
Wenn ein Benutzer eine Datei einsehen möchte, so stellt er eine Anfrage an seinen eigenen Knoten nach dem entsprechenden Schlüssel und einer Angabe zur
Suchtiefe. Erhält ein Knoten eine Anfrage, so überprü� er zunächst, ob er diese
Datei in seinem Speicher hat, und gibt diese, wenn das der Fall ist, zurück. Ist dies
nicht der Fall, so sucht der Knoten einen anderen Knoten aus seiner Routingtabelle heraus, der über einen Schlüssel verfügt, der dem angeforderten am nächsten
kommt. Wenn diese Anfrage irgendwann erfolgreich war, wird die entsprechende
Datei an den anfragenden Knoten zurückgegeben. Dieser Knoten speichert die Datei dann in seinem Cache und fügt den Eintrag für diesen Dateischlüssel in seine
Routingtabelle ein. Die Anzahl der Knoten, die eine Suchanfrage passieren muss,
wächst ungefähr logarithmisch mit der Anzahl der Knoten im Netz.
2.2 OceanStore
OceanStore [29][30][41] wurde an der Universität Berkeley als globaler Datenspeicher entwickelt, der mit Milliarden von Nutzern zurechtkommen soll. Dabei
wurde ein besonderes Augenmerk auf die langfristige Archivierung von Daten
gelegt. Bei den meisten anderen Systemen spielt dies nur eine untergeordnete
Rolle, da dieses Ziel nur schwer erreichbar ist. Besonderes die hohe Dynamik
von Peer-to-Peer-Netzen macht eine langfristige Speicherung von Daten schwer.
OceanStore verwendet ein byzantinisches Fehlertoleranzprotokoll, um für die
nötige Konsistenz zwischen den Replikanten von Daten zu sorgen. Allerdings
bietet OceanStore den Applikationen Möglichkeiten, die Konsistenzmechanismen
zugunsten der Performanz zu schwächen, wenn keine hohen Anforderungen an
die Konsistenz gestellt werden. OceanStore bietet ein versionsbasiertes Archiv an,
6
das laut Eigenaussage die Haltbarkeit von heutigen Archivsystemen um mehrere
Größenordnungen übertri�. Jedes Datenobjekt wird als Read-Only-Objekt mit
einem Erasure-Code gespeichert und über hunderte Knoten verteilt. Durch den
Erasure-Code ist schon ein Teil des eigentlichen Datenobjekts ausreichend, um
das gesamte wieder herzustellen. Zusätzlich wird durch diesen Erasure-Code der
nötige Speicherplatz, der für die Redundanz nötig ist, erheblich reduziert. Gegenwärtig existieren nur Teilsysteme, das Gesamtsystem befindet sich noch in der
Entwicklung. OceanStore basiert auf dem Peer-to-Peer-System Tapestry [49], da
dieses Netz beim Suchen und Speichern von Ressourcen topologische Strukturen
des Netzwerkes berücksichtigen kann. So werden primär die Server befragt, die
sich in der Nähe befinden, also beispielsweise im lokalen Netzwerk, was die Geschwindigkeit erheblich erhöhen kann.
Prinzipiell werden Daten in OceanStore dauerha� gespeichert; da auch die
älteren Versionen von Daten erhalten bleiben, ist es möglich, beliebig in der Zeit
zurück zugehen. Dies ermöglicht einer Applikation zum Beispiel explizit nach
der Version eines Datenobjektes fragen, die vier Stunden alt ist. Ein expliziter Lockingmechanismus, der ein Datenobjekt vor parallelen Schreibzugriffen schützen
würde, wurde nicht entwickelt, allerdings kann durch die Atomität eines Updates
ein solcher Mechanismus von der Applikation implementiert werden, indem ein
Datenobjekt mit der Nummer des Knotens, der die Ressource verändern kann,
erzeugt wird. Existiert kein solches Objekt, so erzeugt der Knoten eines, um die
Ressource verändern zu können; existiert das Objekt jedoch bereits, so wartet der
Knoten bis dieses gelöscht wird.
Die Architektur OceanStore besteht aus zwei Schichten. Die obere beinhaltet
leistungsfähige und gut angebundene Rechner, die Änderungen verbreiten und
die Daten archivieren. Die untere Schicht enthält im Gegensatz dazu weniger leistungsfähige Rechner, die im Wesentlichen nur ihren Speicherplatz beitragen. Der
Vorteil einer solchen Architektur besteht darin, dass auch von dem Speicher der
Systeme profitiert werden kann, die den Anforderungen, die durch die Verwaltung der Ressourcen entstehen, nicht gewachsen sind.
Jedes Datenobjekt ist einem primären Replika aus der oberen Schicht zugeordnet, der alle Veränderungen an dem Objekt vollzieht und entsprechende Identifikationsnummern für die Datei und die Version erzeugt. Diese primäre Replika
besteht aus einer kleinen Anzahl von Servern, die ein byzantinisches Fehlertolleranzprotokoll verwenden, um sich abzustimmen. Dadurch wird gewährleistet,
dass sich der primäre Replika als Ganzes auch dann korrekt verhält, wenn einige
der Server ausfallen. Knoten, die als primärer Replika in Frage kommen, werden in Listen aufgeführt, die jedoch außerhalb des Systems vorliegen müssen.
Dadurch, dass jedem Datenobjekt andere primäre Replikas zugeordnet werden
können, wird ein hohes Maß an Skalierbarkeit erreicht. Zugriffe auf verschiedene
Datenobjekte können so parallel ausgeführt werden und behindern sich nicht gegenseitig, wie es der Fall wäre, wenn ein Replika für alle Daten zuständig wäre.
7
Je größer das Netz folglich wird, desto mehr Datenobjekte können unabhängig
voneinander verwaltet werden.
Neben den primären Replikas existieren sekundäre Replikas und Archivierungsserver, die sowohl aus der oberen, als auch aus der unteren Schicht kommen
können. Die Archivierungsserver speichern Fragmente von Datenobjekten. Diese
Fragmente werden von den primären Replikas mi�els eines Erasure-Codes erzeugt
und an die OceanStore-Server verteilt. Da es aber relativ viel Zeit in Anspruch
nimmt, bis ein Knoten genügend Fragmente zusammen hat, um das Datenobjekt
zu rekonstruieren, speichern die sekundären Replikas die aktuelle Version. Alle
sekundären Replikas sind in einer Baumstruktur mit dem primären Replikas eines
Datenobjektes verbunden. Abbildung 2.1 zeigt, wie die neuen Versionen entlang
dieses Baumes, von den primären Replika aus, verteilt werden.
Soll ein Datenobjekt verändert werden, so teilt der Klient, der die Änderung
vornehmen möchte, dies der primären Replika mit. Die Server in dem primären
Replika entscheiden nun, ob diese Änderung umgesetzt wird. Dazu überprüfen
sie, ob der Klient über die nötigen Rechte verfügt und ob zuvor konkurrierende
Änderungen umgesetzt werden müssen. Um Fehler bei diesen Servern weitgehend
auszuschließen, stimmen sie sich über ein byzantinisches Protokoll ab. Zwar garantiert dieses Protokoll Sicherheit, wenn in einer Gruppe von Servern mit der Größe 3f+1 maximal f Server ausfallen oder fehlerha� arbeiten, jedoch ist dies nur mit
einer quadratischen, von der Zahl der Server abhängigen, Zahl von Nachrichten
möglich. Deswegen ist es nötig, die Zahl der Server in der primären Replika klein
zu halten. Hat sich der primäre Replika auf die Änderung verständigt, so wird
dieses an die sekundären Replikas und an die Archivierungsserver weitergeleitet.
Damit sichergestellt werden kann, dass diese neue Version tatsächlich von dem
primären Replika stammt, wird sie mit einer Signatur versehen. Darüber hinaus
erstellt der primäre Replika einen „Heartbeat", der die neue Version als die aktuelle
ausweist. Damit eine Applikation die neuste Version eines Datenobjektes auch anfordern kann, fordert sich diese von den primären Replikas ein Heartbeat-Objekt
an, das die Identifikation der neusten Version enthält, mit der das Datenobjekt von
den sekundären Replikas geladen werden kann. Anhand des öffentlichen Schlüssels, der primären Replika, kann die Applikation die Korrektheit des Datenobjektes
überprüfen.
Ein Prototyp von OceanStore mit dem Namen Pond [43], wurde im Jahr 2003 getestet und mit NFS verglichen. Dabei ergab sich, dass Pond in WANs etwa um den
Faktor 4,6 schneller beim Lesen und um den Faktor 7,3 langsamer beim Schreiben
war. Die Zeit zum Schreiben war jedoch nicht primär durch Netzwerkkommunikation beschränkt, sondern durch die Generierung von Erasure-Codes und die Signierung von Daten, die einen sehr großen Anteil an dieser Zeit ha�en. OceanStore
arbeitet folglich bei größeren Datenobjekten effizienter als bei kleineren.
8
HotOS
Attendee
Primary Replicas
Archival Servers
(for durability)
Other
Researchers
Secondary
Replicas
(soft state)
Abbildung 2.1 (aus [29]): Die Verteilung der Daten in OceanStore. Neue Daten
werden von „primären Replikas“ an sekundäre und Archivierungsserver verteilt,
von denen Klienten die Daten erlangen können.
2.3 Ivy
Das Ziel von Ivy [21][39] ist es, ein NFS-artiges Dateisystem auf Peer-to-Peer-Basis
bereit zu stellen. Das Peer-to-Peer-Netz ersetzt dabei den zentralen Dateiserver, in
dem sämtliche Daten und Metadaten in einem DHash-System gespeichert werden.
Da DHash die Daten verteilen und vervielfältigen kann, bietet dies Ivy die Möglichkeit, eine hohe Zuverlässigkeit zu erreichen. Die größten Herausforderungen
stellen dabei die unzuverlässigen Teilnehmer in einem Peer-to-Peer-Netz und der
Umgang mit parallelen Schreibzugriffen dar. Zudem ist es möglich, dass nicht
alle Teilnehmer allen andern vertrauen wollen oder können. Deswegen enthält
Ivy Mechanismen, die das Ignorieren von Dateioperationen einzelner Knoten
ermöglichen. Schließlich muss ein verteiltes Dateisystem auch im Falle von Netztrennungen arbeiten können, bei denen in getrennten Netzen die gleiche Datei
verändert wurde, und Mechanismen bieten, diese parallelen Veränderungen zu
erkennen, nachdem das Netz wieder zusammengefügt wurde. Eine Reparatur
dieser Zugriffe kann Ivy jedoch selbst nicht anbieten, sta�dessen stellt es Funktionen bereit, die der Applikation eine Korrektur ermöglichen soll.
Um diese Probleme zu lösen und den Anforderungen gerecht zu werden, verwendet Ivy Logdateien für jeden Knoten, der Schreibzugriff auf das Dateisystem
hat. In diesem Log speichert jeder Knoten nur die Änderungen, die er selber vorgenommen hat. Jeder Knoten kann die Logdateien der anderen lesen, da diese im
DHash-System gespeichert werden, und daraus eine Sicht auf das Dateisystem
konstruieren. Um den Kommunikationsaufwand zu reduzieren, speichert jeder
Knoten dieses Bild lokal und muss nur noch nach neueren Einträgen in den Logdateien suchen. Durch die Verwendung von Logdateien für jeden Knoten ist kein
Lockingmechanismus nötig, um Metadaten zu schützen. Dadurch, dass die Logdateien im DHash gespeichert wurden, sind sie auch dann verfügbar, wenn der
Knoten das Netz verlassen hat.
9
Um Angriffen von anderen Knoten vorzubeugen, signiert jeder Knoten seine
Logdatei, sodass ihre Authenzität von den anderen Knoten überprü� werden
kann. Knoten können ignoriert werden, wenn ihre Logdateien nicht oder nur bis zu
einem bestimmten Zeitpunkt ausgewertet werden, nach dem man davon ausgeht,
dass dieser Knoten kompromi�iert wurde. Wurde das Netzwerk geteilt, so kann
es durch die DHash-Replikation dazu kommen, dass in beiden Netzen von Knoten parallel geschrieben wird. Durch den Versionsvektor der Logdateien, können
solchen konfliktierenden Veränderungen erkannt werden, nachdem das Netzwerk
wieder vollständig verbunden wurde.
Ivy geht davon aus, dass DHash eine Schreib-Lese-Konsistenz bietet, also nach
dem Schreiben von einem bestimmten Wert zu einem Schlüssel, der gleiche Wert
auch gelesen werden kann. Dies entspricht nicht der aktuellen Implementation von
DHash, jedoch sind Verfahren entwickelt wurden, die dies in den meisten Fällen
garantieren können.
Eine Logdatei besteht aus einer verbundenen Liste von Logeinträgen. Jeder Logeintrag wird als ein Block im DHash gespeichert, zusammen mit dem Schlüssel
zum zeitlich vorhergehenden Logeintrag. Jeder Knoten verfügt über einen Block
mit einem festen Schlüssel, in dem er den Schlüssel des neuesten Logeintrages
speichert, den Logkopf. Eine solche Logdatei ist also von anderen Knoten von neuesten zum ältesten Eintrag zu lesen. Das hat in den meisten Fällen den Vorteil, dass
die älteren Einträge bereits gecacht sind, und nicht wieder aus dem Netz gelesen
werden müssen. Jeder dieser Logeinträge enthält Informationen über eine einzelne
Dateimodifikation. Die möglichen Operationen entsprechen im Wesentlichen denen von NFS und können der Tabelle 2.1 entnommen werden. Zudem enthalten sie
nur die Informationen, die unbedingt nötig sind und nicht auf anderem Wege rekonstruiert werden können. So wird zum Beispiel nach einem Schreibzugriff nicht
die neue Dateigröße oder der Zeitstempel gespeichert, da der Zustand der Datei
erst nach der Veränderung sicher feststehen kann. Zudem werden Logeinträge nie
verworfen. Selbst nachdem eine Datei gelöscht wurde bleiben alle Einträge erhalten, um später, wenn festgestellt wurde, dass der Löscheintrag von einem fehlerha�en Knoten kam, einen korrekten Zustand wiederherzustellen. Darüber hinaus
ermöglicht dieses Verfahren auch, einen beliebigen Zustand des Dateisystems aus
der Vergangenheit zu verwenden.
Damit Logdateien von verschiedenen Knoten miteinander verbunden werden
können, ist es nötig, Einträge von mehreren Logdateien, zu ordnen. Dazu speichert
jeder Knoten zu jedem seiner Logeinträge den aktuellen Versionsvektor, auf den
sich diese Veränderung bezieht. Ein Versionsvektor besteht aus zwei Elementen,
zum einen den Schlüssel des Logkopfes und zum anderen den Schlüssel des neuesten Logeintrages. Damit ist es möglich zwei Logeinträge aus unterschiedlichen
Logdateien zeitlich zu ordnen oder aber ihre Gleichzeitigkeit festzustellen. Sind
zwei Einträge gleichzeitig, gilt es noch zwischen konkurrierenden und unabhängigen Einträgen zu unterscheiden. Unabhängige Einträge können zum Beispiel da-
10
durch entstehen, dass zwei Knoten gleichzeitig jeweils eine andere Datei, im gleichen Verzeichnis, anlegen. Dabei kann es nicht zu Inkonsistenzen kommen, da die
Aktionen keinen Einfluss auf die jeweils andere haben. Konkurrierende Einträge
können entstehen, wenn zwei Knoten in einer Datei die gleiche Stelle verändern
wollen. In diesem Fall kann nur eine dieser Aktionen von den anderen Knoten als
gültig erachtet werden, und sie ignorieren die andere.
Ivy bietet zusätzlich eine Möglichkeit, Verzeichniseinträge exklusiv zu verändern, also zu verhindern, dass zwei Knoten die gleiche Datei anlegen. Dies ist
nötig, damit Applikationen, die mi�els des Dateisystems einen Lock-Mechanismus implementieren, wie gewohnt funktionieren können. Bei diesem Lockingmechanismus wird eine Datei erstellt. Gelingt dies, so kann die Applikation den
geschützten Bereich betreten, gelingt dies nicht, weil die Datei bereits existiert, so
muss sie warten, bis die Applikation, die die Datei angelegt hat, sie löscht. Dazu
wird vor dem Erzeugen des Verzeichniseintrages eine „Prepare" in das Log angehängt. Wenn kein anderer Knoten einen „Prepare"-Eintrag für das gleiche Verzeichnis enthält, so kann der Knoten nun die Datei anlegen. Findet der Knoten jedoch einen anderen „Prepare"-Eintrag, so fügt der Knoten einen „Cancel"-Eintrag
in das Log ein und wartet eine gewisse Zeit, ehe er erneut ein „Prepare"-Eintrag
erzeugt.
Typ
Inode
Write
Link
Felder
Type (Datei, Verzeichnis, Link), i-Nummer, Modus, Besitzer
i-Nummer, Position, Daten
SetA�rs
i-Nummer, i-Nummer des Verzeichnisses, Name
i-Nummer des Verzeichnisses, Name
i-Nummer des Verzeichnisses, Name,
neuer Name, i-Nummer des neuen Verzeichnisses
i-Nummer des Verzeichnisses, Dateiname
i-Nummer des Verzeichnisses, Dateiname
i-Nummer, veränderte A�ribute
End
keine
Unlink
Rename
Prepare
Cancel
Bedeutung
Erzeugt eine neue Inode
Schreibt die Daten in
eine Datei
Erzeugt einen neuen
Verzeichniseintrag
Löscht eine Datei
Nennt eine Datei um
Für exklusive Operationen
Für exklusive Operationen
Ändert die Dateia�ribute
Letzter Eintrag im Log
Tabelle 2.1 (aus [39]): Mögliche Ivy Logeinträge
11
2.4 JuxMem
JuxMem [23][2][3] ist kein Shared-Memory-System für die Größenordnungen von
Peer-to-Peer-Netzen. Dieses Verfahren beschränkt sich auf eine deutlich kleinere
Zahl von teilnehmenden Knoten, in einem darüber hinaus relativ stabilen Netzwerk. Die Entwickler von JuxMem sehen es als eine Zwischenstufe zwischen klassischen Distributed-Shared-Memory-Systemen und Peer-to-Peer-Systemen und
entwickeln es als einen Grid-Service. Grid-Systeme unterscheiden sich von Peerto-Peer-Systemen nicht nur in ihrer Größe und Dynamik, Grid-Systeme verfügen
über eine hierarchische Topologie, während Peer-to-Peer-Netze meist eine flache
Topologie aufweisen. Auch sind Grid-Systeme einfacher zu kontrollieren, was das
Vertrauen in die einzelnen Knoten erhöht. Jedoch stellt JuxMem kein klassisches
Distributed-Shared-Memory-System dar, da es Peer-to-Peer-Techniken nutzt und
in deutlich größeren und deutlich dynamischeren Netzen arbeiten kann.
Diese Grundannahmen ermöglichen jedoch Konzepte, die so nicht in Peer-toPeer-Systemen ohne weiteres umsetzbar sind. So ist JuxMem das einzige bekannte
Verfahren, das einen Lockingmechanismus vorsieht. In Peer-to-Peer-Systemen mit
hunder�ausenden oder Millionen von Knoten ist ein solcher Lock-Mechanismus
problematisch, da der nötige Kommunikations-Overhead sehr schnell zu groß
werden kann.
Group "JuxMem"
Provider
Group "data"
Cluster Manager
Group Cluster B
Group Cluster A
Group Cluster C
Client
Overlay Netzwerk
Physikalisches Netzwerk
Cluster C
Cluster A
Cluster B
Abbildung 2.2 (aus [2]): Das JuxMem-Netzwerk. Gruppen werden anhand der
Clusterstruktur aufgebaut.
Das Netzwerk, wie in Abbildung 2.2 dargestellt, besteht aus verschiedenen
Peer-Groups, die jeweils einem Cluster entsprechen. Jede dieser Gruppen enthält
Knoten, die lokalen Speicher zur Verfügung stellen und als Provider bezeichnet
werden. In jeder dieser Gruppen ist ein Knoten für die Verwaltung der von den
Providern gestellten Speicher zuständig. Dieser Knoten wird als Clustermanager
bezeichnet. Schließlich gibt es noch Knoten, die als Klient bezeichnet werden und
den JuxMem-Dienst nutzen. Jedes Datenobjekt ist mit einer Peer-Group, einer Da-
12
tengruppe, verbunden, die aus allen Providern besteht, die jenes Objekt speichern.
Die Knoten einer Datengruppe sind jedoch nicht notwendigerweise von dem gleichen Cluster, sondern können Provider in verschiedenen Clustern sein.
Der Applikation werden sieben Funktionen für die Nutzung des Distributed-Shared-Memory-Systems zur Verfügung gestellt. Die Funktion alloc erzeugt
einen Speicherbereich mit einer bestimmten Größe und einem gewünschten Redundanzlevel. Die Funktion map liefert den Kommunikationskanal, der für die
Veränderung eines Speicherbereiches benutzt wird. Die Funktionen put und get
speichern und laden den Speicherbereich. Um einen Speicherbereich exklusiv
nutzen zu können, ru� die Applikation die Funktion lock auf, und anschließend
die Funktion unlock, die den Speicherbereich wieder frei gibt. Schließlich ist es
möglich, mit der Funktion reconfigure den Knoten zur Laufzeit eine andere Rolle
zuzuweisen und die an Speicher zu Verfügung gestellte Menge zu verändern.
Jeder Provider veröffentlicht die Menge an Speicher, die er anbietet durch eine
Nachricht an seine Clustergruppe. Die Aufgabe des Clustermanagers ist es nun,
diese Nachrichten von allen Providern seiner Gruppe zu sammeln sowie die
Gesamtmenge, die dieser Cluster anbietet, in der JuxMem-Gruppe, in der jeder
Knoten Mitglied ist, mitzuteilen. Mi�els eines Distributed-Hash-Tables wird jeder
Speichergröße ein Clustermanager zugeordnet, der alle Benachrichtigungen von
anderen Clustermanagern, die diese Größe anbieten, speichert. So muss ein Klient diese Mi�eilungen nicht empfangen und auswerten, sondern kann aufgrund
seiner benötigten Speichermenge einen Clustermanager ermi�eln, an den er seine
Anfrage stellt. Dieser Clustermanager wiederum sucht dann den richtigen Cluster
aus, und leitet die Anfrage weiter. Um nicht für jede mögliche Speichergröße einen
Clustermanager zuzuweisen, werden nur Speichergrößen von 2N Bytes verwendet.
Damit dieses System in dynamischen Netzen funktionieren kann, wird die Speichermenge immer wieder veröffentlicht, wenn sie sich ändert oder die Lebenszeit
der Veröffentlichung abgelaufen ist. Zudem existiert in jeder Datengruppe ein Datenmanager, der die anderen Provider in der Gruppe überwacht, und wenn ihre
Zahl unter einen Schwellenwert fällt, welchen der Klient spezifiziert hat, bi�et der
Datenmanager einen anderen Provider in diese Datengruppe. Fällt ein Clustermanager aus, so werden alle Ressourcen des Clusters unerreichbar, deswegen gibt es
einen zweiten Clustermanager, der in diesen Fall die Aufgaben des Clustermanagers übernimmt. Der erste und der zweite Clustermanager synchronisieren sich
periodisch durch den Austausch von Nachrichten. Ein ähnliches Verfahren wird
bei Datenmanagern eingesetzt.
13
2.5 Zusammenfassung
Alle hier vorgestellten Systeme verfügen über einen Mechanismus, Daten zu verändern, die in einem Peer-to-Peer-Netz gespeichert wurden. Sie unterscheiden sich
dabei von einfachen Systemen, die keine nachträglichen Veränderungen von Daten
erlauben, zum Teil erheblich. Jedoch treffen alle vier Verfahren Annahmen über
das Netzwerk oder schränken die Möglichkeiten des Veränderns ein. Keines dieser
Systeme ist in der Lage, mit parallelen Schreibzugriffen in einer Größenordnung,
wie es bei Peer-to-Peer-Systemen zu erwarten wäre, umzugehen. Als größtes Hindernis erweist sich dabei der hohe Overhead, der für einen Locking-Mechanismus
nötig ist, ohne den aber keine Inkonsistenzen durch parallele Schreibvorgänge
verhindert werden können. JuxMem stellt einen Kompromiss dar, der jedoch nicht
in jeden Fall Verwendung finden kann. Abbildung 2.3 zeigt diese Einordnung schematisch.
Für die besonderen Anforderungen von Ubiquitous-Computing [6] wurde keines der Verfahren explizit konstruiert. Einzig JuxMem bietet Möglichkeiten, den
Grad der aktiven Partizipation zu steuern, indem sich ein Knoten auf die Rolle
eines Providers oder Klienten beschränkt. Jedoch geht JuxMem von einem relativ
stabilen Netzwerk aus, was bei mobilen und drahtlosen Teilnehmern nicht erfüllbar ist. Durch aufwendige Signaturberechnungen eignen sich Freenet, OceanStore
und Ivy kaum für leistungsschwache Geräte, da sich diese Berechnungen, zumindest bei OceanStore bereits bei Desktop-Computern als problematisch erweisen. Es
zeigt sich auch, dass die Kommunikation zwar gut skaliert, dies jedoch auf verhältnismäßig hohem Niveau geschieht, so wurden alle Messungen mit breitbandigen
Desktopcomputern vorgenommen. Dies ist jedoch zum Teil den NFS-Benchmarks
zuzuschreiben, die den Overhead des Dateisystemmanagements mit sich bringen.
��
��
��
��
��
��
��
��
��
��
Abbildung 2.3: Einordnung von Peer-to-Peer-Shared-Memory-Systemen. Ivy,
OceanStore und Freenet verwenden ein optimistisches Konsistenzsicherungsverfahren.
14
3 Peer-to-Peer-Frameworks
Anders als bei konventionellen Klient-Server-Architekturen, bei denen ein Rechner die Serverrolle und andere die Klientrolle übernehmen, gibt es in Peer-to-PeerSystemen keine festen Rollenzuteilungen. Ein Knoten in einem Peer-to-Peer-Netz
übernimmt beide Rollen und stellt sowohl eigene Anfragen und beantwortet fremde Anfragen. Der Begriff Peer beziehungsweise Peer-Group stammt aus der Soziologie und beschreibt eine Gruppe von Gleichgestellten, meist auch eine Gruppe,
deren Mitglieder viele wichtige Eigenscha�en teilen. So stellen beispielsweise die
Studenten der Informatik eine eigene Peer-Group dar. Der Begriff Peer ist also
insoweit passend, als dass alle Peers in einem solchen Netzwerk die gleichen Aufgaben übernehmen können. Allerdings sind diese Peer-Groups in der Praxis nicht
homogen sondern stark heterogen.
Diese Heterogenität stellt aber nicht die einzige Herausforderung für Peer-toPeer-Netze dar. Eine Studie [44] ermi�elte, dass die Verweildauer von Knoten
relativ kurz ist, so lag der Median der Sitzungsdauer bei 60 Minuten. Auch wenn
die Zeiten nicht bei allen Peer-to-Peer-Netzen gleich sind, so zeigen die Zahlen
doch, dass diese Netze sich sehr stark verändern. Während klassische Server fast
immer erreichbar sind, sind dies Knoten in Peer-to-Peer-Netzen nur selten. Nur
durch die hohe Redundanz, die in Peer-to-Peer-Netzen möglich ist, kann das Netz
als Ganzes überhaupt zuverlässig funktionieren.
Bekannt wurden Peer-to-Peer-Systeme, auch für die breite Öffentlichkeit, durch
Napster. Obwohl es kein reines Peer-to-Peer-System darstellte, weil es von zentralen Servern abhängig war, und auch nicht das erste Peer-to-Peer-System war, erreichte es diese Bekanntheit, weil es ausschließlich dem Tausch von MP3-Dateien
diente, und somit viele juristische Probleme verursachte. Diese juristischen Probleme, nicht technische, führten zu einer Reihe von neuen Peer-to-Peer-Systemen.
Eines dieser Systeme, Gnutella, das von den Napsternutzern nach der Stilllegung
von Napster benutzt wurde, war zwar ein reines Peer-to-Peer-System ohne zentrale Server, jedoch scheiterte es an dem einfachen Routingalgorithmus, der nicht
genügend skalieren konnte. Kazaa [27], ein anderes Filesharingprogramm auf
Peer-to-Peer-Basis, stellte als erstes die vollständige Gleichheit der Peers in Frage,
und ordnete einigen, besonders leistungsstarken Knoten andere, anspruchsvollere Rollen zu.
Neben diesen File-Sharing-Programmen gibt es noch andere Anwendungsfelder, die mit Peer-to-Peer-Techniken bedient werden. Am ältesten ist wohl das
UseNet, in dem alle News-Server ein gemeinsames Peer-to-Peer-Netzwerk bilden,
um Nachrichten auszutauschen. Aber auch Chat-Systeme wie IRC oder ICQ [20]
basieren auf Peer-to-Peer-Techniken. Gelegentlich wird auch Seti@Home [45] als
ein Peer-to-Peer-System zur Teilung von Rechenleistung angesehen, da jedoch alle
Knoten nur mit einer zentralen Instanz agieren, scheint diese Einordnung nicht
15
gerechtfertigt.
Peer-to-Peer-Systeme müssen aber nicht nur auf den Austausch von Dateien und
das Kommunizieren beschränkt bleiben. Vielmehr bieten sie viele Möglichkeiten,
die Zusammenarbeit zu vereinfachen, da keine dezidierten Server mehr nötig sind.
So stehen beispielsweise viele OpenSource-Projekte vor dem Problem ihre Werke
so zu verteilen, dass keine Kosten entstehen, die nicht durch Einnahmen gedeckt
werden können. So ist das Wikipedia-Projekt [51] auf Spenden angewiesen, um
die Webserver zu betreuen. Könnten die Server durch ein Peer-to-Peer-Netzwerk
ersetzt werden, so wären ähnliche Projekte viel einfacher umsetzbar. In diese Richtung geht Freenet. Freenet stellt sich für den Nutzer als World-Wide-Web ohne
Server dar. Jedoch sind die Ansprüche des Freenet-Projektes andere, nämlich die
Verhinderung von Kontrolle und Zensur, sodass eine effiziente Umsetzung eines
Wikis auf Freenet au�auend unrealistisch erscheint. Im Folgenden werden einige
Peer-to-Peer-Frameworks vorgestellt und auf die Tauglichkeit für ein Peer-to-PeerShared-Memory-System untersucht.
3.1 Chord
Das Besondere an Chord [12][48] gegenüber anderen Peer-to-Peer-Verfahren ist,
dass sowohl die Korrektheit als auch die Performanz bewiesen wurde. Zudem ist
es sehr einfach aufgebaut und kann flexibel verschiedenen Anwendungsgebieten
angepasst werden. Chord weist anders, als einige populäre Verfahren wie Freenet,
eine Ressource explizit Servern zu, die diese vorhalten sollen.
Das Chord-Protokoll unterstützt nur eine Funktion: es bildet einen Schlüssel auf
einen Netzwerkknoten ab. Damit kann zum Beispiel der Knoten ermi�elt werden,
der die Daten zu einem Schlüssel speichert. Chord verwendet „Consistent hashing",
um Schlüssel den Knoten zuzuordnen. Consistent hashing hat den Vorteil, dass
es die Last zwischen verschiedenen Knoten recht gut verteilt, da jeder Knoten für
etwa die gleiche Zahl an Schlüsseln zuständig ist. Zudem benötigt dieses Verfahren relativ wenige Veränderungen bei der Zuordnung der Schlüssel, wenn neue
Knoten hinzukommen oder das System verlassen. Anders als bei anderen Consistent-hashing-Verfahren, bei denen jeder Knoten die meisten anderen kennen muss,
reicht es, wenn ein Knoten in Chord einige wenige andere kennt. Dadurch wird es
allerdings nötig, dass ein Knoten mit andern kommuniziert, um eine Suche nach einem bestimmten Knoten durchzuführen. In einem stabilen Netz mit n Teilnehmern
würde Chord für effizientes Routen O(log n) Knoten kennen müssen und könnte
mit O(log n) Nachrichten jeden anderen Knoten auffinden. Verlassen nun Knoten
das Netz oder kommen neue hinzu, nimmt die Performanz des Systems langsam
ab. Solange mindestens eine Routinginformation pro Knoten korrekt ist, kann
Chord korrektes Routen garantieren, auch wenn dies sehr viel Zeit in Anspruch
nehmen kann.
16
Applikationen, die auf Chord au�auen, bietet Chord Lastenverteilung, Dezentralisation, Skalierbarkeit, Verfügbarkeit und flexible Namensgebung. Da Chord
als Distributed-Hash-Funktion arbeitet, werden die Schlüssel gleichmäßig auf alle
Knoten verteilt, und somit auch die Last, die jeder Knoten in dem Netz erfährt. Die
dezentralisierte Struktur von Chord hat zur Folge, dass alle Knoten gleich sind,
kein Knoten ist wichtiger als ein anderer. Chord skaliert logarithmisch mit der Anzahl der Knoten in einem Netz, dadurch eignet sich das System auch sehr gut für
größere Netze. Chord passt die internen Routingtabellen permanent an, wenn sich
das Netzwerk verändert, so dass der Knoten, der für einen bestimmten Schlüssel
zuständig ist, immer gefunden werden kann, so es zu keinem großen Fehler in der
unterliegenden Netzwerkschicht kommt. Flexible Namensgebung bedeutet, dass
Chord selbest keine Restriktionen für den Au�au der Schlüssel definiert. In dem
flachen Namensraum kann jeder beliebige Schlüssel verwendet werden.
Chord interagiert mit der Applikation über zwei Wege. Zum einen ru� die Applikation die Funktion lookup(key) auf, zum anderen informiert Chord die Applikation, wenn sich die Schlüssel ändern, für die die Applikation zuständig ist. Die
Applikation, die Chord nutzt, ist dagegen für die Authentifizierung, das Cachen,
die Replikation und das Benennen von den Daten zuständig.
Jeder Knoten erhält eine Identifikationsnummer (ID), die aus seiner IP-Adresse
mi�els einem SHA-1 Hash-Verfahren gewonnen wird. Zudem wird eine Identifikationsnummer für jeden Schlüssel erstellt, indem der Hash-Algorithmus auf ihn
angewandt wird. Die Länge dieser Nummern ist 2m, wobei m so gewählt wird,
dass die Wahrscheinlichkeit, dass zwei Knoten oder Schlüssel die gleiche Nummer erhalten, vernachlässigbar ist. Die IDs werden in einem Kreis angeordnet,
das heißt jeder Knoten ist mit dem Knoten der nächst größeren ID und mit der
vorhergehenden ID verbunden. Der Knoten, der für einen Schlüssel mit der ID k
zuständig ist, wird ermi�elt indem der Knoten bestimmt wird, der die gleiche ID
hat oder ihr als nächster folgt. Dieser Knoten wird als Nachfolger von k bezeichnet. Die Abbildung 3.1 zeigt einen Chord-Ring mit m = 6. Es sind zehn Knoten
vorhanden, die fünf Schlüssel speichern sollen. Der Nachfolger der ID 10 ist also
der Knoten mit der Nummer 14. 24 und 30 würden im Knoten mit der ID 32 gespeichert werden, 38 auf der 38 und 54 auf 56.
Verlässt nun ein Knoten das Netz, so übernimmt sein Nachfolger seine Schlüssel. In dem Beispiel übernimmt also der Knoten 21 den Schlüssel 10, wenn der
Knoten 14 ausscheidet. Würde ein neuer Knoten hinzukommen, so würde er einige Schlüssel übernehmen, die zuvor sein Nachfolger inneha�e. Wenn also ein
Knoten 28 hinzukommen würde, so würde dieser den Schlüssel 24 vom Knoten
32 übernehmen.
17
N1
N56
N8
K54
N51
K10
N14
N48
N21
N42
N38
K38
K24
N32
K30
Abbildung 3.1 (aus [48]): Chord-Netzwerk. Chord verbindet alle Knoten mit
einer Ringstruktur. Daten werden von dem Knoten gespeichert, dessen ID größer
oder gleich der ID des Datenpakets ist.
Um einen Schlüssel nachzuschlagen, reicht es nun, wenn jeder Knoten seinen
Nachfolger kennt. An diesen kann er seine Anfrage stellen, der wiederum seinen
Nachfolger fragen kann, wenn er für diesen Schlüssel nicht zuständig ist. Da dieses
Verfahren aber nur linear skalieren würde, speichert jeder Knoten noch zusätzliche
Routinginformationen. Jede dieser Routingtabellen enthält bis zu m Einträge, wobei der i. Eintag in der Tabelle einen Nachfolger bezeichnet, der mindestens um 2i-1
größer sein muss. Anhand dieser Tabelle kann nun ein Knoten die in Frage kommenden Knoten eingrenzen.
Periodisch wird das Netz stabilisiert, das heißt, jeder Knoten überprü�, ob seine Nachfolger noch dieselben sind, oder ob neue Knoten dazwischen gekommen
sind, bzw. seine Nachfolger das Netz verlassen haben. Dazu fragt jeder Knoten
seinen Nachfolger nach dessen Vorgänger, und überprü�, ob dieser nicht sein
neuer Nachfolger sein muss, was der Fall ist, wenn ein neuer Knoten eingetreten
ist. Gleichzeitig wird so der Nachfolger über seinen Vorgänger informiert. Darüber
hinaus überprü� er noch, ob die Einträge aus seiner Routingtabelle korrekt sind
und ob sein Vorgänger noch erreichbar ist.
3.2 JXTA
JXTA [8][24][26] wurde von der Firma Sun Microsystems entwickelt und als Open
Source veröffentlicht. Der Name JXTA wurde aus dem englischen Wort „juxtapose"
abgeleitet, was soviel wie „nebeneinander stellen" bedeutet. JXTA ist ein Peerto-Peer-Protokoll, das heißt, dass es anders als Peer-to-Peer-Applikationen wie
Freenet oder Gnutella kein eigenständiges Programm darstellt, vielmehr soll es
Entwicklern erleichtern ihre eigenen Programme auf Peer-to-Peer-Basis einfacher
zu entwickeln. Für JXTA existiert eine Java-Referenzimplementation sowie Implementationen in C und Perl.
18
Eine Vielzahl von Programmen wurde bereits auf der Basis von JXTA entwickelt. Das Spektrum reicht dabei von einfachen Chatapplikationen bis hin zu
komplexen Distributed-Shraed-Memory-Systemen für Grid-Computing. Dies ist
möglich, da anders als bei anderen Systemen, bei denen nur eine Ressource im
Netzwerk lokalisiert und gespeichert wird, JXTA über eine ganze Reihe von flexibel einsetzbaren Möglichkeiten verfügt. So können Knoten Gruppen bilden, die
gemeinsam einen Dienst anbieten, sie können aber auch mit einen oder mehreren
anderen Knoten Nachrichten austauschen.
Jeder Knoten eines JXTA-Netzwerkes, genannt Peer-Endpoint, ist durch eine
IP-Adresse zusammen mit einer Port-Nummer mit anderen Teilnehmern verbunden. Durch die Einbeziehung der Port-Nummern ist es somit möglich, anders
als bei Chord zum Beispiel, mehrere dieser Peer-Endpoints auf einem Gerät zu
betreiben. Dies ist neben Testzwecken auch für Multiuser-Systeme interessant, da
nur so mehrere Nutzer gleichzeitig von einem Rechner auf dieses Netzwerk zugreifen können. Diese Art der Adressierung legt aber auch den Grundstein für die
Network-Address-Translation-Verträglichkeit (NAT-Verträglichkeit) von JXTA.
Während viele Peer-to-Peer-Systeme davon ausgehen, dass eine IP genau einem
Teilnehmer zugeordnet ist, und somit Geräte, zwischen denen ein NAT-Router
steht, nicht miteinander kommunizieren können, ist dies bei JXTA möglich. Diese
Eigenscha� verdankt JXTA jedoch nicht nur der Port-Adressierung, sondern auch
der Tatsache, dass jeder Knoten mindestens eine permanente TCP-Verbindung
zu anderen Knoten hält. Wäre dies nicht der Fall, so könnten Knoten, die hinter
einem NAT-Router stehen, nicht von außen angesprochen werden, diese Knoten
können einzig selber Verbindungen in die Außenwelt au�auen.
Je nach Leistungsvermögen des Gerätes kann ein Knoten vier verschiedene
Rollen annehmen. Als „Minimal Peer" bietet er nur die grundlegenden Funktionen zum Senden und Empfangen von Nachrichten an. Diese Rolle bietet sich für
besonders ressourcenarme Geräte an, wie etwa PDAs. Der „Simple Peer" hingegen
speichert darüber hinaus noch Informationen über andere Peers, Gruppen und
Dienste ab, um Suchanfragen von anderen Knoten beantworten zu können. „Relay
Peers" speichern neben diesen Informationen auch Routinginformationen zu anderen Knoten und leiten Nachrichten entsprechend weiter. Insbesondere Knoten, die
mit einem NAT-Router an das Internet angebunden sind, also über keine eigene
öffentliche IP-Adresse verfügen, sind auf die Existenz solcher Knoten angewiesen,
um Nachrichten empfangen und senden zu können. Schließlich ist es die Aufgabe
von „Rendezvous Peers", Suchanfragen anderer Knoten an andere Peers weiterzuleiten. In der Regel versucht jeder Peer, der neu in das Netzwerk kommt, sich mit
einem Rendezvous-Peer zu verbinden, damit überhaupt erst Kontakt zu anderen
Peers aufgenommen werden kann.
Durch diese verschiedenen Rollen für Knoten erweist sich JXTA als besonders
geeignet für ein Peer-to-Peer-Netz für Ubiquitous-Computing. Je nach den verfügbaren Ressourcen eines Gerätes kann die Rolle frei gewählt werden. Einfache
19
Geräte, mit wenigen Ressourcen, werden so nur mit einem kleinen Kommunikations-Ovearhead konfrontiert.
Peers können sich selbst zu Gruppen zusammenschließen, den „PeerGroups".
Jeder Peer, der Teil des JXTA-Netzwerkes ist, ist automatisch Mitglied in der „Net
Peer Group". Jede andere Gruppe ist eine Untergruppe dieser Gruppe oder von einer anderen Untergruppe. Jeder Peer kann Mitglied von beliebig vielen Gruppen
sein. Diese Gruppen dienen zum einen der Zugriffsbeschränkung, so kann eine
Gruppe festlegen unter welchen Bedingungen ein Peer Mitglied werden kann, zum
anderen dienen sie der Gruppierung nach Interessen von Peers. Dadurch, dass alle
Peers in einer Gruppe eine bestimmte Eigenscha� teilen, können so Suchanfragen
auf eine bestimmte Menge von Peers beschränkt werden, nämliche auf all jene, die
in der Gruppe Mitglied sind, in der die Suchanfrage durchgeführt wird. Gruppen
bieten in der Regel Dienste an, die von den Gruppenmitgliedern genutzt werden
können. Einige dieser Dienste werden automatisch zur Verfügung gestellt, wie
etwa ein Suchdienst, andere können jedoch von den Knoten definiert werden.
Prinzipiell können auch einzelne Peers Dienste anbieten, jedoch sind diese Dienste
nur zu den Zeiten vorhanden, zu denen der Peer im JXTA-Netzwerk erreichbar ist.
In Peer-Groups sorgt JXTA hingegen dafür, dass der Dienst, solange die Gruppe
besteht, also mindestens ein Peer in ihr Mitglied ist, existiert und verfügbar ist, weil
der Dienst auf jedem Mitglied der Gruppe läu�.
Die Grundlage von JXTA stellen jedoch Nachrichten dar. Nachrichten können
entweder zwischen zwei Peers oder zwischen einem Peer und mehreren Peers
ausgetauscht werden. Jede Nachricht ist ein XML-Dokument, in dem die Daten
in Wertepaaren übermi�elt werden. Nachrichten werden zwischen so genannten
„Pipes" übertragen. Jeder Peer kann über Input- und Output-Pipes verfügen, siehe
Abbildung 3.2. Über das „Pipe Binding Protokoll" werden Input-Pipes mit Output-Pipes verbunden, sodass die Nachrichten, die ein Peer in seine Output-Pipe
schreibt, von den Knoten, deren Input-Pipe damit verbunden wurde, empfangen
werden können. Man unterscheidet dabei zwischen „Point-to-Point-Pipes" und
„Propagate-Pipes", je nachdem ob die Verbindung zwischen zwei oder mehreren
Knoten bestehen kann. Diese Verbindungen sind meist unsicher, das heißt, es wird
keine erfolgreiche Übertragung garantiert und es kann auch keine empfangene
Nachricht qui�iert werden. Jedoch gibt es eine Unterform der Point-to-Point-Pipe
die eine sichere Übertragung zwischen zwei Endpunkten garantiert, die „Secure
Point-to-Point-Pipe".
Jede der genanten Ressourcen, Peer, Peer-Group und Pipe, verfügt über eine
eindeutige Nummer, anhand deren sie identifiziert werden können. Damit diese
Nummern im System bekannt werden, so dass beispielsweise ein Peer weiß, wie
die Pipe-Nummern des Kommunikationspartners lautet, gibt es Advertisements.
Diese Advertisements sind Nachrichten, die eine Ressource beschreiben, zum Beispiel einer Peer ID einen Namen zuordnen.
20
JXTA definiert sechs Protokolle für die Interaktion der Peers. Sie wurden so
entworfen, dass ein möglichst geringer Overhead entsteht und nur wenige Annahmen über die Netzwerkstruktur getroffen werden mussten. Einzig die beiden
Protokolle „Endpoint-Routing-Protocol" und das „Peer-Resolver-Protocol" müssen
von jedem Peer implementiert werden, die anderen sind optional.
Unicast Pipe
Broadcast Pipe
Peer B
Peer A
Peer C
Peer B
Peer A
Peer C
Peer D
Output Pipe
Input Pipe
Abbildung 3.2: JXTA bietet Unicast- und Broadcast-Pipes zur Kommunikation
zwischen verschiedenen Knoten
Die Aufgabe des „Endpoint-Routing-Protocol“ ist es, einen Kommunikationsweg
zwischen zwei Peers zu finden, wenn eine direkte Kommunikation nicht möglich
ist. Das Routingprotokoll ist flexibel genug, um sich bei Netzwerktopologieänderungen schnell anzupassen. Jeder Relay-Peer verfügt über eine Routingtabelle zu
allen ihm bekannten Zielen. Kennt ein Knoten keinen Weg zu dem Ziel, so fragt er
alle ihm bekannten Relay-Router nach dem passenden Pfad.
Das „Peer-Resolver-Protocol" ermöglicht es einem Peer festzustellen, ob eine
Nachricht für ihn bestimmt war. Da es möglich ist, dass eine Nachricht, die an einen einzelnen Peer adressiert wurde, trotzdem an alle Peers eine Gruppe geroutet
wird, muss jeder Peer selber bestimmen können, welche Nachrichten für ihn interessant sind. So wird in der J2SE-Implementation von JXTA eine Nachricht an alle
lokalen Peers und an alle bekannten Rendezvous-Peers gesendet, die lokalen Peers
müssen bestimmen können, ob die Nachricht an sie gerichtet ist, die RendezvousPeers müssen darüber hinaus noch ermi�eln, ob und an welche Knoten sie diese
Nachricht weiterleiten sollen.
Um Ressourcen zu finden oder zu veröffentlichen, wird das „Peer-Discovery-Protocol" verwendet. Dazu baut es auf dem „Peer-Resolver-Protocol" auf, um Suchanfragen an andere Peers zu senden. Die Antworten, in Form eines Advertisements, die
ein Peer auf eine solche Anfrage hin erhält, können redundant sein oder auch ganz
ausbleiben. Auch kann es vorkommen, dass ein Knoten Antworten auf Anfragen
erhält, die er nie gestellt hat, weil ein Peer eine Ressource durch ein Advertisement
veröffentlicht, ohne dass vorher ein Knoten explizit nach ihr gesucht hat.
Das „Pipe-Binding-Protocol" stellt eine virtuelle Verbindung zwischen zwei oder
mehreren Kommunikationsendpunkten her. Dies geschieht indem einer Input-Pipe
eine oder mehrere Output-Pipes zugeordnet werden. Das „Rendezvous-Protocol"
dient der Verteilung von Nachrichten in dem JXTA-Netz. Jeder Rendezvous-Peer
implementiert dieses Protokoll und versendet alle Nachrichten, die er empfängt
21
an alle ihm bekannten Peers weiter. Schließlich dient das „Peer-Information-Protocol"
der Statusabfrage eines Peers. Es steht den Peers jedoch frei, ob sie solche Anfragen
beantworten wollen oder nicht. Zu den Statusinformationen gehören die Menge an
gesendeten und empfangenen Bytes und seit wann der Peer aktiv ist.
3.3 Tapestry
Tapestry [49][53] ist ähnlich wie Chord eine Peer-to-Peer-Routing-Infrastruktur, die
sich eines virtuellen Overlay-Netzes bedient, jedoch berücksichtigt Tapestry zusätzlich noch die Netzwerktopologie, um eine nahe liegende Kopie der Ressource
zu erlangen. Aufgrund dieser Eigenscha� wurde Tapestry als Grundlage für das
OceanStore-System gewählt, da so unnötiger Verkehr vermieden werden kann. So
ist es in anderen Peer-to-Peer-Netzen möglich, dass Knoten, die im Peer-to-PeerNetz nur wenige Hops auseinander liegen, physikalisch über sehr viele Hops
miteinander kommunizieren müssen, und andererseits Knoten, die physikalisch
direkt kommunizieren könnten, könnten im Peer-to-Peer-Netz nur über viele Zwischenschri�e erreicht werden.
Jeder Knoten in einem Tapestry-Netz erhält eine ID, die zufällig aus einem großen Raum gewählt wird. Jeder physikalische Host kann mehrere Tapestry-Knoten
anbieten. Jeder applikationsspezifische Endpunkt erhält ebenfalls eine ID. Da die
Effizienz mit der Größe des Tapestry-Netzes zunimmt, sollten mehrere Applikationen das Netz gemeinsam nutzen. Um diese Koexistenz zu ermöglichen, erhält jede
Applikation eine ID, anhand derer eine Nachricht zu einer Applikation zugeordnet
werden kann, ähnlich den Ports in TCP/IP-Netzen.
Die API von Tapestry bietet vier Funktionen, zum Routen und Veröffentlichen
von Objekten, an. Die Funktionen PublishObject und UnpublishObject bieten nur einen best-effort an, und können der Applikation nicht mi�eilen, ob die eigentliche
Aktion erfolgreich war. Zudem betreffen sie nur die lokalen Objekte, Objekte auf
anderen Knoten können mit diesen Funktionen nicht beeinflusst werden. RouteToObject und RouteToNode versenden Nachrichten an ein Objekt oder an einen Knoten. Um eine Nachricht an einen anderen Knoten routen zu können, speichert jeder
Knoten die IP-Adresse und die Knoten-ID von seinen Nachbarknoten, also den
Knoten mit denen eine direkte Kommunikation möglich ist. Die Nachricht wird
dann an den Knoten übergeben, dessen ID am längsten mit der ID des Zielknotens
übereinstimmt. Wenn eine Nachricht an den Knoten mit der Nummer A2AD zu
routen ist, der lokale Knoten aber nur die Nachbarknoten A0AD und A234 kennt,
so übergibt er die Nachricht an den Knoten A234, da hier die ersten beiden Stellen
mit dem Ziel übereinstimmen. Dieses System garantiert, dass eine Nachricht in
einem Netz mit N Knoten und IDs mit der Basis β höchstens logβN logische Schri�e
benötigt, so lange die Nachbarbeziehungen konsistent bleiben. Wird für eine ID
kein Nachbar gefunden, dessen ID teilweise übereinstimmt, so wählt Tapestry
22
einen Nachbarn mit einer nahen Stelle in der ID aus. Eine Nachricht an A2AD
würde also an den Knoten B123 weitergeleitet werden, wenn der einzige andere
Knoten die ID C123 hat, da B näher an A liegt als C.
Da in einem Peer-to-Peer-Netz häufig Verbindungen ausfallen, wird eine Nachricht nicht nur über einen Nachbarknoten geroutet, sondern redundant über Backupverbindungen. Die Zahl der Nachbarn, die ein Knoten kennen muss, beträgt
somit c⋅β⋅logβN, wobei c das Maß der Redundanz ist.
Ein Peer, der ein Objekt speichert, das nicht von ihm selbst stammt, teilt dies
periodisch dem Knoten mit, der dieses Objekt veröffentlicht hat. Jeder Knoten,
der diese Nachricht weiterleitet, speichert die Information, dass dieser Peer für
dieses Objekt zuständig ist. Ein Peer, der nun an diesem Objekt interessiert ist,
schickt eine Nachricht an den Peer, der es veröffentlicht hat. Die Knoten, die diese
Nachricht weiterleiten, überprüfen jedoch ob sie einen anderen Knoten kennen,
der dieses Objekt ebenfalls speichert. Existiert ein Eintrag, wird die Nachricht an
diesen Knoten weitergeleitet, nur wenn kein anderer Knoten bekannt ist, wird die
Nachricht an den ursprünglichen Knoten weitergeleitet. Das Routingsystem sorgt
dafür, dass Nachrichtenpfade von Knoten, die nah beieinander liegen, sich sehr
schnell schneiden, so dass ein über dieses Verfahren gefundener Replikationsknoten näher am anfragenden Knoten ist, als jeder andere Replikationsknoten mit
dem gleichen Objekt.
4377
437A
43FE
4361
4228
4664
4A6D
AA93
4A4F
Abbildung 3.3 (aus [53]): Anfragen werden in Tapestry an den nächstgelegenden Replika umgeleitet
Das Beispiel in Abbildung 3.3 verdeutlicht dies: der Knoten 4377 erzeugt eine
Ressource, die Knoten 4228 und AA93 speichern diese. Diese beiden Knoten senden periodisch eine Nachricht an den Knoten 4377, dieser Pfad ist durch die gestrichelte Linie gekennzeichnet, alle Knoten auf dem Weg speichern die Information. Fragt der Knoten 4B4F nach der Ressource, leitet der Knoten 4361 die Anfrage
über den Knoten 4A6D an den Knoten AA93 weiter, der die Ressource speichert.
Gleiches geschieht, wenn der Knoten 4664 die Ressource erfragt, der Knoten 43FE
leitet die Anfrage dann an den Knoten 4228 weiter. Die Suchanfrage wird in der
Abbildung mit der durchgezogenen Linie dargestellt.
23
3.4 Zusammenfassung
Zu diesem Zeitpunkt erfüllt einzig JXTA alle nötigen Voraussetzungen von Daedalus. Da sich mobile Geräte häufig hinter NAT-Routern befinden, wie sie etwa
WLAN-Accespoints häufig darstellen, die ihnen erst eine Verbindung zum Internet
gesta�en, ist es zwingend nötig, dass dieses System mit Geräten umgehen kann,
die keine eindeutige IP-Adresse haben und mit denen auch kein direkter Kontakt
aufgenommen werden kann. Des Weiteren sind Systeme, die speziell für den Austausch von Dateien entwickelt wurden, zu begrenzt, um die Daten effizient zu
verändern. Häufig liefe dies darauf hinaus, dass eine neue Version als vollkommen
neues Datenobjekt betrachtet wird, was das Erlangen der neuesten Version erheblich erschwert.
Chord betrachtet alle teilnehmenden Geräte als gleichwertig und eignet sich
deshalb nur bedingt für Ubiquitous-Computing, da nicht auszuschließen ist, dass
ressourcenarme Geräte Daten speichern obwohl noch genügend leistungsstarke
Geräte zur Verfügung stehen. Mit Tapestry kann dieses Szenario zwar verhindert
werden und die Lokalität würde die Netzwerklast reduzieren, Tapestry bietet jedoch keine Möglichkeit, effizient eine Veränderung zu kommunizieren. Folglich
fiel die Wahl auf JXTA als Basis für Daedalus.
4 Daedalus
4.1 Anforderungen
Die Gründe, die für ein System sprechen, welches das verteilte Speichern von
Daten ermöglicht, sind vielfältig. Ist eine Ressource an einen bestimmen Server gebunden, so stellt jeder Fehler, in diesem Server, eine Bedrohung für die Ressource
dar. Verliert der Server die Verbindung zum Klienten, so ist die Ressource zumindest temporär aus Sicht des Klienten nicht mehr vorhanden. Fällt der Server ganz
aus, so kann es sein, dass die Ressource dauerha� fehlt, oder sie, nachdem ein neuer Server installiert und mit einem Backup die Daten des alten Servers eingespielt
wurden, nur noch in einer veralteten Version vorliegt. Darüber hinaus steigt die
Last des Servers linear mir der Zahl der Klienten, die nach dieser Ressource fragen.
So müssen hohe Kosten in Kauf genommen werden, um das System so auszustatten, dass es die erwarteten Anfragen beantworten kann. Steigt nun aber die Zahl der
24
Anfragen über das erwartete Maß hinaus, so entstehen entweder weitere Kosten
oder das System wird durch die hohe Last unbenutzbar. Dies kann man beobachten, wenn stark frequentierte Online Magazine wie Slashdot [47] oder Heise Online
[17] über eine Webseite berichten. Nur kurze Zeit nach der Veröffentlichung eines
solchen Beitrages steigt die Last des Webservers gewaltig. Häufig führt das dazu,
dass dieses Webangebot nicht mehr genutzt werden kann. Für den Betreiber stellt
dies auch ein finanzielles Risiko dar, da sich die Kosten für das Webhosting auch
nach der übertragenden Datenmenge richten.
Dieses Szenario ist allerdings nicht mit jedem verteilten Speichersystem lösbar.
Wird diese Webseite mithilfe eines Loadbalancers auf mehrere Server verteilt,
kann zwar ein Ausfall unter Umständen verhindert werden, die Kosten für die
Datenübertragung bleiben jedoch davon unberührt. Hier könnte erst ein System
auf Peer-to-Peer-Basis Abhilfe versprechen. Da bei diesen Systemen jeder Klient
gleichzeitig auch Server für andere ist, steigt die Zahl der verfügbaren Server mit
der Zahl der Klienten. Aber nicht nur die Ressource wird dadurch verteilt, auch
die Datenmengen, die die Server bearbeiten müssen, skalieren besser. Ansta� das
viele Tausende ihre Anfragen an einen Knoten stellen und somit sehr hohe Verbindungskosten für diesen einen erzeugen, werden nun die Anfragen so verteilt,
dass jeder Server nur wenige Anfragen erhält und somit nur eine verhältnismäßig
kleine Datenmenge übertragen muss.
Neben diesen Vorteilen gibt es aber auch ernst zu nehmende Nachteile für verteilte Speichesysteme auf Peer-to-Peer-Basis. Da die Ressource auf viele Geräten
verteilt ist, ist eine Änderung nicht ohne weiteres möglich, sollen die Daten konsistent im Netz bleiben. Da diese Konsistenz nur mit einem zusätzlichen Overhead
gewährleistbar ist, schränkt dies das Maß der Skalierbarkeit ein. Das hat zur Folge,
dass die bisherigen Peer-to-Peer-Distributed-Shared-Memory-Systeme entweder
Annahmen treffen müssen, die die Zahl der Schreibzugriffe beschränken oder
aber die Skalierbarkeit einschränken. In dieser Arbeit soll noch ein weiterer Faktor
einfließen, der zu weiteren Kompromissen zwingt.
Anders als die Teilnehmer in gewöhnlichen Peer-to-Peer-Systemen, die breitbanding mit dem Internet verbunden sind, über genügend lokale Ressourcen
verfügen und relativ lange in Peer-to-Peer-Netzen agieren, handelt es sich bei den
Geräten aus dem Bereich des Ubiquitous-Computing um eingebe�ete oder mobile
Geräte, die über wenige eigene lokale Ressourcen verfügen können. Insbesondere ist ihre Leistungsfähigkeit durch die begrenzten Stromvorräte eingeschränkt.
Entscheidend aber ist, dass diese Geräte häufig nur für eine sehr kurze Zeit an
der Kommunikation teilnehmen können. So will ein Außendienstmitarbeiter
beispielsweise unterwegs einen neuen Termin in seinen öffentlichen Kalender
eintragen. Dazu schaltet er nur seinen PDA ein, startet den Kalender und macht
die nötigen Eintragungen, um den PDA danach gleich auszuschalten. Die Zeit,
die dieser PDA aktiv als Knoten in dem Peer-to-Peer-Netz teilnehmen konnte,
beläu� sich auf einige wenige Minuten. Da diese kurze Zeit zum großen Teil für
25
das Laden und Speichern der Ressource benötigt wird, bleibt kaum noch Zeit, etwaige Anfragen von anderen Knoten zu beantworten. Diese kurze Verweildauer ist
also dem eigentlichen Peer-to-Peer-Prinzip abträglich, da es sich dabei nicht mehr
um gleichgestellte Knoten handelt, sondern um solche, die länger teilnehmen und
über viele Ressourcen verfügen und solche, die nur kurz teilnehmen und wenige
Ressourcen zur Verfügung haben. Gibt es in einem Peer-to-Peer-System nur Knoten mit kurzer Verweildauer, ist ein Distributed-Shared-Memory-System zum
Scheitern verurteilt. Nimmt kein Knoten zu einem bestimmten Zeitpunkt an dem
System teil, so geht die Ressource verloren. Einzig wenn die Zahl der potentiellen
Teilnehmer sehr groß ist, kann eine dauerha�e Existenz einer Ressource gewährleistet werden. Allerdings ergeben sich aus der geringen Verweildauer bei einer
gleichzeitig hohen Zahl an Teilnehmern noch andere Probleme. Die Zahl derer, die
zu einem bestimmten Zeitpunkt nach einer Ressource fragen, wird sehr groß, was
aufgrund der geringen Leistungsfähigkeit sehr schnell zu einer Überforderung der
Knoten führen wird, da sie mit ständigen Anfragen konfrontiert werden.
Dieses Problem lässt sich anschaulich an einem Beispiel verdeutlichen. Ein System, bei dem ständig ungefähr zehntausend Knoten online sind und jeder Knoten
im Schni� für fünf Minuten erreichbar ist, bekommt pro Sekunde über 300 neue
Teilnehmer. Jeder Knoten wird also alle 30 Sekunden einmal die Ressource ausliefern müssen. Ist die Ressource nun über 35 kByte groß, so ist es selbst unter optimalen Bedingungen für ein, mi�els GSM angebundenes, mobiles Gerät nicht mehr
möglich, selbst zu kommunizieren. Es ist also offensichtlich, dass die Fähigkeiten
eines Knotens im Peer-to-Peer-Netz berücksichtig werden müssen, soll dieses auch
für mobile Geräte nutzbar sein.
Die Nachrichten, die ein leistungsschwacher Knoten erhält und versendet, müssen also minimiert sein, wünschenswert wäre eine On-Demand-Kommunikation.
Dies lässt sich jedoch nur auf Kosten der Konsistenz der Daten erreichen. Einen
Ausweg daraus bietet die Zuweisung verschiedener Aufgaben an die einzelnen
Knoten und zwar so, dass leistungsschwache Geräte, wenn genügend andere Geräte in dem Netz vorhanden sind, sich nur um ihre eigenen Kommunikationswünsche kümmern müssen. Dies hat jedoch zur Folge, dass einige Knoten veraltete
Versionen eine Ressource haben werden. Da diese Knoten jedoch ihrerseits diese
Ressource nicht an andere Knoten ausliefern werden, ist diese Einschränkung in
den meisten Fällen akzeptabel.
Es ist darüber hinaus damit zu rechnen, dass die Datenobjekte in UbiquitousComputing-Umgebungen im Vergleich zu anderen Netzen eher klein sind. Dies
kann sehr schnell zu einem hohen Maß an Overhead führen. Um diesem entgegenzuwirken, müssen die nötigen Verwaltungsinformationen begrenzt und einzelne
Daten sinnvoll miteinander verbunden werden. Dieses Dataclustering kann jedoch
nur auf der Applikationsebene erfolgen.
Zusammenfassend ergeben sich folgende spezifische Anforderungen an ein
26
Peer-to-Peer-Shared-Memory-System für Ubiquitous-Computing:
• hohe Dynamik der Netzstruktur, häufige Teilungen und temporäre Störungen
• hohe Heterogenität der Knoten
• Knoten verfügen zum Teil nur über wenige Ressourcen, wie Bandbreite,
Speicher oder Rechenleistung
• Datenobjekte sind klein
• aufgrund der geringen Kosten werden sehr viele Knoten teilnehmen
4.2 Konzeption von Daedalus
Jede Ressource, die in dem Shared-Memory-System gespeichert werden soll, erhält einen eindeutigen Namen. Anhand dieses Namens kann die Ressource später
gelesen und verändert werden. Alle Ressourcen teilen sich einen Namensraum,
so dass der Name einer Ressource so gewählt werden muss, dass dieser mit einer
hohen Wahrscheinlichkeit für keine andere Ressource verwendet werden wird.
Die Ressourcen können anhand eines Teils ihres Namens gesucht werden, sodass
eine Applikation eine pseudohierarchische Struktur anhand des Namens entwerfen kann.
Anhand dieses Namens wird eine Gruppennummer generiert, die für die
Gruppe steht, die diese Ressource speichern und verwalten wird. Jeder Peer,
der die Ressource lesen, verändern oder bereitstellen will, muss in diese Gruppe
eintreten. Diese Zuordnung von Ressourcen zu einer Gruppe ist insbesondere in
großen Netzen mit vielen Ressourcen sinnvoll. Die Zahl der Peers, die sich für
eine bestimmte Ressource interessieren, wird in vielen Fällen unabhängig von
der Netzgröße sein, sodass etwaige Skalierungsprobleme dadurch umgangen
werden können. Da die Verwaltungs- und Bereitstellungsaufgaben ein hohes Maß
an Kommunikation erfordern, wenn die Anzahl der Gruppenmitglieder groß ist,
sollte diese Aufgabe von Peers übernommen werden, die über genügend Leistung
verfügen. Da die Menge der Kommunikation nicht zuletzt von der Anzahl der
Peers abhängt, die die Verwaltungsaufgaben übernehmen, sollte deren Anzahl
möglichst klein sein, jedoch groß genug, damit viele Anfragen zur gleichen Zeit
nicht zu einer Überlastung dieser Peers führen. Es erscheint sinnvoll, einen bestimmten Prozentsatz der Gruppenmitglieder mit diesen Aufgaben zu betrauen.
Diese Gruppenmitglieder werden im folgenden Manager genannt.
Da nur die Manager entscheiden, welcher Peer die Ressource gegenwärtig verändern kann, und weil nur sie über die aktuellste Version verfügen, muss jedes
27
Gruppenmitglied, auch wenn es kein Manager ist, eine Reihe von diesen Managern
kennen. Darüber hinaus ist es wichtig für die Manager zu wissen, wenn ein neuer
Peer die Gruppe betri� oder ein alter die Gruppe verlässt, um überhaupt ermi�eln
zu können, wie viele Manager nötig sind. Deswegen sollte jedes neue Gruppenmitglied am Anfang Manager werden. Sind genügend andere Manager da, so kann
der neue nach einer gewissen Zeit den Managerstatus ablegen. Diese Wartezeit
soll ermöglichen, dass vorher noch Peers diesen Status verlassen, die über weniger
Leistung und Netzanbindung verfügen als das Neumitglied.
Größe
N
ΔT
ΔN
Beschreibung
Anzahl der Knoten in der Gruppe
Durchschni�liche Verweildauer eines Knotens
Durchschni�liche Paketgröße
Wertebereich
PM
Anteil der Manager
5% ... 20%
RL
Parallele Lesevorgänge
1 ... 5
F
PA
Fraktionsgröße
Mindestzahl, der positiven Antworten auf eine
Validierungsanfrage
Maximalzeit, die eine Ressource gelockt bleibt
3 ... 10
~ �F
Zeit, die auf eine Welcome-Nachricht gewartet
wird
Gruppengröße, bei der fremde Knoten in die
Gruppe gebeten werden
Gruppengröße, bei der passive Knoten aktiviert
werden
20s ... 60s
TM
TW
SB
SP
15s ... 30s
1 ... 3
3 ... 6
Tabelle 4.1: Parameter von Daedalus
Um die Zahl der nötigen Broadcasts zu verringern, antworten auf eine Anfrage,
die per Broadcast kam, nicht alle Empfänger, sondern nur eine konstante Zahl, die
unabhängig von der Gruppengröße sein muss. Eine lineare Abhängigkeit von der
Gruppengröße, wie sie etwa bei der Verwendung von probabilistischen Methoden
entsteht, ist aufgrund der möglicherweise großen Gruppengröße nicht möglich.
Wenn ein Manager aber in etwa die Anzahl der Manager kennt, kann er diese anhand ihrer Nummer in Fraktionen mit einer bestimmten Größe F unterteilen. Ist ein
Manager in der gleichen Fraktion wie der Peer, der die Anfrage stellt, so antwortet
er. Dadurch ist die Anzahl der Antworten konstant, die ein Peer auf einen Broadcast erhält, jedoch kann sie stark schwanken, wenn zum Zeitpunkt seiner Anfrage
Peers die Gruppe betreten oder verlassen, und sich so bei einigen Managern die
Zähler vor der Antwort, bei anderen die Zähler erst nach der Antwort verändern.
Um dieses Risiko zu verringern, wird bei der Berechnung der Fraktion eines Peers
nicht die aktuelle Anzahl der Manager verwendet, sondern von dieser werden ei-
28
nige der hinteren Stellen gestrichen. So führen einige neue Peers zu keiner Veränderung bei der Fraktionsberechnung, wenn sie nicht den Zähler soweit verändern,
dass das Abschneiden der Stellen nicht mehr hil�. Um dem entgegenzuwirken,
sollen nicht nur die Manager mit exakt der gleichen Fraktion antworten, sondern
auch diejenigen, die in einer um eins größeren oder kleineren Fraktion sind.
4.3 Gruppeneintri�
Am Anfang, wenn ein Peer eine Gruppe neu betri�, von der er keine Informationen hat, erhält er den Status eines Managers, das heißt, er ist für die Verwaltung
und Vorhaltung der Ressource zuständig. Damit ein Peer dieses kann, muss er
zunächst die Verwaltungsinformationen der Gruppe und an die eigentlich Ressource erlangen. Dazu sendet er eine Nachricht an alle anderen Manager. Diese
können aufgrund der Nachricht ihre Zähler und die Liste der bekannten Manager
aktualisieren. Ist dies geschehen, so antwortet eine bestimmte, feste Anzahl von
ihnen dem neuen Mitglied mit einer Nachricht, die die Verwaltungsinformationen
enthält. Wurde diese empfangen, verfügt der Peer über sämtliche notwendigen
Informationen zur Verwaltung der Gruppe, insbesondere kennt er die Größe der
Gruppe, einige andere Manager und weiß, welcher Peer gegenwärtig die Ressource gelockt hat. Es fehlt noch die Ressource selber. Dazu schickt der Peer eine
Nachricht an eine begrenzte Zahl RL von anderen Managern, und bi�et sie um
ihre Ressource. Die Anzahl der Manager, die befragt werden, kann je nach Netzwerkanbindung variieren, da die Kommunikation jedoch ungesichert erfolgt und
andere Manager jederzeit nicht mehr erreichbar sein können, ist eine Verteilung
der Anfrage auf mehrere Manager sinnvoll.
Nachdem der Peer die Ressource empfangen hat, ist er ein vollwertiger Manager. Da dieser Peer jedoch auch ein Gerät mit nur einer geringen Leistung sein
kann, überprü� er nun zunächst, ob genügend Manager für diese Gruppengröße
vorhanden sind. Ist dies der Fall, so kann er, nachdem er eine gewisse Zeit gewartet hat, den Managerstatus verlassen und zu einem gewöhnlichen Gruppenmitglied werden. Die Zeit, die gewartet werden muss, hängt in erster Linie von der
Geräteklasse des Peers ab. Je mehr Leistung und Netzanbindung er hat, desto länger muss gewartet werden. Darüber hinaus spielt die Anzahl der Gruppen, in der
dieses Gerät bereits Manager ist, eine Rolle und schließlich noch die Nummer des
Peers, um eine gleichmäßige Anpassung der Managerzahl zu erreichen, nachdem
die optimale Zahl der Manager erreicht wurde. Hat ein Peer jedoch, nachdem er
die Ressource erhalten hat, kein weiteres Interesse an ihr, so kann er auch gleich,
ohne zu warten, die Gruppe verlassen.
Erhält der Peer jedoch auf seine erste Nachricht hin keine Antwort, so ist davon
auszugehen, dass die Gruppe leer oder nur sehr klein ist und es zu einem Übertragungsfehler kam. Damit letzteres ausgeschlossen werden kann, sollte das Neumit-
29
glied diese Nachricht noch einige Male versenden, bevor diese Gruppe nach einiger
Zeit TW als leer, und damit die Ressource als nicht existent, betrachtet wird.
4.4 Lesen der Ressource
Hier gilt es, eine Unterscheidung zwischen Managern und regulären Knoten zu
machen. Ein Manager verfügt durch seine Aufgaben immer über die aktuelle
Version der Ressource, er kann sie also, wenn die Applikation um sie anfragt, ihr
sofort übermi�eln. Bei Peers, die keine Manager sind, kann nicht davon ausgegangen werden, dass die Ressource noch aktuell ist. Da diese Peers nur On-Demand
kommunizieren, also nur, wenn dieser Peer eine Anfrage versendet, verfügt er über
keine Möglichkeit mitzubekommen, ob sich die Ressource verändert hat. Der Peer
muss also einen oder mehrere Manager nach der aktuellen Version fragen. Dies
geschieht, indem er aus seiner Liste der bekannten Manager einige auswählt und
ihnen eine Nachricht schickt. Wenn er die Antworten erhalten hat, kann er diese
der Applikation übergeben.
Erhält der Peer aber keine Antwort auf seine Anfrage, so ist davon auszugehen,
dass die, von ihm befragten Knoten keine Manager mehr oder gar nicht mehr erreichbar sind. Kennt der Peer noch andere Manager, so kann er diese befragen.
Gleichzeitig kann er diese anderen Manager auch um eine neue Liste bi�en. Ist
jedoch keiner der ihm bekannten Manager mehr erreichbar, so muss dieser Peer
selber zum Manager werden, um wieder eine neue Managerliste und die Ressource
zu erhalten.
4.5 Stochastisches Locking
Wie bei allen Shared-Memory-Systemen muss verhindert werden, dass ein gleichzeitiger Schreibzugriff auf eine Ressource von mehreren Applikationen zu Inkonsistenzen führt. Prinzipiell sind zwei Arten dieses Problem zu lösen denkbar: zum
einen ein „optimistisches“ Verfahren und zum anderen ein „pessimistisches“ Verfahren. Das pessimistische entspricht einem Lockingverfahren, bei dem erst dann eine
Ressource gesperrt wird, wenn alle Knoten dem zugestimmt haben. Anschließend
kann die Ressource verändern kann. Dies ist jedoch in Peer-to-Peer-Umgebungen
nicht machbar, da Knoten jeder Zeit unerreichbar werden können. Ein optimistisches Verfahren verzichtet auf ein Sperren der Ressource und versucht parallele
Schreibzugriffe danach aufzulösen. Dieser Ansatz eignet sich nur für Szenarien, in
denen es nur selten zu Konflikten kommen kann. Deswegen kommt bei Daedalus
ein hybrides Lockingverfahren zum Einsatz, das ein Locking einsetzt, jedoch nicht
fordert, dass alle Knoten an der Entscheidung beteiligt sind. So gilt die Ressource
genau dann als gesperrt, wenn eine ausreichend große Mehrheit der Manager po-
30
sitiv antwortet. Das hier verwendete Verfahren basiert auf den Ideen des SigmaProtokolls [32], angepasst an dynamischere Netze. Dabei wurde die Zuverlässigkeit zugunsten einer besseren Skalierbarkeit reduziert, da nicht mehr alle Server
Lockinganfragen beantworten.
Die Ressource wird gelockt, indem der Peer eine Nachricht an alle Manager
verschickt, wie in Abbildung 4.1 verdeutlicht. Diese tragen den Wunsch in eine
Queue ein. Derjenige, der an erster Stelle in der Queue steht, kann die Ressource
locken. Da aber die Queue bei den Managern unterschiedlich aussehen kann, da
die Laufzeiten der Nachrichten unterschiedlich sind, muss nun erst ein Konsens
zwischen den Managern erzielt werden. Dazu verschickt eine bestimmte Fraktion der Manager eine Nachricht an alle Manager und den Peer, der die Ressource
locken möchte, die den ersten Eintrag der Queue enthält. Erhält der Peer eine
Mindestanzahl von Stimmen, so wird die Ressource für ihn gelockt. Erhält er die
notwendige Mehrheit nicht, so sollte er allen Managern mi�eilen, dass er darauf
verzichtet und kann nach einiger Zeit einen erneuten Versuch starten. Dadurch
wird verhindert, dass sich zwei oder mehrere Lockinganfragen gegenseitig blockieren. Nun muss der Peer warten, bis er in späteren Runden eine ausreichende
Mehrheit der Stimmen auf sich vereinigen kann.
Knoten B und C teilen
allen Managern und A mit,
welcher Knoten Gelockt hat
Knoten A sendet eine
Locking-Anfrage
F
E
G
H
I
D
K
O
B
N
P
O
Q
P
A
A
K
N
K
M
B
O
Q
H
C
J
M
G
I
D
K
K
B
H
C
K
F
E
J
M
G
I
D
C
J
F
E
Knoten A sendet die neue
Version des Datums
N
P
Q
A
O
Manager
Unicast
O
Knoten
Broadcast
Abbildung 4.1: Der Lockingmechanismus. Der Knoten A sendet eine Anfrage
an alle Manager, eine Fraktion der Manager beantwortet diese mit einer Nachricht an den Knoten A und alle andern Manager. Durch Auszählung der positiven und negativen Antworten fällt die Entscheidung ob ein Knoten das Datenobjekt gelockt hat.
Manager, die selber keine Stimme abgegeben haben, warten auf die Voten der
anderen Manager und entscheiden, ebenso wie der beantragende Peer wer die
Ressource gelockt hat. Versucht ein Peer die Ressource zu verändern, ohne sie
vorher erfolgreich gelockt zu haben, so wird dieser Versuch ignoriert.
31
Nachdem der Peer den Lockingschutz nicht mehr benötigt, gibt er ihn wieder
frei, indem er einen Broadcast mit dieser Information an alle Manager schickt. Um
aber zu verhindern, dass ein anderer Peer die Nachricht fälscht, um selber den
Lockingschutz zu erhalten, fragt eine Fraktion der Manager bei dem Peer nach,
ob diese Freigabe von ihm kommt. Ist eine Mindestzahl der Antworten des Peers
negativ, so wird davon ausgegangen, dass der Peer das Schreibrecht weiterhin
benötigt und die Freigabe eine Fälschung war. Um zu verhindern, dass ein Peer
vom Netz getrennt wird, bevor er den Lock freigeben oder die Anfragen bestätigen
kann, und somit die Ressource für immer blockieren würde, läu� das Locking nach
einer Zeit TM ab. Verfällt der Lockingschutz oder wurde er freigegeben, so wird
erneut bestimmt, wer nun die Ressource locken kann, wenn weitere Interessenten
in der Queue stehen.
4.6 Schreiben der Ressource
Nachdem ein Knoten die Ressource gelockt hat, so kann er sie uneingeschränkt
verändern. Um Datenverlust zu verhindern, sollte er zunächst, nachdem er das
Schreibrecht erlangt hat, die Ressource erneut laden, wenn er kein Manager ist.
Da jede Ressource eine Versionsnummer hat, werden nur neuere Versionen von
Managen akzeptiert. Das Verändern einer alten Version würde also zur Folge haben, dass all die Manager, die bereits eine neuere Version gespeichert haben, diese
Version als veraltet betrachten und verwerfen.
Wurde die Ressource von dem Peer verändert, schickt er diese per Broadcast an
alle Manager. Eine Fraktion der Manager fragt dann beim Peer nach, ob die Ressource von ihm stammt; wie bei der Freigabe des Lockingmechanismus, soll dies
Fälschungen von anderen Peers verhindern. Dazu wird dem Peer ein Hashwert der
Ressource übermi�elt, anhand dessen die Ressource mit seiner Version vergleichen
kann. Sind eine Mindestzahl der Antworten des Peers positiv, wird die Ressource
von allen Managern als die aktuelle Version gespeichert. Bevor die Bestätigungen
des Peers angekommen sind, wird bei jeder Leseanfrage die alte Version an einen
Peer übermi�elt.
32
4.7 Verlassen der Gruppe
Es kann vorkommen, dass ein Manager oder ein Peer, der gerade noch eine Anfrage verschickt hat, nicht mehr erreichbar ist. Stellt ein Peer fest, dass ein anderer
Peer nicht erreichbar ist, indem er zum Beispiel wiederholt auf Anfragen nicht reagiert, so teilt er dies allen Managern mit. Diese können dann ihre Zähler anpassen
und diesen Peer aus der Liste der ihnen bekannten Manager streichen. War dies
nur eine temporäre Störung, die inzwischen behoben wurde, und der vermeintlich unerreichbare Peer erhält diese Fehlernachricht, so verhält er sich so, als wäre
er neu in die Gruppe gekommen.
Das Verlassen einer Gruppe kann aber auch durch eine Nachricht an alle Manager angekündigt werden. Das verhindert, dass erst einige Nachrichten versendet
werden müssen, ehe der Fehler auffällt. Verlässt ein Manager diesen Status, so versendet er ebenfalls eine Nachricht, die diesen Umstand ankündigt. Nun kann das
Verlassen von mehreren Managern schnell dazu führen, dass die Gruppe Gefahr
läu�, die Ressource nicht mehr speichern zu können. Um dem vorzubeugen, müssen immer genügend Manager vorhanden sein. Dies kann auf zweierlei Wegen erreicht werden. Zum einen können gewöhnliche Gruppenmitglieder zu Managern
gemacht werden, wenn die Zahl der Manager unter SP fällt, zum anderen können
Peers, die nicht in dieser Gruppe sind, jedoch noch genügend Reserven haben, in
diese Gruppe gebeten und zu Managern gemacht werden, wenn die Managerzahl
unter SB fällt. Stellen Manager fest, dass nicht genügend Manager in der Gruppe
vorhanden sind, so schicken sie zunächst eine Aufforderung an Nichtmanager der
Gruppe, mit denen sie zuletzt Kontakt ha�en. Dazu speichert jeder Manager die
Adressen der Peers, die ihn zuletzt um die Ressource baten.
Können nicht genügend Gruppenmitglieder zu Managern gemacht werden,
zum Beispiel weil die Gruppengröße im einstelligen Bereich liegt, so veröffentlich ein Manager diesen Umstand in einer separaten Gruppe, in der all die Geräte
Mitglied sind, die leistungsfähig genug sind, um noch in weitern Gruppen als
Manager zu dienen. Die Peers in dieser Gruppe entscheiden zufällig, ob sie dieser
Bi�e nachkommen. Durch diese Vorgehensweise kann erreicht werden, dass auch,
wenn alle Interessenten an einer Ressource das Netz verlassen haben, die Ressource weiter existiert, solange noch Knoten mit freien Ressourcen erreichbar sind.
33
5 Evaluierung
5.1 Skalierbarkeit
Die Zahl der Nachrichten, die ein Knoten zu bearbeiten hat, hängt von der Rolle
ab, die dieser Knoten in einer Gruppe übernimmt. Hier muss also zwischen Managern und regulären Knoten unterschieden werden. Darüber hinaus richtet sich die
Anzahl der Nachrichten nach der Größe und der Aktivität der Gruppe. Die Größe
des Netzes und damit die Zahl aller Peers im Daedalus-Netz hat hingegen keinen
Einfluss auf die Nachrichtenmenge, da sämtliche Kommunikation in JXTA-Gruppen erfolgt.
Tabelle 5.1 zeigt die zu erwartende Nachrichtenzahl eines Managers in Abhängigkeit der Gruppengröße. Sie zeigt, dass Manager eine linear zur Gruppengröße
wachsende Zahl von Nachrichten empfangen, aber nur eine konstante Zahl von
Nachrichten senden. Der Grund hierfür ist, dass nur eine konstante Zahl von
Managern auf eine Anfrage antwortet. So sinkt die Wahrscheinlichkeit, dass ein
Knoten auf eine bestimmte Anfrage antwortet mit der Anzahl der Knoten in einer
Gruppe. Gleichzeitig nimmt die Zahl der Anfragen in einer Gruppe mit der Zahl
der Knoten zu, wenn man unterstellt, dass alle Knoten in etwa gleich aktiv sind.
Neue Knoten
Lesen
Schreiben
Locking
Last durch das Senden
O(1)
O(1)
O(1)
O(1)
Last durch das Empfangen
O(N)
O(1)
O(N)
O(N)
Tabelle 5.1: Lasten für Manager durch Nachrichten. Die Last durch eingehende
Nachrichten steigt linear mit zunehmender Gruppengröße. Die Zahl der zu sendenden Nachrichten bleibt konstant.
Die Zahl der Nachrichten, die ein regulärer Knoten im Vergleich dazu empfängt
und sendet, ist von der Gruppengröße unabhängig. Da auf jede Anfrage eines
regulären Knotens nur eine konstante Zahl von Managern antwortet, ist die Last
ausschließlich von der Anzahl und Art der Anfragen eines dieser Knoten abhängig
und somit von selbstbestimmbaren Größen.
Die Gesamtlast des Systems lässt sich nur schwer bestimmen, da das JXTA-Netzwerk virtuell ist und keine Rückschlüsse auf die tatsächliche Topologie zulässt. Da
jeder Manager O(N) Nachrichten empfängt und die Zahl der Manager einer Gruppe von der Zahl der Gruppenmitglieder linear abhängt, liegt die Größenordnung
34
der Nachrichten in einer Gruppe bei O(N2). Dies zeigt, dass Daedalus bei großen
Gruppen erheblich ineffizienter wird, da jedoch eine Gruppe nur die Knoten enthält, die sich für ein Datenobjekt interessieren, werden große Gruppen nur sehr
selten au�reten. Nicht betrachtet in dieser Analyse ist die Last, die durch Nachrichten entsteht, die von einem Knoten weitergeleitet werden. Diese Betrachtung
ist jedoch für das Ubiquitous-Computing weniger wichtig, da ressourcenarme
Geräte diese Aufgaben nicht oder nur im geringen Maße wahrnehmen. Darüber
hinaus hängt diese Last von allen JXTA Knoten ab, und ist somit nicht auf Basis
von Daedalus bestimmbar.
Die Last eines Knotens skaliert folglich im worst case linear mit der Zahl der
Gruppenmitglieder, im besten Fall ist sie vollständig unabhängig von externen
Größen und kann von einem Knoten selbständig bestimmt werden. Demgegenüber steht eine quadratische Laststeigerung des Gesamtnetzverkehrs. Da aber der
Großteil dieser Last auf stationäre, leistungsstarke Netzwerkknoten fällt, scheint
dieser Trade-off für Ubiquitous-Computing-Szenarien akzeptabel, insbesondere
da die zu erwartende Gruppengröße, verglichen mit der Gesamtzahl der Knoten
in einem Netz, klein ist, verglichen mit den Netzwerkgrößen anderer Verfahren.
5.2 Performanz
Der Performanz von Daedalus hängt von der Zeit ab, die für die Kommunikation
nötig ist, und von der Zeit, die die einzelnen Knoten zur Verarbeitung der Pakete
benötigen. Zunächst wurde die Verarbeitungszeit ermi�elt, indem alle DaedalusKnoten auf einem Rechner liefen, wodurch keine Kommunikation über Netzkomponenten nötig war. Die Messung erfolgte auf einem Windows 2000 PC mit
einem 2 GHz Prozessor mit der Java 2 Standard Edition (J2SE) 1.5.0 und der JXTA
Version 2.3.4. Die ermi�elten Zeiten sind in Tabelle 5.2 aufgeführt. Zu beobachten
ist dabei, dass die Zeit, die für das Verändern eines Datenobjektes nötig ist, linear
steigt, wenn die Zahl der Manager erhöht wird, die auf eine Anfrage reagieren.
Erklärt werden kann dies mit dem Scheduling des Rechners. So sind mit zunehmender Knotenzahl mehr Kontextwechsel nötig.
Um die Performanz von Daedalus in einem Netzwerk beurteilen zu können,
ist es nötig die Zeiten zu ermi�eln, die JXTA für das Übermi�eln einer Nachricht
benötigt. Die tatsächliche Zeit hängt stark von der Netzstruktur und den Transporteigenscha�en der verwendeten Hardware ab. Deswegen wurde in einer IRISA Studie [5] die Round Trip Time (RTT) von JXTA-Unicast-Nachrichten mit der
einer gewöhnlichen Socket-Kommunikation verglichen. Hierbei zeigte sich, dass
in LAN-Netzen JXTA, je nach verwendeter Kommunikationsmethode, um den
Faktor fünf bis 30 langsamer war als die Socket-Kommunikation. Hauptgrund
hierfür ist die Verarbeitung der JXTA-Nachrichten. Messungen über die Suche
mit JXTA wurden vom JXTA-Benchmark-Projekt [25] durchgeführt.
35
Anhand dieser Daten ist es nun möglich, die Performanz von Daedalus für ein
Szenario abzuschätzen. Die Zeit, die für das Verändern eines Datenobjektes nötig
ist setzt sich aus der Zeit für das Locking, dem Verteilen der neuen Version und
deren Validierung, der Freigabe des Lockings sowie der Zeit zum Verarbeiten der
Nachrichten zusammen.
Update-Zeit: Tu = Tl + Td + Tr
Für das Locking sind zwei Sendevorgänge nötig, für das Verteilen und Validieren sowie für die Freigabe des Lockings jeweils drei. Dazu kommt die Zeit für das
Verarbeiten der JXTA- und Daedalus-Nachrichten. In Abhängigkeit von dieser Sendezeit ergibt sich also folgende Beziehung:
Update-Zeit: Tu = 8 Ts + Tc
In einem Szenario, in dem sich alle Knoten in dem gleichen WLAN befinden,
welches eine gewöhnliche RTT von 1ms hat, hat die eigentlich Kommunikation
kaum einen Einfluss auf die Performanz, die Leistungsstärke der Knoten jedoch
einen hohen. So benötigt ein Update in einer Gruppe mit zwei Managern so etwa
144 ms, ein Update in einer Gruppe mit fünf Managern 354 ms. Erfolgt das Update
von einem Knoten aus, der mit einer Breitbandverbindung angebunden ist, die
eine RTT von 80 ms hat, nimmt die Bedeutung der Netzstruktur zu. So benötigt
ein Updatevorgang nun in einer Gruppe mit zwei Managern 460 ms und 670 ms in
einer Gruppe mit fünf Managern.
Da in vielen Szenarien jedoch die Kommunikation zumindest teilweise über
das Internet erfolgt, wurde schließlich noch ein reales Daedalus-Szenario getestet.
Dabei kommunizierten die Knoten über das Internet miteinander, an das sie per
Breitbandverbindung angeschlossen waren. Dazu wurde zuerst die Zeit gemessen,
die nötig ist, bis sich ein Gerät mit dem JXTA-Netzwerk verbunden hat und der
Basisgruppe des Daedalus-Systems beigetreten ist. Danach die Zeit bis ein Knoten
Mitglied einer Gruppe geworden ist, und die Zeit, die ein passiver Knoten benötigt, um die aktuelle Version in Erfahrung zu bringen. Schließlich wurde die Zeit
ermi�elt, die nötig ist um ein Datenobjekt zu verändern, indem zuerst das Datenobjekt gesichert, geschrieben und danach wieder freigegeben wurde.
Bis auf die erste Messung hängen alle von der Gruppengröße zu einem bestimmten Maße ab. Die Zeit, für den Beitri� zum JXTA-Netzwerk benötigt wird,
ist jedoch unabhängig von der Zahl der Knoten, die den Daedalus anbieten oder
nutzen. Diese Größe ist nur von der Erreichbarkeit der, dem Knoten bekannten,
Rendezvous-Peers abhängig. Diese Zeit spielt jedoch eine große Rolle, da sie sich
als bestimmend für die Zeit, bis ein Knoten den Wert einer Ressource ermi�eln
kann, erweist.
Um die Zeit für das Verbinden zum JXTA-Netzwerk zu ermi�eln wurden 50
Messungen vorgenommen. Gemessen wurde dabei die Zeit, die nötig ist, um zum
36
Netzwerk verbunden zu werden, einen Rendezvous-Peer zu finden und der Daedalus-Basisgruppe beizutreten. Dabei kann in Abbildung 5.1 beobachtet werden,
dass in den meisten Fällen in etwas mehr als zehn Sekunden eine Verbindung
aufgebaut werden konnte, jedoch einige Ausreißer die nötige Zeit verdreifachten.
Als entscheidend für die Frage, wie lange für diesen Vorgang gebraucht wurde,
erweist sich die Zeit, die zum Verbinden mit einem Rendezvous-Peer benötigt
wird. So kann der Ausfall eines solchen Knotens dazu führen, dass beim nächsten
Verbindungsau�au eine wesentlich längere Zeit benötigt wird, nachfolgende Verbindungen können dann allerdings wieder schneller erfolgen, solange der neue
Rendezvous-Peer erreichbar bleibt. Genügend Rendezvous-Peers sind folglich
notwendig, wenn ein Knoten schnell auf Daedalus zugreifen will und er über
keine permanente Verbindung verfügen kann. Im Durchschni� wurden für den
Beitri� 13 Sekunden benötigt, wobei die Häl�e aller Verbindungsau�auten in
unter elf Sekunden erfolgt war.
Abbildung 5.1: Gemessene Zeiten bis der Knoten mit dem JXTA-Netzwerk verbunden ist
Die zum Beitri� einer Gruppe nötige Zeit hängt, je nach Messpunkt, nicht oder
nur bedingt von der Anzahl der Knoten in dieser Gruppe ab. Da ein Knoten bereits nach dem ersten Welcome-Paket aktiv arbeiten kann, wurde nur bis zum
Eintreffen des ersten Welcome-Pakets gemessen. Dadurch wird die benötigte Zeit
jedoch unabhängig von der Anzahl der Knoten. Die hohe Varianz, die man den
Werten aus Abbildung 5.2 entnehmen kann, entsteht durch veränderte Netzwerktopologien. So ist es möglich, wenn der Sender des Hello-Pakets und der Sender
des Welcome-Pakets nur über kurze Wege miteinander verbunden sind, der Kommunikationskanal deutlich schneller aufgebaut werden kann. Der Anteil der Zeit,
den JXTA für den eigentlichen Gruppenbeitri� benötigt, ist dabei relativ klein und
37
stabil. Der Au�au des Unicast-Kommunikationskanals für die Welcome-Pakete
nimmt hier den größten Teil der Zeit ein und stellt auch gleichzeitig die variabelste
Einflussgröße dar. Erkennbar ist jedoch, dass die Werte eine untere Schranke bei
ungefähr einer Sekunde haben und die Mehrheit der Messwerte unter 2,5 Sekunden lag. Im Durchschni� wurden für den Beitri� zu einer Gruppe 2,6 Sekunden
benötigt.
Abbildung 5.2: Gemessene Zeit vom Gruppeneintri� bis zur Erlangung der
Ressource
Für das Laden einer Ressource ergibt sich ungefähr ein Wert von 0,4 Sekunden,
wie Abbildung 5.3 zeigt. Die dri�e und letzte Messreihe soll darüber Auskun� geben, wie sich Daedalus in einem der beiden Standardanwendungsfälle, dem Verändern der Ressource, verhält. Hierbei wurde die Zeit gemessen, die für das Sichern
eines Datenobjektes, das Publizieren und Bestätigen der Veränderung und schließlich dem Freigeben des Objektes nötig war. Der Knoten, der die Veränderung vornehmen sollte, war ein Manager, weswegen ein Ermi�eln der aktuellen Version
nach dem Sichern des Objektes entfallen konnte. Für Knoten, die keine Manager
sind, verlängert sich demzufolge die nötige Zeit um die Zeit, die für das Laden
der Ressource nötig ist, im Durchschni� also um 0,4 Sekunden. Gemessen wurde
zunächst in Gruppen mit zwei, drei und fünf Managern. Anschließend wurden
noch Messungen mit zehn und zwanzig Managern vorgenommen. In allen Fällen
wurde die Zahl der Manager, die für die Entscheidung über den Lockmechanismus
zuständig sind, auf zehn festgelegt. Zu erwarten ist also nur eine Zunahme der Zeiten bis zu zehn Managern, Gruppen mit mehr Managern sollten keinen Zuwachs
dieser Werte erfahren. Abbildung 5.4 zeigt die Verteilung der gemessenen Zeiten.
Abbildung 5.5 zeigt die Entwicklung des Durchschni�swertes und des Medians
bei zunehmender Managerzahl. Erkennbar ist, dass die Zeit langsam zunimmt
38
und insbesondere die Varianz deutlich wächst. Gruppen mit mehr als zehn Managern zeigen, wie erwartet, keine signifikanten Veränderungen zu Gruppen mit
zehn Managern. Es zeigt sich jedoch, dass die Zahl der Manager, die über den
Lockmechanismus entscheiden, Auswirkungen auf die Performanz des Gesamtsystems beim Schreiben haben. Hier muss also in den jeweiligen praktischen Anwendungsfällen ein Kompromiss zwischen Performanz und Konsistenzsicherheit
gefunden werden.
Einzelner PC
Internet Szenario
Verbinden zu JXTA
2627 ms
13211 ms
Einer Gruppe beitreten
268 ms
2618 ms
Ressource laden
130 ms
421 ms
Ressource speichern mit 2 Managern
139 ms
1054 ms
187 ms
1688 ms
349 ms
2651 ms
4130 ms
4266 ms
Tabelle 5.2: Daedalus-Performanz
Die Messungen zeigen deutlich, dass die Performanz des Systems, auch wenn
sie weitgehend unabhängig von der Anzahl der Knoten ist, viel Raum für Verbesserungen lässt. Da der Großteil der Zeit jedoch für Aufgaben verwendet wird, die
das JXTA-Framework erfüllt, ist dies der vielversprechendste Ort, um die nötigen
Zeiten zu reduzieren. Allerdings dür�e durch eine stärkere Verbreitung und damit eine höhere Zahl von Rendezvous-Peers und Relay-Peers dafür sorgen, dass
zukün�ig die Kommunikation im JXTA-Netzwerk schneller erfolgen kann.
39
Abbildung 5.3: Gemessene Zeiten zum Ermi�eln von ungecachten Ressourcen
Abbildung 5.4: Gemessene Zeiten beim Verändern der Ressource
rote Punkte bei zwei, grüne bei drei, blaue bei fünf, viole�e bei zehn und schwarze Punkte bei 20 Managern
40
Abbildung 5.5: Median (grün) und Durchschnitswert (rot) der ermi�elten Zeiten
für zwei, drei, fünf und zehn Managern
5.3 Fehlermodell
Um das Verhalten eines Systems im Fehlerfall vorherzusagen, ist es zunächst nötig, mögliche Fehlerquellen zu bestimmen. Neben der Nichterreichbarkeit eines
Knotens ist mit fehlerha�en und manipulierten Knoten zu rechnen. Die Konsequenzen der Fehler hängen jedoch von der Anzahl der Fehler ab, da ein einzelner
fehlerha�er Knoten kaum Einfluss auf das Gesamtsystem hat. Dazu ist es nötig,
die Zahl der möglichen Fehler zu ermi�eln, bei der Daedalus noch korrekt funktionieren kann. Tabelle 5.3 zeigt die Zuordnung zwischen Fehlern und Folgen. Die
Felder „ne“ stehen dabei für nicht erreichbare Knoten, die Felder „�“ für fehlerha�e oder manipulierte.
41
�RL
�F
�F
�M
�M
M
N
ne � ne � ne � ne � ne � ne � ne �
• •
• • • • • •
Lesen scheitert
• • Daten nicht erreichbar
• •
Daten veraltet
• • • • • • • • • •
Locking scheitert
• • • • • • • • • •
Validierung scheitert
•
•
Datenmanupilation möglich
•
•
Locking für falschen Knoten
•
•
Lockingfreigabe
durch falschen
Knoten
Tabelle 5.3: Abhängig von der Anzahl der fehlerha�en (�) oder nicht erreichbaren (ne) Knoten kommt es zu diesen Fehlern
Sind alle Knoten einer Gruppe nicht erreichbar, ist das Datenobjekt dieser Gruppe
nicht mehr verfügbar. Knoten, die nun der Gruppe beitreten, erstellen neue Versionen des Datenobjektes, unabhängig von der vorhergehenden. Trat dieser Fehler
nur temporär auf und kein neuer Knoten erzeugte in der Zwischenzeit eine neue
Version, so kann, nachdem die Knoten der Gruppe wieder erreichbar sind, die
Gruppe fortgesetzt werden.
Sind alle Manager einer Gruppe nicht erreichbar, so können Anfragen regulärer Knoten nicht beantwortet werden, worau�in diese zu Managern werden. Da reguläre
Knoten möglicherweise nicht die aktuelle Version eines Datenobjektes kennen,
geht diese verloren. Sta�dessen ist nur eine ältere Version vorhanden.
Sind mindestens zwei Dri�el der Manager einer Fraktion manipuliert oder fehlerha�,
kann diese Fraktion falsche Informationen an neue Knoten liefern, das Schreibrecht
einem falschen Knoten zuweisen und das Locking au�eben. Des weiteren ermöglicht dies anderen Knoten das Datenobjekt zu manipulieren.
Sind mehr als ein Dri�el aller Manager einer Fraktion fehlerha�, so können Validierungsanfragen und Lockingentscheidungen fehlschlagen. Betri� dies nur eine
Fraktion, so können nachfolgende Anfragen erfolgreich sein.
Sind mehr als ein Dri�el der Manager fehlerha�, die ein Knoten um die Ressource bi�et
42
(�RL), ist es nicht möglich, die aktuelle Version des Datenobjektes zu erhalten. Folgende Anfragen können jedoch zu einem Ergebnis führen.
5.4 Verfügbarkeit
Die Verfügbarkeit eines einzelnen Knotens in einem Peer-to-Peer-Netz ist aufgrund der geringen Verweildauer und der fehlenden Kontrolle nur gering. Durch
redundante Anfragen kann jedoch ein hohes Maß an Verfügbarkeit des Gesamtsystems erreicht werden. Sämtliche Vorgänge werden in Daedalus redundant
ausgeführt, wobei es im Falle des Lesens einer Ressource dem Knoten überlassen
bleibt, den Grad der Redundanz selbst festzulegen. Neben der Verfügbarkeit ist
die Folge eines Fehlers von Bedeutung.
Um die Verfügbarkeit eines Knotens zu ermi�eln, ist es zunächst nötig, die
Mean Time to Failure (MTTF) sowie die Mean Time to Repair (MTTR) zu bestimmen.
Die MTTR besteht dabei aus der Zeit, die für einen Knoten nötig ist, sich erneut
mit dem JXTA Netzwerk zu verbinden, der Daedalus-Gruppe und der Ressourcengruppe beizutreten und schließlich erneut das Datenobjekt zu erlangen. Diese
Zeit summiert sich auf 20237ms. Die MTTF ist nicht ohne Weiteres bestimmbar.
Schließt man alle Fehler aus, so entspricht sie der Zeit, die ein Knoten in einer
Gruppe Mitglied ist. Die Verfügbarkeit berechnet sich nun durch:
Verfügbarkeit: As =
MTTF
MTTF + MTTR
Die Redundanz für den Gruppeneintri� entspricht F, wobei F die Fraktionsgröße ist und zwischen 3 und 10 liegt, wenn die Gruppe groß genug ist. Nimmt
man für einen Knoten eine Verfügbarkeit von AK=0,9374, was einer MTTF von
fünf Minuten entspricht, und eine Fraktionsgröße von 3 an, so ergibt sich eine
Verfügbarkeit für den Gruppeneintri� von AG=0,9998. Erhöht sich die Fraktionsgröße auf 10 Knoten, so hä�e dies eine Verfügbarkeit für den Gruppeneintri� von
AG=0,999 999 999 999 zur Folge. Die Konsequenz eines fehlerha�en Gruppeneintri�s ist entweder, dass der Knoten von einer leeren Gruppe ausgeht oder dass
er falsche Daten hinsichtlich der Größe der Gruppe hat. Geht ein Knoten davon
aus, dass die Gruppe leer ist, so kann er nicht in der Gruppe partizipieren, jedoch
auch nicht andere Knoten behindern. Darüber hinaus kann er zu einem späteren
Zeitpunkt erneut einen Gruppeneintri� versuchen. Erhielt der Knoten falsche
Informationen über die Gruppe, kann der Knoten ohne Probleme in der Gruppe
teilnehmen, er wird jedoch Anfragen beantworten, für die er nicht zuständig ist.
Solange dies jedoch nur für einen kleinen Teil der Knoten zutri�, ist die zusätzliche Last vernachlässigbar.
Die Verfügbarkeit des Lesens hängt davon ab, wieviele Manager ein Knoten um
43
ein Datenobjekt bi�et. Folglich kann jeder Knoten auf Kosten von Bandbreite eine
hohe Zuverlässigkeit erlangen. In Abhängigkeit von AL ergibt sich also folgende
Leseverfügbarkeit AR:
AR=1-(1-AK)RL
Bei einer dreifach redundanten Anfrage an Knoten mit der Verfügbarkeit von
AK=0,9375 beträgt die Leseverfügbarkeit 0,9998. Scheitert die Anfrage, weil kein
Knoten antwortet, so kann diese Anfrage noch einmal gestellt werden, es entsteht
also lediglich eine Verzögerung. Wird die Anfrage jedoch mit einem falschen Datenobjekt beantwortet, empfiehlt sich ein zusätzlicher Datenschutz, etwa in Form
von Checksummen, um das Datenobjekt zu überprüfen.
Verändert ein Knoten das Datenobjekt, so wird die neue Version als Broadcast
an alle Manager verschickt. Folglich verfügt jeder Manager danach mit einer Wahrscheinlichkeit von RK über die korrekte neue Version. Zusätzlich empfängt jeder
Manager noch mindestens PA Validierungsnachrichten, anhand deren der Manager
die Version überprüfen kann. Besteht eine Fraktion aus 3 Knoten, bedeutet dies,
dass jeder Manager mindestens 2 Bestätigungsnachrichten erhalten muss. Die
Verfügbarkeit der Validierung ist in diesem Fall AV=0,996. Es besteht also eine Gesamtzuverlässigkeit für diesen Vorgang von A=0,9958. In den meisten Fällen wird
man also Fraktionsgrößen deutlich größer als 3 Knoten wählen. Einen weiterer
Zugewinn an Verfügbarkeit kann darüber hinaus auch in diesem Fall durch die
Verwendung von Checksummen oder Codierungsverfahren erreicht werden.
Die Verfügbarkeit des stochastischen Lockings hängt von den gleichen Parametern ab, von denen auch die Verfügbarkeit des Schreibens abhängt. Folglich sind
beide Zuverlässigkeiten gleich. Beide Vorgänge unterscheiden sich jedoch in der
Konsequenz des Verfügbarkeit . Ist die Entscheidung der Fraktion, die über das
Locking abstimmt, fehlerha�, so wird das Schreibrecht auf die Ressource entweder einem andern Knoten oder gar keinem Knoten zugesprochen. In beiden Fällen
führt der Fehler nicht zu inkonsistenten Daten sondern zu einer Verzögerung.
5.5 Responsivität
Das Maß der Responsivität gibt an, mit welcher Wahrscheinlichkeit ein Vorgang
zu einem Zeitpunkt erfolgreich in einer bestimmten Zeit ausgeführt werden kann.
Dabei hängt diese Größe von der Verfügbarkeit des Dienstes und der Wahrscheinlichkeit, das Ergebnis in der geforderten Zeit zu erhalten, ab [22].
Responsivität: ri(t) = ai pi
Ausgehend von den in den vorhergehenden Abschni�en ermi�elten Werten
ergeben sich die, in Tabelle 5.4 angegebenen, Werte für die Responsivität. Dabei
44
wurde die Fraktionsgröße auf fünf Manager festgelegt. Die Leseoperation erfolgt
ebenfalls fünffach parallel.
Laden
Speichern
(2 Manager)
Speichern
(3 Manager)
Speichern
(5 Manager)
Speichern
(10 Manager)
Speichern
(20 Manager)
r(0,5)
0,75
0
r(1)
~1
0,489
r(2)
~1
0,946
r(3)
~1
~1
r(4)
~1
~1
r(5)
~1
~1
r(7)
~1
~1
r(8)
~1
~1
0
0,249
0,697
0,847
~1
~1
~1
~1
0
0
0,3
0,7
0,9
0,95
~1
~1
0
0
0
0,15
0,55
0,85
0,9
~1
0
0
0
0,05
0,5
0,8
0,95
~1
Tabelle 5.4: Responsivität einer Gruppe beim Laden und Verändern eines Datenobjektes
5.6 Datenoverhead
Der Datenoverhead ist die Menge an Daten die übermi�elt werden müssen, ohne
das sie Informationen für die Anwendungen enthalten. Das sind im Besonderen
die Nachrichten, die zum Eintri� in Gruppen, zur Gruppenverwaltung und zum
Locking nötig sind. Die Nachrichtengrößen von Daedalus ohne Nutzlast sind in
Tabelle 5.5 aufgeführt. Für einen Vergleich zu einer reinen Datenübermi�lung
ohne JXTA muss darüber hinaus für jede Nachricht der Overhead von JXTA berücksichtigt werden, der 877 Byte beträgt.
In einem Szenario, in dem ein Knoten in einer Gruppe mit drei Managern ein
Datenobjekt verändern will, muss er neben den eigentlichen Daten noch 2214
Bytes senden und 3054 Bytes empfangen. Insgesamt also 5528 Bytes zusätzlich zu
den Daten, die gespeichert werden sollen, für Daedalus. Der Overhead der durch
die JXTA-Kommunikation entsteht, 10524 Bytes, bedeutet, dass Daedalus im Vergleich zu einem direkten Übermi�eln der Nutzdaten in diesem Fall 16052 Bytes
mehr übertragen muss.
45
Nachrichtentyp
Bye
Error
Hello
Invitation
Manager-Request
Mutex
Mutex-Responce
Request
Ressource
Validation
Validation-Request
Welcome
Größe in Bytes
216
296
219
210
220
206
324
220
392
235
347
376
Tabelle 5.5: Paketgrößen von Daedalusnachrichten
5.7 Zusammenfassung
Die Performanzeinschätzungen und der Overhaed machen deutlich, dass Daedalus
nicht für jedes Szenario einsetzbar ist. Insbesondere profitieren Applikationen um
so mehr von Daedalus, je länger die Daten gespeichert bleiben. Werden die Daten
zu häufig verändert, so sind andere Verteilungsmechanismen, etwa ein Multicast,
zweckmäßiger. Da das Verändern von Daten vergleichsweise viel Zeit in Anspruch
nimmt, ist es sinnvoll die Daten so zu strukturieren, dass Veränderungen selten
und nur von wenigen Knoten aus erfolgen.
Optimierungspotential besteht in den Nachrichtenpaketen, die gegenwärtig
etwas größer sind, als unbedingt nötig. Darüber hinaus kann besonders für große
Gruppen eine Veränderung der Parameter wie Fraktionsgröße und der Mindestmehrheiten eine Steigerung der Performanz erreicht werden. Weitergehend ist ein
Verzicht auf das Locking bei manchen Daten denkbar, was eine Performanzsteigerung um den Faktor drei zur Folge haben kann. Dies kann jedoch zu Dateninkonsistenzen führen, die durch andere Schichten abgefangen werden müssen.
Da der Datenoverhead von Daedalus und JXTA unabhängig von der Größe des
Datenobjektes ist, empfiehlt es sich, Daten zusammenzufassen und größere Datenobjekte in Daedalus zu speichern. So liegt der Datenoverhead für das Verändern
eines ein MByte großen Datenobjektes unter 2%.
46
6 Die Implementation
6.1 MagicMap als Umgebung
Das in dieser Arbeit vorgestellte Peer-to-Peer-Shared-Memory-System wurde als
Proof-of-Concept für das MagicMap-Projekt [19] implementiert. Bei MagicMap
handelt es sich um eine Anwendung, die mi�els Signalstärkemessungen von
WLAN-Geräten die Position eines PDAs oder ähnlichen mobilen Geräten ermittelt. Ist die Position bekannt, wird diese in Karten dargestellt. Ziel dieses Projektes
ist es, positionsbasierte Dienste und die Suche nach Geräten, beziehungsweise den
dazugehörigen Personen, anzubieten. Die Positionen und Karten werden bisher
durch einen Webservice gespeichert und verwaltet, der auf einem zentralen Server
läu�. Es zeichnet sich jedoch ab, dass diese Lösung den zu erwartenden Anforderungen nicht genügen wird. Bereits bei einer relativ geringen Belastung betrug die
Antwortzeit des Servers mehrere Minuten. Da eine Veröffentlichung der Technik
und der So�ware in der Zeitschri� c’t [9] geplant ist, ist mit sehr vielen Anfragen
zu rechnen, die der Server in keiner vertretbaren Zeit beantworten könnte. Die
Abbildung 6.1 zeigt die MagicMap-Architektur, den Beitrag dieser Arbeit stellen
die gelb gezeichneten Schni�stellen und die hellblau gezeichneten Zylinder dar.
MagicMap-Knoten messen selbständig die WLAN-Signalstärken von anderen
Geräten und übermi�eln diese Werte an den Server. Ein Knoten, der die Position
eines anderen Gerätes ermi�eln möchte, fragt den Server nach allen Messwerten
zu diesem Gerät und kann anhand der Daten die Position berechnen.
Aufgrund des Szenarios lassen sich einige Aussagen bezüglich der teilnehmenden Geräte treffen, die die hohen Anforderungen des im vorherigen Kapitel
vorgestellten Verfahrens vereinfachen. So ist jede Ressource nur für eine kleine
Zahl von Peers interessant, so wird die Gruppengröße in der Regel deutlich unter
hundert Peers liegen. Die Peers werden zwar weiterhin relativ kurz aktiv sein,
jedoch signifikant länger, als bei dem Beispiel des mobilen Kalendereintrages. Dadurch, dass die PDAs ihre Position anhand von WLAN-Signalstärken bestimmen,
kann mit einer hohen Wahrscheinlichkeit gerechnet werden, dass sie über WLAN
ebenfalls kommunizieren werden. Dies ist natürlich nicht garantiert, da zur Positionsbestimmung nur das Messen nötig ist, ein Zugang zu dem WLAN-Netz muss
nicht gegeben sein. Da jedoch ausreichend über einen WLAN-Zugang verfügen
werden, sind diese Ausnahmen kein Problem für das System. Da das Ziel von MagicMap die Ermöglichung von positionsbasierten Dienstleistungen ist, ist es auch
wahrscheinlich, dass genügend dauerha� verfügbare Peers teilnehmen, so dass
die Kontinuität von Daten gewährleistet werden kann.
47
Abbildung 6.1: Die MagicMap-Architektur
Neben dem veränderten Speichern hat ein Peer-to-Peer-Ansatz für MagicMap
auch Folgen für die Berechnung der Daten. Eine einfache Lösung, bei der alle Knoten die Positionen von den Knoten berechnen, die sie interessieren, ist problematisch. Ein Knoten würde dazu in einer Vielzahl von Gruppen teilnehmen und viele
Datenobjekte auswerten. Zudem entsteht durch das vielfältige Berechnen einer
einzelnen Position ein hohes Maß an Redundanz, ohne dass dadurch die Positionsberechnung verbessert wird, wenn die Ergebnisse nicht kommuniziert werden.
Deswegen sollen die Positionsberechnungen von einigen, leistungsstarken Knoten
erfolgen und dann in Daedalus veröffentlich werden, so dass alle anderen Knoten
die Position erfahren können. In Abbildung 6.2 wird der Knoten B von den beiden
Knoten C und D vermessen. Der Knoten A berechnet anhand der Messwerte dieser
Knoten nun die Position und veröffentlicht sie in Daedalus.
48
A
B
C
D
E
measures
calculates
Abbildung 6.2: Verteiltes Messen und Berechnen in MagicMap. Die Messwerte
der Knoten C und D werden von A benötigt um die Position von B zu bestimmen.
6.2 Schni�stelle zu MagicMap
MagicMap ist modular aufgebaut, das heißt, dass jedes Modul eine Aufgabe
übernimmt und jedes dieser Module prinzipiell durch andere ersetzt oder auf es
komple� verzichtet werden kann. Dies hat den Vorteil, dass auf einem Gerät nur
die Module installiert werden müssen, die auch tatsächlich benötigt werden. Ist
kein GPS-Empfänger installiert, so wird dieses Modul nicht benötigt und ist keine
Ausgabemöglichkeit vorgesehen, so muss die Visualisierung mi�els Karten nicht
vorhanden sein. Dies hat jedoch zur Folge, dass eine Vielzahl von Prozessen die
Funktionalität von Daedalus in Anspruch nimmt. Hier bieten sich nun zwei prinzipiell verschiedene Ansätze an, jedes Modul mit der Schni�stelle auszusta�en.
Zum einen kann das Shared-Memory-System als Bibliothek statisch oder dynamisch mit jedem Modul verlinkt werden. Der große Nachteil dieser Vorgehensweise liegt im Verlust der Flexibilität. Jedes Modul ist dann auf die Verwendung
dieses Shared-Memory-Systems angewiesen und kann nur mit großem Aufwand
andere Speichertechniken nutzen. Zudem schränkt dieser Ansatz die möglichen
Programmiersprachen für die Entwicklung von Modulen ein. Durch das statische
Linken würden darüber hinaus deutlich mehr Ressourcen benötigt werden, da
mehrere Instanzen gleichzeitig laufen müssen.
Ein anderer Ansatz, und der in diesem Fall gewählte, implementiert das SharedMemory-System als eigenes Modul. Auf jedem Gerät läu� dieses Modul als eigenständiger Prozess und kommuniziert mit den anderen Modulen per UDP. Der
Vorteil dieser Lösung ist, dass sie keinerlei Annahmen und Einschränkungen über
andere Module machen muss. Die Wahl von UDP als Kommunikationsprotokoll
ist zum einen in der bisherigen serverzentrierten Shared-Memory-Infrastruktur
begründet. Zum anderen entspricht sie auch pragmatischen Anforderungen. So
wäre eine Implementierung als Webservice prinzipiell denkbar, jedoch erscheint
der zusätzliche Ressourcenbedarf in keiner Relation zum möglichen Gewinn an
49
Flexibilität zu stehen, da die primäre Pla�form für MagicMap PDAs sind.
Da diese Schni�stelle von mehreren anderen Modulen gleichzeitig genutzt werden kann, ergeben sich hohe Anforderungen an diese Schni�stelle, die, wenn sie
vollständig erfüllt werden sollen, auf die parallele Nutzung von mehreren SharedMemory-Instanzen hinführen. So würden zwei Lockanforderungen von verschiedenen Modulen für die gleiche Ressource bedeuten, dass ein Endpunkt des
JXTA-Netzwerkes mit zwei verschiedenen IDs diese Anfragen versendet. Es zeigt
sich jedoch, dass dieses hohe Maß an Parallelität, die nur durch parallel laufende
JXTA-Endpunkte erreichbar ist, in der Praxis von MagicMap nicht nötig ist. Es
kann davon ausgegangen werden, dass zwei Module nicht die gleichen Ressourcen verändern wollen, da ein WLAN-Positionierungsmodul nur die Positionen
von anderen WLAN-Geräten, ein GPS-Modul nur die eigene Position bestimmen
kann. Um jedoch diesen Fall nicht vollkommen ausschließen zu müssen, bietet die
Schni�stelle neben den Funktionen von Daedalus noch weitere Funktionen an, die
den Wert einer bestimmen Ressource ändern.
Einem Modul, das auf Daedalus au�auen will, stehen folgende Funktionen zur
Verfügung. „Get" ermi�elt den aktuellen Wert einer Ressource, das Shared-Memory-Modul antwortet mit diesem Wert oder einem Fehler, wenn diese Ressource
noch keinen Wert enthält oder keine Verbindung zum JXTA-Netzwerk besteht.
Mit „Lock" kann das Modul eine Ressource sichern, um sie mit „Set" zu verändern,
mit „Release" wird diese Ressource wieder freigegeben, siehe Abbildung 6.3. Mit
den Aufrufen „Minresult" und „Timeout" können die Werte für die Mindestzahl
von Suchergebnissen, nach dem das Modul informiert wird, und die Zeit, die auf
eine Antwort im JXTA-Netz gewartet wird, festgelegt werden. Mit „Search" kann
eine Suche nach einer JXTA-Gruppe oder einem Peer gestartet werden. Wurde die
Mindestzahl von Gruppen oder Peers gefunden, wird das Modul mit einer UDPNachricht informiert. Möchte das Modul nicht so lange warten, kann es auch jeder
Zeit mit „Results" die Liste der aktuell gefundenen Gruppen und Peers erfragen.
Damit ein hierarchischer Positionierungsbaum erstellt und verwaltet werden kann,
existieren die Aufrufe „Join" und „Leave" um einer Gruppe beizutreten oder eine
Gruppe zuverlassen. Damit ein Modul eine Ressource verändern kann, ohne dass
sie sich um das Sichern und Freigeben der Ressource kümmern muss, ermöglicht
es die Funktion „Update" Modulen, die unabhängig von dem Wert der Ressource
diese verändern wollen, dies zu tun.
50
DSM
Modul
MagicMap
Position
ermitteln
Get
Ressource
ermitteln
JXTA-Gruppe
Hello
Welcome
Request
Resource
Got
Ressource
sichern
Lock
Position
verändern
Locked
Get
Got
Set
Release
Anfrage aus
dem Cache
beantworten
Ressource
veröffentlichen
und freigeben
MutexRequset
MutexResponce
Resource
ValidationReq.
Validation
MutexRelease
ValidationReq.
Validation
Abbildung 6.3: Die Interaktion von MagicMap, DSM-Modul und der JXTAGruppe, die für die Ressource zuständig ist
6.3 Clustering der Daten
Es reicht nicht, einzig die Serverkommunikation mit der Peer-to-Peer-Schni�stelle zu ersetzen, vielmehr ist es nötig, die einzelnen Daten zu analysieren und zu
gruppieren. Würde für jeden Messwert ein neues Datenobjekt erzeugt werden, so
entstünde ein erheblicher Overhead für die Verwaltung, zudem wäre die Zahl der
Knoten in der entsprechenden Gruppe sehr klein, sodass es leicht zu Datenverlust
kommen kann, wenn diese Knoten das Netzwerk verlassen. Für die Gruppierung
der Messwerte ergeben sich zwei Möglichkeiten, zum einen können alle Messwerte zu einem Gerät in einem Datenobjekt gespeichert werden oder alle Messwerte
eines Gerätes. Speichert man alle Werte zu einem Gerät in einem Objekt, so vereinfacht dies die Ermi�lung der Position, weil nur ein einziges Objekt abzufragen
ist. Jedoch müssen in diesem Fall mehrere Knoten schreibend auf dieses Objekt
zugreifen. Da die gewünschte Aktualisierungsrate von 10 Sekunden selbst bei realistischen Knotenzahlen nicht mehr eingehalten werden kann, muss diese Möglichkeit ausgeschlossen werden.
Die Alternativvariante, alle Messwerte, die ein Gerät ermi�elt, in einem Datenobjekt zu speichern, hat den Vorteil, dass für dieses Objekt kein Lockingmechanismus nötig ist. Hier stellt sich jedoch das Problem, dass ein Knoten, der eine
Position ermi�eln möchte, nicht feststellen kann, auf welche Datenobjekte er zugreifen muss, um alle Messwerte zu erhalten. So ist es nötig, dass jeder Knoten,
der die Signalstärke eines Gerätes gemessen hat, sich in eine Liste einträgt, die der
rechnende Knoten auslesen und so alle Datenobjekte ermi�eln kann. Für dieses
Datenobjekt ist jedoch ein Lockingmechanismus nötig, weil mehrere Knoten sich
51
parallel in die Liste ein- oder austragen könnten. Anders als bei dem Locking des
Messwerte-Datenobjektes ist hier mit keiner hohen Aktualisierungsrate zu rechnen
und veraltete Einträge verfälschen das Ergebnis nicht.
Neben den beiden Datenobjekten kommt noch ein weiteres hinzu, in dem die
berechnete Position eines Gerätes gespeichert wird. Bei diesem Objekt kann es
ebenfalls zu konkurrierenden Schreibvorgängen kommen, wenn die Position redundant von mehreren Knoten berechnet werden soll. In der Abbildung 6.4 ist der
Au�au dieser Datenobjekte an einem Beispiel dargestellt. Das Objekt „MagicMapx-Position“ enthält die berechnete Position des Gerätes x. „MagicMap-x-Sense“ enthält alle Messwerte von x und „MagicMap-x-See“ enthält alle Knoten, die ein Signal
vom Gerät x empfangen können.
��
��
��
��
��
��
��
��
�
�
�
��
��
��
��
��
��
��
��
��
Abbildung 6.4: Datenobjekte für MagicMap
6.4 Daedalus als MagicMap-Modul
Wird die MagicMap-Applikation gestartet, so verbindet sie sich mit dem JXTANetzwerk. Dazu wird versucht, mit einem Rendezvous-Peer Kontakt aufzunehmen. Dieser Vorgang kann unter Umständen sehr lange dauern, ist keiner dieser
Rendezvous-Peers in unmi�elbarer Nähe, dauert dies im Durchschni� über zehn
Sekunden. Ein Verzicht auf eine Verbindung zum Rendezvous-Peer würde mit sehr
hoher Wahrscheinlichkeit bedeuten, dass dieser Peer nicht mit anderen kommunizieren kann. Es ist also von Vorteil, wenn Geräte, die an diesem System teilnehmen
und längere Zeit erreichbar sein werden, selber als Rendezvous-Peer agieren.
52
JXTA "NetGroup"
"HU_ROK_DistributedSharedMemoryGroup"
"MagicMap-Position-AA:00:B7:EF:A9:23"-Gruppe
"MagicMap-Map-Berlin-Adlershof"-Gruppe
"MagicMap-Position-6C:15:70:AB:09:99"-Gruppe
"MagicMap-Map-Berlin-Mitte"-Gruppe
"HU_ROK_MagicMap"-Gruppe
"Europe"-Gruppe
"Germany"-Gruppe
"Berlin"-Gruppe
Abbildung 6.5: Beispielha�e Gruppenhierarchie
Nachdem die Verbindung aufgebaut wurde, tri� der Peer nun der Gruppe
„HU_ROK_DistributedSharedMemoryGroup" bei. Diese Gruppe bildet die Basis
für alle Ressourcegruppen, die Untergruppen von dieser sein werden. Da jeder
Peer, der an Daedalus teilnimmt, Mitglied dieser Gruppe sein muss, bietet sich
die Gruppe an, um in ihr nach anderen Peers zu suchen. Beispielsweise kann man
nach Freunden suchen, wenn man den Namen ihres Peers kennt. Neben der Suche
nach anderen Teilnehmern ermöglicht die flache Einordnung sämtlicher Ressourcen unter dieser Gruppe auch eine gezielte Suche anhand des Ressourcennamens
oder Teilen davon. Zusätzlich tri� er noch der Gruppe „HU_ROK_MagicMap"
bei. Diese ist die Wurzel für eine hierarchische Gruppenstruktur, die die Welt beschreibt, wie sie exemplarisch in Abbildung 6.5 zu sehen ist.
Jetzt wird die Applikation die Position des Gerätes erfahren wollen, dazu liest
sie die Ressource „MagicMap-x-Position" aus, wobei x für die MAC-Adresse des
WLAN-Modules des Gerätes steht. Dazu wird der Gruppe gleichen Namens unterhalb der Basisgruppe beigetreten. Jede Gruppe verfügt über eine Broadcastkanal. Jeder kann an diesen Kanal Nachrichten senden, die dann alle Manager der
Gruppe empfangen. An diesen Kanal schickt nun der neue Peer ein Hello-Paket,
siehe Abbildung 6.6. Das Hello-Paket enthält die ID des Peers und seine Geräteklasse. Dabei steht eine Null für ein sehr leistungsschwaches Gerät mit schlechter
Anbindung, eine Drei dagegen für einen sehr leistungsfähigen Peer mit einer
Breitbandleitung.
53
<?xml version="1.0"?>
<!DOCTYPE DSM-PacketType>
<DSM-PacketType>
<hello>
<from>
urn:jxta:uuid-59616261646162614A787
46150325033FABA1D93F26A4E69B058CA90
B963F41D03
</from>
<class>
2
</class>
</hello>
</DSM-PacketType>
Abbildung 6.6: Das Hello-Paket
Erhält ein Peer ein Hello-Paket, so erhöht er zunächst seine Zähler für Mitglieder
und Manager und überprü� danach, ob er diesem Paket antworten muss. Ist dies
der Fall, so schickt er ein Welcome-Paket, siehe Abbildung 6.7, an den Absender
des Hello-Pakets. Die Felder „manager_count" und „member_count" geben dabei
Auskun� über die gegenwärtige Zahl von Managern und Mitgliedern. Erhält ein
Peer auf ein Hello-Paket mehrere, divergierende Angaben zu den Zahlen, so speichert er den ersten ihn erreichenden Wert und ändert diesen nur um höchstens fünf
Prozent pro weiterer Nachricht. Dieses Vorgehen verhindert, dass ein falsch informierter Manager andere in die Irre führen kann, da aber keine exakte Kenntnis
der Größen notwendig ist, muss so nicht bis zum Eintreffen einer Mindestzahl von
Antworten gewartet werden. Neben diesen Zahlen werden noch eine Reihe von
IDs von Managern übermi�elt, diese speichert der neu hinzugekommene Peer, um
später Anfragen an diese Peers zu stellen. Schließlich existiert noch das Feld „mutex", das, wenn ein Peer über das Schreibrecht gegenwärtig verfügt, seine ID enthält.
Hat gegenwärtig kein Peer das Schreibrecht, so wird dieses Feld nicht übermi�elt.
Erhält ein Peer auf sein Hello-Paket hin keine Antwort, so bedeutet dies, dass die
Gruppe leer ist, es zumindest keine aktiven Teilnehmer gibt. In diesem Fall hat kein
anderer Peer seine Position für ihn bestimmt. Hat er aber selber andere WLANGeräte orten können, so liest er deren Position anhand der auf ihre MAC-Adresse
passende Ressource aus.
Hat der Peer jedoch eine oder mehrere Welcome-Nachrichten erhalten, so sucht
er sich aus der Managerliste drei Manager aus, die er mit einem Request-Paket,
siehe Abbildung 6.8, um die Ressource bi�et. Dabei übermi�elt er neben seiner ID
54
noch den Namen der Ressource.
Wenn ein Peer dieses Request-Paket empfängt, so überprü� er zunächst ob er
überhaupt über die Ressource verfügt. Ist dies der Fall, so übermi�elt er sie an den
Absender des Request-Paketes mi�els eines Resource-Paketes, siehe Abbildung
6.9, wobei neben dem Namen der Ressource, die Versionsnummer, die ID des Autors der Version im Feld „from", die Uhrzeit, zu der diese Version erstellt wurde im
Feld „date", die eigentliche Ressource im Feld „value" und schließlich noch seine
eigene ID im Feld „sender". Letzteres ermöglicht dem Anfragesteller festzustellen,
welche Master noch antworten.
<DSM-PacketType>
<welcome>
<manager_count>2</manager_count>
<member_count>10</member_count>
<manager>
urn:jxta:uuid-59616261646162614A78
746150325033FABA1D93F26A4E69B058CA
90B963F41D03
</manager>
<manager>
urn:jxta:uuid-59616255646162614868
74AC503250AB85B70D93F26A4009B0577A
90B963F4C603
</manager>
<mutex>
urn:jxta:uuid-5961625564616261486874AC
503250AB85B70D93F26A4009B0577A90B963F4
C603
</mutex>
</welcome>
</DSM-PacketType>
Abbildung 6.7: Das Welcome-Paket
Hat der Peer nun auch die Ressource erhalten, so kann er zunächst überprüfen, ob genügend Manager vorhanden sind und in diesem Fall den Status selber
ablegen, wenn seine Mindestverweilzeit abgelaufen ist. Diese Mindestverweilzeit
berechnet sich wie folgt: die Geräteklasse mal zwei Minuten minus 20 Sekunden
pro Gruppe, in der dieser Peer bereits Manager ist, plus den letzten drei Stellen
der ID des Peer als Millisekunden. Diese Berechnung sorgt dafür, dass leistungsschwache Geräte so schnell wie möglich den Managerposten aufgeben können.
55
Zudem muss die Auslastung eines Knotens berücksichtigt werden, da auch ein
ansonsten leistungsstarker Peer nur in einer bestimmte Menge von Gruppen Manager sein kann, ohne dass die Last zu hoch werden würde. Der Einfluss der ID soll
verhindern, dass nachdem die Managerzahl groß genug wurde, alle Geräte einer
Klasse auf einmal diesen Posten verlassen. Will ein Peer nicht mehr Manager sein,
so gibt er dies mit einer Bye-Nachricht, siehe Abbildung 6.10, bekannt. Wobei er
neben seiner ID im Feld „from" noch über den Status Auskun� gibt, den er verlässt.
Verlässt er den Managerstatus, bleibt aber noch in der Gruppe, so wird im „status"Feld „manager" angegeben. Empfängt ein Peer diese Bye-Nachricht, so passt er nur
seine Zähler an und überprü� ob dieser Peer zuvor in seiner Managerliste war, in
diesem Fall wird er aus der Liste gestrichen.
Nun kann der Peer die empfangene Ressource auswerten. Die Daten geben dabei
Auskun�, wer diese Position berechnet hat, welcher Pfad den Standort am genauesten beschreibt und welche Karte der Berechnende verwendet hat.
Will nun seinerseits der Peer eine berechnete Position veröffentlichen, so tri� er
zunächst der entsprechenden Gruppe, wie oben beschrieben, bei. Danach muss er
das Schreibrecht erlangen, dies geschieht indem er ein Mutex-Paket an alle Manager verschickt. Mutex-Pakete werden für das Beantragen, der Freigabe verwendet.
In Abbildung 6.11 ist ein Mutex-Paket für die Beantragung des Schreibrechts zu
sehen, beim Freigeben wird sta� dem Feld „request" das Feld „release" verwendet.
Analog das Feld „yield", wenn der Peer einem anderen den Vortri� gewähren
möchte, indem er seinen Wunsch fallen lässt und nach kurzer Zeit erneut beantragt. In diesen Feldern wird die ID des Peers übermi�elt.
<?xml version=”1.0”?>
<DSM-PacketType>
<request>
<from>
urn:jxta:uuid-59616255646162614868
74AC503250AB85B70D93F26A4009B0577A
90B963F4C603
</from>
<name>
test
</name>
</request>
</DSM-PacketType>
Abbildung 6.8: Das Request-Paket
56
<DSM-PacketType>
<resource>
<name>test</name>
<version>12</vesion>
<from>
urn:jxta:uuid-59616255646162614868
74AC503250AB85B70D93F26A4009B0577A
90B963F4C603
</from>
<date>10254848</date>
<value>Test String</value>
<sender>
urn:jxta:uuid-59616255646162614868
74AC503250AB85B70D93F26A4009B0577A
90B963F4C603
</sender>
</resource>
</DSM-PacketType>
Abbildung 6.9: Das Resource-Paket
<DSM-PacketType>
<bye>
<from>
urn:jxta:uuid-59616255646162614868
74AC503250AB85B70D93F26A4009B0577A
90B963F4C603
</from>
<status>manager</status>
</bye>
</DSM-PacketType>
Abbildung 6.10: Das Bye-Paket
57
<DSM-PacketType>
<mutex>
<request>
urn:jxta:uuid-59616255646162614868
74AC503250AB85B70D93F26A4009B0577A
90B963F4C603
</request>
</mutex>
</DSM-PacketType>
Abbildung 6.11: Das Mutex-Request-Paket
Erhält ein Peer die Bi�e um das Schreibrecht, so vermerkt er diese in einer
Queue. Danach überprü� er, ob er für die Beantwortung von Schreibrechtsanfragen zuständig ist. Ist dies der Fall, so sendet er ein Mutex-Response-Paket, siehe
Abbildung 6.12, an alle Manager und den Antragsteller. Diese Nachricht enthält
neben der ID des absendenden Managers, die ID des Peers, der in seiner Queue
an erster Stelle steht. Alle anderen Manager und der Antragsteller sammeln diese
Nachrichten und zählen die Stimmen, die jeder Peer bekommt. Erhält ein Peer zwei
Dri�el der Stimmen, so erhält er das Schreibrecht. Erhält der Antragsteller keine
Mehrheit und gleichzeitig auch kein anderer eine Zwei-Dri�el-Mehrheit, so schickt
er mit dem Mutex-Paket eine Yield-Nachricht, worau�in alle Manager ihn von der
Queue löschen und wieder hinten anstellen und so agieren als wäre es ein erneuter
Request. Dadurch wird verhindert, dass sich zwei oder mehrere Schreibrechtswünsche gegenseitig blockieren.
Wenn der Peer nun das Schreibrecht erlangt hat, sollte er zunächst Manager
nach der aktuellen Fassung der Ressource bi�en, so er nicht selber Manager ist,
und damit automatisch über die aktuelle Version verfügt. Danach kann er nun die
Ressource entsprechend verändern und, wenn dies geschehen ist, an alle Manager
mit einem Resource-Paket übermi�eln. Die Manager werden diese Ressource zunächst nicht sofort speichern. Vielmehr werden einige eine Anfrage an den Knoten
schicken, der die Ressource gelockt hat. Dieses Validation-Request-Paket, siehe
Abbildung 6.13, enthält in diesem Fall neben dem Absender im Feld „from" die
Felder „node" und „hash". Dabei enthält „node" die ID des vermeintlichen Senders
und „hash" enthält einen Hashwert auf die Ressource. Diese Angaben überprü�
der Peer auf Korrektheit und übermi�elt das Ergebnis mit dem Validation-Paket,
siehe Abbildung 6.14, an alle Manager. Wenn mindestens zwei Dri�el aller Anfragen positiv beantwortet wurden, wird diese neue Version von allen Managern als
die aktuelle übernommen. Die Korrektheit wird bestätigt, indem das Feld „hash"
auf „yes" gesetzt wird, „no" würde eine Inkorrektheit bedeuten. Damit ein Peer, der
das Schreibrecht hat und abstürzt, nicht das gesamte System behindert, gilt dieses
Schreibrecht nur für 20 Sekunden.
58
<DSM-PacketType>
<mutex_response>
<from>
urn:jxta:uuid-59616255646162614868
74AC503250AB85B70D93F26A4009B0577A
90B963F4C603
</from>
<access_to>
urn:jxta:uuid-59616255646162614868
74AC503250AB85B70D93F26A4009B0577A
90B963F4C603
</access_to>
</mutex_response>
</DSM-PacketType>
Abbildung 6.12: Das Mutex-Response-Paket
<DSM-PacketType>
<validation_request>
<from>
urn:jxta:uuid-59616255646162614868
74AC503250AB85B70D93F26A4009B0577A
90B963F4C603
</from>
<node>yes</node>
</validation_request>
</DSM-PacketType>
Abbildung: 6.13: Das Validation-Request-Paket
59
<DSM-PacketType>
<validation>
<from>
urn:jxta:uuid-59616255646162614868
74AC503250AB85B70D93F26A4009B0577A
90B963F4C603
</from>
</validation>
</DSM-PacketType>
Abbildung 6.14: Das Validation-Paket
Nachdem die Ressource erfolgreich verändert wurde, gibt der Peer nun sein
Schreibrecht auf. Dies geschieht durch eine Mutex-Nachricht an alle Manager,
wobei das Feld „release" seine ID enthält. Empfangen die Manager diese Nachricht,
geben sie die Ressource noch nicht frei. Einige Manager werden dem Peer ein Validation-Request-Paket schicken, um die Echtheit der Nachricht zu überprüfen. Dabei wird analog zum Verfahren des Speicherns vorgegangen, sta� des Feldes „hash"
wird nun aber das Feld „release" genutzt.
<DSM-PacketType>
<error>
<from>
urn:jxta:uuid-59616255646162614868
74AC503250AB85B70D93F26A4009B0577A
90B963F4C603
</from>
<node>
urn:jxta:uuid-77616228AA6BC2004854
787C5A52522B88470D93F26A4010B807A7
95E96309D303
</node>
</error>
</DSM-PacketType>
Abbildung 6.15: Das Error-Paket
Will der Peer die Gruppe verlassen, so gibt er dies mit dem Bye-Paket bekannt,
dabei wird der Status auf „group" gesetzt. Hin und wieder kann es vorkommen,
dass ein Peer ohne diese Nachricht verschicken zu können, die Gruppe verlässt.
60
Damit die Zähler für die Gruppengröße auch sinken können, wenn dies der Fall
ist, verschicken Peers eine Error-Nachricht, siehe Abbildung 6.15, an alle Manager,
wenn ein Peer nach einer gewissen Zeit nicht auf eine Anfrage geantwortet hat.
Zudem kann es passieren, dass nach einer Zeit lang Inaktivität, ein Peer feststellen
muss, dass alle seine Manager in der Liste nicht mehr erreichbar sind. In diesem
Fall schickt er ein Manager-Request-Paket, siehe Abbildung 6.16, an alle Manager,
welche ihm darau�in wie auf ein Hello-Paket antworten, nur dass sie ihrerseits
keine Zähler verändern.
<DSM-PacketType>
<manager_request>
<from>
urn:jxta:uuid-59616255646162614868
74AC503250AB85B70D93F26A4009B0577A
90B963F4C603
</from>
</manager_request>
</DSM-PacketType>
Abbildung 6.16: Das Manager-Request-Paket
6.5 Alternative Lösungen
Neben der hier vorgestellten Integrationsmöglichkeit bieten sich andere Lösungen
an, wenn bestimmte Anforderungen an MagicMap gestellt werden. Durch den
hohen Zeitaufwand für Schreibvorgänge in Daedalus kann es sinnvoll sein, Daten, die nur punktuell oder für eine sehr kurze Zeitspanne relevant sind, nicht zu
speichern sondern an die Empfängerknoten direkt zu versenden. Für MagicMap
kommt dies beispielsweise für die Signalstärkemessungen in Frage, die zum einen
nur bis zur nächsten Messung Gültigkeit haben und die darüber hinaus nur für
eine sehr kleine Zahl von Knoten relevant sind, sodass ein direktes Versenden der
Daten performanter erfolgen kann.
Der Nachteil einer solchen Lösung besteht darin, dass Knoten, die neu hinzukommen eine Zeit lang warten müssen, ehe sie Daten erhalten können. Wird die
Aktualisierungsfrequenz jedoch so erhöht, dass die Zeit, die ein Knoten zur Erlangung eines Datenobjektes in Daedalus benötigt, vergleichbar ist, verschwindet
dieser Nachteil. Eine solch hohe Updatefrequenz ist jedoch kaum von Daedalus
leistbar, sodass hier eine Verteilungslösung zwingend wird.
61
In diesen Fällen wird ein Speichersystem wie Daedalus jedoch nicht überflüssig.
Sta�dessen übernimmt es in diesem Szenario das Speichern der nötigen Verwaltungsinformationen. Denkbar wäre es, dass alle Berechnungsknoten, die sich für
die Messerwerte eines bestimmten Knotens interessieren, dies in einem DaedalusDatenobjekt veröffentlichen. Somit kann jeder Knoten die Messwerte an genau die
Knoten schicken, die sie gegenwärtig benötigen.
Neben den Positionsdaten können noch weitere, für MagicMap wichtige, Daten gespeichert werden. In manchen Fällen kann es wünschenswert sein, dass
bei Erreichen einer bestimmten Position oder beim Verlassen eines Gebietes eine
Nachricht versendet wird. So könnte Alarm gegeben werden, wenn ein autonomes
Fahrzeug den Arbeitsbereich verlässt. Die Information, welcher Knoten zu welchen Bedingungen informiert werden soll, kann dabei als Datenobjekt in Daedalus
gespeichert und von anderen Knoten ausgewertet werden. Dadurch, dass diese
Information nicht statisch bei einigen Knoten konfiguriert wurde, ist es möglich,
kurzfristig und ohne großen Aufwand andere Überwachungen zu veranlassen.
Neben einer solchen, auf Daedalus basierenden Lösung, ist es auch denkbar, alle
Daten in MagicMap direkt zu versenden. Diese Lösung kann in einigen Fällen am
performantesten sein, jedoch erfordert sie, dass die Konfiguration weitestgehend
konstant bleibt. In geschlossenen Szenarien, wo dies der Fall und die Performanz
das wichtigste Kriterium ist, ist ein Verzicht auf Daedalus oder andere Shared-Memory-Systeme sinnvoll.
Schließlich bleibt die jetzige Situation, ein zentraler Server, als Option weiter erhalten. Diese Variante ist, so der Server ausreichend performant ist, die schnellste
Lösung. Sie erfordert darüber hinaus weniger Leistung von den mobilen Knoten,
als es verteilte Lösungen können. Der Nachteil liegt hierbei in der Unflexibilität.
Neue Knoten können schnell zu einer Überlast des Server führen, und damit die
Performanz verschlechtern oder hohe Kosten verursachen, wenn ein neuer Server
benötigt wird.
Die Möglichkeiten zeigen, dass hierbei ein Kompromiss zwischen Flexibilität
und der Performanz gefunden werden muss. Je flexibler die Lösung gestaltet werden muss, desto mehr Rollen übernimmt ein verteiltes Speicher-System was zu
einem Verlust an Performanz führt. Je mehr über das Szenario bekannt ist, in dem
MagicMap eingesetzt werden soll, desto einfacher kann eine spezielle Lösung für
genau dieses Szenario entworfen werden, das eine hohe Performanz bietet. Ist dieses Wissen jedoch nicht vorhanden, bietet sich Daedalus als Datenspeicher für die
Selbstkonfiguration der Knoten an.
62
7 Zusammenfassung und Ausblick
Ziel dieser Arbeit war der Entwurf eines Peer-to-Peer-Shared-Memory-Systems
für Ubiquitous-Computing. Anders als bei bisherigen Peer-to-Peer-Shared-Memory-Systemen erforderte dies auf die besonderen Bedingungen von mobilen
und eingebe�eten Geräten Rücksicht zu nehmen. Jedes Peer-to-Peer-System stellt
bereits einen Kompromiss zwischen Zuverlässigkeit und Performanz dar. In diesem Fall kommt nun eine weitere Komponente hinzu, das Sparen von Ressourcen.
Dabei ist es nicht notwendigerweise so, dass alle Geräte über die gleiche Beschränkung der Ressourcen verfügen. Diesen Umstand macht sich Daedalus zunutze, indem die teilnehmenden Geräte in verschiedene Klassen unterteilt werden, anhand
deren ihre Ressourcen genutzt werden.
Aufgrund der Klasseneinteilung kann Daedalus jedem Knoten gerade soviel
Ressourcen abverlangen, dass das System funktionieren kann, ohne dabei die
Ressourcen leistungsschwacher Geräte zu überfordern. So reicht die Bandbreite
der möglichen Beteiligungsformen von einem reinen On-Demand-Verhalten bis
hin zu einer Belastung, die vergleichbar mit der Belastungherkömmlicher Peerto-Peer-Systeme ist. Daedalus ist folglich nicht ausschließlich ein System für Ubiquitous-Computing, es eignet sich ebenso für gewöhnliche Netzwerkstrukturen.
Dazu nimmt jeder Knoten einer Gruppe eine bestimmte Rolle ein, entweder agiert
er aktiv als Manager oder passiv als regulärer Knoten. Je leistungsfähiger ein Knoten ist, desto höher ist die Wahrscheinlichkeit, dass dieser Knoten eine aktive Rolle
übernimmt.
Neben der Einteilung der Knoten in Klassen basiert Daedalus auf zwei weiteren
Ideen. Zum einen der Gruppenstruktur und zum anderen dem stochastischen Locking. Jedes Datenobjekt ist genau einer Gruppe zugeordnet, die es speichert und
verwaltet. Alle Knoten, die sich für dieses Datenobjekt interessieren, sind Mitglied
in der Gruppe und nehmen je nach Leistungsklasse Verwaltungsaufgaben wahr
oder agieren als Klient. Durch diese Unterteilung wird der Verwaltungs-Overhead
reduziert. Die Last eines einzelnen Knotens ist nun nicht mehr von der Anzahl der
Knoten im gesamten Daedalus-System abhängig, sondern einzig von der Zahl der
Knoten in einer spezifischen Gruppe.
Das stochastische Locking verhindert, dass durch gleichzeitige Schreibzugriffe
Inkonsistenzen entstehen. Eine Locking-Anforderung wird hierbei nicht von allen
Replikas beantwortet, sondern nur von einem kleinen Teil. Zudem ist es nicht nötig, dass alle Antworten auf diese Anfrage positiv ausfallen, eine Mehrheit genügt,
um ein Datenobjekt zu sperren. Dabei stellt dieser Ansatz einen Kompromiss
zwischen einem pessimistischen Ansatz, wie er etwa in Form des Lockings in
Server-orientierten Distributed-Shared-Memory-Systemen zum Einsatz kommt,
und einem optimistischen Ansatz, der nachträglichen Conflict-Resolution, das in
einigen Peer-to-Peer-Shared-Memory-Systemen eingesetzt wird, dar.
63
Es zeigt sich, dass trotz des Au�aus auf einfache, unzuverlässige und ressourcenarme Geräte eine vergleichsweise hohe Verfügbarkeit erreicht werden kann,
ohne die Performanz und die Skalierbarkeit zu stark zu beschränken. Dennoch
eignet sich Daedalus weniger für besonders zeitkritische Anwendungen. So benötigt das Verändern eines Datenobjektes im Durchschni� 4 Sekunden, eine hohe
Responsivität ist hingegen erst erreichbar, wenn dafür 7 Sekunden zur Verfügung
stehen. In kleinen Gruppen kann dieser Wert jedoch deutlich unterschri�en werden und in größeren Gruppen nimmt er nicht zu.
Durch die Zuweisung von verschiedenen Rollen an einzelne Knoten einer Gruppe ist es möglich, die Last von ressourcenarmen Geräten konstant zu halten, und
somit unabhängig von der Gruppengröße. Die Last hängt nur von der Aktivität
dieses Gerätes ab. Im Gegenzug dazu steigt die Last der Manager, also der Knoten,
die über mehr Ressourcen verfügen, linear mit der Zahl der Gruppenmitglieder
an. Anders als bei einigen anderen Lösungen ist sie aber unabhängig von der Zahl
der Knoten im gesamten Netzwerk. Die Last, die durch den Nachrichtenverkehr in
einer Gruppe entsteht, steigt dagegen sehr schnell, nämlich quadratisch, an. Da in
den meisten Szenarien die Netzwerkinfrastruktur jedoch gut ausgebaut ist, stellt
dies einen akzeptablen Kompromiss dar. Schließlich wird durch die eindeutige
Zuordnung von Gruppe und Datenobjekt die Gruppengröße in den meisten Fällen
klein sein, und nur in wenigen Ausnahmefällen auf tausend oder mehr Knoten
ansteigen.
Die Einbindung in MagicMap hat gezeigt, dass ein sorgsames Clustering der
Daten nötig ist, wenn Daedalus effizient arbeiten soll. Um den Overhead zu reduzieren, der durch die Verwaltung der Datenobjekte entsteht, ist es nötig, verschiedene Daten in einem Datenobjekt zusammenzufassen. Darüber hinaus muss dafür
Sorge getragen werden, dass zeitkritische Abläufe nicht durch Daedalus behindert
werden. So war es nötig, die Zahl der schreibend auf ein Datenobjekt zugreifenden
Knoten zu reduzieren. Daedalus bietet neben einem höheren Maß an Flexibilität
für MagicMap-Szenarien eine deutlich bessere Skalierbarkeit als der bisherige Server. Da der Server für alle MagicMap-Knoten zuständig ist, steigt seine Last mit
jedem neuen Knoten an. Die Last eines Daedalus-MagicMap-Knotens hingegen
nimmt nicht zu, wenn neue Knoten hinzukommen.
Neben MagicMap bieten sich noch eine Reihe von weiteren Einsatzmöglichkeiten für Daedalus an. Applikationen, die es Arbeitsgruppen ermöglichen zusammenzuarbeiten, können ihre Daten in Daedalus speichern und somit mobilen
Nutzern zugänglich machen, ohne in eine Serverinfrastruktur zu investieren.
OpenSource-Projekte, wie Wikipedia, können dieses System nutzen, wenn sie keine finanziellen Mi�el zum Betrieb eigener Server haben. In Katastrophengebieten,
ohne Infrastruktur, kann Daedalus zum Austausch von Nachrichten und Statusinformationen dienen, um etwa jedem Helfer einen Überblick zu bieten.
Daedalus bietet keinen Datenschutz und nur ein geringes Maß an Datenpersis-
64
tenz. Die Persistenz der Daten kann nur für stabile, große oder langsam schrumpfende Gruppen gewährleistet werden. Sinkt die Gruppengröße zu schnell, ist es
nicht möglich das Datenobjekt auf andere Knoten zu kopieren. Ist eine Gruppe
einmal leer, geht auch das dazugehörige Datenobjekt verloren.
Um auch einen Schutz der Daten vor unrechtmäßigen Zugriffen zu schützen,
sind mehrere Wege denkbar. So könnten die Daten auf Applikationsebene verschlüsselt werden, wodurch jedoch keine Sabotage der Daten verhindert werden
kann. Auf der Basis von JXTA ist es denkbar, Beschränkungen auf Gruppeneintritte zu legen, dieses würde jedoch einen möglichen Verlust der Datenpersistenz zur
Folge haben.
65
8. Literaturverzeichnis
[1]
K. ABERER, A. DATTA, M. HAUSWIRTH und R. SCHMIDT: Das P-Grid-Overlay-
[2]
G. ANTONIU, L. BOUGÉ und M. JAN: JuxMem: An Adaptive Supportive
[3]
G. ANTONIU, L. BOUGÉ und M. JAN: JuxMem: Weaving together the P2P and
[4]
G. ANTONIU, J.-F. DEVERGE und S. MONNET: Building Fault-Tolerant
[5]
G. ANTONIU, P. HATCHER, M. JAN UND D. NOBLET: Performance Evaluation
of JXTA Communication Layers, in: Proc. Workshop on Global and
Peer-to-Peer Computing (GP2PC 2005), Cardiff, UK, May 2005.
[6]
F. BAGCI, J. PETZOLD, W. TRUMLER und TH. UNGERER: Ubiquitous Mobile
[7]
M. Barborak, A. Dahbura, and M. Malek: The Consensus Problem in FaultTolerant Computing, in: ACM Computing Surveys, Vol. 25, No. 2,
171-220, June 1993
[8]
ROBERT BECKER, FRANZISKA LIEBSCH, YANN-RUDOLF MICHEL und DANIEL
MÜLLER: JXTA: Einführung und Überblick, unveröffentlicht,
Netzwerk: Von einem einfachen Prinzip zu einem komplexen
System, in: Datenbank Spektrum, 5. Jahrgang, He� 13, Mai 2005.
Platform for Data Sharing on the Grid, in: Journal of Parallel and
Distributed Computing Practices, 2005.
DSM paradigms to enable a Grid Data-sharing Service, in: Kluwer
Journal of Supercomputing, 2005.
Consistency Protocols for an Adaptive Grid Data-Sharing Service,
in: Proceedings ACM Workshop on Adaptive Grid Middleware
(AGridM 2004), Antibes Juan-les-Pins, France, September 2004.
Agent System in a P2P-Network, in: UbiSys-Workshop at the Fi�h
Annual Conference on Ubiquitous Computing, Sea�le, Oktober 2003.
Seminararbeit, Freie Universität Berlin 2004.
[9]
c’t: h�p://www.heise.de/ct/
[10] MIGUEL CASTRO und BARBARA LISKOV, Practical Byzantine Fault Tolerance,
in: Proceedings of the Third Symposium on Operating Systems
Design and Implementation, New Orleans, USA, Februar 1999.
66
[11] JOSH CATES, Robust and Efficient Data Management for a Distributed Hash
Table, unveröffentlicht, Master’s thesis, Massachuse�s Institute of
Technology, 2003.
[12] Chord: h�p://pdos.csail.mit.edu/chord/
[13] IAN CLARKE, OSKAR SANDBERG, BRANDON WILEY und THEODORE W. HONG:
Freenet: A Distributed Anonymous Information Storage and
Retrieval System, in: Lecture Notes in Computer Science Bd. 2009
S. 46 ff, 2001.
[14] ANWITAMAN DATTA, MANFRED HAUSWIRTH und KARL ABERER: Updates
in Highly Unreliable, Replicated Peer-to-Peer Systems, in:
Proceedings of the 23rd International Conference on Distributed
Computing Systems, ICDCS2003, 2003.
[15] Freenet: h�p://freenet.sourceforge.net/
[16] EMIR HALEPOVIC UND RALPH DETERS: JXTA Performace Study, in: IEEE Pacific
Rim Conference on Communications, Computers and Signal
Processing (PACRIM ’03), Victoria, B.C., Canada: IEEE Computer
Society, Aug. 2003, pp. 149–154.
[17] Heise Online: h�p://www.heise.de/
[18] TOBIAS HÜBNER und MARTIN SCHWEIGERT: WLAN-basierte Ortung mit
MagicMap, unveröffenticht, Studienarbeit, Humboldt-Universität
zu Berlin 2005.
[19] PETER K. IBACH, TOBIAS HÜBNER und MARTIN SCHWEIGERT, MagicMap–
Kooperative Positionsbestimmung über WLAN, Chaos
Communication Congress, Berlin, 27.-29. Dezember 2004.
[20] ICQ: h�p://www.icq.net
[21] Ivy: h�p://pdos.csail.mit.edu/ivy/
[22] A. M. JOHNSON UND M. MALEK: Survey of So�ware Tools for Evaluating
Reliability, Availability, and Serviceability, in: ACM Computing
Surveys, 20 (4), 227-269, December 1988; translated and reprinted in
Japanese, Kyoritsu Shuppan Co., Ltd., publisher, 1990
[23] JuxMem: h�p://juxmem.gforge.inria.fr/
67
[24] JXTA: h�p://www.jxta.org/
[25] JXTA-Bench Projekt: h�p://bench.jxta.org/
[26] JXTA Protocol Specifications Project. Project JXTA v2.3.x: Protocol
specification. Technical report, April 2005. h�p://spec.jxta.org/.
[27] Kazaa: h�p://www.kazaa.com/
[28] JOHN D. KUBIATOWICZ: Extracting Guarantees from Chaos, in:
Communications of the ACM, Bd. 46, Nr. 2, Februar 2003.
[29] JOHN KUBIATOWICZ, DAVID BINDEL, YAN CHEN, STEVEN CZERWINSKI,
PATRICK EATON, DENNIS GEELS, RAMAKRISHNA GUMMADI, SEAN RHEA,
HAKIM WEATHERSPOON, WESTLEY WEIMER, CHRIS WELLS und BEN
ZHAO: OceanStore: An Architecture for Global-Scale Persistent
Storage, in: Proceedings of the Ninth international Conference on
Architectural Support for Programming Languages and Operating
Systems (ASPLOS 2000), November 2000.
[30] JOHN KUBIATOWICZ, DAVID BINDEL, YAN CHEN, PATRICK EATON, DENNIS GEELS,
RAMAKRISHNA GUMMADI, SEAN RHEA, HAKIM WEATHERSPOON, WESTLEY
WEIMER, CHRIS WELLS und BEN ZHAO: OceanStore: An Extremely
Wide-Area Storage System, in: U.C. Berkeley Technical Report UCB//
CSD-00-1102, März 1999.
[31] Jean-Claude Laprie und Karama Kanoun: So�ware Reliability and System
Reliability, in Michael R. Lyu: So�ware Reliability Engineering.
New York 1995: 27-69
[32] S.D.LIN, Q. LIAN, M. CHEN und Z. ZHANG: A Practical Distributed Mutual
Exclusion Protocol in Dynamic Peer-to-Peer Systems, in: IPTPS04,
2004.
[33] S. LODHA und A. D. KSHEMKALYANI: A Fair Distributed Mutual Exclusion
Algorithm, in: IEEE Transactions on Parallel and Distributed
Systems, Bd. 11(6), S. 537-549, Juni 2000.
[34] MagicMap: h�p://www.informatik.hu-berlin.de/rok/MagicMap/
[35] Miroslaw Malek: Folien zu Dependability and Responsiveness Concepts,
Measures and Models, In: Vorlesung Zuverlässige Systeme,
Humboldt-Universität zu Berlin. Wintersemester 2002/2003
68
[36] MIROSLAW MALEK: Introduction to NOMADS, in: Computing Frontiers
2004, Ischia, Italy, April 2004.
[37] A. MAUTHE UND D. HUTCHISON, Peer-to-Peer Computing: Systems, Concepts
and Characteristics, in: Praxis in der Informationsverarbeitung &
Kommunikation (PIK) Special Issue on Peer-to-Peer, 26(03/03), 2003.
[38] N. MILANOVIC, J. RICHLING, M. MALEK: Lightweight Services for Embedded
Systems, in: Proceedings of the 2nd IEEE Workshop on So�ware
Technologies for Embedded and Ubiquitous Computing Systems
(WSTFEUS 2004), Vienna, Austria, 2004.
[39] ATHICHA MUTHITACHAROEN, ROBERT MORRIS, THOMER GIL und BENJIE CHEN:
Ivy: A Read/Write Peer-to-peer File System, in: Proceedings of the 5th
USENIX Symposium on Operating Systems Design and
Implementation (OSDI ’02), 2002.
[40] Napster: h�p://www.napster.com/
[41] OceanStore: h�p://oceanstore.cs.berkeley.edu/
[42] P-Grid: h�p://www.p-grid.org/
[43] SEAN RHEA, PATRICK EATON, DENNIS GEELS, HAKIM WEATHERSPOON, BEN ZHAO
und JOHN KUBIATOWICZ: Pond: the OceanStore Prototype, in:
Proceedings of the 2nd USENIX Conference on File and Storage
Technologies (FAST ’03), März 2003.
[44] STEFAN SAROIU, P. KRISHNA GUMMADI und STEVEN D. GRIBBLE: A
Measurement Study of Peer-to-Peer File Sharing Systems, in:
Proceedings of Multimedia Computing and Networking 2002
(MMCN’02), Januar 2002.
[45] Seti@home: h�p://setiathome.ssl.berkeley.edu/
[46] BUJOR D. SILAGHI: Replication Techniques for Peer-to-Peer Networks,
unveröffentlicht, Dissertation, University of Maryland 2003.
[47] Slashdot: h�p://slashdot.org/
[48] ION STOICA, ROBERT MORRIS, DAVID LIBEN-NOWELL, DAVID KARGER, M. FRANS
KAASHOEK, FRANK DABEK und HARI BALAKRISHNAN: Chord: A Scalable
Peer-to-peer Lookup Service for Internet Applications, in: IEEE
Transactions on Networking Bd. 11, Februar 2003.
69
[49] Tapestry: h�p://www.cs.ucsb.edu/~ravenben/tapestry/
[50] Ma�hias Werner: Responsivität: Ein konsensbasierter Ansatz. Magdeburg
2000
[51] Wikipedia: h�p://www.wikipedia.de/
[52] ZHENG ZHANG: The Power of DHT as a Logical Space, in: �dcs, Bd. 00,
S. 325-331, Oktober 2004.
[53] BEN Y. ZHAO, LING HUANG, JEREMY STRIBLING, SEAN C. RHEA, ANTHONY D.
JOSEPH und JOHN D. KUBIATOWICZ, Tapestry: A Resilient Globalscale Overlay for Service Deployment, in: IEEE Journal on Selected
Areas in Communications, Bd. 22, S. 41-53, Januar 2004.
70
Erklärung
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig und ohne unerlaubte Hilfe verfasst habe. Alle verwendeten Quellen und Hilfsmi�el sind als
solche aufgeführt.
Darüber hinaus erkläre ich hiermit mein Einverständnis, dass die vorliegende
Arbeit in der Bibliothek des Instituts für Informatik der Humboldt-Universität zu
Berlin ausgestellt werden darf.
Berlin, den 29. November 2005
Christian Keller
71

Daedalus – Ein P2P-Shared-Memory- System für

Transcription

Similar documents

Wegweiser über türkische Medien

Soziale Ungleichheit und sozialer Wandel Soziale Neue

Ok - MANZ

alfsa - BFKDO Tulln

Erfolgsfaktor It

Microsoft Management Console

20 pcnews—122

die Rolle öffentlich-RechtlicheR Medien iM inteRnet

Neue Maßstäbe für serverless Backup Bessere

Inhaltsanalyse des Spiels "Age of Empires II: The Age of Kings "

12_04_Erste Schritte mit Ubuntu 12.04