Transaktionaler Schutz für Wartungsoperationen in

Transaktionaler Schutz für
Wartungsoperationen
in Overlaynetzen
Diplomarbeit
von
cand. inform. Jens Pflüger
Universität Karlsruhe
Fakultät für Informatik
Institut für Programmstrukturen und Datenorganisation
Lehrstuhl für Systeme der Informationsverwaltung
Prof. Dr.-Ing. Klemens Böhm
Verantwortlicher Betreuer:
Prof. Dr.-Ing. Klemens Böhm
Betreuender Mitarbeiter:
Dipl.-Inform. Michael Klein
Tag der Anmeldung: 15. Mai 2005
Tag der Abgabe: 14. November 2005
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen
1
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen
Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als
die angegebenen Quellen und Hilfsmittel verwendet habe.
cand. inform. Jens Pflüger
Karlsruhe, 14. November 2005
2
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen
3
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Inhalt
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen
Inhaltsverzeichnis
1
Einführung.........................................................................................................................8
1.1 Hintergrund ................................................................................................................8
1.2 Overlays .....................................................................................................................9
1.3 Projekt-Kontext.........................................................................................................10
1.4 Aufgabenstellung ......................................................................................................11
1.5 Gliederung ................................................................................................................12
2 Grundlagen: Lanes-Overlay .............................................................................................14
2.1 Struktur.....................................................................................................................14
2.2 Operationen ..............................................................................................................16
2.2.1
Strukturaufbau ...................................................................................................16
2.2.2
Strukturwartung .................................................................................................20
2.2.3
Dienste-Management .........................................................................................23
2.2.4
Strukturoptimierung ...........................................................................................26
3 Stand der Forschung ........................................................................................................28
3.1 Problemstellung ........................................................................................................28
3.2 Ansätze in der Literatur.............................................................................................30
3.2.1
Pastry.................................................................................................................30
3.2.2
Bamboo .............................................................................................................32
3.2.3
Chord.................................................................................................................32
3.2.4
CAN (Content Addressable Network) ................................................................33
3.2.5
DynaMO............................................................................................................35
3.2.6
Tapestry.............................................................................................................36
3.2.7
Lanes .................................................................................................................38
3.3 Zusammenfassung ....................................................................................................39
4 Konzeption ......................................................................................................................42
4.1 Gesamtarchitektur .....................................................................................................42
4.2 Commit-Protokoll .....................................................................................................44
4.2.1
Besonderheiten im vorliegenden Anwendungsfall ..............................................44
4.2.2
Commit-Protokoll-Analyse ................................................................................45
4.2.3
Funktionelle Anpassungen .................................................................................50
4.2.4
Netzwerkpartitionierungen .................................................................................52
4.3 Schedule-Protokolle..................................................................................................54
4.3.1
Sequentieller Scheduler ......................................................................................54
4.3.2
Optimistischer Ansatz ........................................................................................54
4.3.3
Vorab-Sperren....................................................................................................55
4.3.4
Zwei-Phasen-Sperren .........................................................................................55
4.3.5
Zeitstempel-Verfahren .......................................................................................56
4
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Inhalt
4.3.6
Scheduler ohne Schutz .......................................................................................56
4.4 Sperrenverwaltung ....................................................................................................56
4.4.1
Verklemmungsvermeidung ................................................................................57
4.4.2
Verklemmungserkennung...................................................................................57
4.5 Log-Manager ............................................................................................................58
4.6 Isolation, Transaktionen & Sessions ..........................................................................58
4.7 Zusammenfassung ....................................................................................................60
5 Realisierung.....................................................................................................................62
5.1 DIANEmu ................................................................................................................62
5.1.1
Aufbau des Simulators .......................................................................................62
5.1.2
Implementierung von Protokollen ......................................................................63
5.1.3
Simulation .........................................................................................................63
5.2 Das Wartungstransaktionssystem ..............................................................................64
5.2.1
Transaktionsverwaltung .....................................................................................64
5.2.2
Transaktionslog..................................................................................................68
5.2.3
Scheduler ...........................................................................................................69
5.2.4
Sperren- und Verklemmungsmanagement ..........................................................70
5.2.5
Integration in DIANEmu....................................................................................71
5.3 Implementierung von Lanes & 2PC-Protokoll ...........................................................73
5.3.1
Netzwerkpartitionierungen in Lanes ...................................................................74
5.3.2
Funktionelle Anpassungen des Lanes-Protokolls ................................................74
6 Evaluierung .....................................................................................................................76
6.1 Szenario....................................................................................................................76
6.2 Effektivität................................................................................................................77
6.3 Effizienz ...................................................................................................................78
6.4 Vergleich der Scheduleprotokolle..............................................................................80
6.5 Zusammenfassung ....................................................................................................81
7 Zusammenfassung & Ausblick.........................................................................................82
7.1 Zusammenfassung ....................................................................................................82
7.2 Ausblick ...................................................................................................................83
Anhang ...................................................................................................................................86
A Abkürzungen .................................................................................................................86
B Idee eines spezifischen Lösungsansatzes für Lanes.........................................................87
C Ergänzungen zur Lanes-Spezifikation ............................................................................88
C.1 Strukturinformationen..............................................................................................88
C.2 Methoden ................................................................................................................88
D Ergänzungen zu Pastry, Chord und Tapestry .................................................................93
D.1 Pastry ......................................................................................................................93
D.2 Chord ......................................................................................................................93
D.3 Tapestry ..................................................................................................................94
E Klassen- und Paketübersicht ..........................................................................................96
E.1 Transaktionssystem..................................................................................................96
5
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Inhalt
E.2 Lanes-Protokoll .......................................................................................................98
E.3 Zwei-Phasen-Commit-Protokoll.............................................................................102
E.4 Sonstiges ...............................................................................................................103
F Parameter-Einstellungen...............................................................................................104
F.1 2-Phasen-Commit-Protokoll...................................................................................104
F.2 Lanes-Protokoll......................................................................................................104
Literatur................................................................................................................................106
6
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Inhalt
7
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 1 Einführung
1
1.1
Einführung
Hintergrund
In den letzten Jahren spielen mobile Kommunikationssysteme wegen ihrer Flexibilität eine
immer wichtiger werdende Rolle. Diese Entwicklung kam mit der Einführung von GSM
(Global System for mobile Communications, [1]) im mobilen Funktelefonmarkt ins Rollen.
Mittlerweile hat sich auch WLAN (Wireless LAN (IEEE 802.11), [2]) im Bereich der mobilen
Rechnerkommunikation etabliert. Das heute in der Praxis gängigste Verfahren zur
Unterstützung der Mobilität ist die Verwendung einer möglichst flächendeckenden Infrastruktur
in Form von Funk-Basisstationen. In Zugangspunkt- oder Zellnetzwerken wird über diese festen
Bezugspunkte die Kommunikation abgewickelt. GSM und WLAN funktionieren auf diese
Weise. Der WLAN-Standard spezifiziert darüber hinaus aber bereits einen Kommunikationsmodus, bei dem keine feste Infrastruktur erforderlich ist und die Netzteilnehmer direkt
miteinander kommunizieren können. Diese Kommunikationsform, so genannte mobile Ad-hocNetze (MANETs), ist momentan noch wenig verbreitet und wird höchstens in kleinen Netzen in
sehr begrenzten Rahmen, beispielsweise bei der Vernetzung der Laptops der Teilnehmer einer
Firmensitzung, eingesetzt. Die derzeitige Forschung arbeitet jedoch daran diese Netze auch in
größeren Bereichen, wie zum Beispiel in Innenstädten oder auf dem Universiätscampus,
einsetzen zu können und geeignete Anwendungen für diese Szenarien bereitzustellen.
MANETs zeichnen sich dadurch aus, dass die Kommunikation zwischen den Netzteilnehmern,
im Gegensatz zu beispielsweise GSM, ohne zusätzliche, festinstallierte Infrastrukturkomponenten organisiert wird. Die Geräte müssen daher alle anfallenden Aufgaben, wie das
Routing der Nachrichten, selbst übernehmen. MANETs sind besonders in Bereichen von
Interesse, in denen eine feste Infrastruktur zu teuer, zu unzuverlässig oder überhaupt nicht
verfügbar ist.
Ein Überblick über die genannten und weitere aktuelle mobile Kommunikationstechniken ist in
[3] zu finden.
Die Suche nach Informationen und die Nutzung von Dienstleistungen im Internet sind heute
selbstverständlich. Auch in mobilen Netzen soll der Zugriff auf im Netz vorhandenes Wissen,
auf Dokumente oder Funktionen möglich sein. Wie solche Dienste in Ad-hoc-Netzen
veröffentlicht werden können, wie man sie beschreibt und wie sie von interessierten
Teilnehmern gefunden werden können, steht im Zentrum des Interesses des DIANE-Projekts
[10], in dessen Rahmen auch diese Arbeit entstand und das unten näher beschrieben wird.
DIANE bedeutet Dienste in Ad-hoc-Netzen .
Die Ankündigung von Diensten und deren semantische Suche kann in mobilen Netzen mit
festen Infrastrukturkomponenten relativ einfach mit serverbasierten Verzeichnisstrukturen, wie
sie ähnlich schon lange Zeit im Internet verwendet werden, realisiert werden. Die semantische
Suche nach gewünschten Diensten in MANETs stellt hingegen eine große Herausforderung dar.
Wegen des vollkommen dezentralen Ansatzes sind klassische serverbasierte Dienst8
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 1.2 Overlays
vermittlungstechniken des Internets nicht anwendbar. Fluten von Dienstankündigungs- und
Dienstsuchenachrichten im Netz ist auf Grund der begrenzten Ressourcen der Teilnehmer
ebenfalls nicht geeignet.
Ein gängiges Mittel, um die Nutzung dynamischer Netze seien es drahtlose Ad-hoc-Netze
oder Peer-to-Peer-Netze im Festnetz effizienter zu gestalten, ist die Definition von Overlaystrukturen über diesen Netzen. Overlays definieren logische Nachbarschaftsbeziehungen
zwischen Knoten und ermöglichen es, Nachrichten nicht durch Fluten, sondern gezielter im
Netz zu verbreiten. Im nachfolgenden Abschnitt wird auf grundlegende Ansätze solcher
Overlay-Netze eingegangen.
Bei der Lösung dieser funktionellen Herausforderungen ist jedoch auch zu berücksichtigen, dass
mobile Endgeräte in der Regel nur über begrenzte Ressourcen verfügen. Dazu zählen sowohl
Speicherkapazität und Rechenleistung als auch die verfügbare Batterieenergie. Protokolle im
Bereich von MANETs müssen diesen Limits mit einem sparsamen Ressourcenverbrauch
Rechnung tragen.
1.2
Overlays
Unter einem Overlay-Netz, oder kurz Overlay, versteht man eine logische Netzstruktur, die über
die tatsächliche physische Netzwerktopologie gelegt wird. Somit ist ein Overlay formal eine
Schicht zwischen den unteren Netzwerkschichten des ISO-OSI-Basisreferenzmodells und
dessen höheren benutzerorientierten Schichten. Durch diese Zwischenschicht soll die
funktionelle Lücke zwischen dem unvollkommenen Kommunikationssystem und der vom
Benutzer erwarteten Funktionalität in diesem Fall eine effiziente Dienstsuche verringert
werden. Dieser Mehrwert ist vor allem in den infrastrukturlosen und dynamischen Ad-hocNetzen von Vorteil.
Die Verbindungen in der Overlay-Struktur sind in der Regel Multi-Hop-Verbindungen. Das
bedeutet, dass die Kommunikation benachbarter Knoten im Overlay-Netz über einen Pfad aus
mehreren physischen Verbindungen (1-Hop-Verbindungen) abläuft. Der Ausfall einer
physischen Verbindung muss nicht zwingend den Ausfall der Overlay-Verbindung bedeuten, da
normalerweise mehrere Routen zwischen den benachbarten Overlay-Knoten existieren. Nicht in
jedem Fall ist daher eine Anpassung der Overlay-Struktur erforderlich, sondern es reicht aus,
die physische Route anzupassen.
[3] liefert einen guten Überblick über Overlays zur Dienstfindung und kategorisiert diese. Drei
Dimensionen dieser Einteilung lassen sich dabei unterscheiden:
Aufgeprägte vs. selbstorganisierte Overlays:
Aufgeprägte Overlays sind im Voraus festgelegt und passen sich nicht der
Netzcharakteristik an. Dagegen liegt der Bildung selbstorganisierter Overlays ein Satz
von Regeln oder Strategien zu Grunde, wobei die aktuellen Netzeigenschaften mit
einbezogen werden.
Nachrichtenverteilung vs. Adressabbildung:
Overlays zur Nachrichtenvermittlung beeinflussen das Routing von Nachrichten.
Adressabbildende Overlays dienen hingegen dazu, einen virtuellen Adressraum auf
verfügbare Geräte zu verteilen.
9
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 1.3 Projekt-Kontext
Semantikfreie vs. semantikorientierte Overlays:
Semantikorientierte Overlays berücksichtigen beim Aufbau, welche Dienste angeboten
werden. Semantikfreie Overlays sind dienstunabhängige Strukturen.
Semantikfreie, aufgeprägte Overlays sowohl mit Nachrichtenvermittlung als auch
Adressabbildung spielen in der Praxis die größte Rolle. In diese Kategorie fällt das OverlayNetz Lanes, das im Rahmen von DIANE entwickelt wurde und dessen Aufbau und Funktion
später noch detailliert beschrieben wird. Auch weitere Overlay-Netze, die zur Ankündigung und
Suche von Diensten genutzt werden können, werden im weiteren Verlauf vorgestellt.
1.3
Projekt-Kontext
Diese Arbeit ist Teil des DIANE-Projekts (Dienste in Ad-hoc-Netzen, [10]) im Rahmen des
Schwerpunktprogramms 1140 der DFG. Die Ziele von DIANE sind die Entwicklung und
Evaluierung von Konzepten zur effizienten Bereitstellung und Nutzung von Diensten in
mobilen Ad-hoc-Netzen (MANETs). Ein mögliches Anwendungsszenario könnte hierbei ein
universitäres Ad-hoc-Netz zur Unterstützung der Prüfungsvorbereitungen von Studenten sein.
Die Entwicklung eines solchen Gesamtsystems erfordert die gleichzeitige Lösung vieler
Teilproblemstellungen. Abbildung 1-1 liefert einen Überblick dieser im Rahmen von DIANE
anfallenden Aufgaben.
M
O
T
I
V
A
T
I
O
N
(Semantische) Dienstbeschreibung
(Dezentrale) Dienstsuche
(Effiziente) Dienstausführung
Transparente Dienstkombination
S
I
M
U
L
A
T
I
O
N
Abbildung 1-1: Ziele von DIANE
Diese Arbeit beschäftigt sich im Wesentlichen mit der Suche nach Diensten und den dafür
notwendigen Mechanismen. Diese Suche muss sowohl verteilt als auch effizient erfolgen, da in
Ad-hoc-Netzen weder eine zentrale Dienstverwaltung noch hohe Ressourcenkapazitäten zur
Verfügung stehen. Overlay-Strukturen bieten ein effizientes Mittel zum Auffinden von
Diensten. DIANE verfolgt hier zwei Ansätze. Semantische Overlays, wie zum eispiel
Dienstringe [14], gruppieren die angebotenen Dienste auf Grund ihrer semantischen
Ähnlichkeiten. Alternativ hierzu existieren Overlays, wie das in dieser Arbeit verwendete
Lanes-Overlay [12], die von der Semantik der angebotenen Dienste abstrahieren.
Weitere Aufgabenbereiche in DIANE sind die Entwicklung einer ausdrucksstarken und zugleich
automatisch vergleichbaren Dienstbeschreibung, die Schaffung von Anreizen zur Bereitstellung
und Erbringung von Diensten, eine effiziente Dienstausführung und das Ermöglichen von
Dienstkombinationen. Für die Evaluation der Ergebnisse wurde speziell für DIANE der
Simulator DIANEmu [11] entwickelt.
10
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 1.4 Aufgabenstellung
1.4
Aufgabenstellung
Allen Overlay-Strukturen gemeinsam ist, dass sie gewartet werden müssen: Knoten kommen
hinzu und verlassen das Netz. Dadurch ändern sich die physischen Nachbarschaftsbeziehungen,
Informationen müssen übergeben werden, usw. Insbesondere in Ad-hoc-Netzen, deren
Teilnehmer sich bewegen und häufig ein- und ausgeschaltet werden, kommt die Notwendigkeit
zur fortlaufenden Anpassung an die zu Grunde liegende Topologie hinzu.
Es ist relativ einfach, sich für jedes dieser Probleme geeignete Mechanismen zu überlegen
schwierig ist es hingegen, sicherzustellen, dass diese Mechanismen nicht nur alleine korrekt
ablaufen, sondern auch dann, wenn es während ihrer Ausführung zu Fehlern kommt oder
mehrere Dinge gleichzeitig geschehen.
A
B
C
D
Abbildung 1-2: Lane mit 4 Knoten
Die prototypische Implementierung des Lanes-Overlays im DIANE-Projekt hat gezeigt, dass
hier eine fehlerfreie Implementierung sehr komplex ist. Lanes strukturiert die Knoten zu
kettenartigen Overlay-Beziehungen (so genannte Lanes). Abbildung 1-2 zeigt eine Lane mit vier
Knoten. Kapitel 2 beschreibt detailliert die Struktur und Algorithmen des Lanes-Overlays.
Ein kurzes Beispiel soll im Folgenden das Problem noch einmal verdeutlichen. Fällt Knoten B
in der in Abbildung 1-2 gezeigten Lane aus, wird ein Reparaturalgorithmus angestoßen, der A
und C miteinander verbindet. Dies ist unkritisch, solange währenddessen keine weiteren
Ereignisse auftreten, die ebenfalls zu Korrekturen führen, zum Beispiel
Auch Knoten C fällt aus. Die von D gestarteten Reparaturmechanismen kollidieren
dann mit denen von A gestarteten.
Währenddessen möchte ein neuer Knoten E in die Lane integriert werden.
Die Lane ist mittlerweile zu kurz und soll mit einer anderen Lane verbunden werden.
Im Rahmen dieser Diplomarbeit soll zunächst untersucht werden, wie andere
Implementierungen von Overlays dieses Problem angehen und wie befriedigend diese Lösungen
sind, insbesondere hinsichtlich der Schwierigkeit, eine korrekte Realisierung zu verwirklichen.
In einem zweiten Schritt soll dann eine möglichst generische Lösung für die korrekte
Abwicklung von Reparatur- und Optimierungsaufgaben in Overlays entwickelt werden.
Ausgangspunkt der Überlegungen ist es dabei, dass diese Aufgaben korrekt ablaufen würden,
wenn sie transaktional geschützt werden. Damit wären sowohl Atomizität (begonnene Aufgaben
werden vollständig oder gar nicht ausgeführt) als auch Isolation (gleichzeitig ablaufende
Aktionen stören sich gegenseitig nicht) und Konsistenz (das Overlay ist nach Ausführung der
Aktionen wieder in einem gültigen Zustand) gewährleistet. Die letzte ACID-Eigenschaft von
Transaktionen die Dauerhaftigkeit spielt in diesem Zusammenhang keine besondere Rolle.
11
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 1.5 Gliederung
1.5
Gliederung
Lanes dient dieser Arbeit als Beispiel für ein Overlay-Netz. Daher wird in Kapitel 2 zunächst
ausführlich die Struktur des Lanes-Overlays sowie die für dessen Aufbau und Erhaltung
erforderlichen Operationen beschrieben.
Kapitel 3 analysiert die Probleme bei parallelen Operationen und deren Ursachen. Es wird ein
Überblick über bekannte Overlay-Peer-to-Peer-Systeme gegeben und deren Funktionsweise
beschrieben. Gleichzeitig wird untersucht, wie diese Systeme die Probleme paralleler
Operationen behandeln bzw. lösen. Außerdem wird am Beispiel von Lanes aufgezeigt, wie
komplex eine protokollindividuelle Lösung ist.
In Kapitel 4 erfolgt die Entwicklung eines Konzepts für ein transaktionales Schutzsystem für
Wartungsoperationen in Overlay-Netzen sowie die Beschreibung der dafür notwendigen
Komponenten.
Kapitel 5 zeigt die softwaretechnische Realisierung dieses Konzepts und des Lanes-Protokolls
im Kontext des Simulators DIANEmu und diskutiert einzelne Implementierungsdetails.
Die Evaluation der Ergebnisse gegenüber einer schutzlosen Lanes-Implementierung und eine
Analyse des zusätzlichen Aufwands erfolgt in Kapitel 6.
Die Arbeit schließt in Kapitel 7 mit einer kurzen Zusammenfassung der erarbeiteten Ergebnisse
und einem Ausblick auf zukünftige Tätigkeiten.
Der Anhang ergänzt die beschriebenen Sachverhalte. Dort sind unter anderem ein
Abkürzungsverzeichnis, ein Überblick über die Implementierung, bei der Evaluation
verwendete Parameter und Ergänzungen zu Lanes zu finden.
12
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 1.5 Gliederung
13
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 2 Grundlagen: Lanes-Overlay
2
Grundlagen: Lanes-Overlay
Diese Arbeit entwickelt einen Schutzmechanismus gegen Fehler durch parallele
Wartungsoperationen in Overlay-Netzen. Als Beispiel für ein Overlay wird Lanes
herangezogen, um die auftretenden Probleme zu analysieren, die Anforderungen an ein solches
Schutzsystem zu bestimmen und die Ergebnisse an einer erweiterten Implementierung von
Lanes im DIANE-Simulator DIANEmu [11] zu testen. Darum ist es sinnvoll in diesem Kapitel
zunächst einen genauen Blick auf Lanes zu werfen.
Lanes [12] ist ein strukturiertes Overlay-Netzwerk, das im Rahmen des DIANE-Projekts
entwickelt wurde. Es ermöglicht eine effiziente Dienstsuche speziell im Bereich mobiler Adhoc-Netze.
Beim Entwurf von Lanes musste untersucht werden, welche Dienstsuche-Mechanismen in
hochdynamischen Netzen am besten geeignet sind. Dabei standen vier Grundarten dieser
Mechanismen zur Auswahl. Der zentralisierte Ansatz, wie er aus der Internet-Welt bekannt ist,
eignet sich kaum für Ad-hoc-Netze. Das Fluten von Nachrichten im gesamten Netzwerk (oder
einem Teil davon) ist die einfachste Methode zur Verbreitung von Dienstangeboten und
Dienstanfragen. Wegen des hohen Nachrichtenaufkommens ist dieses Vorgehen aber nur in
Umgebungen mit einer sehr großen Dynamik sinnvoll. Ziel bei der Entwicklung eines neuen
Dienstsuchemechanismus muss demnach eine gegenüber dem Fluten bessere Effizienz
bezüglich des Nachrichtenaufkommens und/oder des Erfolgs der Suche sein. Interessante
Mechanismen zur Dienstsuche stellen verteilte Hashverfahren und semantisches Routing dar. In
der Lanes-Struktur werden Ideen beider Verfahren kombiniert. Für eine detailliertere
Beschreibung dieser Dienstsuche-Verfahren wird an dieser Stelle auf [12] oder [13] verwiesen.
Jedes strukturierte Overlay-Netz definiert eine logische Struktur, die besonders günstig für die
Realisierung der Aufgabe des Overlays ist, auf der tatsächlich vorhandenen zu Grunde
liegenden Netztopologie. Diese Struktur muss von den beteiligten Netzknoten zunächst
aufgebaut und im weiteren zeitlichen Verlauf auch bei sich ändernden Verhältnissen in der
Netztopologie erhalten und optimiert werden. Hierzu sind Wartungsoperationen erforderlich.
Sowohl die Struktur des Lanes-Overlays als auch die Operationen, die zu deren Wartung
notwendig sind, werden im Folgenden beschrieben.
2.1
Struktur
Die Lanes-Struktur ist über der Transportschicht (4. Schicht des ISO-OSI-Modells [4])
realisiert. Die Lanes-Struktur besteht aus parallelen Bahnen eng gekoppelter Knoten, wovon
sich auch der Name des Protokolls ableitet (lane: engl. Bahn). Jeder Knoten kennt seinen
Vorgänger- und Nachfolgerknoten (sofern vorhanden) und kommuniziert innerhalb der Lane
ausschließlich mit diesen beiden. Die Kommunikation zwischen zwei benachbarten Lanes
erfolgt per Anycast. Anycast ist eine Gruppenkommunikationsform. Die Netzknoten werden zu
Gruppen zusammengefasst und können unter einer gemeinsamen Gruppenadresse angesprochen
14
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 2.1 Struktur
Dienstankündigung
werden. Anders als beim Multicast wird eine Nachricht, die an eine Gruppenadresse gesendet
wurde, nicht an alle Gruppenmitglieder weitergeleitet, sondern nur an ein Mitglied, in der Regel
zu dem, das dem Sender am nächsten liegt. Somit verwaltet jeder Knoten neben den Adressen
von Vorgänger und Nachfolger in der Lane auch die beiden Anycast-Adressen der benachbarten
linken und rechten Lane.
Lane a
Lane b
1
4
Lane c
2
3
any
cast
5
any
cast
8
6
9
7
10
Lane d
any
cast
11
12
Dienstsuche
Abbildung 2-1: Lanes-Struktur (nach [12])
Jede Lane verwaltet einen Teil des Anycast-Adressraums und besitzt zwei Anycast-Adressen
eine rechte und eine linke. Diese Adressen entsprechen dem unteren und oberen Rand des durch
die Lane abgedeckten Bereichs. Die Nachbar-Lanes kennen jeweils nur eine dieser beiden
Adressen, je nachdem, ob sie in der Struktur weiter links oder weiter rechts angeordnet sind.
Die Aufteilung einer Lane aus Optimierungsgründen in zwei neue Lanes ist mit einer
Halbierung des Adressbereichs der ursprünglichen Lane zu vergleichen. Das hat den Vorteil,
dass die äußeren Adressen von dieser Halbierung unberührt bleiben, was bedeutet, dass die
Nachbar-Lanes der ursprünglichen Lane die Nachbar-Anycast-Adressen nicht aktualisieren
müssen. Die Aufteilung einer Lane wird später noch detailliert vorgestellt.
Angebotene Dienste der Mitglieder einer Lane werden nur innerhalb dieser Lane propagiert.
Somit ist jeder Knoten darüber informiert, welche Dienste in seiner Lane angeboten werden. Bei
der Suche nach einem geeigneten Dienst werden zunächst die gespeicherten
Dienstbeschreibungen der eigenen Lane auf Übereinstimmungen überprüft. Zusätzlich wird die
Anfrage an die Nachbar-Lanes weitergegeben. Dies geschieht solange bis keine weitere
Nachbar-Lane mehr existiert.
Durch die Gruppierung von Knoten zu Lanes (und somit auch ihrer Dienstbeschreibungen)
gelingt es der Lanes-Struktur sowohl bei Dienstankündigungen als auch bei der Dienstsuche die
Reichweite gegenüber dem Fluten zu begrenzen. Die Anzahl der für die Suche nötigen
Nachrichten ist auf die Zahl der Lanes beschränkt.
Des Weiteren ist die Lanes-Struktur vollkommen dezentral. Das bedeutet, dass kein Knoten eine
herausragende Rolle bezüglich Funktion oder Aufbau spielt. Lanes ermöglicht außerdem eine
semantische Dienstsuche ohne diese Dienstsemantik für den Aufbau der Overlay-Struktur zu
verwenden. Stattdessen stehen die Dimensionen der Grundstruktur von Lanes für
Dienstankündigung (vertikal) und Dienstsuche (horizontal).
15
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 2.2 Operationen
Lanes stellt den Kompromiss zwischen stark strukturierten Ansätzen mit guten
Benutzungseigenschaften, aber hohen Wartungskosten und schwach strukturierten Netzen mit
geringem Verwaltungsaufwand dar.
2.2
Operationen
Um die Struktur eines Overlays zunächst aufbauen zu können und im weiteren zeitlichen
Verlauf auch bei Änderungen in der zu Grunde liegenden Netztopologie zu erhalten und
gegebenenfalls zu optimieren, sind Wartungsoperationen der Overlay-Mitglieder erforderlich.
Dieser Abschnitt beschreibt die Operationen, die im Lanes-Protokoll definiert sind. Diese
Operationen lassen sich in vier Gruppen einteilen. Zunächst muss die Lanes-Struktur aufgebaut
werden. Dies geschieht durch die Operationen Login und Logoff. Im Laufe der Zeit können
Fehler in der Lanes-Struktur durch Knotenausfälle oder ähnliches entstehen, die durch
regelmäßige Wartung behoben werden müssen. Die dritte Operationsart auf der Struktur einer
Lane sind Optimierungen. Dazu gehört zum Beispiel das Teilen einer Lane, falls deren Größe
ein bestimmtes Maß übersteigt. Die letzte Gruppe von Operationen sind die Funktionen des
Dienstmanagements, die die Lanes-Struktur zum Veröffentlichen oder zur Suche von Diensten
nutzen. In den folgenden Unterkapiteln werden diese Operationsgruppen vorgestellt.
Zur Modellierung der Protokollabläufe werden UML 2.0 Zustandsdiagramme [29] verwendet.
Einige Details sind dabei allerdings in Methodenaufrufen gekapselt. Der Pseudocode dieser
Methoden ist im Anhang C zu finden. Komplexe Zustände, d.h. Zustände, die selbst
umfangreiche Prozeduren in Form ganzer Zustandsdiagramme kapseln, sind durch zwei kleine
ovale Symbole gekennzeichnet (vgl. zum Beispiel den Zustand loggingIn in Abbildung 2-2).
Die Zustandsübergangsdiagramme wurden teilweise in Zusammenarbeit mit Mathias Röhl von
der Universität Rostock erstellt, wo zurzeit ebenfalls an einer Lanes-Implementierung im
dortigen Simulator JAMES [9] gearbeitet wird.
Die im Folgenden beschriebenen Operationen können parallel ausgeführt werden. Daher kann
sich ein Knoten zu einem Zeitpunkt gleichzeitig in mehreren Zuständen befinden.
Beispielsweise ist ein Knoten weiterhin im Zustand loggedIn auch wenn parallel dazu eine
Optimierung der Lanes-Struktur durchgeführt wird. Bei der Betrachtung der Zustandsübergangsdiagramme ist das zu beachten.
2.2.1 Strukturaufbau
Jeder Knoten, der Dienste im Lanes-Overlaynetz anbieten oder nutzen möchte, muss in genau
eine Lane integriert sein. Das Einfügen eines neuen Knotens in eine Lane erfolgt durch den
Login, der durch einen LoginCall des Benutzers angestoßen wird. Der Austritt aus der LanesStruktur erfolgt durch einen Logoff.
Abbildung 2-2 zeigt das grundlegende Verhalten dieses Login-Logoff-Zyklus. Die
Ablaufdetails von Login und Logoff wird durch die komplexen Zustände loggingIn und
loggingOff modelliert.
16
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 2.2 Operationen
Abbildung 2-2: Login/Logoff-Zyklus
Login
Soll ein neuer Knoten in eine Lane integriert werden, muss die Kettenstruktur an einer Stelle
aufgebrochen werden. Die Lanes-Mitglieder an dieser Nahtstelle registrieren den neuen Knoten
als Vorgänger bzw. Nachfolger. Der neue Knoten aktualisiert seinerseits seinen Vorgänger und
Nachfolger. Dadurch wird die Lanes-Kette wieder geschlossen.
Der Login eines neuen Knotens (Initiator) wird durch einen LoginCall des Benutzers
angestoßen. Der betreffende Knoten wechselt in den komplexen Zustand loggingIn, der in
Abbildung 2-3 gezeigt wird. Abbildung 2-4 und Abbildung 2-5 zeigen den Login-Vorgang aus
Sicht der beiden beteiligten Lane-Mitglieder. Der Initiator sendet eine LoginRequest-Nachricht
(beinhaltet die Adresse des Knotens) an alle über einen Hop erreichbaren Knoten (Broadcast).
Abbildung 2-3: Login-Details (Initiator)
17
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 2.2 Operationen
Empfängt ein Mitglied einer Lane diesen Request, antwortet es mit einem LoginOffer-Angebot,
sofern ein Login an dieser Stelle möglich bzw. gewünscht wird (vgl. Methode acceptRequest()).
Beispielsweise kann die maximale Lane-Größe erreicht sein, sodass weitere Logins abgelehnt
werden. Die LoginOffer-Nachricht beinhaltet die Adressen des Lane-Mitglieds und seines
Nachfolgers sowie ggf. weitere Statusangaben (z.B. Lane-Länge).
Der Initiator sammelt die Angebote für eine bestimmte Zeit (vgl. Zustand WaitForOffers). Nach
Ablauf dieser Zeit wählt er das für sich günstigste Angebot aus (vgl. Methode
chooseBestOffer()), sendet eine LoginAccept-Nachricht an den Knoten, der das Angebot
gemacht hat (Reaktor1), und wartet auf dessen Antwort.
Als Heuristik für die Auswahl des geeignetsten Angebots ist Verschiedenes denkbar. Zum
Beispiel werden Angebote von Knoten bevorzugt, deren Nachfolger ebenfalls ein LoginOffer
gesendet haben. Eine Alternative wäre die Wahl der kürzesten Lane, falls mehrere zur Auswahl
stehen, um die Lane-Größen so gering wie möglich zu halten.
Abbildung 2-4: Login-Details (Reaktor 1)
Für den Fall, dass der neue Knoten keine Antwort auf seinen LoginRequest erhält, startet er eine
neue Lane.
Nach Erhalt einer LoginAccept-Nachricht informiert das Lane-Mitglied (Reaktor 1) zunächst
seinen Nachfolger (Reaktor 2) mit einer LoginInformation-Nachricht (enthält die Adresse des
neuen Knotens) über den neuen Knoten.
Abbildung 2-5: Login-Details (Reaktor 2)
18
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 2.2 Operationen
Der Nachfolger bestätigt per LoginInformationConfirmation-Nachricht und ändert daraufhin
seinen Verweis auf den Vorgänger. Sobald Reaktor 1 die Bestätigung erhalten hat, sendet er
eine LoginConfirmation-Nachricht (beinhaltet die Adressen beider Nachbarn des neuen
Knotens) an den Initiator und ändert den Verweis auf seinen Nachfolger. Der neue Knoten setzt
die Adressen der Nachbarn auf die übermittelten Werte und ist damit Mitglied der Lane.
Logoff
Tritt ein Lanes-Mitglied aus der Struktur aus entsteht eine Lücke in der Kette, die wieder
geschlossen werden muss. Vorgänger und Nachfolger des die Lane verlassenden Knotens
müssen ihre Nachbarschaftszeiger entsprechend aktualisieren.
Der Logoff eines Lane-Mitglieds wird durch einen LogoffCall des Benutzers eingeleitet, worauf
je eine LogoffInformation-Nachricht an die beiden Nachbarn des Knotens, falls vorhanden,
versendet wird, die die Adresse des jeweils anderen Nachbarn enthält. Danach löscht der sich
abmeldende Knoten sämtliche Statusinformationen und tritt aus der Lane aus (vgl. Abbildung
2-6). Falls der ausscheidende Knoten keinen Vorgänger und Nachfolger mehr besitzt, d.h. er
bildet allein eine Lane, werden die Knoten der Nachbar-Lanes per Multicast-RemoveLaneNachricht über die Auflösung der Lane informiert. Die Nachbar-Lanes passen die AnycastAdressen ihrer Lane-Nachbarn daraufhin an. Die RemoveLane-Nachricht enthält die dafür
notwendigen Anycast-Adressen der Nachbarn der aufzulösenden Lane (vgl. Abbildung 2-7).
Abbildung 2-6: Logoff-Details (Initiator)
Empfängt ein Mitglied eine LogoffInformation-Nachricht, so aktualisiert es seinen Nachbarn
(Vorgänger oder Nachfolger) mit der in der Nachricht enthaltenen Information. Der Nachfolger
des ausscheidenden Knotens informiert abschließend alle Lane-Mitglieder darüber, dass die
Dienstbeschreibungen dieses Knotens zu löschen sind. Das Dienstmanagement wird unten
genauer betrachtet.
Abbildung 2-7: Logoff-Details (Reaktor)
19
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 2.2 Operationen
2.2.2 Strukturwartung
Ad-hoc-Netze zeichnen sich durch eine relativ hohe Dynamik der Netztopologie aus. Knoten
verlassen das Netz und neue Knoten kommen hinzu. Zudem können Verbindungen durch die
Bewegung der mobilen Teilnehmer unterbrochen werden oder Knoten durch Abschattung der
Funkübertragung oder erschöpfte Batteriekapazität nicht mehr erreichbar sein. Alle genannten
Faktoren gefährden die Konsistenz der Lanes-Struktur. Daher müssen Mechanismen
bereitstehen, um die Lücken innerhalb einer Lane, die durch ausgefallene Knoten entstanden
sind, wieder zu schließen (Intra-Lane-Verbindungen). Auch die Anycast-Verbindungen
zwischen benachbarten Lanes müssen aufrechterhalten werden (Inter-Lane-Verbindungen).
Intra-Lane-Verbindungen
Fehlerhafte Verbindungen oder ausgefallene Knoten müssen von den anderen LanesMitgliedern erkannt und, soweit dies möglich ist, repariert werden, um die Funktionsfähigkeit
der Lanes-Struktur zu gewährleisten. Hierfür werden periodische Ping-Nachrichten verwendet.
Jeder Knoten sendet in festen Zeitabständen (Ping-Timer) eine LanePing-Nachricht an seinen
Nachfolger, sofern ein solcher vorhanden ist. Dieser antwortet mit einer LanePong-Nachricht.
Die Ping-Nachrichten prüfen die Konnektivität zwischen benachbarten Knoten und dienen
zudem der periodischen Auffrischung von Zustandsinformationen. Dazu gehören zum Beispiel
der Vor-Vorgänger eines Knotens oder ein Zählerwert seiner Vorgänger. Letzterer wird später
für die optimierenden Operationen benötigt.
Abbildung 2-8: Überblick über die Verbindungsprüfung
Die Ping-Kette kann durch einen Verbindungs- oder Knotenausfall unterbrochen werden (vgl.
Abbildung 2-9). Die an die Schadensstelle angrenzenden Knoten können diesen Fehler
erkennen, aber nicht unterscheiden, ob es sich um einen ausgefallenen Knoten oder eine
unterbrochene Verbindung handelt. Der Knoten vor einer Fehlerstelle (Fehler-Predecessor)
erkennt ein Fehlverhalten anhand der ausbleibenden LanePong-Nachrichten seines potentiell
20
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 2.2 Operationen
ausgefallenen Nachfolgers. Der auf den Fehler folgende Knoten (Fehler-Successsor) bemerkt
den Schaden durch ausbleibende LanePing-Mitteilungen des Vorgängers.
Knotenausfall
Netzwerkpartitionierung
1
1
Kein LaneBroken
2
2
kein Ping
gesendet
3
LaneBroken
3
LaneBroken senden
nicht möglich
Ping senden
nicht möglich
4
4
Abbildung 2-9: Lane-Broken-Prinzip (nach [12])
Beide leiten daraufhin einen Reparaturmechanismus ein, der im Zustandsdiagramm in
Abbildung 2-8 im komplexen Zustand RepairLane gekapselt ist. Die Details der zwei
Ausprägungen für Fehler-Predecessor und Fehler-Successor werden in Abbildung 2-10 und
Abbildung 2-11 gezeigt.
Nachdem der Fehler-Successor den Fehler durch das ausbleibende LanePing erkannt hat, wird
versucht, den Vor-Vorgänger, also den Fehler-Predecessor, per LaneBroken-Nachricht zu
erreichen, um die Lücke in der Lane zu schließen.
Abbildung 2-10: LaneRepair-Zustand (Fehler-Successor)
Der Fehler-Predecessor seinerseits wartet nach Erkennung des Fehlers auf eine LaneBrokenMitteilung. Die eintreffende Nachricht wird mit einer LaneBrokenConfirmation bestätigt. Der
Fehler-Successor wird zum neuen Nachfolger (vgl. Zustand updateSuccessor ). Damit ist die
Reparatur für den Fehler-Predecessor abgeschlossen. Für die Entfernung der Dienstangebote des
ausgefallenen Knotens sorgt bei erfolgreicher Lane-Reparatur der Fehler-Successor.
Ist aber die Verbindung zum Fehler-Successor unterbrochen, wartet der Fehler-Predecessor
vergebens auf eine LaneBroken-Nachricht und leitet nach einer Timeout-Zeit die Partitionierung
21
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 2.2 Operationen
der Lane ein. Der Nachfolger wird entfernt (vgl. Zustand removeSuccessor ). Der restliche
Lane-Teil wird dann dazu angehalten, die Dienstangebote aller dem Fehler-Predecessor
nachfolgenden Knoten zu löschen. Das Dienstmanagement wird im folgenden Kapitel genauer
betrachtet. Damit ist Reparatur wenn auch gescheitert für den Fehler-Predecessor wiederum
beendet.
Abbildung 2-11: LaneRepair-Zustand (Fehler-Predecessor)
Der Fehler-Successor wartet auf die LaneBrokenConfirmation-Nachricht. Bei deren Eintreffen
wird der Fehler-Predecessor als neuer Vorgänger gesetzt (vgl. Zustand updatePredecessor ).
Danach wird der kompletten, nun reparierten Lane mitgeteilt, welche Dienste durch den
Knotenausfall entfernt werden müssen. Im Fall, dass die LaneBrokenConfirmation-Nachricht
vor dem Ablauf eines Timers nicht eingetroffen ist, wird eine Lane-Partitionierung
angenommen und analog umgekehrt zum Fehler-Predecessor der Vorgänger entfernt und die
restliche verbliebene Lane über den Wegfall der Dienste informiert.
Inter-Lane-Verbindungen
Nicht nur die Verbindungen zwischen den Knoten innerhalb einer Lane, sondern auch zwischen
den Lanes können unterbrochen werden. Für diesen Fall gibt es zwei Ursachen.
Ein Grund für den Verbindungsverlust stellen Netzwerkpartitionierungen dar. Netzwerkpartitionierung wird in [12] und in dieser Arbeit nicht genauer betrachtet. Im Partitionierungsfall
sind keine Reparaturmaßnahmen möglich. Ein besonderes Problem stellt in diesem Rahmen
auch die Wiedervereinigung zweier getrennt voneinander fortentwickelter Partitionen dar. Ohne
Adressreorganisation ist dieses Problem nicht zu lösen.
Die andere Ursache eines Verbindungsverlusts zwischen Lanes ist der Ausfall einer einzelnen
Lane, zum Beispiel durch den Ausfall des letzten verbleibenden Knotens einer Lane. Es ist
durchaus möglich, dass die Nachbar-Lanes der ausgefallenen Lane auf Grund der darunter
liegenden Netzwerktopologie miteinander kommunizieren könnten, um so die Lücke zu
schließen. Das Problem ist aber, dass einer Lane die Adresse der übernächsten Lane nicht
bekannt ist. Es muss also eine Möglichkeit gefunden werden, wie die Adresse der übernächsten
Lane herausgefunden werden kann. Abbildung 2-12 zeigt das Prinzip dieses Mechanismus.
22
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 2.2 Operationen
LaneMissingResponse(8, 9, 10)
I
1
II
2
3
IV
III
4
5
6
7
8
V
9
VI
10
11 12
LaneMissing(8, 9)
Abbildung 2-12: Lane-Missing
Mehrere Lanes entstehen ausschließlich durch die Teilung von existierenden Lanes (LaneSplitting, s.u.). Werden bei der Teilung an die neu entstandenen Lanes benachbarte Adressen
vergeben, entsteht eine Sortierung der Lanes bezüglich ihrer Adressen. Diese Sortierung ist
grundlegend dafür, den richtigen Nachbarn der ausgefallenen Lane zu finden.
Eine Lane A, die einen rechten Nachbarn vermisst, sendet eine LaneMissing-Nachricht mit ihrer
rechten Adresse sowie der linken Adresse der Ausgefallenen per Broadcast. Erhält eine Lane B,
die ihren linken Nachbarn vermisst, diese Nachricht, antwortet sie, sofern die angegebene linke
Adresse der ausgefallenen Lane kleiner ist als ihre eigene linke Adresse. Lane III würde im
Beispiel auf die LaneMissing-Nachricht von Lane IV nicht antworten, da sie links davon
liegt. Die LaneMissingResponse-Nachricht enthält neben den Adressen aus der LaneMissingNachricht zusätzlich die rechte Adresse der von Lane B vermissten Lane. Diese Adresse muss
nicht mit der rechten Adresse der von Lane A vermissten Lane übereinstimmen! Lane A
sammelt alle Antworten und wählt auf Grund der Sortierung als neue rechte Adresse die
kleinste Adresse unter den Antworten aus, die größer ist als ihre eigene linke Adresse. Das
Beispiel aus Abbildung 2-12 würde demnach nach Abarbeitung aller Lanes-Ausfälle wie folgt
aussehen: Lane I (1,4), Lane III (5,6), Lane IV (7, 10) und Lane VI (11,12).
Das beschriebene Problem ist ein seltener Ausnahmefall, der nur im Fehlerfall eintritt, da
normalerweise die Nachbar-Lanes durch den letzten verbleibenden Knoten der Lane über ihre
Auflösung informiert werden.
2.2.3 Dienste-Management
Jeder Knoten einer Lane kennt sämtliche in seiner Lane verfügbaren Dienste. Neben einer
beliebig weit reichenden Beschreibung der Dienstsemantik wird für jeden Dienst die UnicastAdresse des Knotens vermerkt, auf dem der Dienst zu finden ist.
Für das Management der Dienstbeschreibungen einer Lane sind vier Funktionen notwendig: die
Ankündigung neuer Dienste innerhalb der Lane, das Löschen nicht mehr aktueller
Dienstbeschreibungen, die periodische Auffrischung der Dienstbeschreibungen zur
Konsistenzerhaltung und schließlich die Suche nach Diensten.
23
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 2.2 Operationen
Dienste veröffentlichen (Publish)
Möchte ein Knoten einen Dienst in seiner Lane veröffentlichen (vgl. Abbildung 2-13), sendet er
eine ServiceOffer-Nachricht an seinen Vorgänger und seinen Nachfolger (sofern vorhanden).
Diese Nachricht beinhaltet die Adresse des Anbieters, sowie die eigentliche
Dienstbeschreibung. Empfängt ein Knoten eine ServiceOffer-Nachricht von seinem
Nachbarknoten, speichert er die enthaltene Dienstbeschreibung und leitet die Nachricht an den
gegenüberliegenden Nachbarknoten weiter.
Abbildung 2-13: Dienst veröffentlichen
Dienst zurückziehen (Unpublish)
Analog zur Bekanntgabe eines Dienstes kann ein Knoten auch eine bereits veröffentlichte
Dienstbeschreibung wieder entfernen (vgl. Abbildung 2-14). Hierzu sendet er an seinen
Vorgänger und Nachfolger eine ServiceRevoke-Nachricht mit der entsprechenden
Dienstbeschreibung. Erhält ein Knoten eine ServiceRevoke-Nachricht von einem
Nachbarknoten, entfernt er die angegebene Dienstbeschreibung und leitet die Nachricht an den
anderen Nachbarknoten weiter. Eine ServiceRevoke-Nachricht kann auch mehrere zu
entfernende Dienstbeschreibungen beinhalten, da beim Verlassen der Lane
absichtlich
(Logoff) oder auf Grund von Fehlern alle Dienste eines Knotens auf einmal gelöscht werden
müssen.
Abbildung 2-14: Dienstbeschreibung(en) entfernen
24
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 2.2 Operationen
Dienstsuche
Möchte ein Knoten einen Dienst nutzen, muss er zunächst wissen, wo dieser zu finden ist.
Zunächst prüft er, ob der gesuchte Dienst in der eigenen Lane verfügbar ist, d.h. ob er eine
entsprechende Dienstbeschreibung selbst gespeichert hat. Außerdem sendet er je eine
ServiceRequest-Nachricht an die benachbarten Lane-Anycast-Adressen und wartet für
bestimmte Zeit auf Beantwortung (ServiceRequestResult-Nachrichten) seiner Suche, um auch
weitere passende Dienste im Netz zu finden. Abbildung 2-15 zeigt das Zustandsdiagramm der
Dienstsuche.
Ein Knoten, der eine ServiceRequest-Nachricht empfängt, prüft, ob er eine entsprechende
Dienstbeschreibung gespeichert hat. Falls ja, ist der Dienst in der Lane verfügbar und der
Knoten antwortet mit einer ServiceRequestResult-Nachricht, die die Dienstbeschreibung des
gefundenen Dienstes sowie die Unicast-Adresse des Dienstanbieters beinhaltet. Danach leitet er
die ServiceRequest-Nachricht an die gegenüber liegende Lane weiter, falls diese existiert.
Abbildung 2-15: Dienstsuche
In [12] hingegen ist hier ein etwas anderes Vorgehen beschrieben. Dort werden ServiceRequestNachrichten nicht an die gegenüberliegende Lane weitergeleitet, wenn bereits ein passender
Dienst gefunden wurde. Der Nachteil dieser Methode besteht darin, dass eventuell besser
passende Dienste, die weiter weg liegen, nicht gefunden werden. Das soll durch die
Weiterleitung der ServiceRequest-Nachrichten wie sie hier beschrieben wurde verhindert
werden.
Dienstauffrischung
Die Ankündigung eines neuen Dienstes oder die Löschanforderung von Diensten wird
schrittweise von Knoten zu Knoten durch die Lane weitergereicht. Durch Übertragungsfehler
kann es passieren, dass einzelne Knoten die Aktualisierung des Dienstangebots nicht
mitbekommen. Ein periodischer Auffrischungsmechanismus soll diese Inkonsistenzen wieder
ausgleichen.
25
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 2.2 Operationen
Abbildung 2-16: Dienstbeschreibungen aktualisieren
Der erste Knoten der Lane sendet in größeren Intervallen eine RefreshRequest-Nachricht durch
die Lane. Jeder Knoten fügt die Beschreibungen der von ihm angebotenen Dienste zu einer
empfangenen RefreshRequest-Nachricht hinzu und leitet sie an seinen Nachfolger weiter. Der
letzte Knoten sendet die Liste der Dienstbeschreibungen in einer RefreshComplete-Nachricht
zurück. Beim Empfang einer solchen Nachricht aktualisiert jeder Knoten seine gespeicherten
Dienstbeschreibungen der Lane.
2.2.4 Strukturoptimierung
Der Aufwand des Dienst-Managements ist unmittelbar abhängig von der Größe der einzelnen
Lanes-Ketten. Wenige große Lanes bedeuten eine geringe Anzahl an ServiceRequestNachrichten, die zwischen den einzelnen Ketten ausgetauscht werden müssen. Dafür nimmt der
Aufwand für die Ankündigung und Löschung von Dienstbeschreibungen in diesem Fall stark
zu. Genau umgekehrt verhält es sich für zu kleine Lanes. Daher ist zu gewährleisten, dass die
Größe der Lanes immer in einem festen Intervall gehalten wird. Gegebenenfalls sind zu große
Ketten aufzuspalten oder zu kleine Ketten wieder mit den Nachbar-Lanes zu vereinigen
Lane-Teilung (Splitting)
[12] schlägt für die Teilung einer Lane ein Reißverschluss-Verfahren vor. Das bedeutet, die
Knoten werden abwechselnd auf die neuen Lanes verteilt. Dahinter steht die Idee, dass dadurch
zwischen den beiden neuen Lanes eine möglichst gute Konnektivität geschaffen werden kann.
Die Teilung einer Lane ist in Abbildung 2-17 dargestellt. Der letzte Knoten einer Lane, d.h. der
Knoten ohne Nachfolger, leitet die Teilung seiner Lane durch das Senden einer SplitRequestNachricht an seinen Vorgänger ein. Der letzte Knoten ist der einzige Knoten einer Lane, der die
tatsächliche Lane-Größe durch die in der Ping-Nachricht enthaltenen Vorgängerzähler kennt
(Lane-Größe = Vorgängerzähler + 1).
26
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 2.2 Operationen
Abbildung 2-17: Lane-Teilung
Die Nachricht wird bis zum ersten Knoten weitergeleitet, wobei jeder Knoten sich in eine der
beiden enthaltenen Listen einträgt. Die Listen repräsentieren die neu zu erstellenden Lanes. Der
erste Knoten antwortet mit einer SplitComplete-Nachricht, die die vollständigen Listen enthält
und in gleicher Weise wieder zum letzten Knoten zurück gesendet wird. Jeder Zwischenknoten
leitet die SplitComplete-Nachricht weiter und passt seinen Zustand anhand der Listen an. Um
die Teilung abzuschließen, müssen noch die angebotenen Dienste der beiden Lanes aktualisiert
werden, was jedoch nicht explizit realisiert werden muss. Diese Aufgabe übernimmt die
periodische Auffrischung der Dienste in der jeweiligen Lane. Somit kann der Zustand
updateServiceOffers (*) aus der Modellierung entfernt werden.
Wiedervereinigung von Lanes (Merging)
Unterschreitet die Größe einer Lane einen bestimmten Wert, ist die Lanes-Struktur ebenfalls
nicht mehr effizient. Die Lane wird dann mit den Nachbar-Lanes wiedervereinigt. Anders als in
[12] beschrieben, wird der Vereinigungsalgorithmus nicht im Reißverschlussprinzip
durchgeführt, sondern durch das Aus- und erneute Einloggen der Mitglieder der zu kleinen
Lane. Die Lokalität der Nachbarschaftsbeziehungen wird durch den erneuten Login besser
gewährleistet. Zudem wird auf bereits Bekanntes zurückgegriffen und weitere Fehlerquellen
vermieden.
Auch hier startet der letzte Knoten (d.h. der Knoten ohne Nachfolger) wegen seiner Kenntnis
über die Lane-Größe die Vereinigung mit einer MergeRequest-Nachricht an die anderen LaneMitglieder. Empfängt ein Lane-Mitglied diese Nachricht, wird der Logoff eingeleitet.
Gegenüber dem normalen Logoff werden aber keine LogoffInformation- und OfferRemoveNachrichten versendet, da alle anderen Knoten der Lane sich ebenfalls ausloggen und somit
sämtliche Statusinformation zurückgesetzt wird. Der letzte Knoten übernimmt die Aufgabe, die
Nachbarlanes über die Auflösung der Lane per RemoveLane-Nachricht zu informieren.
Nach dem Logoff wird nach einer zufälligen Wartezeit mit dem erneuten Login begonnen.
Durch die Wartezeit wird die Wahrscheinlichkeit paralleler Logins verringert. Nach
erfolgreichem Login in eine andere Lane werden die bereitgestellten Dienste wieder bekannt
gemacht.
27
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 3 Stand der Forschung
3
Stand der Forschung
Die Protokollbestandteile eines Overlays, wie sie beispielsweise für Lanes im letzten Kapitel
definiert wurden, sind jedes für sich korrekt ausführbar. Was geschieht jedoch, wenn mehrere
von ihnen gleichzeitig ausgeführt werden? Die Beschreibungen von Lanes in Kapitel 2
klammern diesen Fall bisher aus. Eine erste prototypische Implementierung [13] hat, wie bereits
erwähnt, gezeigt, dass dieser Fall nicht ignoriert werden kann, da wegen des gemeinsamen
Zugriffs auf die Zustandsdaten der Knoten Schäden an der Lanes-Struktur auftreten können.
Dieses Kapitel untersucht zunächst, wo genau die Probleme liegen und welche Fehler entstehen
können. In einem zweiten Schritt werden dann einige Overlay-Netze, die, wie Lanes auch, zur
Dienstsuche genutzt werden können, vorgestellt und ihr Verhalten in den Problemfällen
analysiert. Dabei wird auch untersucht, wie allgemein diese Ansätze sind und ob sie sich
beispielsweise auf Lanes übertragen lassen.
3.1
Problemstellung
Dass Fehler durch die parallele Ausführung mehrerer Overlay-Wartungsoperationen auftreten,
wurde bereits beschrieben. Dieser Abschnitt soll nun zeigen, welche Fehler das sind und in
welche Kategorien diese eingeteilt werden können. Die beschriebenen Situationen werden
anhand von Beispielen des Lanes-Overlays verdeutlicht.
Alle Fehlersituationen entstehen dadurch, dass mehrere Wartungsoperationen nebenläufig die
Strukturdaten des Overlays lesen und ändern. Das Lesen und Schreiben der Werte erfolgt dabei
für jede der Operationen nicht punktuell, sondern sequentiell. Diese Lese-Schreib-Sequenzen
der Operationen werden zu einer gemeinsamen globalen Sequenz, einem so genannten
Schedule, vereinigt. Je nachdem, welche Reihenfolge die Lese- und Schreiboperationen auf den
Strukturdaten aufweisen, können Inkonsistenzen entstehen. Die gleiche Problematik ist auch bei
nebenläufigen Operationen in Datenbanksystemen bekannt (vgl. [8]).
Die erste Fehlergruppe, die identifiziert werden kann, sind verloren gegangene Änderungen
(Lost Updates). Sie entstehen, wenn zwei nebenläufige Operationen zunächst das gleiche
Datenobjekt lesen und dann Änderungen vornehmen. Nur die letzte Änderung hat einen
dauerhaften Effekt. Die anderen geschriebenen Werte gehen verloren. Der Schedule hat
schematisch dargestellt in diesem Fall folgende Struktur: r1(x)r2(x)w1(x)w2(x) (ri(x): Leseoperation der Operation i auf Datum x, analog Schreiboperation wi(x)). Die Schreiboperation
der ersten Operation geht verloren. Abbildung 3-1 zeigt ein Lanes-Beispiel. Wird ein Login
zwischen der SplitRequest- und der SplitComplete-Phase durchgeführt (vgl. Kapitel 2), geht die
Information darüber bei der Vollendung des Splits wieder verloren. Das liegt daran, dass bereits
in der SplitRequest-Phase die Struktur der neuen Lanes festgelegt wird. Die SplitCompletePhase dient dann der Verwirklichung dieser Struktur ungeachtet etwaiger zwischenzeitlicher
Änderungen.
28
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 3.1 Problemstellung
Split-Request (1)
Split-Complete (3)
1
2
3
4
7
5
6
Login (2)
1
3
5
2
4
6
7
Abbildung 3-1: Lost Update
Ein weiterer Grund für das Auftreten von Fehlern ist das Fehlen von Abbruchoperationen.
Operationen, die in mehreren Schritten durchgeführt werden, wie der Lanes-Login, können
nicht zurückgesetzt werden. Wird beim Login-Vorgang (vgl. Kapitel 2) durch Reaktor 1 eine
LoginInformation-Nachricht an Reaktor 2 gesendet, aktualisiert dieser seinen Verweis auf den
Vorgänger. Fällt jetzt der Reaktor 1 aus oder loggt er sich absichtlich aus, muss der Login
eigentlich abgebrochen werden. Hierfür ist aber keine Routine vorgesehen. Die Strukturdaten
von Reaktor 2 wurden aber bereits geändert und sind somit inkonsistent.
Doch selbst wenn Abbruchoperationen vorhanden wären, können Probleme dadurch auftreten,
dass eine Operation Werte einer anderen Operation liest, obwohl noch nicht feststeht, ob diese
erfolgreich beendet werden kann (Schema: r1(x)w1(x)r2(x)a1). Dieses Problem, für das das
Beispiel des vorangegangenen Abschnitts gleichfalls angeführt werden kann, wird als Dirty
Read bezeichnet.
Ein weiteres Problem, das aus der Datenbankwelt bekannt ist, sind so genannte Non-repeatable
Reads. Es tritt im einfachsten Fall dann auf, wenn eine Operation Werte liest, die aus ihrer Sicht
zu unterschiedlichen Zeitpunkten gültig sind. Das Sequenzschema lautet in diesem Fall
beispielsweise r1(x)r2(y)w2(y)r1(y)r2(x)w2(x). Operation 1 liest das Datum x bevor es von
Operation 2 geändert wird, das Datum y aber erst nach dessen Änderung. Ein Beispiel für
Operation 1 bei Lanes sind Dienstankündigungen, die entlang einer Lanes-Kette weitergeleitet
werden. Dabei werden die Vorgänger- und Nachfolgerverweise gelesen. Durch eine
nebenläufige Split-Operation kann es passieren, dass einer der beiden bereits aktualisiert wurde,
der andere jedoch noch nicht. Die Dienstankündigungsnachricht wird also falsch weitergeleitet.
Da bei dieser Fehlersituation die Struktur des Overlays keinen Schaden nimmt, ist dieses
Problem bei reinen Leseoperationen gegebenenfalls tolerierbar.
29
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 3.2 Ansätze in der Literatur
3.2
Ansätze in der Literatur
In diesem Abschnitt werden einige bekannte strukturierte Overlay-Netze, die für die
Dienstbereitstellung und -suche genutzt werden können, vorgestellt und darauf hin untersucht,
wie sie mit dem Problem paralleler Wartungs- und Optimierungsoperationen umgehen. Dabei
ist besonders von Interesse, wie befriedigend diese Lösungen im Anwendungsbereich mobiler
Ad-hoc-Netze sind und ob sie allgemein genug sind, um auf andere Overlays, wie Lanes,
übertragen werden zu können.
Einige der im Folgenden beschriebenen Overlays sind verteilte Hash-Tabellen (Distributed
Hashtable, DHT). Die Netzknoten einer DHT realisieren einen verteilten Speicher. Die zu
speichernden Objekte
in unserem Fall Dienstbeschreibungen
werden mit Hilfe einer
Hashfunktion auf numerische Werte abgebildet. Diese Werte sind den Adressen, der Netzknoten
zugeordnet, auf denen das dazugehörende Objekt gespeichert ist. Somit kann mit Hilfe einer
einfachen mathematischen Berechnung überprüft werden, ob ein gesuchtes Objekt vorhanden ist
und wo es sich befindet.
3.2.1 Pastry
Pastry [16] ist ein generisches internetbasiertes Wide-Area-Peer-to-Peer-System für Routing
und verteilte Objektspeicherung. Als Distributed Hashtable (DHT) dient es als allgemeine
Grundlagen-Komponente für verschiedene P2P-Anwendungen. Die einzigen Benutzerfunktionen, die angeboten werden, sind daher das Ablegen und Auslesen von Schlüssel-ObjektPaaren im verteilten Objektspeicher. Pastry wurde ursprünglich von Microsoft Research
entwickelt. Mittlerweile existiert aber mit FreePastry auch eine weitere frei verfügbare
Implementierung der Rice University in Houston (USA) [17].
Struktur & Routing
Das Pastry-Overlay-Netzwerk ist selbstorganisierend und besteht aus gleichberechtigten
Knoten. Jeder Knoten besitzt eine Knoten-ID, die durch ein Hashverfahren aus der IP-Adresse
beim Eintritt in das Pastry-Netz berechnet wird. Der Knoten-ID-Raum ist kreisförmig
angeordnet (vgl. Abbildung 3-2). Dabei wird die Kreisstruktur implizit durch die Reihenfolge
der IDs gebildet. Dabei müssen nicht alle IDs belegt sein.
0
2 128 -1
d 47 1 f1
d 4 6a 01
d 46 2b a
d 46 a1 c
d4 2 13 f
d 1a 08 e
R ou te (d 46 a1 c)
65 a1 fc
Abbildung 3-2: Pastry-Stuktur (nach [16])
30
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 3.2 Ansätze in der Literatur
Die einzigen Operationen, die Pastry verwendet, dienen dem Aufbau und der Optimierung der
in jedem Knoten für das Routing benötigten Komponenten (vgl. Anhang D). Dazu gehören
unter anderem eine Routingtabelle und der so genannte Leaf-Set. Der Leaf-Set eines Knotens
beinhaltet Knoten, deren IDs zur eigenen ID am ähnlichsten sind.
Mit Hilfe dieser Komponenten läuft das Routing folgendermaßen ab. Trifft eine Nachricht mit
Schlüssel D bei einem Knoten mit Knoten-ID A ein, wird zunächst überprüft, ob sich D
innerhalb der Werte des Leaf-Sets befindet. Falls ja, wird die Nachricht direkt zu dem Knoten
des Leaf-Sets weitergeleitet, dessen Knoten-ID am wenigsten von D abweicht. Sonst wird die
Nachricht mit Hilfe der Routingtabelle an einen Knoten weitergeleitet, dessen Knoten-ID-Präfix
um ein Bit mehr mit D s ID übereinstimmt.
Einfügen neuer Knoten
Kommt ein Knoten X neu ins Pastry-Netz hinzu, müssen die Routingtabelle und der Leaf-Set
zunächst initialisiert werden. Nachdem der neue Knoten seine Knoten-ID berechnet hat, bittet er
einen ihm bekannten Pastry-Knoten Y, eine spezielle Join-Nachricht mit Schlüssel X zu
versenden. Die Nachricht wird ganz normal durch das Pastry-Netz zu dem Knoten Z
weitergeleitet, dessen Knoten-ID am besten mit Schlüssel X übereinstimmt. Alle Knoten, die
die Join-Nachricht weitergeleitet haben, inklusive Y und Z, senden ihre Zustandsinformation an
X. Aus den erhaltenen Informationen kann X seine Strukturinformationen berechnen. Zum
Schluss teilt er seine Ankunft seinen Nachbarn mit, damit eine Anpassung der Routingeinträge
erfolgen kann.
Fehlerbehandlung & Knotenaustritt
Verlassen Knoten das Netz
absichtlich oder durch Ausfall
werden die
Zustandsinformationen der anderen Knoten durch eine faule Änderungsstrategie angepasst. Das
bedeutet, dass die Einträge bezüglich des ausgeschiedenen Knotens in den Routingtabellen und
den Leaf-Sets der benachbarten Knoten erst dann entfernt werden, wenn diese bei einer
zukünftigen Operation das Fehlen des Knotens bemerken.
Bewertung
Die implizite Ringstruktur von Pastry erfordert keine Wartung, da die Knotenreihenfolge einzig
von der natürlichen Ordnung der Knoten-IDs abhängt. Inkonsistenzen durch parallele
Operationen, vor allem den Logins, aber auch durch Knotenausfälle sind möglich, stellen aber
keine Problem dar. Werden die Routingtabellen oder die Leaf-Sets fehlerhaft gesetzt, nimmt
lediglich die Performanz des Routing ab, da der Routing-Mechanismus von Natur aus schon
fehlertolerant ist. Zudem sind die Routingtabellen weniger anfällig für den parallelen Zugriff
mehrerer Operationen, da diese auf verschiedenen Bereichen der Tabelle operieren. Fehler in
den Leaf-Sets sind bei Pastry am gefährlichsten. Um die Leaf-Sets möglichst korrekt zu halten
werden sie periodisch
oder nach Änderungen
unter den Nachbarn ausgetauscht, um
Inkonsistenzen zu erkennen und zu beheben. Pastry wurde für das Internet konzipiert, sodass die
beschriebenen Maßnahmen ausreichen. Diese Maßnahmen sind jedoch speziell auf die
Gegebenheiten und Anforderungen von Pastry abgestimmt. Eine Übertragung dieser
protokollspezifischen Lösungen zur Fehlerbehebung auf andere Overlays ist daher kaum
möglich.
31
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 3.2 Ansätze in der Literatur
FreePastry, eine frei verfügbare Java-Implementierung der Rice University in Houston (USA),
verwendet das Prinzip des wechselseitigen Ausschlusses (Semaphoren), um den Zugriff auf
exklusive Ressourcen zu steuern. In Java wird hierfür das Schlüsselwort synchronized
verwendet. Dadurch können parallele Zugriffe auf die lokalen Strukturwerte durch mehrere
Operationen verhindert werden. Die globale Konsistenz kann dadurch aber dennoch nicht
garantiert werden.
Zusammenfassend lässt sich also feststellen, dass die Fehlerkorrekturansätze von Pastry nicht
den mit dieser Arbeit verfolgten Zielen erfolgreicher Schutz vor parallelen Operationen und
ein allgemeiner Ansatz genügen.
3.2.2 Bamboo
Bamboo ([18], [19]) ist eine Distributed Hashtable (DHT) auf der Basis von Pastry. Dabei
wurden Anpassungen im Routing und in der Bestimmung von nahen Nachbarn
vorgenommen, um auch bei hohen Zuwachs- und Abwanderungsraten von Knoten eine
Bandbreite-sparende Lösung zu ermöglichen. Versuche mit FreePastry, einer Implementierung
von Pastry der Rice University, haben nämlich gezeigt, dass bei hohen Zu- und
Abwanderungsraten ein großer Teil der Lookups fehlschlagen. Als Grund hierfür nennen S.
Rhea et al. in [19], dass Knoten auf Grund der langen Wartezeiten das Netz wieder verlassen,
obwohl sich noch Anfragen in ihren Warteschlagen befinden. In Phasen der Ruhe erholte sich
das Netz gut, doch leider sind solche Phasen in der Realität selten. Trotz dieses Mangels wurde
Pastry als Grundlage für Bamboo gewählt. Ein Hauptunterschied zu Pastry besteht darin, statt
reaktivem Recovery periodische Korrekturen durchzuführen. Die grundlegenden PastryMechanismen und die Zustandsinformationen der Knoten bleiben davon aber unberührt, sodass
bei Bamboo kein anderes Verhalten bezüglich des Problems paralleler Operationen zu erwarten
ist.
3.2.3 Chord
Chord ([21]) ist ein weiteres Internet-Peer-to-Peer-Protokoll für Routing und verteilte
Objektspeicherung mit viel Ähnlichkeit mit Pastry. Chord wurde am MIT in Cambridge
entwickelt und legt den Fokus auf die Realisierung der Funktionalität einer verteilten
Hashtabelle.
Struktur & Routing
Beim Chord-Overlay-Netzwerk handelt es sich, wie bei Pastry, ebenfalls um ein Ringnetzwerk,
wobei die Knoten in der Reihenfolge ihrer IDs angeordnet sind. Objekte werden auf dem
Knoten gespeichert, der bezüglich des Objektschlüssels die nächsthöhere ID hat. Die
Nachfolger eines Knotens werden in einer so genannten Fingertabelle verwaltet (vgl. Anhang
D). Dort wird gespeichert, welcher Knoten für welches Schlüsselintervall verantwortlich ist, um
eine gezielte Weiterleitung der Nachrichten zu ermöglichen.
Einfügen neuer Knoten
Möchte ein Knoten in das Netzwerk eingegliedert werden, muss er einen bereits im Netz
angemeldeten Knoten kontaktieren. Der neue Knoten erhält die Fingertabelle des
32
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 3.2 Ansätze in der Literatur
Netzwerkmitglieds, um seine eigene Fingertabelle zu initialisieren. Danach werden die anderen
Knoten über das neue Mitglied informiert, um ihre Fingertabellen anzupassen. Als letzter
Schritt müssen die Objekte, die zukünftig auf Grund ihrer ID von dem neuen Knoten zu
verwalten sind, von dessen Nachfolger übertragen werden.
Fehlerbehandlung & Knotenaustritt
Die bis jetzt beschriebenen Mechanismen sind noch nicht einsetzbar, da in der Praxis Knoten
ausfallen, sodass Lücken im Ring entstehen, oder mehrere Knoten gleichzeitig hinzukommen,
wodurch Überschneidungen möglich sind.
Um Störungen des Netzwerks besser begegnen zu können, speichert ein Knoten nicht nur seinen
direkten Nachfolger sondern mehrere. Das Hinzukommen und Wegfallen von Knoten kann dazu
führen, dass die Nachfolgerlisten und die Fingertabellen schadhaft werden, wobei Fehler in den
Fingertabellen nur zu einer verlangsamten Suche führen. Um Fehler durch neue Knoten,
ausgefallene Knoten oder fehlerhafte Nachrichten zu beheben, führt jeder Knoten periodisch
eine Stabilisierungsroutine aus. Jeder Knoten führt dabei eine Selbstsuche im Netzwerk
durch, d.h. er befragt seine Nachbarn nach ihren Vorgängern und Nachfolgern. Dadurch können
noch nicht erkannte Lücken oder neue Knoten gefunden werden. Auf Grund dieses
Fehlerprotokolls muss jeder Peer neben seinem Nachfolger also auch seinen Vorgänger
speichern.
Bewertung
Für die korrekte Funktionsweise des Chord-Protokolls ist eine periodische Ausführung der
Stabilisierungsroutine zwingend erforderlich. Kann das durch zu viele hinzukommende oder
wegfallende Knoten nicht mehr garantiert werden, sind Ringbrüche und Partitionierungen
möglich [20]. Zusätzlich können parallele Logins, die in mehreren Schritten die Fingertabellen
aktualisieren, zu Fehlern in der Struktur führen. Das Chord-Protokoll baut bei der
Fehlerbekämpfung zum einen auf Verringerung der Auswirkung von Fehlern durch
Redundanzen und zum anderen auf die Korrektur von Fehlern durch die Stabilisierungsroutine.
Beides kann aber in einer hochdynamischen Umgebung Fehler nicht beheben, sodass die ChordLösungen für den vorliegenden Fall bei Ad-hoc-Netzen nicht geeignet sind. Aber auch bei den
niedrigeren Fehlerwahrscheinlichkeiten im Internet können die in dieser Arbeit betrachteten
Probleme auftreten. Chord bietet keine Mechanismen an, um diese Probleme explizit zu lösen.
Stattdessen wird die Behebung ihrer Auswirkungen den beschriebenen Fehlerkorrekturverfahren
überlassen. Auch die Chord-Verfahren sind nicht auf andere Overlays übertragbar. Insgesamt
zeigen sie sich damit ebenfalls als nicht zufriedenstellend für die hier betrachteten Probleme.
3.2.4 CAN (Content Addressable Network)
Das Content Addressable Network (CAN) ([22]) ist ein weiterer Vertreter eines strukturierten
Overlay-Netzes zur Realisierung einer verteilten Hashtabelle der Universität von Kalifornien in
Berkeley.
33
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 3.2 Ansätze in der Literatur
Struktur & Routing
Anders als bei den bisher beschriebenen Overlay-Netzen, handelt es sich bei CAN nicht um ein
Ringnetzwerk. Stattdessen bildet ein d-dimensionaler begrenzter Koordinatenraum die Basis für
das CAN-Netzwerk. Jeder Knoten des Netzwerks verwaltet einen Teil dieses Raums, eine so
genannte Zone, und somit die Objekte, deren Schlüssel mittels einer Hashfunktion auf einen
Punkt in dieser Zone abgebildet wurden. Die Zonen sind untereinander disjunkt und die
Vereinigung aller Zonen ergibt den gesamten Koordinatenraum.
y
1
2
4
01
110
111
5
3
00
10
0
1
0
1
0
5
1
3
VID
1
0
1
2
4
x
Abbildung 3-3: Beispiel CAN-Zonen (nach [22])
Kommen neue Knoten ins Netz hinzu, müssen bestehende Zonen geteilt werden, um diese
Regeln einzuhalten. Dabei werden die Zonen abwechselnd entlang der einzelnen Dimensionen
halbiert. Es entsteht somit ein binäres Buddy-System. Das bedeutet, dass je zwei wohldefinierte
Zonen aus einer gemeinsamen Zone durch Halbierung hervorgehen bzw. zu einer Zone
wiedervereinigt werden können. Dieser Sachverhalt kann durch einen binären Baum (vgl.
Abbildung 3-3) dargestellt werden. Dabei kann jeder Zone eine eindeutige virtuelle ID (VID)
zugeordnet werden. Bei jeder Halbierung wird diese um ein Bit verlängert, je nachdem, ob die
Zone die linke oder rechte Hälfte darstellt. Diese virtuellen Adressen dienen auch zur
Adressierung der Knoten, die die jeweiligen Zonen verwalten.
Das Routing durch das CAN-Netz wird durch die Speicherung der IP-Adressen und der VIDs
der Nachbarknoten jedes Knotens unterstützt. Als Nachbarn eines Knotens werden alle Knoten
bezeichnet, deren Zonen eine gemeinsame Grenze mit der Zone dieses Knotens besitzen. Das
Routing erfolgt anhand des Greedy-Prinzips entlang der Dimensionen des CAN-Raums. Das
bedeutet, dass ein Knoten eine ankommende Nachricht immer zu dem Nachbar weiterleitet,
dessen VID am ähnlichsten zur Empfängeradresse ist. Natürlich existieren mehrere mögliche
Wege zu einem Ziel, was dazu genutzt wird, ausgefallene Knoten zu umgehen.
Einfügen neuer Knoten
Um einen neuen Knoten in das CAN-Netzwerk zu integrieren, muss ihm eine eigene Zone
zugewiesen werden. Hierzu kontaktiert der neue Knoten einen Netzwerkknoten, dessen Zone
halbiert und inklusive der verwalteten Information zur Hälfte an den neuen Knoten übermittelt
wird. Die VIDs der Knoten wird um ein Bit vergrößert. Als nächster Schritt müssen die
Nachbarschaften aktualisiert werden. Die Menge der Nachbarknoten ist eine Teilmenge der
Nachbarn des alten Knotens inklusive des neuen Knotens. Nach der Berechnung der jeweiligen
34
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 3.2 Ansätze in der Literatur
Nachbarn müssen diese auch über die Änderung informiert werden. Hierzu werden UpdateNachrichten gefolgt von periodischen Refresh-Nachrichten versendet.
Fehlerbehandlung & Knotenaustritt
Verlässt ein Knoten das Netzwerk, ist sicherzustellen, dass die von ihm verwaltete Zone durch
einen anderen Knoten den so genannten Takeover-Knoten übernommen wird. Durch das
Buddy-System ist nicht immer eine Wiedervereinigung der Zonen möglich. Gegebenfalls muss
der Takeover-Knoten temporär mehrere Zonen verwalten und hat somit auch mehrere VIDs.
Um langfristig wieder eine Zone pro Knoten zu erhalten, wird in [22] ein Algorithmus
vorgestellt.
Die Nachbarn eines ausgefallenen Knotens erkennen den Fehler durch ausbleibende RefreshNachrichten. Sie entfernen daraufhin den Knoten aus ihrer Nachbarliste und versuchen den
Takeover-Knoten zu kontaktieren. Hierfür wird eine spezielle Recovery-Nachricht an die VID
des ausgefallenen Knoten gesendet. Die anderen Peers routen die Nachricht immer näher zum
Takeover-Knoten, da dessen VID der VID des ausgefallenen Knotens am ähnlichsten ist.
Dadurch lernt der Takeover-Knoten die Nachbarn seiner neu übernommenen Zone kennen und
umgekehrt. Bei mehrfachen Fehlern kann dieses Verfahren jedoch scheitern, da RecoveryNachrichten ins Leere laufen. Eine periodische Stabilisierungsprozedur ähnlich zu Chord
soll dieses Problem lösen.
Bewertung
Die CAN-Struktur ist die komplexeste der betrachteten Overlay-Netze. Sie ist strenger als
beispielsweise die Lanes-Struktur, da neben den oberen und unteren Nachbarknoten auch
die linken und rechten explizit gespeichert werden müssen. Letztere werden bei Lanes
durch das Anycast-Routing ersetzt. Der Erhalt dieser CAN-Struktur ist dementsprechend
aufwändig. Bei mehrfachen Fehlern, Knotenausfällen und nebenläufigen Strukturoperationen
sind inkonsistente Zustände leicht möglich. Sowohl der Login als auch der Logoff eines
Knotens stellen komplexe Operationen dar, die umfangreiche Reorganisationen der Netzstruktur
nach sich ziehen. Dass auch Inkonsistenzen durch parallele Operationen möglich sind, ist daher
leicht einzusehen. Der Stabilisierungsalgorithmus kann an dieser Situation nur wenig ändern. Er
benötigt gewisse Ruhephasen, um die vollständige Konsistenz der Zustandinformation wieder
herzustellen. Diese Art der Fehlerbehebung ist im hochdynamischen Umfeld von Ad-hocNetzen und für das betrachtete Problem paralleler Operationen nicht ausreichend. Zudem sind
die CAN-Mechanismen, wie auch die von Pastry und Chord, protokollspezifisch.
3.2.5 DynaMO
Das Overlay DynaMO der Freien Universität Berlin [28] wurde als Peer-to-Peer-System für
mobile Netze entwickelt. DynaMO greift die Struktur des internetbasierten Peer-to-PeerSystems Pastry auf und passt es an die Gegebenheiten im mobilen Netzwerk-Bereich an.
Der Hauptunterschied zu Pastry besteht in der Wahl der Knoten-IDs. Pastry verfolgt einen TopDown-Ansatz und berechnet die Knoten-IDs aus der Netzwerkadresse, dem Public Key oder
ähnlichem. Dadurch entsteht im Bezug auf die darunterliegende Netzwerktopologie eine
zufällige Verteilung der IDs. DynaMO hingegen berücksichtigt die Struktur des
35
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 3.2 Ansätze in der Literatur
darunterliegenden Netzwerks bei der Vergabe der IDs, verfolgt also einen Bottom-Up-Ansatz.
Das Ziel dabei ist, ähnliche IDs an Knoten zu vergeben, die in diesem Basisnetzwerk benachbart
sind. Dadurch wird erreicht, dass das Routing im Overlay-Netz möglichst ähnlich zum
darunterliegenden physikalischen Netzwerk erfolgt. Um die Lokalität der IDs zu gewährleisten
verwendet DynaMO das so genannte Landmarking. Einige Knoten sind als Landmarken
ausgezeichnet und verwalten jeweils einen Teil des ID-Raumes. Die IDs der Landmarken sind
fest und im ganzen Netz bekannt. Ein neu hinzukommender Knoten kontaktiert die
Landmarken, um herauszufinden, welche ihm am nächsten liegt. Von diesem LandmarkenKnoten erhält er daraufhin eine seinem Standort entsprechende ID.
DynaMO übernimmt die Mechanismen sind von Pastry erweitert diese, um Lokalitätseigenschaften besser zu nutzen und dadurch Ressourcen zu sparen. Damit ist DynaMO für die
Anwendung in MANETs besser geeignet als Pastry. Die hier betrachtete Problematik findet
aber auch in DynaMO keine tiefere Aufmerksamkeit, obwohl sich bei der Dynamik mobiler
Netze die Frage noch dringender stellt.
3.2.6 Tapestry
Die Routing-Infrastruktur Tapestry [24] ist das letzte Overlay-Peer-to-Peer-System, das im
Rahmen dieser Arbeit untersucht werden soll. Es ist Teil der von Oceanstore [27], einem
System zur globalen verteilten Datenspeicherung der Universität von Kalifornien in Berkeley.
Struktur & Routing
Jeder Tapestry-Knoten wird durch eine Knoten-ID eindeutig identifiziert. Die einzige
Information, die jeder Knoten besitzt, ist die so genannte Neighbor Map, eine Routingtabelle,
die sowohl die Knoten-IDs als auch die IP-Adressen benachbarter Knoten enthält. Tapestry
folgt, wie Pastry auch, dem Plaxton-Routingschema. Das bedeutet, Nachrichten werden anhand
des längsten Präfixes der Knoten-ID weitergeleitet, bis der gewünschte Knoten gefunden wurde.
Abbildung 3-4 gibt ein Beispiel für das Routing mit dem Zielknoten 4598 an. Gleichzeitig lässt
sich daran erkennen, dass Tapestry im Unterschied zu beispielsweise Pastry oder Chord, die
eine Ringstruktur bilden, keine besondere Struktur auf dem darunter liegenden Netz etabliert,
sondern einen durch die Neighbor Maps erzeugten Graphen aufweist.
84F8
3E98
0325
9098
0098
2888
7598
1598
4598
D598
87CA
2118
Abbildung 3-4: Beispiel Tapestry-Routing (nach [26])
36
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 3.2 Ansätze in der Literatur
Um veröffentlichte Objekte im Netz schnell zu finden, wird ein verteiltes Verzeichnissystem
aufgebaut. Für die hier betrachteten Probleme paralleler Operationen spielt diese Zeigerstruktur
aber eine untergeordnete Rolle. Die Beschreibung dieses Aspekts ist daher in den Anhang D
verschoben.
Einfügen neuer Knoten
Damit sich ein neuer Knoten N in ein bestehendes Tapestry-Netz einloggen kann, muss er
zunächst seine Knoten-ID berechnen. Zudem ist es notwendig einen Peer des Netzes zu kennen,
der als Gateway-Knoten bezeichnet wird.
Die Neighbor Map des neu hinzukommenden Knoten muss initialisiert werden. Dies geschieht
in einem iterativen Verfahren, das die Nachbarknoten, die in der Neighbor Map enthalten sind,
kontaktiert und mit Hilfe derer Neighbor Maps die eigene Routingtabelle vervollständigt bis
eine hinreichende Genauigkeit erreicht wurde. Als Ausgangspunkt für das Verfahren wird die
Neighbor Map des Gateway-Knotens verwendet. Der Login schließt mit der Übernahme der
Objektverweise ab.
Fehlerbehandlung & Knotenaustritt
Verlässt ein Knoten freiwillig das Netz, teilt er dies zuvor den Knoten aus seiner Neighbor Map
mit. Die Nachbarn passen ihre Routingtabellen daraufhin an. Nun können die Objektverweise
vom ausscheidenden Knoten auf seinen Surrogatknoten in gleicher Weise übertragen werden,
wie beim Einfügen eines neuen Knotens.
Im Fall eines unfreiwilligen Knotenausfalls müssen die anderen Knoten die entstandene Lücke
erkennen und wieder schließen. Ausgefallene Knoten oder unterbrochene Verbindungen werden
von den Peers durch periodische Beacon-Nachrichten erkannt. Daraufhin können fehlerhafte
Einträge aus den Neighbor Maps entfernt werden.
Das Objektrepublishing erfolgt ebenfalls periodisch. Dadurch werden automatisch
Objektverweise, die vom ausgefallenen Knoten verwaltet wurden an den neuen Surrogatknoten
weitergeleitet und die Server-Pointer neu gesetzt. Alte Server-Pointer werden nach einer
bestimmten Zeit entfernt.
Bewertung
Tapestry definiert keine neue Struktur über dem physischen Netzwerk. Stattdessen erweitert es
die physische Struktur um ein Zeigersystem, das zum Auffinden von gespeicherten Objekten
dient. Tapestry kann daher auf Wartungsoperationen zur Strukturerhaltung verzichten. Beim
komplexen Login-Vorgang, der dazu dient die Routingtabellen des neuen Knoten und dessen
Nachbarn zu aktualisieren, sind Inkonsistenzen durch parallele Operationen durchaus möglich.
Die Weiterleitung von Nachrichten auf Basis von Routingtabellen ist aber sehr robust, da der
Zielknoten über verschiedene Routen erreicht werden kann. Die periodische Aktualisierung der
Zeigerstruktur ist für den Anwendungsbereich von Tapestry im Internet bei niedrigen
Fehlerwahrscheinlichkeiten völlig ausreichend. Temporäre Inkonsistenzen werden toleriert. Für
Netzwerke mit hoher Dynamik ist Tapestry nicht geeignet. Zhao, Kubiatowicz und Joseph
weisen darauf auch in [24] hin. Auch hier gilt, wie bei den zuvor betrachteten Overlays, dass der
37
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 3.2 Ansätze in der Literatur
Ansatz durch die spezielle Struktur und die Verwendung von Routingtabellen nicht allgemein
genug ist, um auch auf andere Overlays angewendet zu werden.
3.2.7 Lanes
Alle bisher beschriebenen Ansätze waren individuell auf die Anforderungen des jeweiligen
Overlay-Netzes zugeschnitten. Auch für Lanes wäre eine protokollspezifische Lösung denkbar,
um Fehler durch Knotenausfälle und parallele Operationen zu beheben. Im Folgenden wird eine
Möglichkeit für eine solche Lösung für Lanes vorgestellt.
Grundlage dieses Fehlermechanismus ist die Priorisierung der einzelnen Protokollteile, wodurch
eine Totalordnung auf den Operationen induziert wird. Eine Operation mit Priorität x kann eine
andere mit Priorität y abbrechen, wenn x<y gilt. Zudem wird eine Operation mit niedrigerer
Priorität als die der laufenden Operation nicht gestartet. Eine mögliche Ordnung der LanesOperationen könnte, beginnend mit der höchsten Priorität, wie folgt lauten: LaneBroken,
LaneSplit, LaneMerge, Logoff, Login. Das kann damit begründet werden, dass das LaneBroken
als Reparatur-Mechanismus elementar für die Funktionalität von Lanes ist. Darauf folgen die
langlaufenden Operationen Split und Merge. Die kurzen Operationen Login und Logoff haben
die geringste Priorität. Grundsätzlich ist aber auch eine andere Ordnung möglich.
Zu einem Zeitpunkt kann stets nur eine Operation ausgeführt werden. Dadurch wird ein
paralleles Ändern der Strukturdaten durch mehrere Operationen verhindert.
Für die kritischen Strukturvariablen Vorgängeradresse, Nachfolgeradresse und Adressen der
linken und rechten Nachbar-Lane werden temporäre Kopien angelegt, auf denen Änderungen
vorgenommen werden können. Nach erfolgreicher Ausführung einer Operation werden die
temporären Werte wieder in die Originalvariablen zurückkopiert.
Der Pseudocode in Abbildung 3-5 beschreibt den grundlegenden Ablauf einer Operation. Durch
ein Flag wird angezeigt, welche Operation aktuell ausgeführt wird. Der Index des Bit-Arrays
entspricht der Priorität.
operation(int priority) {
if(bitArray.selectedIndex() > priority){
//Operation niederer Priorität abbrechen
cancelOperation(bitArray.selectedIndex());
bitArray[priority] = 1;
copyTempVars(); //Temporäre Variablen initialisieren
//Operationscode
...
bitArray[priority] = 0;
putTempVars(); //Temporäre Werte zurückschreiben
}
}
cancelOperation(int priority) {
bitArray[priority] = 0;
send(AbortMessage);//Versende Abbruchnachricht (z.B. LoginAbort)
}
Abbildung 3-5: Prioritätsgesteuerte Operationsausführung
38
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 3.3 Zusammenfassung
Um den Abbruch einer Operation zu behandeln, wird jeder Teil des Protokolls individuell um
einen Zustand Cancel ergänzt. Dieser Zustand wird erreicht, wenn durch eine höher priorisierte
Operation auf demselben Knoten die Funktion cancelOperation() aufgerufen wird oder eine
Abort-Nachricht von anderen Knoten eintrifft. Daraufhin wird das entsprechende Bit
zurückgesetzt und die temporären Werte verworfen. Im ersten Fall wird zudem eine AbortNachricht an die anderen beteiligten Knoten gesendet. Zusätzlich zu dem neuen Zustand ist
noch eine Prüfung zu Beginn der Operation erforderlich, ob diese bezüglich ihrer Priorität
momentan überhaupt ausgeführt werden kann. Zustandsdiagramme, die den LoginMechanismus mit den beschrieben Erweiterungen darstellen sind im Anhang B zu finden.
Das beschriebene Verfahren besitzt kein atomares Commitment, was zu Problemen führt, da die
Knoten unterschiedlich lange mit einer Operation beschäftigt sind und somit zu
unterschiedlichen Zeitpunkten abschließen. Zum Beispiel hat der Reaktor 2 beim Lanes-Login
am wenigsten Aufwand und beendet den Vorgang deshalb als Erster. Ist eine Operation einmal
abgeschlossen, d.h. die temporären Variablenwerte wurden in die Originalvariablen
zurückkopiert, kann sie nicht mehr rückgängig gemacht werden. Eine danach noch eintreffende
Abbruch-Nachricht eines anderen Knotens kann nicht mehr behandelt werden. Die Erweiterung
jeder Operation des Overlay-Protokolls um einen Mechanismus für das atomare Commitment,
beispielsweise das 2-Phasen-Commitprotokoll, ist nicht praktikabel. Stattdessen werden
Wartefunktionen am Ende der Operationsausführung jedes Knotens verwendet, um annähernd
zeitgleiche Fertigstellungen der Operationen zu erreichen.
Die aktuell existierende Lanes-Implementierung [13] verwendet zwar nicht das soeben
beschriebene Verfahren, versucht aber in ähnlicher Weise die einzelnen Fehlersituationen, die
eintreten können, zu behandeln. Diese Implementierung, aber auch das beschriebene Verfahren
zeigen deutlich, dass eine individuelle Erweiterung jeder Operation des Overlay-Protokolls
aufwändig, komplex, schwer überschaubar und dadurch auch kaum wartbar ist. Dadurch wird
die Entwicklung von neuen korrekten Overlays sehr erschwert.
3.3
Zusammenfassung
Dieses Kapitel hat gezeigt, welche Probleme durch Operationen, die nebenläufig auf den
Strukturdaten des Overlays arbeiten, auftreten können. Die anschließende Analyse
verschiedener Overlay-Strukturen hat verschiedene Strategien aufgezeigt, wie mit diesen
Problemen umgegangen werden kann.
Alle beschriebenen Lösungsansätze für den Umgang mit Fehlern sind protokollspezifisch auf
die jeweiligen Overlay-Strukturen und Einsatzgebiete angepasst. Keine Lösung ist damit aber
allgemein genug, um einfach auf andere Overlays angewendet werden zu können. Die
Entwicklung korrekter Fehlermaßnahmen ist sehr komplex. Die potenziell eintretenden
Fehlerfälle sind schwer zu überschauen. Der entstehende Code ist aus diesem Grund auch
schlecht wartbar. Bei der Entwicklung neuer Overlays muss deshalb viel Aufwand in
Fehlerbehebungsmechanismen investiert werden. Eine generische, wiederverwendbare
Komponente wäre in diesem Fall wünschenswert. Natürlich haben individuelle Lösungen aber
auch den Vorteil die Besonderheiten und Gegebenheiten des jeweiligen Protokolls einbeziehen
zu können und daher eine für jeden Fall möglichst effiziente Lösung zu erreichen.
Einige der betrachteten Ansätze verwenden reaktive Fehlerkorrekturmaßnahmen in Form von
periodischen Reorganisationsmaßnahmen. Temporäre Inkonsistenzen werden toleriert. Im
Internet, wo im Vergleich zu mobilen Ad-hoc-Netzen, mit einer geringeren Fehlerrate und
39
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 3.3 Zusammenfassung
weniger Fluktuationen der Teilnehmerzahl zu rechnen ist, reichen diese Maßnahmen in der
Regel aus. Unter hohen Belastungen können diese Prozeduren die strukturelle Konsistenz der
Netze aber nicht mehr sichern. In diesem Fall wäre ein proaktiver Ansatz, d.h. die Vermeidung
von Fehlern, geeigneter.
Einige Overlays verwenden fehlertolerante Strukturen, beispielsweise Routingtabellen, die
Inkonsistenzen leichter verkraften, bauen erst gar keine expliziten neuen Strukturen auf, wie
zum Beispiel Tapestry, oder definieren ihre Struktur nur implizit. Dadurch sind weniger und
zudem fehlerresistentere Wartungsoperationen möglich.
Die vorgestellte prioritätsbasierte Lösung für Lanes hat zum Ziel, die Operationen zu einer
globalen Sequenz zu ordnen, um nebenläufige Datenzugriffe zu verhindern. Dieser Ansatz hat
aber den Nachteil, dass dadurch vollkommen auf die parallele Ausführung von Operationen
verzichtet wird, auch wenn diese möglich wäre. Zudem können durch die Verzögerungen bei
den wartenden Operationen Timeouts in den Overlay-Algorithmen auftreten.
Keiner der gefundenen Ansätze zeigte sich für den Einsatz in dynamischen mobilen Ad-hocNetzen als gut geeignet und zugleich generisch genug, um in verschiedenen Overlays zum
Einsatz zu kommen.
40
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 3.3 Zusammenfassung
41
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4 Konzeption
4
Konzeption
Es wurde bereits ausführlich beschrieben, dass Overlay-Netze
insbesondere in Ad-hocNetzen gewartet werden müssen, um auf neu hinzukommende Knoten, Knoten, die das Netz
verlassen, oder Topologieänderungen des darunter liegenden Netzes reagieren zu können. Jeder
Knoten verwaltet einen Teil der dafür nötigen Strukturinformationen des Overlays. Werden
mehrere Operationen, die Änderungen an diesen Zustandsdaten vornehmen, gleichzeitig
ausgeführt, können Dirty Reads, Inconsistent Reads und Lost Updates auftreten, wie es Kapitel
3 gezeigt hat. Bei der prototypischen Implementierung von Lanes konnten diese Effekte
beobachtet werden. Dort wurde versucht durch Hinzufügen von Fehlerzuständen und
Abbruchoperationen in den Protokollablauf, die einzelnen Protokollbestandteile zu isolieren. Es
hat sich aber gezeigt, dass auf diese Weise eine fehlerfreie Implementierung sehr komplex und
unüberschaubar wird. Eine Analyse anderer Overlay-Netze ergab ebenfalls keine
zufriedenstellende Lösung.
Die Grundidee, die hinter dieser Arbeit steht, ist daher, die Fehlerbehandlung nicht im OverlayProtokoll, sondern in einem eigenständigen System zu realisieren. Dabei orientiert sich diese
Arbeit an Datenbanksystemen, wo die gleichen Probleme auftreten und mit Hilfe von
Transaktionen gelöst werden können.
Dieses Kapitel beschreibt, wie ein solches Transaktionssystem für die Wartungsoperationen in
Overlay-Netzen aussehen kann, welche Komponenten und Techniken erforderlich sind und wo
die Probleme und Unterschiede zu klassischen Transaktionen in Datenbanksystemen liegen.
Zunächst wird ein Überblick über das ganze System gegeben, bevor auf die einzelnen
benötigten Teile genau eingegangen wird.
4.1
Gesamtarchitektur
Das zu realisierende System ist vergleichbar mit einem verteilten Datenbanksystem (vgl.
Abbildung 4-1). Jeder Knoten kann dabei als Server für den Zugriff auf die von ihm verwalteten
Strukturdaten angesehen werden. Die Operationen des darüber liegenden Overlay-Protokolls
werden durch globale Transaktionen zwischen den beteiligten Knoten geschützt. Das System ist
homogen, da in der Regel alle Knoten eines Overlays gleichberechtigt agieren und die gleichen
Strukturen verwalten.
Somit ist ein verteilter Transaktionsmanager und die von ihm benötigte Komponenten zu
entwickeln. Durch diese Transaktionsschicht wird verhindert, dass die Algorithmen des
Overlay-Protokolls direkt auf die Strukturdaten zugreifen. Abbildung 4-2 zeigt, wie sich diese
neue Schicht und ihre Komponenten, die im Folgenden beschrieben werden, zu einem
Gesamtsystem zusammenfügen. Das System muss die ACID-Eigenschaften der Wartungstransaktion garantieren können. Dabei spielt die Dauerhaftigkeit im vorliegenden Fall eine eher
untergeordnete Rolle, da Knotenausfälle ein Zurücksetzen des jeweiligen Knotenzustands beim
Wiederanlauf zur Folge haben. Die Wahrung von Atomizität, Konsistenz und Isolation erfolgt
in zwei Ebenen.
42
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.1 Gesamtarchitektur
1
T
2
5
TA
K
3
T
4
Abbildung 4-1: Lanes vs. Verteiltes DBMS
Zum einen müssen die Knoten diese Eigenschaften lokal garantieren (lokale Konsistenz).
Hierzu greifen die Overlay-Operationen über Transaktionen auf die Strukturinformationen zu.
Ein Scheduler serialisiert Lese- und Schreiboperationen dieser Transaktionen so, dass keine
Inkonsistenzen möglich sind, bzw. macht gegebenenfalls fehlerhafte Transaktionen rückgängig.
Prinzipiell sind alle gängigen Schedule-Protokolle (vgl. [8]), beispielsweise sperrenbasierte
Verfahren, hier denkbar. Je nachdem, welcher Scheduler gewählt wurde, sind verschiedene
zusätzliche Komponenten für dessen Funktion notwendig. Im Allgemeinen sind das ein LogManager, eine Sperrenverwaltung sowie ein System zur Erkennung, Beseitigung und
Vermeidung von Verklemmungen.
Abbildung 4-2: Gesamt-Architektur
43
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.2 Commit-Protokoll
Neben der Wahrung der lokalen Konsistenz muss darüber hinaus auch die Atomizität und somit
auch die Konsistenz zwischen den Knoten untereinander sichergestellt werden können (globale
Konsistenz). Das bedeutet, dass die Knoten sich gegenseitig darüber abstimmen müssen, ob und
wann ein Commit der Wartungsoperationen stattfinden kann. Zur Lösung dieses Problems wird
eines von vielen in der Literatur ([5], [7]) beschriebenen Commit-Protokolle eingesetzt. Das
Commit-Protokoll und das Overlay-Protokoll, in diesem Fall das Lanes-Protokoll, arbeiten
unabhängig voneinander. Dem Overlay-Protokoll steht eine wohldefinierte Schnittstelle des
Transaktionsmanagers zur Verfügung, mit deren Hilfe der Zugriff auf den Knotenzustand und
dessen Änderung ermöglicht wird.
Trotz der weitgehenden Analogie zu verteilten Datenbanksystemen gibt es auch Unterschiede.
Im Gegensatz zu Datenbanken ist die Anzahl zu schützender Daten gering. Bei Lanes sind das
nur sieben Werte (Vorgänger, Nachfolger, Vor-Vorgänger, linke und rechte Lane-Adresse, linke
und rechte Nachbar-Lane). Zudem ist die Anzahl paralleler Operationen auf einem Knoten eher
niedrig. Dauerhaftigkeit spielt, wie bereits beschrieben, keine Rolle. Ein interessanter Aspekt ist
darüber hinaus, dass die zu schützenden Zustandsdaten, insbesondere die Knotenadressen,
gleichzeitig als Metadaten für das verteilte Datenbanksystem dienen. Diese Unterschiede sind
auch der Grund dafür, dass statt der Verwendung eines verfügbaren verteilten Datenbanksystems eine individuelle Entwicklung des Transaktionssystems geeigneter ist.
4.2
Commit-Protokoll
Das so genannte Consensus-Problem [6] beschreibt eine Gruppe von Problemen. Die
Gemeinsamkeit dieser Probleme besteht darin, dass sich eine Menge von Prozessen auf einen
gemeinsamen Wert einigen müssen. Dabei spielen zwei Funktionen eine wesentliche Rolle:
Vorschlagen (engl.: propose) und Entscheiden (engl.: decide). Zunächst wird von jedem Prozess
ein möglicher finaler Wert vorgeschlagen. Daraufhin entscheidet jeder Prozess, welcher der
vorgeschlagenen Werte gewählt werden soll. Dabei sind folgende Randbedingungen zu
beachten:
1. Keine 2 Prozesse entscheiden unterschiedlich (Einigung)
2. Jeder korrekte Prozess erreicht letztendlich eine Entscheidung (Terminierung)
3. Die Prozesse müssen sich für einen vorgeschlagenen Wert entscheiden (Gültigkeit)
Das atomare Commitment von Transaktionen, d.h. die gemeinsame Entscheidung aller
beteiligten Knoten eines verteilten DBMS auf Commit oder Abort, ist eine spezielle
Ausprägung des Consensus-Problems und im vorliegenden Fall der Wartung von OverlayNetzen von Interesse. Der transaktionale Schutz der Wartungsoperationen kann helfen, die
Atomizität und Isolation dieser Operationen zu garantieren.
4.2.1 Besonderheiten im vorliegenden Anwendungsfall
Um die Atomizität und Isolation von Wartungsoperationen in Overlay-Netzen sicherzustellen,
muss wie gerade beschrieben am Ende dieser Operationen eine gemeinsame Entscheidung der
beteiligten Knoten über den Erfolg oder Misserfolg der Operation getroffen werden. Dabei
eignet sich ein analoges Vorgehen wie beim Commitment bei Transaktionen in
Datenbanksystemen. Folgende Besonderheiten sind im vorliegenden Fall jedoch zu beachten:
44
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.2 Commit-Protokoll
1. Knoten können ausfallen:
Im Gegensatz zu VDBMS können die anderen Knoten trotz des Ausfalls mit der
getroffenen Entscheidung abschließen. Der Knotenausfall wird in höherer Ebene vom
Overlay-Protokoll behandelt. Dabei ist es unerheblich, ob der ausgefallene Knoten die
Aktion noch ausführen konnte oder nicht, da nach einem Ausfall sämtliche
Statusinformation gelöscht wird und der Knoten sich erneut im Overlay-Netz anmelden
muss.
2. Verbindungen zwischen Knoten können abbrechen:
Gehen Nachrichten zwischen Knoten verloren, so wird ein Verbindungsabbruch
zwischen diesen Knoten vermutet. Ist ein Knoten dadurch isoliert, so muss dieser
Knoten das erkennen. Die Isolation eines Knotens ist gleichbedeutend mit dem
unfreiwilligen Ausscheiden aus dem Overlay-Netz, d.h. der Knoten ist aus der
Netzstruktur ausgeschlossen und muss sich wie im ersten Fall ggf. neu anmelden. Die
anderen Knoten können nicht unterscheiden, ob ein Knoten ausgefallen ist oder nur die
Verbindung unterbrochen wurde.
Die Konsistenz der Statusdaten wird durch den Ausfall von Knoten oder durch Wegfallen der
Verbindung also nicht verletzt. Dadurch lassen sich die Protokolle etwas vereinfachen.
Insbesondere ist keine Sicherung des Fortgangs des Commits durch Logdateien erforderlich, da
keine Wiederanlauf-Recovery nach einem Knotenausfall erforderlich ist.
4.2.2 Commit-Protokoll-Analyse
Beim vorliegenden Problem sind aus der Literatur ([5], [7]) viele Verfahren zur Lösung des
Commit-Problems am Ende verteilter Transaktionen bekannt. Im Folgenden werden mögliche
Protokolllösungen vorgestellt und auf ihre Tauglichkeit für den Einsatz in mobilen Ad-hocNetzen hin untersucht.
Lineares 2-Phasen-Commit-Protokoll
Beim linearen 2-Phasen-Commit übernimmt ein Knoten die Rolle eines Koordinators. Der
Koordinator legt eine fest definierte lineare Ordnung der Knoten fest (vgl. Abbildung 4-3). Er
selbst ist der erste Knoten. Soll die Transaktion abgeschlossen werden, sendet der Koordinator
eine Ready-Meldung an den Nachfolgeknoten. Ist dieser zu einem Commit bereit gibt er
seinerseits eine Ready-Meldung an seinen Nachfolger weiter. Andernfalls sendet er eine AbortNachricht an den Vorgängerknoten zurück und führt das Abort aus. Die nachfolgenden Knoten
erkennen den Abort durch einen Timeout auf Grund der fehlenden Ready-Meldung.
Abbildung 4-3: lineares 2PC
Empfängt der letzte Knoten die Ready-Meldung (Die Knotenreihenfolge wird in der ReadyMeldung mitgeschickt.) antwortet er mit einer Ack-Nachricht, falls er mit dem Commit
einverstanden ist, und führt das Commit aus. Die anderen Knoten leiten das Ack bis zum
Koordinator weiter und führen ebenfalls das Commit aus.
45
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.2 Commit-Protokoll
Auftretende Fehler in der ersten Phase, d.h. während der Kommunikation von Koordinator weg,
sind unkritisch. Der Wegfall einer Ready-Nachricht würde von den nachfolgenden Knoten
durch einen Timeout erkannt und ein Abort eingeleitet. Die restlichen Knoten könnten auf das
resultierende Ausbleiben eines Acks ebenfalls mit Abort reagieren. Damit wäre auch der
Wegfall einer Abort-Nachricht auf dem Rückweg kein Problem mehr, da alle vorangehenden
Knoten das Abort sowieso nach einem Timeout durchführen. Der kritische Punkt liegt im
Verlust einer Ack-Nachricht, da alle Knoten nach und einschließlich dem Sender des Acks
bereits ein Commit ausgeführt haben, alle vorangehenden Knoten aber auf Grund des Fehlens
einer Nachricht auf Abort entscheiden würden. Es ist also einem Knoten nicht möglich
festzustellen, ob er isoliert von den anderen Knoten ist. Umgekehrt kann ein isolierter Knoten
dazu führen, dass die restlichen Knoten zu einem inkonsistenten Ergebnis kommen.
Das lineare 2-Phasen-Commit-Protokoll benötigt nur 2(N-1) Nachrichten (N: Anzahl der
beteiligten Subtransaktionen) und scheint somit für den mobilen Bereich, in dem Ressourcen
knapp sind und somit möglichst wenig Aufwand getrieben werden soll, geeignet zu sein. Dieser
Vorteil wird jedoch durch den Verlust der Parallelität erkauft, da die Teilnehmer sequentiell
nacheinander über Commit oder Abort entscheiden. Ein weiterer Nachteil dieses Verfahrens ist
das Aufprägen der linearen Struktur ungeachtet der Struktur des dazugehörenden OverlayNetzes. Die möglichen Inkonsistenzen beim Ausfall von Knoten sind aber der entscheidende
Grund, das lineare 2-Phasen-Commitprotokoll nicht zu wählen.
Zentrales 2-Phasen-Commit-Protokoll
Das zentrale 2-Phasen-Commit-Protokoll verwendet wie im linearen Fall zwei Schritte:
Abstimmung und Entscheidung. Die Entscheidungsfindung geschieht jedoch von allen
Teilnehmern gleichzeitig unter Koordination eines Koordinators.
Abbildung 4-4 und Abbildung 4-5 zeigen den Protokollablauf für den Koordinator bzw. für die
Teilnehmer. Sobald die laufende Operation abgeschlossen werden soll, sendet der Koordinator
eine Prepare-Nachricht an alle Teilnehmer und wechselt in den Prepare-Zustand. Dort wartet er
auf die ankommenden Abstimmungsergebnisse der Teilnehmer. Die Teilnehmer antworten auf
eine Prepare-Nachricht mit einer Ready-Meldung und wechseln ebenfalls in den PrepareZustand, um auf das Abstimmungsergebnis vom Koordinator zu warten, oder senden eine
NotReady-Nachricht, falls sie zu einem erfolgreichen Abschluss der Operation nicht bereit sind.
Im letzten Fall führen sie sofort ein Abort aus, da durch ihre negative Stimme der Koordinator
sicher nicht mehr auf Commit entscheiden kann.
Abbildung 4-4: 2PC
Koordinator
46
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.2 Commit-Protokoll
Empfängt der Koordinator ausschließlich Ready-Nachrichten entscheidet er auf Commit. Fehlen
Antworten bis zum Ablauf eines Timers oder ist unter den Abstimmungsnachrichten der
Teilnehmer eine NotReady-Nachricht wird die Operation abgebrochen. Die Teilnehmer warten
auf die Entscheidung des Koordinators und bestätigen sie mit einem Ack. Nach dem Erhalt der
Acks der Teilnehmer für die Entscheidung oder einem weiteren Timeout ist die Operation
seitens des Koordinators beendet. Auch die Teilnehmer führen die vom Koordinator erhaltene
Aktion aus und schließen ihre Transaktion ab.
Abbildung 4-5: 2PC
Teilnehmer
Während des gesamten Protokollablaufs können aber wiederum Fehler auftreten, die vor allem
in der Unsicherheitsphase, d.h. den Zeitraum zwischen dem Senden der Ready-Nachricht des
Teilnehmers und der Ankunft der Entscheidung des Koordinators zu Problemen führen. Im
Original-2PC-Protokoll führt ein Fehler an dieser Stelle zur Blockade des Protokolls bis der
Koordinator dem Teilnehmer die Entscheidung mitteilen kann. In dem vorliegenden speziellen
Fall des Schutzes von Wartungsoperationen, kann ein Terminierungsprotokoll angegeben
werden, um eine Blockade zu vermeiden. Es ist in den Zustandsdiagrammen hellgrau und
gestrichelt hervorgehoben und wird im Folgenden zusammen mit den möglichen
Fehlersituationen beschrieben.
Das Ausbleiben von Nachrichten wird mit Hilfe von Timern abgehandelt. Bei ausbleibender
Prepare-Nachricht reagiert der Teilnehmer nach Ablauf der festgelegten Maximaldauer der
Transaktion mit einem Abbruch. Der Koordinator erkennt den Fehler anhand der ausbleibenden
Abstimmungsnachricht. Gehen Abstimmungsnachrichten verloren wird laut Protokoll ohnehin
vom Koordinator auf Abort entschieden.
Probleme bereiten jedoch Nachrichtenausfälle in der Unsicherheitsphase, also das Ausbleiben
der Entscheidung des Koordinators oder der Acks. Diese Fälle müssen wie bereits erwähnt über
ein Terminierungsprotokoll gelöst werden. Empfängt ein Teilnehmer keine Entscheidung vom
Koordinator innerhalb einer festgelegten Zeitspanne, sendet er eine MissingResult-Nachricht an
47
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.2 Commit-Protokoll
alle an der Operation beteiligten Knoten. Kennt ein anderer Knoten die Entscheidung des
Koordinators, gibt er sie per MissingResultAnswer-Nachricht an den anfragenden Knoten
zurück, sodass dieser die Operation ebenfalls korrekt abschließen kann. Erhält ein Knoten keine
Antwort auf seine Anfrage, geht er davon aus, dass die Verbindung zu den anderen Knoten
unterbrochen wurde. In diesem Fall ist aber auch die Overlay-Struktur nicht mehr zu reparieren,
sodass eine ConnectionLost-Meldung an den Anwendungsprozess des Knotens zurückgeliefert
wird, um ein Logout zu erzwingen. Die anderen Knoten bleiben davon unberührt. Sie können
die Operation gemäß Koordinatorentscheidung beenden. Der Verlust eines Knotens wird später
durch die Overlay-Mechanismen erkannt und durch eine neue Wartungsoperation behoben. An
dieser Stelle ist der Unterschied zum normalen 2PC-Protokoll. Dort muss der Teilnehmer auf
die Antwort des Koordinators warten und ist solange blockiert.
Der Verlust der Ack-Nachrichten ist nicht so kritisch, da der Koordinator davon ausgeht, dass
sich der Teilnehmer die Entscheidung von den anderen Teilnehmern besorgt. Erhält der
Koordinator jedoch keine Acks, kann er davon ausgehen, dass er selbst der isolierte Knoten ist
und verlässt das Overlay-Netz. Falls der Koordinator ausfällt, hat das zur Folge, dass alle an der
Transaktion beteiligten Knoten das Netz verlassen und sich neu einloggen müssen. Das könnte
durch einen Mechanismus vermieden werden, der es erlaubt, einen neuen Koordinator zu
wählen. Ein solcher Mechanismus ist nicht trivial und führt seinerseits zu neuen
Schwierigkeiten, die gelöst werden müssen. Der Aufwand, der durch das Overlay-Netz
inklusive dem Schutzsystem verursacht wird, muss so gering wie möglich gehalten werden, da
sonst die Gefahr besteht den beschriebenen Vorteil gegenüber der naiven Fluten-Methode zu
verlieren. In dieser Arbeit wird daher auf ein Verfahren zur Koordinatorwahl verzichtet.
Das 2-Phasen-Commit-Protokoll stellt eine mögliche Lösung im vorliegenden Anwendungsfall
dar. Es besitzt einen Kommunikationsaufwand von 4(N-1) Nachrichten.
3-Phasen-Commit-Protokoll
Das 3-Phasen-Commit-Protokoll ist eine Erweiterung des 2-Phasen-Commits mit dem Ziel
Blockierungen, die in der Unsicherheitsphase durch die Abhängigkeit der Teilnehmer vom
Koordinator beim Ausfall von Knoten entstehen können, zu verhindern. Dies ist jedoch nur
möglich, wenn nicht alle Knoten ausfallen und keine Kommunikationsfehler auftreten. Es kann
bewiesen werden, dass ein atomares Commit-Protokoll für diesen Fall nicht existieren kann [4].
Die Grundidee dieses Protokolls ist, dass kein Knoten bereits auf Commit entschieden haben
kann, solange ein anderer Knoten noch unsicher ist. Dies wird durch einen zusätzlichen Schritt
im Commit-Fall erreicht, einem so genannten Pre-Commit-Zustand. Diese Erweiterung bedeutet
aber auch, dass das Nachrichtenaufkommen weiter auf 6(N-1) steigt.
Der Koordinator (vgl. Abbildung 4-6) sendet eine Prepare-Nachricht an jeden Teilnehmer, wenn
eine verteilte Transaktion abgeschlossen werden soll, und wechselt in den Prepare-Zustand.
Dort verweilt er bis zum Ablauf eines Timers und sammelt alle von den Teilnehmern
ankommenden Antworten. Ein Teilnehmer antwortet entweder mit Ready, falls ein Commit
durchgeführt werden kann, oder sonst mit NotReady und wechselt ebenfalls in den PrepareZustand. Sind nach Ablauf des Timers beim Koordinator alle Antworten eingetroffen und es
handelt sich ausschließlich um Ready-Nachrichten, wird eine PreCommit-Nachricht an die
Teilnehmer versendet und in den Vor-Commit-Zustand gewechselt (Hier ist der Unterschied
zum 2-Phasen-Commit-Protokoll, bei dem direkt in den Commit-Zustand gewechselt würde).
Falls nicht alle Antworten der Teilnehmer pünktlich eintreffen oder mindestens eine NotReadyNachricht dabei sein sollte, wird auf Abort entschieden, eine Abort-Nachricht versendet und in
den Abort-Zustand gewechselt.
48
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.2 Commit-Protokoll
Der Teilnehmer (vgl. Abbildung 4-7) wartet im Prepare-Zustand auf die Entscheidung des
Koordinators. Beim Empfang einer Pre-Commit-Nachricht wird mit einem PreAck bestätigt, in
den PreCommit-Zustand gewechselt und auf die entgültige Entscheidung des Koordinators
gewartet. Wird eine Abort-Nachricht empfangen, wird diese mit einer Bestätigung quittiert und
die Transaktion abgebrochen.
Abbildung 4-6: 3PC - Koordinator
Der Koordinator wartet im Erfolgsfall im PreComit-Zustand auf die PreAcks der Teilnehmer.
Falls alle PreAcks innerhalb einer Zeitspanne empfangen werden, wird eine Commit-Nachricht
gesendet und in den Commit-Zustand gewechselt, andernfalls eine Abort-Nachricht, wie bereits
beschrieben.
Der Teilnehmer wartet im PreCommit-Zustand auf die endgültige Entscheidung des
Koordinators und bestätigt diese mit einem Ack. Die Transaktion wird daraufhin je nach
Entscheidung des Koordinators abgebrochen oder abgeschlossen.
Abbildung 4-7: 3PC - Teilnehmer
Wie bereits im 2PC-Protokoll sind Nachrichtenverluste außerhalb der Unsicherheitsphase
unkritisch und werden nach einem Timeout mit einem Abort behandelt, wie zum Beispiel beim
Verlust von Prepare-, Ready-, NotReady-, PreCommit- oder PreAck-Nachricht.
49
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.2 Commit-Protokoll
Das Problem bereitet auch hier der Verlust der entgültigen Entscheidung des Koordinators.
Beim Verlust der Commit-Nachricht bleibt der Teilnehmer unsicher, ob nicht vielleicht doch
noch vom Precommit-Zustand in den Abort-Zustand gewechselt werden soll. Dieser Fall kann
allerdings nur auftreten, wenn vorher bereits ein PreAck verloren gegangen ist. An dieser Stelle
könnte ein ähnliches Terminierungsprotokoll zum Einsatz kommen, wie es bereits beim 2PCProtokoll beschrieben wurde.
Zusammenfassung
Es wurden die gängigsten Commit-Protokolle aus dem Transaktionsbereich vorgestellt und auf
die Gegebenheiten in Overlay-Netzen angepasst. Welches dieser Protokolle eignet sich nun am
besten für den Einsatz als Schutzmechanismus der Wartung von Overlay-Netzen?
Das lineare 2-Phasen-Commit-Protokoll hat gerade für den mobilen Bereich den Vorteil,
wenige Nachrichten zu benötigen. Dem entgegen steht das Problem, dass bereits ein
ausgefallener Knoten den ganzen Protokollablauf stören und zu einem erneuten Start des
Protokolls unter Ausschluss dieses Knotens führen kann. Gerade im mobilen Bereich ist, auf
Grund der geringen Reichweite der Geräte, der Ausfall von Nachrichten keine Seltenheit, sodass
dieses Protokoll wenig geeignet erscheint.
Eine mögliche Lösung für das Problem stellt das 3-Phasen-Commit-Protokoll dar. Mit dem
zusätzlichen Terminierungsprotokoll kann es den Ausfall einzelner Knoten überstehen. Der
Nachteil besteht jedoch in der hohen Zahl der benötigten Nachrichten. Zudem kann das 3Phasen-Commit-Protokoll seinen Vorteil gegenüber dem 2-Phasen-Commit im vorliegenden
Fall nicht ausspielen, da durch das Entfernen isolierter Knoten aus dem Overlay-Netz keine
langen Blockierungen auftreten.
Am geeignetsten der untersuchten Protokolle ist somit das zentrale 2-Phasen-Commit-Protokoll,
das mit dem gegebenen Terminierungsprotokoll eine funktionell zufriedenstellende Lösung der
Problemstellung verspricht. Dennoch ist der Aufwand des Terminierungsprotokolls nicht
unerheblich. Gerade für Operationen, die viele Knoten betreffen muss der Aufwand dem Nutzen
kritisch gegenübergestellt und alternative Möglichkeiten abgewägt werden.
Kritisch sind Verbindungsabbrüche und Nachrichtenausfälle während des Commitments. Die
betroffenen Knoten versuchen, sich die Entscheidung des Koordinators mit Hilfe eines
Fehlerprotokolls zu besorgen. Ist diese Fehlerbehebung jedoch erfolglos, kann die Konsistenz
der Zustandsdaten nicht mehr gewährleistet werden, da die Gefahr besteht, dass der isolierte
Knoten anders entscheiden könnte als der Koordinator. Bei Inkonsistenzen der Zustandsdaten
kann auch der transaktionale Schutz die Korrektheit späterer Operationen nicht mehr
gewährleisten, da das Transaktionssystem mit denselben Adressen arbeitet wie das zu
schützende Overlay-Protokoll. Zum Schutz vor solchem Verhalten muss der isolierte Knoten
daher einen Zwangslogout, wie für das zentrale 2-Phasen-Commitprotokoll bereits beschrieben,
durchführen.
4.2.3 Funktionelle Anpassungen
Der vorhergehende Abschnitt hat gezeigt, dass das 2-Phasen-Commit-Protokoll das für die
gegebenen Anforderungen geeignetste der hier vorgestellten Protokolle ist. Allerdings ist eine
Verwendung des Protokolls in seiner Grundform, wie sie oben beschrieben wurde, direkt nicht
50
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.2 Commit-Protokoll
möglich, sodass einige Anpassungen vorgenommen werden müssen. Warum diese notwendig
sind und wie sie im Einzelnen aussehen wird nachfolgend geschildert.
Zwei Zielsetzungen werden mit den Änderungen im funktionellen Ablauf des 2-PhasenCommits verfolgt. Einerseits soll durch die Änderungen eine weitgehende Transparenz des
Commit-Protokolls gegenüber dem Overlay-Protokoll erreicht werden. Zum anderen wird
zusätzlich versucht den Aufwand des Commitments zu reduzieren.
Beim 2-Phasen-Commit ist es für die Funktion des Protokolls erforderlich, dass sich die
Teilnehmer und der Koordinator kennen. Welche Knoten an einer Operation beteiligt sind hängt
vom jeweiligen Overlay ab. Dennoch sollen die Wahl des Koordinators sowie die Bekanntgabe
der Teilnehmer gegenüber der Implementierung des Overlays weitgehend transparent sein. Es
wird deshalb darauf verzichtet diese Variablen durch explizite Methodenaufrufe des
Transaktionsmanagers zu setzen. Stattdessen ist ein anderer Mechanismus zu finden, der diese
Aufgabe übernimmt. In dieser Arbeit wird der Ansatz verfolgt, eine Protokollierung der
Empfängeradressen gesendeter Nachrichten jedes beteiligten Knotens durchzuführen. Diese
Adresslisten werden von jedem Knoten zusammen mit seinem Transaktionsergebnis an den
Koordinator gesendet. Als Koordinator wird immer der Initiator einer Aktion gewählt. Die
Koordinatoradresse ist dann Teil der verwendeten Session-ID und somit jedem Knoten bekannt.
Bis zum Empfang der Listen sind dem Koordinator die Teilnehmer unbekannt. Deshalb wird
auf die initiale Aufforderung zum Commit verzichtet. Stattdessen wird einfach auf die Ankunft
der Abstimmungsnachrichten gewartet. Durch die Konsolidierung der Adresslisten kann der
Koordinator alle beteiligten Teilnehmer herausfinden und gegebenenfalls fehlende
Abstimmungsnachrichten erkennen. Die Behandlung dieser Fehler beschreibt der folgende
Abschnitt. Das beschriebene Kennenlernprotokoll (Get-to-Know-Protokoll) wird an einem
Beispiel in Abbildung 4-8 dargestellt. Das Beispiel zeigt eine Operation, an der drei und
manchmal auch vier Knoten beteiligt sind. Knoten 1 ist der Initiator der Operation und somit
auch der Koordinator. Beim Commit senden alle beteiligten Knoten ihren Abschlusswunsch und
die Adressen der Knoten, mit denen sie während der Operation kommuniziert haben an den
Koordinator. Knoten 2 teilt dem Koordinator beispielsweise mit, das er mit Knoten 1 und 3 in
Kontakt stand.
C
True
2
1
True
2, (4)
2
True
1, 3
3
optional
4
True
Abstimmung
Abbildung 4-8: Get-to-Know-Protokoll
Auf Grund der Kenntnis der Teilnehmer kann der Koordinator nun das Transaktionsergebnis
bestimmen und den Teilnehmern auch direkt bekannt geben. Eine explizite Bestätigung durch
die Teilnehmer ist nicht erforderlich, wenn auf ein zuverlässiges Transportprotokoll aufgesetzt
wird. Der Koordinator erkennt dadurch nicht angekommene Ergebnisse.
Probleme bereitet das Terminierungsprotokoll der Teilnehmer bei Nichterhalt eines Ergebnisses,
da einem Teilnehmer durch das eingeführte Verfahren nicht notwendigerweise die anderen
Teilnehmer bekannt sein müssen. An dieser Stelle wird daher statt einer gezielten Anfrage eine
51
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.2 Commit-Protokoll
Broadcastsuche durchgeführt, auf die ein anderer Knoten, der das Ergebnis der Transaktion
kennt, antwortet.
Neben der Transparenz haben die beschriebenen Anpassungen des 2-Phasen-Commits einen
Aufwandsvorteil. Da die Abstimmungsanforderungsnachrichten des Koordinators sowie die
abschließenden Bestätigungen der Teilnehmer entfallen, halbiert sich die Anzahl der benötigten
Nachrichten auf 2(N-1). Allerdings nimmt der Aufwand im Fehlerfall durch die verwendete
Broadcastfunktion zu.
4.2.4 Netzwerkpartitionierungen
Während der Kommunikation der Knoten können Netzwerkpartitionierungen entstehen. Das 2Phasen-Commitprotokoll reagiert auf diese Verbindungsabbrüche unterschiedlich, je nachdem,
in welcher Phase die Störungen auftreten. Alle Knoten müssen ihre Stimme an den Koordinator
melden. Bleiben Stimmen aus, wird auf Abort entschieden. In der Entscheidungsphase sorgt das
Terminierungsprotokoll dafür, dass ein isolierter Knoten nach einem vergeblichen Versuch, die
Entscheidung von den anderen Knoten zu erfahren, aus dem Overlay-Netz entfernt wird.
Treten also Netzwerkpartitionierungen bereits vor Beginn des Commit-Protokolls auf, wird
momentan auf Abort entschieden und die entsprechende Transaktion zurückgesetzt. Die
Analyse des LanesBroken-Mechanismus im Lanes-Overlay hat jedoch gezeigt, dass das nicht
immer wünschenswert ist. Trotz einer gebrochenen Lane findet der Algorithmus einen
erfolgreichen Abschluss. Der Grund für diesen Gegensatz liegt in der eigenständigen
Fehlerbehebung des Lanes-Protokolls. Im Gegensatz zum Lanes-Login, für den keine
Fehlerbehandlung in der Lanes-Spezifikation beschrieben ist, wird beim LaneBrokenAlgorithmus explizit auf Fehler reagiert, die bei anderen Operationen zum Zurücksetzen führen
würden. Das Commit-Protokoll wird somit ganz oder zumindest teilweise von seiner Aufgabe
enthoben. Im Nichtfehlerfall bleibt die Funktionalität des Commit-Protokolls aber unberührt.
Um das Problem zu lösen kann eine spezielle Commit-Operation eingeführt werden. Auf der
Teilnehmerseite dient sie dazu, eine zum Zwangslogoff alternative Aktion für den Fall der
Isolation von den anderen Knoten auszuwählen. Jedes Overlay-Protokoll definiert einen Satz
solcher Alternativoperationen, auf die durch Angabe ihrer Kennziffer zugegriffen werden kann.
Die Null bezeichnet dabei den erzwungenen Knotenausstieg also die Defaultoperation.
Auf der Seite des Koordinators ist das Toleranzverfahren komplexer. Ihm wird mitgeteilt, wie
viele fehlende Teilnehmerstimmen im Fehlerfall tolerierbar sind. Durch die Modifikationen des
2-Phasen-Commits, die im letzten Kapitel beschrieben wurden, entsteht hierbei jedoch ein
Problem. Die Anzahl aller an einer Operation beteiligten Knoten lässt sich nur abschätzen, da
beim Verlust von Abstimmungsnachrichten nicht nur das gewünschte Ergebnis des
Teilnehmerknotens verloren geht, sondern auch die Adressen der Kommunikationspartner
dieses Knotens. Daher kann es vorkommen, dass der Koordinator von der Abwesenheit eines
Knotens nichts weiß, falls auch dessen Abstimmungsnachricht verloren geht.
Das Beispiel in Abbildung 4-9 verdeutlicht den beschriebenen Sachverhalt. Das Netzwerk ist
zwischen Knoten 2 und 3 partitioniert. Der Koordinator (Knoten 1) erkennt den Fehler, da in der
Adressliste von Knoten 2 der dritte Knoten enthalten ist, von diesem aber keine
Abstimmungsnachricht vorliegt. Knoten 4 ist dem Koordinator jedoch völlig unbekannt, weil er
nur in der verlorenen Adressliste von Knoten 3 genannt wird.
52
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.2 Commit-Protokoll
Partitionierung
2
C
True
2
1
optional
3
True
1, 3
4
True
2, (4)
True
-
Abstimmung
Abbildung 4-9: Beispiel Netzpartitionierung
Für die Gesamtknotenzahl K gilt:
K
k11 k12 k 21 k 22
mit
k11:
(1)
Anzahl der Knoten, die in einer erhaltenen Adressliste enthalten sind und
deren Abstimmungsnachricht durch den Koordinator empfangen wurde
(im Beispiel: Knoten 1 + 2)
Anzahl der Knoten, die in einer keiner erhaltenen Adressliste enthalten sind,
deren Abstimmungsnachricht aber durch den Koordinator empfangen wurde
(im Beispiel: kein solcher Knoten vorhanden)
Anzahl der Knoten, die in einer erhaltenen Adressliste enthalten sind, deren
Abstimmungsnachricht aber durch den Koordinator nicht empfangen wurde
(im Beispiel: Knoten 3)
Anzahl der Knoten, die weder in einer erhaltenen Adressliste enthalten sind,
noch deren Abstimmungsnachricht durch den Koordinator empfangen wurde
(im Beispiel: Knoten 4)
k12:
k21:
k22:
Zwei Fälle können unterschieden werden. Gilt k12= k21= k22=0 ist kein Fehler aufgetreten. Hier
ist aber vor allem der zweite Fall, d.h. das Vorhanden sein von Fehlern (k12, k21, k22 0) von
Interesse.
Unter Hinzunahme von Anwendungsinformationen über die minimale bzw. maximale Anzahl
an der Operation beteiligter Knoten (kmin bzw. kmax (Im Beispiel 3 bzw. 4)) lässt sich die einzige
Unbekannte k22 abschätzen:
(1)
k min
K
k max
k min
k11 k12
k 21 k 22
k max
k min
k11 k12
k 21
k max
k 22
k11 k12 k 21
(2)
Für die Anzahl ausgefallener Knoten kx ergibt sich daraus:
kx
(2)
k min
X min
53
k 21 k 22
k11 k12
kx
kx
X max
k max
k11 k12
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.3 Schedule-Protokolle
Wird beim Commit als Toleranz die maximale erlaubte Anzahl ausgefallener Knoten X
angegeben, kann damit direkt entschieden werden, dass
das Commit durchgeführt werden kann, falls X
Xmax
die Operation abgebrochen werden muss, wenn X < Xmin
In der Praxis sind die beiden Randfälle X = 0 (keine Toleranz) und X = kmax (vollständige
Isolation des Koordinators) von größter Bedeutung. Unsicherheit bei der Entscheidung existiert
im Bereich X
[Xmin, Xmax), da die tatsächliche Anzahl ausgefallener Knoten nicht exakt
bestimmt werden kann. Um auch in diesem Fall eine Entscheidung herbeizuführen, werden zwei
Toleranzlevel eingeführt. Bei einer strengen Strategie wird bei Fällen im unsicheren Bereich
stets auf Abort entschieden und die Menge tolerierbarer Fälle somit eingeschränkt (hartes
Toleranzlevel). Die Alternative hierzu ist die Entscheidung auf Commit in den betreffenden
Fällen (weiches Toleranzlevel). Dadurch wird die tolerierte Fall-Menge erweitert. Im Einzelfall
ist es somit erlaubt, dass die tatsächliche Anzahl ausgefallener Knoten größer als X ist.
Durch das beschriebene Toleranzverfahren kann die momentane Wirkung des CommitProtokolls bei Bedarf abgeschwächt werden.
4.3
Schedule-Protokolle
Aus der Literatur [8] sind eine Vielzahl von Schedule-Protokollen zur Durchsetzung von
Serialisierbarkeit der Transaktionshistorien in Datenbanksystemen bekannt. Die meisten davon
arbeiten dabei auf Basis von Sperren oder Zeitstempeln. Viele dieser Verfahren könnten auch
im vorliegenden Fall zum Einsatz kommen. Daher ist es sinnvoll das Schedule-Protokoll in der
späteren Implementierung ebenfalls als abgeschlossene Komponente anzusehen, um eine
einfache Austauschbarkeit verschiedener Protokolle und Protokollimplementierungen zu
erlauben. Im Folgenden werden einige mögliche Lösungen vorgestellt.
4.3.1 Sequentieller Scheduler
Die einfachste Möglichkeit Inkonsistenzen durch parallele Operationen zu verhindern, ist ihre
strenge sequentielle Ausführung. Das könnte mittels Warteschlangen oder einem kompletten
Sperren aller Strukturdaten erreicht werden. Auf diese Art wird aber jegliche Parallelität
aufgegeben, auch wenn die Operationen verschiedene Daten bearbeiten und somit keine
Überschneidungen auftreten.
4.3.2 Optimistischer Ansatz
Der optimistische Ansatz geht davon aus, dass während der Operationsausführung keine Fehler
auftreten. Falls dies doch der Fall ist, muss eine Operation rückgängig gemacht werden.
Dabei wird im vorliegenden Fall wie folgt vorgegangen. Die benötigten Variablen werden in
den lokalen Arbeitsbereich der Transaktion kopiert, wenn sie benötigt werden, aber nicht
gesperrt. Auf diesen lokalen Variablen wird die Operation ausgeführt. Dabei beginnt die
Transaktion für jeden Knoten zusammen mit der dazugehörenden Session beim Empfang bzw.
54
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.3 Schedule-Protokolle
Versand der ersten Nachricht. Am Ende der Operation werden nun die Variablen gesperrt. Es
wird geprüft, ob zwischenzeitlich Veränderungen durchgeführt wurden, zum Beispiel durch
parallel laufende Operationen. Es folgt das Commit-Protokoll, nach dessen erfolgreicher
Ausführung die Werte festgeschrieben werden. Zum Schluss werden die Sperren wieder
freigegeben.
Dieses Verfahren begrenzt die Isolation auf den Zeitraum zwischen der Korrektheitsprüfung
und der Ausführung des Commit-Protokolls und verspricht daher eine möglichst große
Parallelität von Operationen. Bei vielen gleichzeitig auszuführenden Operationen ist aber eine
große Rücksetzquote wahrscheinlich, sodass sich erst durch eine Evaluierung zeigen muss, ob
der optimistische Ansatz mehr Vor- oder Nachteile gegenüber einer sperrenbasierten Lösung
bietet.
4.3.3 Vorab-Sperren
Beim Vorab-Sperren werden sämtliche für eine Overlay-Operation notwendigen Zustandsvariablen, bevor mit der Ausführung der Operation begonnen wird, gesperrt. Anders als in den
meisten Fällen bei Datenbanksystemen sind für jede Overlay-Operation die notwendigen
Variablen schon im Voraus bekannt. Diese werden dem Transaktionsmanager beim Aufruf der
Start-Operation der Transaktion mitgeteilt. Vorab-Sperren ermöglicht somit die Isolation der
Overlay-Operationen in einer sehr einfachen Weise. Verklemmungen können nicht auftreten.
Eine mögliche Parallelität konkurrierender Operationen wird auf diese Weise stark
eingeschränkt.
Ein strenges Vorab-Sperren der Form, dass alle Knoten gleichzeitig zu Beginn der Operation
ihre benötigten Variablen sperren, ist allerdings im vorliegenden Fall nicht möglich. Hierfür
wäre ein Startprotokoll nötig, in dem sich die Knoten über den Startzeitpunkt verständigen.
Diese Kommunikation ist aber, wie am Beispiel des LaneBroken-Verfahren zu sehen ist, nicht
immer möglich. Außerdem wird so zusätzlicher Nachrichten-Overhead erzeugt.
Stattdessen wird eine abgeschwächte Variante des Vorab-Sperrens verwendet. Die Knoten
sperren alle benötigten Variablen, sobald sie die Transaktion erreicht.
4.3.4 Zwei-Phasen-Sperren
Eine Alternative zum Vorab-Sperren könnte das klassiche strenge Zwei-Phasen-Sperrprotokoll
sein. Die Zustands-Variablen werden dabei nach und nach gesperrt, wenn sie von der Operation
das erste Mal benötigt werden. Die Sperren werden dann bis zur Beendigung des CommitProtokolls gehalten und dann auf einmal freigegeben. Die Strenge des Vorab-Sperrens kann
dadurch abgeschwächt werden. Die Sperrphasen der einzelnen Knoten werden verkürzt,
wodurch potentiell eine größere Parallelität erreicht werden kann. Abbildung 4-10 verdeutlicht
dies schematisch am Beispiel des Lanes-Login. Die Knoten haben kürzere Sperrzeiten
gegenüber dem Vorab-Sperren und können damit andere Operationen noch fortführen und
beenden, obwohl der neue Knoten bereits den Login begonnen hat. Man erkennt vor allem
beim Initiator eine erhebliche Verkürzung der Sperrzeit. Das liegt daran, dass dieser erst ganz
am Ende des Logins Schreiboperationen auf seinen Strukturdaten ausführt, diese aber beim
Vorab-Sperren bereits zu Beginn gesperrt werden müssen. Ein Startprotokoll wird über dies
nicht benötigt.
55
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.4 Sperrenverwaltung
LoginRequest
Vorabsperren
LoginInformation
LoginAccept
Ende Commit-Protokoll
LoginConfirmation
Initiator
Reaktor 1
Reaktor 2
2-Phasen
Initiator
Reaktor 1
Reaktor 2
Optimistisch
Initiator
Reaktor 1
Reaktor 2
Abbildung 4-10: Vergleich der Sperrphasen
4.3.5 Zeitstempel-Verfahren
Auf Zeitstempel basierende Scheduler verwenden keine Sperren. Stattdessen wird jeder
Transaktion ihr Startzeitpunkt als Zeitstempel zugeteilt. Jede Operation dieser Transaktion trägt
ebenfalls diesen Zeitstempel. In Konflikt stehende Operationen zweier Transaktionen werden
auf Basis ihrer Zeitstempel sortiert. Anders ausgedrückt wird eine Operation zurückgewiesen
und somit die dazugehörende Transaktion zurückgesetzt, wenn bereits eine Operation einer
anderen Transaktion auf dem gleichen Datenelement ausgeführt wurde, die einen höheren
Zeitstempelwert aufweist.
4.3.6 Scheduler ohne Schutz
Dieser Scheduler, der streng genommen keiner ist, dient ausschließlich einer späteren
Evaluation. Er leitet sämtliche Lese- und Schreiboperationen des Overlay-Protokolls ohne
Sperren zu setzen an den Variablenmanager weiter. Dadurch wird ein System ohne
transaktionalen Schutz simuliert, das als Vergleich herangezogen werden kann. Details zur
Evaluation sind in Kapitel 6 zu finden.
4.4
Sperrenverwaltung
Im Simulator DIANEmu ist bereits eine Sperrenverwaltung integriert, die vom neuen
Transaktionsmanager genutzt werden kann und somit nicht neu entworfen werden muss. Diese
Sperrenverwaltung bietet nur eine Sperrenart (Exklusivsperre). Da aber nur wenige parallele
Operationen auf einem Knoten zu erwarten sind, kann der daraus resultierende
Parallelitätsverlust akzeptiert werden.
56
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.4 Sperrenverwaltung
Der so genannte Variablen-Manager jedes Knotens stellt folgende Operationen zur Verfügung:
Checkout: Setzt eine exklusive Sperre auf einer Variablen,
andere Zugriffe werden bis zur Sperrenfreigabe
geblockt.
Peek: Dient ausschließlich zum Lesen einer Variablen. Es
wird keine Sperre gesetzt. Somit kann kein
Repeatable Read gewährleistet werden und Dirty
Reads sind möglich.
Checkin: Schreibt einen Wert zurück und gibt die zuvor
gesetzte Sperre wieder frei.
Remove: Sperrt die angegebene Variable, löscht sie und gibt
die Sperre wieder frei. Diese Funktion wird nicht
verwendet, da der Satz von Strukturdaten konstant
ist und sich nur deren Werte ändern (vgl. Funktion
checkin).
TryCheckout: Testet, ob auf einer Variablen eine Sperre gesetzt ist.
Damit kann vermieden werden, dass mehrere Operationen parallel Änderungen der Daten für
einen Knoten durchführen und Inkonsistenzen hervorrufen. An einer Operation für die
Erhaltung der Lanes-Struktur sind jedoch mehrere Knoten beteiligt, deren lokaler Zugriff auf
ihre Zustandsdaten zwar isoliert abläuft, aber keine Koordination bzgl. der Datenänderungen
zwischen den einzelnen Knoten garantiert wird. Aus diesem Grund ist wie oben beschrieben
zusätzlich ein Commit-Protokoll nötig.
4.4.1 Verklemmungsvermeidung
Bei der Verwendung von Sperren können zwei oder mehr Transaktionen verklemmen, wenn sie
gegenseitig benötigte Sperren halten. Um Verklemmungen (Deadlocks) zu vermeiden, wird vor
der Vergabe einer Sperre der so genannte Wartegraph auf Zyklen geprüft. Die Knoten des
Wartegraphen sind mit den Transaktionskennungen markiert. Eine Kante von Knoten x nach
Knoten y bedeutet, das die Transaktion x auf eine Sperre wartet, die Transaktion y hält. Für die
Prüfung auf einen Zyklus wird zunächst mit Hilfe des Warshall-Algorithmus die transitive
Hülle des Wartegraphen bestimmt. Danach kann ein Zyklus leicht durch gesetzte
Diagonalelemente der Adjazenzmatrix erkannt werden. Würde durch die Vergabe einer Sperre
eine Verklemmung eintreten, wird die anfordernde Transaktion zurückgesetzt.
4.4.2 Verklemmungserkennung
Obwohl mit Hilfe des Wartegraphen ein System für die Vermeidung von Verklemmungen
realisiert werden kann, ist trotzdem zusätzlich eine Erkennung von Verklemmungen notwendig,
da Transaktionen hängen bleiben könnten. Die von diesen Transaktionen gehaltenen Sperren
würden nie mehr freigegeben. Um das zu verhindern wird ein Timer verwendet. Periodisch wird
geprüft, ob eine Transaktion ihre maximale Dauer überschritten hat. Falls ja, wird die
Transaktion zurückgesetzt.
57
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.5 Log-Manager
4.5
Log-Manager
Die Log-Manager-Komponente hat die Aufgabe, sämtliche sowohl lesende als auch schreibende
Zugriffe auf die Zustandsvariablen der laufenden Transaktionen eines Knotens
mitzuprotokollieren. Jedem dieser Einträge wird mit einem Zeitstempel und den Werten vor und
nach der Änderung (nur bei Schreibzugriffen) versehen.
Durch den Log-Manager kann gewährleistet werden, dass überschriebene Werte von
Transaktionen, die abgebrochen werden müssen, wieder zurückgesetzt werden können. Zudem
ist die Erstellung einer Operationen-Historie möglich.
Im Gegensatz zu herkömmlichen Datenbanksystemen wird das Log im vorliegenden Fall nicht
dazu eingesetzt, Robustheit gegenüber Knotenausfällen zu erreichen. Ein ausgefallener Knoten
wird in jedem Fall aus der Struktur des Overlay-Netzes entfernt und die Zustandsinformationen
nach seinem Re-Start neu initialisiert. Transaktionen, die zum Zeitpunkt des Ausfalls noch nicht
abgeschlossen hatten, müssen daher auch nicht zurückgesetzt werden. Außerdem erfolgt keine
dauerhafte Speicherung der Zustandsdaten, sodass eine Wiederausführung bereits
abgeschlossener aber noch nicht festgeschriebener Transaktionen ebenfalls nicht notwendig ist.
Das Log muss somit nicht dauerhaft angelegt sein, sondern nur eine Protokollierung zur
Laufzeit ermöglichen.
4.6
Isolation, Transaktionen & Sessions
Das verteilte atomare Commitment ist eine aufwändige Operation. Gerade in Ad-hoc-Netzen
sollte der nötige Aufwand aber so gering wie möglich gehalten werden. Daher ist zu überlegen,
ob die Ausführung des Commit-Protokolls in jedem Fall notwendig ist.
Ein Beispiel für einen solchen Fall sind die periodischen Ping-Nachrichten des Lanes-Overlays.
Ein transaktionaler Schutz ist hier nicht sinnvoll, da zum einen keine tiefgreifenden Eingriffe in
die Overlaystruktur vorgenommen werden und zum anderen durch die Häufigkeit dieser
Nachrichten ein solcher Schutz einfach zu aufwändig wäre.
Die Aktualisierungsfunktionen für Dienste (ServiceOffer und ServiceRemove) können hier
ebenfalls als Beispiel angeführt werden. Das Löschen und Einfügen eines Dienstes ist zeitgleich
nicht möglich, außerdem können Inkonsistenzen, die durch den Ausfall einzelner Nachrichten
entstehen,
beispielsweise
durch
periodische
Auffrischungen
der
vorhandenen
Dienstbeschreibungen einfacher behoben werden. Fehler, die dadurch in der Zwischenzeit bei
der Dienstsuche auftreten, sind zum Teil tolerierbar. Mit Fehler ist in diesem Zusammenhang
gemeint, wenn eine Dienstsuche scheitert, obwohl der Dienst verfügbar ist, oder umgekehrt.
Ähnliches gilt zum Beispiel auch beim bereits bekannten Overlaynetz Bamboo. Dort wird
lediglich versucht sämtliche Objekte mit bestimmtem Schlüssel, die in der verteilten
Hashtabelle abgelegt wurden zu finden. Garantien gibt es dafür aber nicht.
Sowohl der Ping-Mechanismus als auch die Dienstfunktionen können somit als unkritische
Operationen bezeichnet werden, zu denen des Weiteren auch reine Leseoperationen (z.B. die
Lanes-Dienstsuche) gezählt werden können. Bei unkritischen Operationen kann der Aufwand
des Commit-Protokolls eingespart werden.
58
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.6 Isolation, Transaktionen & Sessions
Operationstypen
unkritisch
nur lesend
kritisch
schreibend u.
fehlertolerant
schreibend
(garantiertes Gruppen-Commit)
schreibend
(Einzelentscheidungen erlaubt)
Abbildung 4-11: Operationstypen
Dem entgegen stehen kritische Operationen, die in die Netzstruktur eingreifen, und somit
isoliert ablaufen müssen, um schadhafte Strukturinformationen zu vermeiden. Solche
Operationen sind ausschließlich schreibend. Prinzipiell ist hier ein Commit-Protokoll
erforderlich. Kapitel 4.2 hat jedoch gezeigt, dass Fälle existieren, in denen das CommitProtokoll wegen einer Netzpartitionierung nicht abschließen kann, die dazugehörende OverlayOperation jedoch als korrekt ausgeführt gilt. Daher unterscheidet man bei kritischen
Operationen zwei Typen, je nachdem, ob ein Commitprotokoll ausführbar ist oder nicht. Der
normale Fall ist dabei das garantierte Gruppen-Commit, d.h. das Commit-Protokoll ist
durchführbar und muss erfolgreich abschließen, andernfalls gilt die Operation als gescheitert
und wird zurückgesetzt. Ein Beispiel für diesen Typ ist der Lanes-Login. Der zweite kritische
Operationstyp, zum Beispiel der LaneBroken-Mechanismus, erlaubt Einzelentscheidungen der
Knoten im Fall von Netzwerkpartitionierungen, da hier ein Gruppen-Commit nicht möglich ist.
Die Entscheidung, von welchem Typ eine kritische Operation ist, kann erst am Ende getroffen
werden. Die Typwahl muss dem Transaktionsmanager über zwei verschiedene
Commitvarianten mitgeteilt werden. Abbildung 4-11 zeigt alle möglichen Operationstypen.
SessionID: 1
Ping/Pong
Vorbereitung
Timeout
SessionID: 2
LaneBroken
Reparatur
erfolgreich
transaktional
geschützter Kern
Timeout
SessionID: 3
Dienstaktualisierung
Nachbearbeitung
Abbildung 4-12: Sessions LaneBroken-Algorithmus
Die einzelnen Protokollfunktionen von Overlays, wie Login, Logoff oder die Reparaturmaßnahmen sind nicht immer genau einem Operationstyp zuzuordnen. Stattdessen besteht eine
Wartungsoperation aus mehreren Suboperationen und besitzt einen dreiteiligen Aufbau. In
Abbildung 4-12 wird dieser Aufbau am Beispiel des LaneBroken-Algorithmus verdeutlicht. Ein
transaktional geschützter kritischer Kernbereich nimmt wichtige Änderungen an den
Strukturinformationen vor. Er ist von einer vorbereitenden Phase und einer Nachbearbeitung
umgeben, die keinen Transaktionsschutz benötigen, da dort unkritische Operationen zu finden
sind, wie sie im vorangegangenen Abschnitt beschrieben wurden. Jeder dieser drei Bereiche
kann muss aber nicht vorhanden sein.
59
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.7 Zusammenfassung
Ein Beispiel für diese Dreiteilung ist der LaneBroken-Algorithmus des Lanes-Overlays. Hier
sind alle mit Ausnahme der rein lesenden Operation vorgestellten Operationstypen zu
finden. Den geschützten Kern bildet die Lane-Reparatur. Ihn umschließen der Ping/PongMechanismus und die Dienstaktualisierung. Gegebenenfalls kann auf die explizite
Dienstaktualisierung wegen der periodischen Dienstauffrischung sogar verzichtet werden.
Beim Lanes-Login, um ein weiteres Beispiel zu nennen, ist nur ein dem geschützen Bereich
vorrausgehender Randbereich vorhanden. Vor der eigentlichen Aktualisierung der
Strukturvariablen werden unverbindlich Login-Anfragen und -Angebote versendet. Erst ab dem
Zeitpunkt des Akzeptierens eines Angebots durch den neuen Knoten ist ein Schutz erforderlich.
Um parallel ablaufende Protokollprozesse auf einem Knoten grundsätzlich unterscheiden zu
können, verwendet DIANEmu ein Sessionkonzept. Jedem Prozess wird eine eindeutige SessionID zugewiesen. Mit Hilfe dieser ID werden dann eintreffende Nachrichten automatisch den
richtigen Prozessen zugeordnet. Beim Aufruf eines Benutzer-Calls wird jeweils eine neue
Session gestartet. Zusätzlich besteht die Möglichkeit Sessions aus einer bereits bestehenden
Session heraus durch Versenden einer mit der neuen Session-ID versehenen Nachricht manuell
zu starten oder sie auch manuell zu beenden.
Das neue Transaktionskonzept muss in das vorhandene Sessionkonzept integriert werden. Dabei
wird eine 1-zu-1-Zuordnung zwischen den geschützten Bereichen und Sessions verwendet.
Jeder durch eine Transaktion geschützte Bereich verwendet genau eine Session. Als eindeutige
Transaktions-ID kann daher die Session-ID verwendet werden. Die Session-IDs beinhalten
neben einer laufenden Nummer auch die Adresse des Initiators dieser Session. Dieser Knoten ist
somit allen an der Session beteiligten Knoten automatisch bekannt und übernimmt beim
Commit-Protokoll aus diesem Grund immer die Rolle des Koordinators. Es ist sinnvoll, die
Randbereiche vom geschützten Kernbereich durch die Verwendung unterschiedlicher SessionIDs abzukoppeln. Diese Trennung erlaubt eine einfache Ausführung der einzelnen Bereiche mit
ihren unterschiedlichen Operationstypen.
4.7
Zusammenfassung
In diesem Kapitel wurde ein Konzept für ein System vorgestellt, das Inkonsistenzen durch
nebenläufig ausgeführte Wartungsoperationen verhindern soll. Die Idee, die dieser Ansatz
verfolgt, ist die Verwendung von Transaktionen, da bei Datenbanksystemen, dem Ursprung des
Transaktionskonzepts, ähnliche Probleme existieren. Tatsächlich hat die entwickelte Lösung
Ähnlichkeiten mit einem verteilten Datenbanksystem.
Um verteilte Transaktionen erfolgreich zu isolieren, sind zwei Aspekte zu beachten. Sowohl die
lokale Konsistenz als auch die globale Konsistenz müssen gewährleistet werden. Die dafür
benötigten Komponenten, wie Scheduleprotokolle oder das Commitprotokoll, wurden
beschrieben.
Es wurden aber auch Unterschiede zu verteilten Datenbanken dargelegt, die zusammen mit der
Forderung nach der Entwicklung einer generischen Schutzkomponente, die für viele Overlays
einsetzbar sein soll, einige Anpassungen vor allem am Commit-Protokoll erforderlich machten.
Hier ist zum Beispiel das Kennenlernprotokoll (Get-to-Know-Protokoll) zu nennen.
60
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 4.7 Zusammenfassung
61
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 5 Realisierung
5
Realisierung
Dieses Kapitel stellt die wichtigsten Punkte der softwaretechnischen Realisierung des
beschriebenen Transaktionssystems vor. Dieses System erweitert den Simulator DIANEmu des
DIANE-Projekts und wurde wie dieser in Java implementiert.
Die Implementierungen des Lanes-Protokolls sowie des verwendeten Zwei-Phasen-CommitProtokolls verwenden die Gegebenheiten des DIANEmu zur Realisierung von Protokollen.
Daher werden dazu hier nur Besonderheiten und interessante Aspekte beleuchtet. Gleich im
Anschluss wird ein Einblick in die Entwicklung von Protokollen für den DIANE-Simulator
sowie dessen Aufbau gegeben. Eine detaillierte Auskunft darüber liefert [11]. Ein Überblick
über alle im Rahmen dieser Arbeit erstellten Java-Klassen und Pakete ist im Anhang E zu
finden.
5.1
DIANEmu
Für ein besseres Verständnis des Entwurfs des entwickelten Schutzsystems ist es sinnvoll, hier
zunächst einen Überblick über den im DIANE-Projekt verwendeten Simulator zu geben.
5.1.1 Aufbau des Simulators
Der Netzwerk-Simulator DIANEmu besitzt eine fünfschichtige Architektur, auf die hier ein
kurzer Blick geworfen wird.
Die unterste Schicht bildet der Connectivity Layer. Hier wird die Funkreichweite der einzelnen
Knoten unter Beachtung der Umgebung (Gebäude, Bäume, ) berechnet.
Die zweite Ebene ist der Network Layer. Diese Schicht stellt ein zuverlässiges Transportsystem
zum Nachrichtenaustausch zwischen den Netzteilnehmern zur Verfügung. Sie ist damit mit den
Schichten 2 bis 4 des ISO-OSI-Referenzmodells vergleichbar.
Die Protokoll-Schicht (Protocol Layer) stellt die wichtigste Schicht des Simulators dar. Hier
werden die Overlay-Protokolle, wie Lanes, implementiert (vgl. nächstes Kapitel).
In der User Layer werden die Verhaltensweisen der einzelnen Benutzer simuliert. Dazu gehören
seine Bewegungen, sein Nutzungsverhalten (Ein- / Ausschalten des Geräts, Suche nach
Diensten oder andere Protokollfunktionen, usw.) aber auch die Eigenschaften der Geräte, wie
Prozessorleistung oder Speicherkapazität.
Die oberste Schicht bildet der Meta Layer. Sie dient der Definition und der Ausführung
komplexer Testfälle (Benchmarks).
62
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 5.1 DIANEmu
Die Benutzeroberfläche des Simulators zur grafischen Darstellung der Simulationsabläufe folgt
einem Model-View-Controller-Entwurf. Die Protokolle der Protocol Layer manipulieren
Strukturdaten, die für jeden Netzteilnehmer in einem Modell hinterlegt sind, und stellen damit
den Controller dar. In speziellen View-Komponenten kann spezifiziert werden, wie die
Modelldaten grafisch dargestellt werden sollen.
5.1.2 Implementierung von Protokollen
DIANEmu stellt eine umfangreiche Sammlung von Komponenten zur Verfügung, die die
Implementierung und Integration eigener Protokolle in die Simulationsumgebung (ProtokollSchicht) ermöglichen.
Die Klasse Protocol dient dazu, die Funktionen zu definieren, die dem Benutzer zur Verfügung
stehen sollen, zum Beispiel Login, Logoff oder Dienstsuche. Durch diese Funktionsaufrufe
werden die einzelnen Protokoll-Prozesse mit Hilfe eines Calls gestartet. Ein Ergebnis des
Prozesses, beispielsweise die gefundenen Dienste, wird mit einer Response an den Benutzer
zurückgegeben.
Jedes Protokoll besteht aus mehreren Zuständen (Klasse ProtocolState), zwischen denen
gewechselt wird, falls bestimmte Ereignisse eintreten. In den Zuständen ist die eigentliche
Funktionalität des Protokolls gekapselt. Es können Aktionen angegeben werden, die beim
Eintritt in den Zustand oder beim Empfang von festgelegten Nachrichten (Klasse Message)
ausgeführt werden sollen.
Neben diesen abstrakten Komponenten werden einige grundlegende Funktionen zur Verfügung
gestellt, die immer wiederkehrende Aufgaben bei der Implementierung von Protokollen
übernehmen. Hier ist vor allem das Sammeln von Nachrichten über einen bestimmten Zeitraum,
Timer und das Session-Konzept, das eine automatische Zuordnung von ankommenden
Nachrichten zu den parallel ablaufenden Protokoll-Prozessen ermöglicht, zu nennen. Darüber
hinaus existiert ein so genannter Variablenmanager, der die Verwaltung beliebiger Daten
übernimmt.
Jeder Knoten des Netzwerks verfügt über eigene Instanzen aller verwendeten Protokolle und der
von ihnen verwendeten Komponenten.
5.1.3 Simulation
Abbildung 5-1 zeigt die grafische Oberfläche des Simulators DIANEmu, der zur Evaluation der
Ergebnisse dieser Arbeit verwendet wurde. Der linke Bereich visualisiert die aktuelle
Netzwerktopologie, die vorhandenen Knoten und deren Position sowie den Versand und
Empfang von Nachrichten. In der Abbildung ist hier eine Lane aus sechs Knoten zu sehen. Der
rechte Bereich liefert Detailinformationen über Ereignisse, Nachrichten und Wartezustände, wie
Empfänger- und Senderadressen, ausführender Knoten, Session-IDs und die zeitliche Abfolge.
Der Simulator kann mit verschiedenen Szenarien, so genannten Benchmarks, initialisiert
werden, durch die das Verhalten der einzelnen Knoten definiert wird [15]. Dadurch ist
63
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 5.2 Das Wartungstransaktionssystem
zusammen mit den angezeigten Werten ein umfassender schrittweiser Test realisierter
Protokolle in verschiedenen Situationen möglich.
Eine detaillierte Beschreibung des Simulators ist in [11] zu finden.
Abbildung 5-1: Grafische Oberfläche des DIANEmu
5.2
Das Wartungstransaktionssystem
Abbildung 5-2 zeigt ein UML-Klassendiagramm des realisierten Systems. Auf die Darstellung
der Attribute und Methoden wurde aus Gründen der Übersichtlichkeit verzichtet. Einige dieser
Details werden im Laufe des folgenden Kapitels erläutert. Sowohl das Lanes- als auch das 2Phasen-Commitprotokoll sind nur angedeutet, um deren Integration in das System aufzuzeigen.
Ihre benötigten Protokollzustände und Nachrichten wurden bereits ausführlich dargelegt und
bedürfen keiner weiteren Beschreibung. Um die Grafik zusätzlich zu strukturieren und die
Zusammengehörigkeit der Klassen zu verdeutlichen, wurden diese durch logische Pakete
unterlegt. Der schematische Systemaufbau wurde bereits im letzten Kapitel anhand von
Abbildung 4-2 beschrieben.
5.2.1 Transaktionsverwaltung
Wie Abbildung 5-2 deutlich zeigt, ist Transactionsmanager die zentrale, alle Systemteile
verbindende Komponente. Dem Transaktionsmanager fallen zwei wichtige Kernaufgaben zu. Er
stellt erstens eine Schnittstelle zur Verfügung, über die das Overlay-Protokoll auf seine
64
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 5.2 Das Wartungstransaktionssystem
Strukturdaten zugreifen kann. Sowohl diese Schnittstelle als auch zweitens die Verwaltung der
laufenden Transaktionen werden im Folgenden beschrieben.
Abbildung 5-2: Gesamtentwurf
Die Funktionalität des Transaktionsmanagers ist allgemein gehalten. Sämtliche spezifischen
Funktionen, wie die Art des Abschlusses oder die Prüfung auf Korrektheit der ausgeführten
Transaktion sind in das Scheduleprotokoll bzw. das Commit-Protokoll ausgelagert. Welche
65
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 5.2 Das Wartungstransaktionssystem
Protokolle hier verwendet werden sollen, wird in einer Konfigurationsdatei festgelegt. Die
Integration vorhandener und neuer Protokolle ist daher sehr einfach und individuell möglich.
Der Transaktionsmanager verbindet diese Einzelkomponenten und macht sie untereinander
verfügbar, falls dies erforderlich ist. Beispielsweise ist das verwendete Scheduleprotokoll
dadurch in der Lage, auf die Logeinträge der laufenden Transaktion zuzugreifen oder selbst
neue Einträge hinzuzufügen.
Schnittstelle zum Overlay-Protokoll
Der Transaktionsmanager bietet dem Overlay-Protokoll Schnittstellenfunktionen zur
Manipulation der Strukturdaten sowie zum Start und zur Beendigung von Transaktionen an. Die
bisher für diesen Zweck verwendeten Änderungsfunktionen, die durch die Klasse ProtocolState
des DIANEmu bereitgestellt wurden, wurden deaktiviert, um die ausschließliche Verwendung
der neuen Schnittstelle zu erzwingen, da sonst ein transaktionaler Schutz nicht gewährleistet
werden könnte.
Folgende Methoden zur Verwaltung von Transaktionen bietet die Schnittstelle des
Transaktionsmanagers:
1. void start(String sessionID, boolean loginValue) :
Startet eine neue Transaktion. Als Transaktions-ID wird die angegebene Session-ID
verwendet. Sofern keine Parameter beim Transaktionsstart gesetzt werden müssen (vgl.
2.) kann auf den Aufruf dieser Methode verzichtet werden, da sie beim ersten Lesen
oder Schreiben sowie beim Empfang oder beim Senden einer Nachricht einer
unbekannten Transaktion automatisch ausgeführt wird. Der Parameter loginValue dient
dazu, den Login-Status zu Beginn der Transaktion zu protokollieren. Dieser Status wird
nicht vom Variablenmanager verwaltet. Dadurch ist es später beim Commit notwendig,
unabhängig vom verwendeten Scheduler zu prüfen, ob dieser Zustand während der
Transaktion nicht durch andere Operationen geändert wurde.
2. void start(String sessionID, Object startParameter, boolean loginValue) :
Startet eine neue Transaktion (vgl. 1.). Der anzugebende Startparameter ist vom
verwendeten Scheduler abhängig. Beispielsweise sind beim Vorabsperren alle für die
Transaktion zu sperrenden Strukturdaten anzugeben.
3. void abort(String sessionID) :
Bricht die Transaktion ab und setzt Änderungen an den Strukturdaten wieder zurück.
Dieser Methodenaufruf muss am Ende einer Transaktion erfolgen und startet das
Commit-Protokoll.
4. boolean tryCommit(String sessionID) :
Versuch, die Transaktion erfolgreich zu beenden. Dieser Methodenaufruf muss am Ende
einer Transaktion erfolgen und startet das Commit-Protokoll. Der Knoten zeigt damit
an, dass er die Transaktion erfolgreich abschließen kann. Der tatsächliche Erfolg der
Operation hängt aber vom Ergebnis des Commit-Protokolls ab. Scheitert das CommitProtokoll, wird die Transaktion abgebrochen, ihre geänderten Werte zurückgesetzt und
ein negatives Ergebnis zurückgegeben.
66
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 5.2 Das Wartungstransaktionssystem
5. boolean tryCommit(String sessionID, CommitToleranceConfiguration config):
Versuch, die Transaktion unter Angabe eines Toleranzniveaus (vgl. Kapitel 4)
erfolgreich zu beenden. Dieser Methodenaufruf muss am Ende einer Transaktion
erfolgen und startet das Commit-Protokoll. Der Erfolg der Operation hängt vom
Ergebnis des Commit-Protokolls ab.
Beim Beenden einer Transaktion ist zu beachten, dass neben dem erfolgreichen Abschluss und
dem Transaktionabbruch potentiell ein drittes Ergebnis möglich ist. Wie bereits beschrieben
wurde, ist es dem Commit-Potokoll beim Auftreten von Netzwerkpartitionierungen nicht immer
möglich ein konsistentes Ergebnis zu erreichen. Dieser Fall wird dem Overlay-Protokoll durch
eine Ausnahme angezeigt, sodass Gegenmaßnahmen ergriffen werden können. Der
Transaktionsmanager bietet eine Behandlung dieses Fehlers abhängig vom jeweiligen
Toleranzniveau an. Für eine detailliertere Beschreibung sei aber an dieser Stelle auf die
Anpassungen des 2-Phasen-Commits verwiesen (vgl. Kapitel 4).
Neben den Methoden zur Transaktionsverwaltung werden folgende Methoden zur Manipulation
der Strukturdaten angeboten:
6. Object directRead(String name):
Lesen eines Wertes ohne transaktionalen Schutz (für unkritische Operationen)
7. directWrite(String name, Object value):
Schreiben eines Wertes ohne transaktionalen Schutz (für unkritische Operationen)
8. Object read(String name, String sessionID):
Transaktional geschütztes Lesen eines Wertes (für kritische Operationen)
9. write(String name, Object value, String sessionID):
Transaktional geschütztes Schreiben eines Wertes (für kritische Operationen)
10. addToAnycastAddress(String address, String anycast, String sessionID):
Die Manipulation der Zuordnungen von Knotenadressen zu Anycastadressen (in diesem
Fall das Hinzufügen einer solchen Zuordnung) stellt einen Spezialfall dar, da diese
Informationen nicht vom Variablenmanager, sondern von der Netzwerkschicht direkt
verwaltet werden. Um zu garantieren, dass Änderungen nur im Erfolgsfall einer
Transaktion wirksam werden, sind deshalb spezielle Schreibfunktionen erforderlich.
11. removeFromAnycastAddress(String address, String anycast, String sessionID):
Entfernen einer Knotenadress-zu-Anycastadress-Zuordnung (analog zu addToAnycastAddress)
12. getUnicastAddresses(String anycastAddress, String sessionID):
Liefert die Knotenadressen, die einer Anycast-Adresse zugeordnet sind. Auch das Lesen
dieser Zuordnungen von Knotenadressen muss, wie auch deren Manipulation,
protokolliert werden, um beim Commit etwaige zwischenzeitliche Änderungen
erkennen zu können (vgl. 10.).
13. getAnycastAddresses(String unicastAddress, String sessionID):
Liefert die Anycast-Adressen, denen die angegebene Knotenadresse zugeordnet ist (vgl.
12.).
67
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 5.2 Das Wartungstransaktionssystem
Verwaltung und Protokollierung von Transaktionen
Durch expliziten Aufruf der Startoperation oder implizit durch eine Lese- oder Schreibfunktion
mit bisher unbekannter Session-ID wird eine neue Transaktionsinstanz (Klasse Transaction)
angelegt. Diese Instanz erlaubt die Ablage und Sammlung von für die Bearbeitung und den
Abschluss der Transaktion relevanter Informationen. Dazu gehören beispielsweise die
Transaktions-ID, die Koordinator-Adresse, die aus der Session-ID gewonnen wird, der aktuelle
Transaktionszustand (Working, Aborted, Committed) und eventuell Start-Parameter, die
abhängig vom gewählten Scheduleprotokoll sind. Darüber hinaus ist die Angabe beliebiger
weiterer Parameter in Form von Bezeichner-Werte-Paaren möglich und es existiert eine lokaler
Speicherbereich für Variablenwerte, der zum Beispiel vom optimistischen Scheduleprotokoll
verwendet wird, um die gelesenen oder geschriebenen Werte transaktionslokal zu verwalten.
Durch diese bereits vordefinierten allgemeinen lokalen Ablagebereiche können neue Protokolle
leicht ohne Änderungen in das bisherige System integriert werden.
Abbildung 5-3: Paket Core
Eine weitere grundlegende Funktion ist das Mitprotokollieren von Adressen der gesendeten
oder empfangenen Nachrichten. Bei empfangenen Nachrichten ist die Senderadresse und bei
gesendeten Nachrichten die Empfängeradresse von Interesse. Dies ist von erheblicher
Bedeutung für das spätere Commit-Protokoll, da jeder Knoten auf diese Weise den Knotenkreis
festhält, mit dem er während der Transaktion in Kontakt steht. Dadurch kann der Koordinator
letztendlich bestimmen, welche Knoten an der Transaktion beteiligt sind. Wie das für das
Commit-Protokoll genutzt werden kann zeigt Kapitel 4.
Die Nachrichtenprotokollierung wird automatisch durchgeführt. Die Nachrichten, deren
Adressen gespeichert werden sollen, müssen lediglich von einer speziellen Unterklasse der
Message-Klasse des DIANEmu
der Klasse TransactionTrackedMessage (s.u.)
erben.
Nachrichten die nicht protokolliert werden sollen, wie zum Beispiel die Pings, erben nach wie
vor von der Klasse Message.
5.2.2 Transaktionslog
Die Klasse LogManager übernimmt die Protokollierung der durch die Transaktion ausgeführten
Operationen. Jede Transaktion erhält ein eigenes Verzeichnis (TransactionLogEntryStorage) in
dem die Log-Einträge (LogEntry) abgelegt werden. Es wird sowohl der Beginn und das Ende
einer Transaktion protokolliert, als auch die gelesenen oder geschriebenen Werte. Jeder
Logeintrag ist mit einem Zeitstempel versehen.
68
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 5.2 Das Wartungstransaktionssystem
Abbildung 5-4: Paket Log
Am Transaktionende können aus dem Log Informationen darüber gewonnen werden, ob die
Ausführung der Transaktion erfolgreich war oder nicht. Diese Prüfung übernimmt, genauso wie
das Schreiben der Logeinträge, das Schedule-Protokoll.
5.2.3 Scheduler
Die Fabrik-Klasse ScheduleFactory erzeugt eine Instanz des zu verwendeten Scheduleprotokolls
(vgl. Konfigurationsdatei) und stellt sie dem Transaktionsmanager zur Verfügung. Die
Implementierung der Datenmanipulations- sowie der Transaktionsverwaltungfunktionen des
Transaktionsmangers erfolgt zum großen Teil durch das Scheduleprotokoll, da das Vorgehen
bei diesen Funktionen von der verfolgten Schedulestrategie abhängt.
Abbildung 5-5: Paket Scheduler
Folgende Methoden der abstrakten Oberklasse ScheduleProtocol müssen durch die ein
konkretes Scheduleverfahren realisierende Unterklassen implementiert werden:
1. Object read(String name, Transaction transaction):
Transaktional geschütztes Lesen (vgl. TransactionManager)
69
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 5.2 Das Wartungstransaktionssystem
2. write(String name, Object value, Transaction transaction):
Transaktional geschütztes Schreiben (vgl. TransactionManager)
3. addToAnycastAddress(String address, String anycasts, Transaction trans):
Hinzufügen einer Adress-zu-Anycastadress-Zuordnung (vgl. TransactionManager).
4. removeFromAnycastAddress(String address, String anycast, Transaction trans):
Entfernen einer Adress-zu-Anycastadress-Zuordnung (vgl. TransactionManager).
5. start(Transaction transaction):
Starten einer Transaktion ohne Startparameter (vgl. TransactionManager).
6. startParameterIsSet(Transaction transaction):
Starten einer Transaktion mit Startparameter (vgl. TransaktionManager). Hier muss
beispielsweise das Sperren der verwendeten Strukturdaten beim vorab sperrenden
Scheduler erfolgen.
7. close(Transaction transaction, boolean result):
Beenden einer Transaktion. Entweder wird die Transaktion erfolgreich beendet und die
geänderten Werte festgeschrieben oder die Transaktion wird zurückgesetzt.
8. boolean determineTAResult(Transaction transaction):
Prüft, ob auf Grund der verfolgten Schedulestrategie ein Commit oder Abort eingeleitet
werden muss. Beispielsweise muss beim optimistischen Scheduleverfahren geprüft
werden, ob während einer Transaktion Änderungen an den verwendeten Daten durch
andere Transaktionen vorgenommen wurden.
Im Rahmen dieser Arbeit wurden beispielhaft das Vorabsperren, das 2-Phasen-Sperren, ein
sequentieller sowie ein optimistischer Scheduler realisiert. Zudem erlaubt ein Scheduleprotokoll, das den Transaktionsschutz umgeht, einen Vergleich eines transaktional geschützten
mit einem ungeschützten System.
5.2.4 Sperren- und Verklemmungsmanagement
Die Sperrenverwaltung (Variablenmanager), die vom DIANEmu bereitgestellt wird, wird um
eine Komponente für die Verklemmungsvermeidung erweitert. Sie prüft jedes Mal bevor eine
Sperre an eine Transaktion vergeben wird, ob dadurch Probleme mit anderen parallel laufenden
Transaktionen entstehen. Hierzu wird ein Wartegraph in Form einer Adjazenz-Matrix verwaltet.
Für die Prüfung wird der Wartegraph so erweitert, als ob die Sperre an die Transaktion vergeben
wurde, und danach die Hülle des Graphen mit Hilfe des Warshall-Algorithmus gebildet. Ob ein
Zyklus und somit eine Verklemmung vorliegt, kann dann einfach durch die Überprüfung der
Diagonalwerte der Matrix ermittelt werden. Falls ein Diagonalelement belegt ist, wird die
Anfrage nach der Sperre abgewiesen und der Fehler durch eine Ausnahme angezeigt. Die
Transaktion wird daraufhin abgebrochen.
70
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 5.2 Das Wartungstransaktionssystem
Abbildung 5-6: Sperren-Manager und Verklemmungsvermeidung
Zusätzlich zur Vermeidung von Verklemmungen wurde eine Verklemmungserkennung
realisiert. Das ist notwendig, um die gehaltenen Sperren von hängenden Operationen wieder
freigeben zu können. Hierzu wird ein Timer verwendet. Die Verklemmungserkennung ist direkt
im Transaktionsmanager realisiert.
5.2.5 Integration in DIANEmu
Um die Entwicklung von Overlay-Protokollen zu vereinfachen, wurden für einige Klassen des
DIANEmu konkretere Unterklassen erstellt, die die Karakteristik von Overlays wiedergeben
und gleichzeitig das entwickelte Transaktionssystem in den Simulator integrieren. Die ebenfalls
im Rahmen dieser Arbeit erstellte Implementierung des Lanes-Overlays zeigt, wie die im
Folgenden beschriebenen Klassen zu verwenden sind.
Abbildung 5-7: Paket Overlay
DIANEmu basiert auf dem Model-View-Controller-Entwurfsmuster (MVC). Es sieht eine
strikte Trennung zwischen Darstellung (View), Datenhaltung (Model) und Anwendungslogik
(Controller) vor.
71
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 5.2 Das Wartungstransaktionssystem
OverlayProtocol & OverlayProtocolState
Die Klasse OverlayProtocol ist Superklasse aller Overlay-Protokolle. Sie integriert den
Transaktionsmanager in das System und stellt ihn den Protokollzuständen (Klasse
OverlayProtocolState) zur Verfügung. In den Zuständen findet die eigentliche Implementierung
des Protokolls statt. Insbesondere besitzt die Klasse OverlayProtocolState die Funktionen zum
Versenden und Empfangen von Nachrichten und leitet diese Nachrichten zur Protokollierung an
den Transaktionsmanager weiter. Das Protokoll mit seinen Zuständen bildet zusammen den
MVC-Controller.
OverlayModel
Die Klasse OverlayModel beschreibt ein allgemeines Modell eines Overlay-Protokolls und ist
somit die Modell-Komponente des verwendeten MVC-Entwurfsmusters (Model-ViewController). Jedes Overlay besitzt einen Mechanismus, der einem Knoten erlaubt, der Struktur
beizutreten (Login) oder wieder auszusteigen (Logoff). Die OverlayModel-Klasse bietet die
entsprechenden Methoden an.
Ursprünglich sollten im DIANEmu die Overlay-Strukturinformationen hier im Modell abgelegt
werden. Durch den Einbau des Transaktionsschutzes werden aber nun alle kritischen Daten
direkt im Variablenmanager gesichert. Damit die Sicht (View) des MVC-Entwurfsmusters
(s.u.), die das Modell für den Benutzer grafisch aufarbeitet, dennoch Zugriff auf die OverlayStruktur bekommt stellt die Klasse OverlayModel die Methode getModelVariable(String name)
zum Lesen der Strukturdaten zur Verfügung.
OverlaySwingView
Diese Klasse übernimmt die grafische Darstellung des zu Grunde liegenden Modells, ist also
der View der MVC-Sruktur (Model-View-Controller). Sie bietet eine farblich unterschiedliche
Darstellungsweise des Knotens, je nachdem, ob dieser eingeloggt ist oder nicht. In einer
Unterklasse wird diese Funktionalität ergänzt. Beispielsweise stellt die Klasse LanesSwingView
die Lanes-Ketten durch Pfeile dar. Abbildung 5-1 zeigt einen Screenshot des DIANEmu bei
dem die LanesSwingView-Darstellung zu sehen ist.
TransactionTrackedMessage
Nachrichten, die durch das Transaktionssystem mitprotokolliert werden sollen, müssen
Subklassen der Klasse TransactionTrackedMessage sein. Die Empfänger- bzw. Senderadresse
der Nachricht werden automatisch protokolliert. Zudem besteht die Möglichkeit dem
Transaktionssystem zusätzliche im Nachrichtenrumpf transportierte Adressen zugänglich zu
machen.
TransactionFailureActionRepository
Beim Auftreten von Netzwerkpartitionierungen ist es möglich, dass das Commitprotokoll nicht
ordnungsgemäß beendet werden kann. Ein Teilnehmer, der das Ergebnis des Commits nicht
erhält muss zwangsmäßig das Overlay-Netz verlassen, da ein konsistentes Ergebnis sonst nicht
garantiert werden kann. Sollen solche Fehler jedoch toleriert werden, können alternative
Maßnahmen definiert werden. Dies geschieht in der Klasse TransactionFailureActionRepository
bzw. in einer ihrer für ein bestimmtes Overlay konkretisierten Unterklassen. Jede Aktion
bekommt eine Nummer zugewiesen, um mit Hilfe der Methode executeFailureAction(int
actionNo) ausgeführt werden zu können. Die Standard-Aktion, der Zwangslogout, hat die
Kennziffer 0.
72
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 5.3 Implementierung von Lanes & 2PC-Protokoll
5.3
Implementierung von Lanes & 2PC-Protokoll
DIANEmu stellt eine umfangreiche Bibliothek zur Realisierung von Netzwerkprotokollen
jeglicher Art zur Verfügung. Dabei immer wieder benötigte Funktionen, wie das Sammeln von
ankommenden Nachrichten für eine bestimmte Zeitspanne, werden bereits durch das System
angeboten und müssen nicht explizit implementiert werden. Dadurch ist eine wesentlich
kompaktere Implementierung der Zustände möglich, als es im allgemeinen Entwurf von Lanes
in Kapitel 2 modelliert oder auch beim 2-Phasen-Commit im letzten Kapitel beschrieben wurde.
Abbildung 5-8: Paket Lanes
Für den Login in Lanes sind beim Initiator beispielsweise nur noch 2 Zustandsklassen
erforderlich: eine Vorbereitungsphase bis einschliesslich zum Versenden einer LoginAcceptNachricht und eine daran anschliessende Abschlussphase. Auch das Splitting ist innerhalb einer
Zustandsklasse PerformSplittingState realisiert. Ähnliches gilt auch für die Realisierung des 2Phasen-Commit-Protokolls.
Zudem bietet die Netzwerkschicht des DIANE-Simulators ein zuverlässiges Transportsystem.
Das bedeutet, dass der Sender einer Nachricht eine Rückmeldung erhält, falls eine Nachricht
nicht korrekt an den Empfänger ausgeliefert werden konnte. Darum müssen prinzipiell keine
expliziten Bestätigungsnachrichten versendet werden, sofern diese keine zusätzlichen
Informationen beinhalten. Bei der Lanes-Implementierung wurde aus diesem Grund zum
Beispiel auf die Pong-Nachricht verzichtet.
Abbildung 5-9: Paket TwoPC
73
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 5.3 Implementierung von Lanes & 2PC-Protokoll
Die Realisierung des 2-Phasen-Commit-Protokolls erfolgt direkt mit den von DIANEmu zur
Protokollimplementierung bereitgestellten Mitteln. Sie basiert also nicht wie Lanes auf den
neuen Overlayprotokollklassen (OverlayProtocol, OverlayProtocolState, ).
5.3.1 Netzwerkpartitionierungen in Lanes
Das Problem von Netzwerkpartitionierungen ist für Lanes noch nicht gelöst. Das Problem ist
hierbei nicht die Trennung einer einst verbundenen Lanes-Struktur, sondern deren potentielle
Wiedervereinigung. Beide Teilstrukturen könnten sich in der Zwischenzeit weiterentwickelt
haben. Dadurch besteht die Gefahr, dass Adressbereiche doppelt vergeben wurden, was nur
durch eine Adressreorganisation behoben werden kann.
Auf Grund dessen ist momentan ein Partitionierungsschutz aktiviert und es sind derzeit
höchstens Knotenausfälle zu erwarten.
5.3.2 Funktionelle Anpassungen des Lanes-Protokolls
Einführende Tests des implementierten Lanes-Protokolls haben gezeigt, das die alleinige
periodische Aktualisierung des Zeigers auf den Vor-Vorgänger eines Knotens durch die PingNachrichten nicht ausreichend ist. Durch strukturändernde Operationen innerhalb eines PingZyklus ist der Zeiger veraltet. Ein nun auftretender Lane-Bruch kann dann nicht mehr behoben
werden.
Als Folge daraus sind bei allen Operationen Änderungen des Zeigers auf den Vor-Vorgänger zu
berücksichtigen. Insbesondere müssen bei den Operationen Login, Logoff und LaneBroken die
Nachfolgeknoten über eine UpdatePredPred-Nachricht über diese Änderungen informiert
werden. Bei der Split-Operation kann jeder Knoten seinen Vor-Vorgänger durch die Listen der
SplitRequest- oder SplitComplete-Nachricht selbst bestimmen.
74
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 5.3 Implementierung von Lanes & 2PC-Protokoll
75
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 6 Evaluierung
6
Evaluierung
Das entwickelte Transaktionsschutzsystem wurde anhand einer Lanes-Implementierung im
Simulator DIANEmu getestet. Primär war natürlich eine Gegenüberstellung einer schutzlosen
und einer transaktional geschützten Lösung von Interesse, um die Korrektheit des
Schutzsystems zu zeigen. Darüber hinaus liefert die Evaluierung aber auch Antworten auf
folgende Fragen:
Wie groß ist der Mehraufwand, der durch das Schutzsystem entsteht?
Ist eines der realisierten Schedule-Protokolle besonders für die Anwendung in Overlays
geeignet?
Dieses Kapitel beschreibt die Ergebnisse dieser Untersuchungen. Zuvor wird das Szenario
erläutert, das den Simulationsläufen zu Grunde gelegt wurde.
Die Untersuchung der Effektivität und der Effizienz der Lanes-Algorithmen wurde bereits in
[13] durchgeführt. Daher wurde an dieser Stelle darauf verzichtet.
6.1
Szenario
Für den Test des Systems wurde eine DIANEmu-Benchmark verwendet. Sie ermöglicht die
Durchführung parametrisierter Simulationsläufe der entwickelten Protokolle. Im Folgenden
werden die verwendeten Einstellungen beschrieben. Eine detaillierte Beschreibung des
Benchmarking ist in [15] zu finden.
Jeder Lauf simulierte eine Nutzung des Lanes-Overlays durch 25 Benutzer über eine Zeitdauer
von 1000 s. Die Benutzer waren zu Beginn einer Simulation nicht eingeloggt. Der Zeitpunkt
ihres ersten Logins in Lanes war gleichverteilt im Intervall ab 30 s bis zum Simulationsende.
Danach hatten die Benutzer im Einzelnen folgendes Verhalten:
Jeder Benutzer bot bis zu fünf Dienste, frühestens ab 60 s nach seinem Login, an. Ein
neuer Dienst wurde gleichverteilt alle 120 s bis 240 s publiziert, sofern die maximale
Anzahl noch nicht erreicht wurde. Jeder dieser Dienste war 120 s verfügbar, bevor das
Dienstangebot wieder zurückgezogen wurde.
Ein eingeloggter Benutzer suchte alle 60 s bis 120 s nach einem Dienst.
Nach 40 s, in denen keine Aktion (Dienstsuche, Dienstangebot) durchgeführt wurde,
verließ der Knoten das Overlay-Netz. Ein erneuter Login war erst nach 10 s möglich.
Jedes Lanes-Mitglied sendete alle 15 s eine Ping-Nachricht an seinen Nachfolger. Die Größe
einer Lane wurde auf minimal 3 und maximal 10 Knoten festgelegt.
76
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 6.2 Effektivität
Als Commit-Protokoll kam, wie beschrieben, das 2-Phasen-Commit zum Einsatz. Für die
vorgestellten Schedule-Protokolle wurden jeweils mehrere Simulationsläufe durchgeführt.
Dauer
Benutzerzahl
Suchfrequenz
Angebotsfrequenz
Angebotshaltezeit
Erster Login
Erstes Angebot
Angebotszahl
Wartezeit nach Logoff
Logoff (max. Zeit ohne
Beschäftigung)
1000 (s)
25
U(60, 120) (s)
U(120, 240) (s)
120 (s)
U(30, 1000) (s)
U(60, 1000) (s)
5
10 (s)
40 (s)
Tabelle 1: Benchmark-Einstellungen
Die genannten Benchmark-Einstellungen sind in Tabelle 1 nochmals zusammengefasst. Weitere
Konfigurationsparameter des 2-Phasen-Commits und des Lanes-Protokolls, wie zum Beispiel
maximale Wartezeiten und andere Timer-Werte, sind im Anhang F aufgeführt.
6.2
Effektivität
Ziel dieser Arbeit war die Entwicklung eines Schutzsystems, das Inkonsistenzen der
Strukturdaten von Overlays verhindert. Um das testen zu können, wurde nach jedem
Simulationslauf eine Prüfroutine ausgeführt. Diese analysierte die Lanes-Struktur, die während
des Laufs aufgebaut wurde, dahingehend, ob der Vorgänger (bzw. Nachfolger) eines Knotens,
diesen auch als dessen Nachfolger (bzw. Vorgänger) ausgewiesen hat. Die gesamten Lanes
wurden analog auf korrekte Nachbarschaften hin untersucht.
Es wurden je 50 Simulationsläufe mit einem geschützten und einem nicht geschützten System
mit zwei verschiedenen Netzlasten durchgeführt. Um ein ungeschütztes System zu simulieren
wurde, wie bereits in Kapitel 4.3 beschrieben, ein spezieller Scheduler verwendet, der die Leseund Schreiboperationen ohne Sperren oder ähnlichem direkt an den Variablenmanager
weiterleitet. Abbildung 6-1 zeigt die Ergebnisse der Simulationen.
inkonsistenter 70
Testlaufanteil 60
(%)
50
66%
44%
40
Netzlast 1
30
Netzlast 2
20
10
2%
4%
0
ohne Schutz
mit Schutz
Abbildung 6-1: Testlaufanteil mit inkonsistentem Ergebnis
77
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 6.3 Effizienz
Die unterschiedlichen Netzlasten wurden durch verschiedene Benchmark-Einstellungen
erreicht. Netzlast 1 verwendete die Parameter wie sie im vorangegangenen Kapitel beschrieben
wurden. Eine höhere Netzlast (Netzlast 2) wurde durch eine Verdopplung der Knotenanzahl und
eine Herabsetzung der Logoff-Idle-Zeit auf 30 Sekunden erzielt. Durch einen schnelleren
Logoff der Knoten waren in der gegebenen Simulationszeit mehr Logins und durch die höhere
Dynamik mehr Lane-Teilungen und -Wiedervereinigungen möglich.
Um 50% der ungeschützten Testläufe endete mit einem inkonsistenten Ergebnis. Bei höherer
Netzlast war das Ergebnis höher. Die Wahrscheinlichkeit eines korrekten Laufs war umso
geringer, je stärker das Netz genutzt wurde. Das war auch zu erwarten, da mit steigender
Wahrscheinlichkeit für nebenläufige Operationen sich auch die Fehlerquellen mehrten. Mit
eingeschaltetem Transaktionsschutz konnten die Fehler, von einer geringen Restfehlerrate
abgesehen, verhindert werden. Die aufgetretenen Probleme in diesem Fall sind vermutlich auf
Programmierfehler zurückzuführen. Der Mehrwert des transaktionalen Schutzsystems konnte
auf diese Weise bestätigt werden.
Die beobachteten Auswirkungen der Fehler in der Lanes-Struktur waren unter anderem
Nachfolgerverweise (bzw. Vorgängerverweise) auf nicht eingeloggte Knoten, sowie Knoten mit
mehreren Vorgängern. Die schlimmste Auswirkung, die festgestellt werden konnte, war die
Bildung von Zyklen. Das hatte zur Folge, dass Ankündigungen oder Löschanforderungen von
Diensten ewig kreisten. Die Anzahl der Dienstnachrichten im simulierten Zeitraum der
betroffenen Testläufe stieg um mehr als das Zwanzigfache gegenüber Läufen, in denen dieses
Problem nicht auftrat.
6.3
Effizienz
Nachdem der vorangegangene Abschnitt die Notwendigkeit und den Nutzen des entwickelten
transaktionalen Schutzsystems verdeutlicht hat, wird nun untersucht, welcher zusätzliche
Aufwand durch dieses System entsteht. Als Maß für die Aufwandsmessung dient die Anzahl
versendeter Nachrichten. Um ein aussagekräftigeres Ergebnis zu erhalten, wurden die Werte
von 300 Simulationsläufen arithmetisch gemittelt und verschiedene Scheduler verwendet.
Dennoch kann diese Analyse lediglich einen Eindruck über den Aufwand des Systems für die
verwendete Lanes-Implementierung geben. Allgemeingültige Aufwandsaussagen sind kaum
möglich, da viele Faktoren Einfluss darauf ausüben. Dazu gehören die Art der geschützen
Operationen, die Wahrscheinlichkeit ihres Auftretens, die Anzahl der beteiligten Knoten sowie
des Verhältnis zwischen der Zahl der Nachrichten der Operation und des sie schützenden
Commit-Protokolls.
Abbildung 6-2 zeigt die durchschnittliche Verteilung der Nachrichtentypen für das am Anfang
des Kapitels beschriebene Szenario. Die Nachrichten gehören zwei Gruppen an, den LanesNachrichten sowie den Nachrichten des Commit-Protokolls (transaktionale Nachrichten). Zu
den Nachrichten des Lanes-Overlays gehören Pings, Dienstnachrichten (Ankündigung,
Löschung, Suche, Refreshment) und sonstige Wartungsoperationen. Letztere sind von
besonderem Interesse, da nur sie durch das Schutzsystem geschützt werden. Dadurch kann
schon erheblicher Aufwand eingespart werden, da diese Gruppe, zu der Logins, Logoffs, Splits,
usw. zählen, nur rund 49% des Nachrichtenaufkommens von Lanes im untersuchten Szenario
ausmachen. Dienstnachrichten und Pings führen keine tiefgreifenden Strukturänderungen durch
und benötigen daher keinen Schutz (vgl. Kapitel 4.6).
78
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 6.3 Effizienz
Nachrichten- 120
verteilung (%) 100
19%
80
49%
60
20%
40
20
31%
0
Dienst-Nachrichten
Ping-Nachrichten
Sonstige Nachrichten
transaktionale Nachrichten
Abbildung 6-2: durchschnittliche Nachrichtenverteilung
Insgesamt, also unter Einbezug der Pings und Dienstnachrichten, wurde ein Mehraufwand von
19% durch das Transaktionssystem verursacht. Betrachtet man nur das Verhältnis der
Transaktionsnachrichten zu den Nachrichten der Operationen, die dadurch tatsächlich geschützt
wurden, ergab sich ein Zusatzaufwand von 40%. Das verdeutlicht, wie wichtig es ist, vorab
genau zu überlegen, ob und welche Operationen geschützt werden müssen.
Bei der Betrachtung der Transaktionen konnte festgestellt werden, dass davon im Mittel ca.
78% erfolgreich beendet werden. Die durchschnittliche Zahl der an der Transaktion beteiligten
Knoten war 3.
Um den Systemaufwand noch besser einschätzen zu können, wurden neben den
Untersuchungen am beschriebenen Szenario auch weitere Analysen mit verschiedenen
Netznutzungsraten durchgeführt. Unter der Netznutzung versteht man in diesem
Zusammenhang nicht die Dienstfunktionen oder Pings, sondern die Anzahl der zu schützenden
Wartungsoperationen. Als Indikator für das Auftreten von Wartungsoperationen diente die
Anzahl der Logins und Logoffs. Je öfter dieser Operationen auftreten, desto höher ist die
Netzdynamik und somit auch die Wahrscheinlichkeit für Splits oder Merges. Um die Zahl der
Logins und Logoffs zu verändern wurden gegenüber dem beschriebenen Szenario nur die
Wartezeit bis zu einem Logoff und die Wartezeit bis zum erneuten Login manipuliert. Die
Ergebnisse dieser Testläufe sind in Abbildung 6-3 dargestellt. Das Szenario, wie es oben
beschrieben wurde, wies zum Vergleich ca. 65 Logins sowie etwa 40 Logoffs auf.
Der beobachtete Aufwand ist am geringsten, wenn keine Logoffs auftreten. Das kann leicht
nachvollzogen werden, da in diesem Fall nur 25 Logins vorkommen (bei 25 Netzknoten) sowie
genau zwei Split-Operationen (bei einer maximalen Lanes-Länge von 10). Sowohl das
Gesamtaufkommen von Transaktionsnachrichten als auch deren Verhältnis zu den
Operationsnachrichten sind demnach beschränkt. Je mehr Logoffs beobachtet wurden, desto
mehr Logins waren letztendlich wieder möglich. Dies bringt auch Dynamik bei Split- und
Merge-Operationen. Der Aufwand stieg dadurch leicht an. Dagegen konnte beim Anteil
erfolgreich abgeschlossener Transaktionen (bzw. abgebrochener Transaktionen) kein Trend
festgestellt werden.
79
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 6.4 Vergleich der Scheduleprotokolle
100
%
90
80
70
60
50
40
30
20
10
0
25/0
35/9 34/13 39/20 43/27 60/40 70/40
Netznutzung (Logins/Logoffs pro 1000s)
erfolgreiche Transaktionen
abgebrochene Transaktionen
Verhältnis TA-Nachrichten zu Wartungsnachrichten
Transaktions-Gesamtaufwand
Abbildung 6-3: Aufwand vs. Netznutzung
Zusammenfassend ist festzustellen, dass der Aufwand des transaktionalen Systems nicht
unbedeutend ist. Durch eine genaue Abwägung, wann der Schutz wirklich sinnvoll und
notwendig ist, kann er jedoch stark gesenkt werden.
6.4
Vergleich der Scheduleprotokolle
Neben der generellen Funktion des Systems und seines Gesamtaufwands wurde untersucht, ob
charakteristische Unterschiede im Systemverhalten durch den Einsatz der verschiedenen
implementierten Schedule-Protokolle feststellbar sind. Die Ergebnisse dieses Vergleichs sind in
diesem Abschnitt zusammengefasst. Abbildung 6-4 liefert einen grafischen Überblick. Die
Daten lieferten je 50 Simulationsläufen mit den beschriebenen Szenarioparametern.
Zu den untersuchten Protokollen gehörten, wie bereits ausführlich beschrieben, ein
optimistischer Scheduler, das Zwei-Phasen-Sperrprotokoll, das Vorabsperren sowie ein
sequentieller Scheduler. Als Vergleichskriterien dienten Parameter, die auch schon in den
vorangegangenen Abschnitten genannt wurden, wie die Anzahl erfolgreich abgeschlossener
Transaktionen, das Verhältnis zwischen der Anzahl der Transaktionsnachrichten und der Anzahl
der transaktional geschützten Lanes-Nachrichten sowie der Anteil der Transaktionsnachrichten
am Gesamtnachrichtenaufkommen. Zusätzlich wurden auch Transaktionen betrachtet, die auf
Grund von Timing-Fehlern beim Commit abgebrochen werden mussten (fehlerhafte
Transaktionen).
Abbildung 6-4 zeigt, dass alle Scheduleprotokolle ähnliche Ergebnisse liefern. Keines der
Protokolle erscheint auf den ersten Blick besonders geeignet oder ganz ungeeignet. Bei einer
genaueren Betrachtung der Ergebnisse sind jedoch leichte Vorteile des Vorabsperrens
erkennbar. Es erlaubt die parallele Ausführung von Operationen, sofern diese nicht auf den
80
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 6.5 Zusammenfassung
gleichen Strukturdaten arbeiten, und verringert somit die Gefahr von Timeouts. Diese führen
zum Beispiel beim sequentiellen Scheduler zu einer erhöhten Rate fehlerhafter Transaktionen.
%
100
90
80
70
60
50
40
30
20
10
0
81
87
91
84
52
9
erfolgreiche
TAs
2 4
19 16
8
fehlerhafte TAs
Optimistisch
2PC
43 47 47
15 18
Anteil TANachrichten
Vorabsperren
Verhältnis TAzu LanesNachrichten
Sequentiell
Abbildung 6-4: Schedulervergleich
Durch das Vorabsperren wird außerdem das Risiko für Verklemmungen und die dadurch
notwendigen Transaktionsabbrüche gegenüber beispielsweise dem 2-Phasen-Sperren
minimiert. Insgesamt resultiert daraus das beste Ergebnis der Quote erfolgreicher
Transaktionen. In allen Bereichen zeigte das optimistische Verfahren die schlechtesten Werte
und ist daher am wenigsten zu empfehlen. Das liegt daran, dass bei auftretenden Fehlern die
Transaktion zurückgesetzt und neu gestartet wird. Bei sperrenbasierten Protokollen hingegen
wird versucht parallele Operationen zu verzögern, um das Rücksetzen zu vermeiden. Dies ist
aber auch nur im begrenzten Rahmen möglich, wie der sequentielle Scheduler zeigt.
6.5
Zusammenfassung
Die Effektivität des entwickelten Transaktionsschutzes konnte durch die durchgeführten Tests
bestätigt werden. Neben der Effektivität wurde für das Lanes-Overlay ein mäßiger
Zusatzaufwand festgestellt, der auch dadurch erreicht wurde, dass nicht alle Operationen
geschützt werden. Sonst fällt der Aufwand, der durch das verwendete Commit-Protokoll
entsteht, deutlich höher aus.
Der theoretische Beweis der Korrektheit des Systems steht noch aus. Dabei ist gerade der
Aspekt interessant, dass nicht alle Operationen und Operationsteile geschützt werden. Die
Korrektheit der verwendeten Scheduler und des 2-Phasen-Commit-Protokolls ist hingegen in
der Literatur ausreichend beschrieben.
Im Rahmen der Tests konnte nur begrenzt das Verhalten bei Knotenausfällen und ausbleibenden
Nachrichten überprüft werden, da das Lanes-Protokoll, das für die Simulationsläufe verwendet
wurde, für die Probleme, die bei der Partitionierung des Netzwerks entstehen, noch nicht
vollständig spezifiziert wurde. Einige Fehler traten bei der Simulation auf Grund von TimingProblemen während der Operationen dennoch auf. Das Schutzsystem reagierte in diesen Fällen
erfolgreich mit dem Abbruch der jeweiligen Transaktion.
81
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 7 Zusammenfassung & Ausblick
7
Zusammenfassung & Ausblick
Dieses Kapitel liefert einen Überblick über die Ergebnisse dieser Arbeit und zeigt danach in
einem Ausblick, welche zukünftigen Tätigkeiten daran angeschlossen werden könnten.
7.1
Zusammenfassung
Ziel dieser Diplomarbeit war die Entwicklung eines Schutzsystems für Wartungsoperationen in
Overlay-Netzen für die Dienstsuche und -bereitstellung in mobilen Ad-hoc-Netzen im Rahmen
des DIANE-Projekts. Dieses System sollte die Atomizität und Isolation dieser Operationen
gewährleisten und somit die Konsistenz der Strukturinformationen des Overlay-Netzes auf
jedem einzelnen teilnehmenden Knoten erhalten.
Untersuchungen verschiedener Overlay-Protokolle wie CAN, Chord, Pastry oder Tapestry im
Vorfeld, ergaben mehrere bisher gängige Lösungsansätze des Problems: strenge sequentielle
Bearbeitung der Operationen, zum Beispiel durch die Verwendung von Prioritäten, das Zulassen
von Inkonsistenzen und deren periodische Korrektur durch Reorganisationsphasen,
Verwendung fehlertoleranter Strukturen sowie eine protokollspezifische Fehlerbehandlung.
Keine dieser Lösungen konnte jedoch voll überzeugen.
Der in dieser Arbeit verfolgte Ansatz sollte deshalb diesen Möglichkeiten entgegenstehen und
eine vom verwendeten Overlay-Protokoll möglichst unabhängige, generische Lösung
bereitstellen, um eine Einsetzbarkeit in verschiedenen Overlay-Protokollen zu erreichen und die
Entwicklung dieser Protokolle zu vereinfachen.
Als Ausgangspunkt für die Überlegungen diente das aus dem Datenbankumfeld bekannte
Prinzip von Transaktionen. Transaktionen dienen dort zur Durchsetzung der ACIDEigenschaften und stellen somit genau das Instrument zur Verfügung, das auch bei der
Ausführung von Wartungsoperationen in Overlays für deren korrekten Ablauf benötigt wird.
Ein Overlay-Netz wurde demnach als verteiltes Datenbanksystem aufgefasst, in dem jeder
Knoten seine lokalen Strukturdaten selbst verwaltet. Wartungsoperationen stellen dann verteilte
Transaktionen auf diesen Daten dar.
Mehrere Teilaufgaben waren bei der Entwicklung dieses transaktionalen Schutzsystems zu
bearbeiten. Lokale Scheduler garantieren die Serialisierbarkeit auf jedem der Knoten. Dabei
wurden mehrere in der Praxis gängige Schedule-Protokolle, wie das Zwei-Phasen-Sperren oder
ein optimistisches Verfahren, zusammen mit zusätzlichen Komponenten, die für deren Funktion
notwendig sind, realisiert. Dazu gehörte vor allem ein umfangreiches Logging. Ein
Commitprotokoll erzeugte darüber hinaus globale Serialisierbarkeit. Hier wurde nach
Untersuchung mehrerer Alternativen das Zwei-Phasen-Commitprotokoll gewählt.
Schließlich musste das Schutzsystem in die bisherige Implementierung des DIANE-Simulators
integriert werden. In diesem Zusammenhang ist eine API entstanden, die die Entwicklung neuer
82
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 7.2 Ausblick
Overlay-Protokolle vereinfacht und ihnen darüber hinaus den transaktionalen Schutz zur
Verfügung stellt. Scheduler und Commit-Protokoll wurden so realisiert, dass verschiedene
Implementierungen bei Bedarf einfach ausgetauscht werden können.
In einem letzten Schritt wurde das Lanes-Overlay im DIANE-eigenen Simulator implementiert
und mit dem entwickelten Transaktionssystem geschützt. Lanes diente in dieser Arbeit als
ausführliches Beispiel eines Overlay-Netzes. An ihm wurden die beschriebenen Probleme
analysiert und schließlich die Arbeitsweise und Korrektheit des entwickelten Systems im
Anschluss daran erfolgreich getestet. Die Evaluation hat darüber hinaus aber auch gezeigt, dass
beim Einsatz des Systems genau dessen Nutzen gegenüber dem hauptsächlich durch das
Commit-Protokoll entstehenden Aufwand abzuwägen ist. Auf Grund der Generiziät des
Systems werden alle Operationen transaktional gleich behandelt. Nicht alle Operationen dienen
jedoch der Erhaltung der Struktur und müssen daher auch nicht zwingend geschützt werden. So
konnte bei Lanes erheblich Aufwand eingespart werden, in dem die Dienstoperationen und die
Ping-Nachrichten der Konnekivitätsprüfungen, die zusammen ca. 50% des Nachrichtenaufkommens von Lanes stellen, keinen Transaktionsschutz in Anspruch nahmen.
7.2
Ausblick
Im Laufe der Realisierung des Transaktionssystems und der Implementierung des LanesProtokolls konnten einige Themenbereiche identifiziert werden, die Ansatz für weiterführende
Arbeiten sein können. Mit dem Ausblick auf diese zukünftigen Aufgaben wird diese Arbeit
abgeschlossen.
Für das entwickelte Schutzsystem wurde bisher ausschließlich das 2-Phasen-Commit-Protokoll
implementiert, da es bei der Analyse der gängigen Commit-Protokolle als am geeignetsten
angesehen wurde. Das soll für die Zukunft jedoch nicht bedeuten, dass hier eventuell alternative
Verfahren, beispielsweise auch eine proprietäre Lösung, nicht möglich sind. Das System
ermöglicht die leichte Integration solcher Lösungen.
Gleiches gilt auch für die verwendeten Schedule-Protokolle. Hier wurden bereits einige
Verfahren umgesetzt und getestet. Eine Erweiterung dieser Protokollsammlung um zum
Beispiel zeitbasierte Verfahren stellt einen weiteren Ansatzpunkt dar.
Es existieren zahlreiche Overlay-Netze. Hier konnte daher nur einen Bruchteil dieser Protokolle
hinsichtlich geeigneter Lösungen zur Konsistenzwahrung von Strukturinformationen untersucht
werden. Diese Arbeit konzentrierte sich dabei auf Overlay-Strukturen, die sich für die
Dienstsuche eignen. Diese Untersuchungen könnten auch auf Overlays für andere
Aufgabenbereiche ausgedehnt werden, wie zum Beispiel die am Institut für Telematik der
Universität Karlsruhe entwickelten Verfahren zur Gruppenkommunikation in Ad-hoc-Netzen
[23].
Diese Arbeit verwendete für die Realisierung des Transaktionssystems das Lanes-Overlay als
praktisches Beispiel eines typischen Overlay-Netzwerks. Neben Arbeiten, die sich mit der
Erweiterung des Systems beschäftigen, wäre daher auch dessen Integration und Nutzung in
einem weiteren Overlay-Protokoll eine wichtige Aufgabe, um die Funktionalität auch für andere
Bereiche zu evaluieren.
Obwohl das Lanes-Protokoll durch diese Arbeit bereits prototypisch umgesetzt wurde, ist
dessen Entwicklung noch nicht abgeschlossen. Eine wichtige Aufgabe in diesem Umfeld wäre
83
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 7.2 Ausblick
die Klärung des Verhaltens beim Auftreten von Netzwerkpartitionierungen. Dieses Problem
wurde bisher von der Betrachtung ausgeschlossen.
In dieser Arbeit wurde ansatzweise für den Login in Lanes ein Verfahren vorgestellt, wie die
Fehlerbehebung ohne Transaktionsschutz realisiert werden könnte. Es hat sich gezeigt, dass
dieser Ansatz sehr komplex ist. Dennoch wäre eine funktionsfähige Referenzimplementierung
von Lanes, die dieses Verfahren nutzt, eine interessante Ergänzung zu dieser Arbeit.
84
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- 7.2 Ausblick
85
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
Anhang
A Abkürzungen
ACID
API
CAN
DBMS
DFG
DHT
DIANE
DNS
GSM
IEEE
ISO
JAMES
LAN
MANET
Cambridge-MIT
MVC
OSI
SHA-1
TCP
UML
VDBMS
VID
WLAN
2PC
Atomicity Consistency Isolation Durability
Application Programming Interface
Content Addressable Network
Datenbasis-Managementsystem
Deutsche Forschungsgemeinschaft
Distributed Hashtable
Dienste in Ad-hoc-Netzen
Domain Name Service
Global System for mobile Communications
Institute of Electrical and Electronics Engineers
International Standard Organization
Java-based Agent Modeling Environment for Simulation
Local Area Network
Mobile Ad Hoc Network
Cambridge Massachusetts Institute of Technology (CMI)
Model-View-Controller-Entwurfsmuster
Open System Interconnection
Secure Hash Algorithm
Transmission Control Protocol
Unified Modeling Language
Verteiltes Datenbasis-Managementsystem
Virtueller Identifier
Wireless Local Area Network
2-Phasen-Commit
86
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
B Idee eines spezifischen Lösungsansatzes für Lanes
Abbildung B-1 zeigt die in Kapitel 3 beschriebenen Erweiterungen des Lanes-Protokolls am
Beispiel des Login. Die neu hinzukommenden Teile sind gestrichelt und hellgrau dargestellt.
Abbildung B-1: Lanes-Login mit Fehlermechanismus
87
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
C Ergänzungen zur Lanes-Spezifikation
Im Folgenden sind vervollständigende Angaben zur Spezifikation von Lanes aus Kapitel 2 zu
finden. Dazu zählen die verwendeten Methoden und die Strukturdaten, die von den einzelnen
Lanes-Mitgliedern verwaltet werden.
C.1 Strukturinformationen
LanesHandler
-unicastAdress : String
-leftLaneAddress : String
-rightLaneAddress : String
-leftNeighborLane : String
-rightNeighborLane : String
-pred : String
-succ : String
-laneOffers : List
-loggedIn : boolean
-predPred : String
-predCounter : int
Abbildung C-2: Attribute des Lanes-Handler
C.2 Methoden
LoginAccept accept() {
LoginAccept accept = new LoginAccept();
accept.destination = bestOffer.getSender();
return accept;
}
boolean acceptRequest(LoginRequestMessage request){
//apropriate heuristic
if(..){
return true;
}else{
return false;
}
}
void addService(Service s){
laneOffers.add(s);
}
RefreshRequestMessage addToRequest(RefreshRequestMessage rrm){
rrm.laneOffers.add(myservices);
return rrm;
}
88
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
SplitRequestMessage addToRequest(SplitRequestMessage srm){
List nodeList1 = srm.list1;
List nodeList2 = srm.list2;
if(nodeList2.size() < nodeList1.size()){
nodeList2.add(unicastAddress);
}else{
nodeList1.add(unicastAddress);
}
srm.list1 = nodeList1;
srm.list2 = nodeList2;
return srm;
}
void chooseBestOffer() {
if (laneOffers.size() == 0) {
bestOffer = null;
}else {
//appropriate heuristic
...
}
}
LoginInformation informSuccessor(LoginAcceptMessage accept) {
LoginInformation inform = new LoginInformation();
inform.destination = succ;
inform.newPred = accept.getSender();
return inform;
}
LoginResponse loginResponse() {
LoginResponse response = new LoginResponse();
response.success = loggedIn;
return response;
}
LoginRequest loginRequest() {
LoginRequestMessage lrm = new LoginRequestMessage();
lrm.destination = "255.255.255.255";
lrm.setTimeToLive(-1); // no time to live
}
LogoffResponse logoffResponse() {
LogoffResponse response = new LogoffResponse();
response.success = !loggedIn;
return response;
}
boolean nextExists(Message m){
//m instanceof ServiceOfferMessage or ServiceRevokeMessage
String previous = m.getSender();
if(previous == pred && succExists()){
return true;
}else if(previous == succ && predExists()){
return true;
}else{
return false;
}
}
89
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
boolean nextLaneExists(ServiceRequestMessage srm){
String previous = srm.sourceLane;
if(previous == leftNeighborLane && rightNeighborLane != null){
return true;
}else if(previous == rightNeighborLane &&
leftNeighborLane != null){
return true;
}else{
return false;
}
}
boolean predExists(){
if(pred != null){
return true;
}else{
return false;
}
}
ServiceRevoke removeOffers(String address){
ServiceRevoke revoke = new ServiceRevoke();
revoke.addServicesFromNode(address);
laneOffers.removeAll(address);
return revoke;
}
ServiceRevoke removeOffers(Service s, String address){
ServiceRevoke revoke = new ServiceRevoke();
revoke.addService(s, address);
laneOffers.remove(s, address);
return revoke;
}
void removePredecessor(){
pred = null;
}
void removeSuccessor(){
succ = null;
}
void resetValues(){
laneAddressLeft = null;
laneAddressRight = null
pred = null
succ = null;
leftNeighborLane = null;
rightNeighborLane = null;
loggedIn = false;
laneOffers.clear();
}
void send(Message message) {
//Versenden einer Nachricht
}
90
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
boolean serviceLocallyAvailable(Service s){
if(s in laneOffers){
return true;
}else{
return false;
}
}
void setAsFirstMember() {
leftLaneAddress = "222.222.222.1";
rightLaneAddress = "222.222.222.254";
leftNeighborLane = null;
rightNeighborLane = null;
pred = null;
succ = null;
loggedIn = true;
}
boolean succExists(){
if(succ != null){
return true;
}else{
return false;
}
}
void updateLeftNeighbor(Message message){
if(message instanceof RemoveLaneMessage){
leftLaneAddress =
((RemoveLaneMessage)message).getLeftAddress();
}
}
void updateRightNeighbor(Message message){
if(message instanceof RemoveLaneMessage){
rightLaneAddress =
((RemoveLaneMessage)message).getRightAddress();
}
}
void updateServices(RefreshCompleteMessage rcm){
laneOffers = rcm.offers;
}
void updateStructure(SplitCompleteMessage scm){
List nodeList1 = scm.list1;
List nodeList2 = scm.list2;
if(unicastAddress in nodeList1){
int index = nodeList1.getIndexOf(unicastAddress);
laneAddressRight = laneAddressLeft +
(laneAddressRight
laneAddressLeft)/2;
pred = nodeList1[index-1];
succ = nodeList1[index+1];
rightNeighborLane = laneAddressLeft +
(laneAddressRight
laneAddressLeft)/2+1;
}else{
int index = nodeList2.getIndexOf(unicastAddress);
laneAddressLeft = laneAddressLeft +
(laneAddressRight
laneAddressLeft)/2+1;
91
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
}
pred = nodeList2[index-1];
succ = nodeList2[index+1];
leftNeighborLane = laneAddressLeft +
(laneAddressRight
laneAddressLeft)/2;
}
void updateSuccessor(Message message){
if(message instanceof LoginAcceptMessage){
succ = ((LoginAcceptMessage)message).getSender();
}else if(message instanceof LogoffInformationMessage){
succ = ((LogoffInformationMessage)message).newSucc;
}else if(message instanceof LaneBrokenConfirmationMessage){
succ = ((LaneBrokenMessage)message).getSender();
}
}
void updatePredecessor(Message message){
if(message instanceof LoginInformationMessage){
pred = ((LoginInformationMessage)message).newPred;
}else if(message instanceof LogoffInformationMessage){
pred = ((LogoffInformationMessage)message).newPred;
}else if(message instanceof LaneBrokenConfirmationMessage){
pred = ((LaneBrokenConfirmationMessage)message).getSender();
}
}
void updateValues(LoginConfirmationMessge lcm) {
laneAddressLeft = lcm.laneAddressLeft;
laneAddressRight = lcm.laneAddressRight;
pred = lcm.getSender();
succ = lcm.succ;
leftNeighborLane = lcm.NeighborLaneLeft;
rightNeighborLane = lcm.NeighborLaneRight;
Enumeration<Service> theOfferedServices =
lcm.laneOfferedServices.elements();
for (Service curServ : theOfferedServices) {
laneOffers.add(curServ);
}
}
92
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
D
Ergänzungen zu Pastry, Chord und Tapestry
Dieser Anhang stellt eine Ergänzung zu den Beschreibungen der Overlay-Netze in Kapitel 3
dar.
D.1 Pastry
Abbildung D-3 zeigt ein Beispiel für die Zustandsinformationen eines Pastry-Knotens. In
Kapitel 3 wurde bereits die Funktionsweise des Routing mit Hilfe der Routingtabellen und des
Leaf-Sets beschrieben. Der Leaf-Set eines Knotens beinhaltet Knoten, deren IDs zur eigenen ID
am ähnlichsten sind. Der Knotenzustand wird durch den so genannten Neighborhood-Set
komplettiert, der bisher nicht erläutert wurde. Der Neighborhood-Set dient nicht dem Routing,
sondern der Verwaltung von Lokalitätseigenschaften. Er beinhaltet die Adressen von Knoten,
die bezüglich einer zu Grunde liegenden Metrik, zum Beispiel Latenz oder Fehlerwahrscheinlichkeit, dem betrachteten Knoten am nächsten liegen.
Neighborhood-Set
Routing-Tabelle
13021022
02212102
10200230
22301203
02212102 22301203 31203203
11301233
31203203
11301233 12230203 13021022
31301233
33213321
10031203 10132102 10323302
Knoten ID
10233102
Leaf-Set
kleiner
größer
10233033
10233120
10233021
10233122
10233001
10233230
10233000
10233232
10200230 10211302 10222302
10230322 10231000 10232121
...
Abbildung D-3: Pastry-Knotenzustand (nach [16])
D.2 Chord
Abbildung D-4 verdeutlicht die Struktur von Chord und die für das Routing verwendeten
Fingertabellen. Diese speichern die direkten Nachfolger eines Chord-Knotens im Ring
zusammen mit dem Intervall der Objekt-IDs, für die der jeweilige Knoten zuständig ist.
93
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
Start
Int.
Nachf.
1
[1,2)
1
2
[2,4)
3
4
[4,0)
6
Start
Int.
Nachf.
2
[2,3)
3
3
[3,5)
3
5
[5,1)
6
0
7
1
6
2
3
5
Start
Int.
Nachf.
7
[7,0)
0
0
[0,2)
0
2
[2,6)
3
4
Start
Int.
Nachf.
4
[4,5)
6
5
[5,7)
6
7
[7,3)
0
Abbildung D-4: Chord-Knotenzustand (nach [21])
D.3 Tapestry
Dieser Abschnitt beschreibt das verteilte Verzeichnissystem von Tapestry, das zur
Veröffentlichung und zur Suche nach Objekten verwendet wird.
Bei den vorgestellten Overlay-Netzen werden die gespeicherten Objekte auf Grund der
Ähnlichkeit der Objekt-IDs und der Knoten-IDs auf den gemeinsamen verteilten Speicher
verstreut. Tapestry geht hier einen anderen Weg und überlässt die Entscheidung über den
Speicherort der Objekte den Anwendern. Der Knoten mit der zu einer Objekt-ID ähnlichsten
Knoten-ID wird als Wurzel bezeichnet und verwaltet den Verzeichniseintrag für das jeweilige
Objekt.
4377
437A
43FE
3228
Buch XY
(4378)
4361
4664
4A6D
4B4F
E391
AA93
Publizierung
Objektpointer
Anfrage
57EC
Buch XY
(4378)
Abbildung D-5: Objektpublizierung und speicherung (nach [26])
Ein Server S (Knoten auf dem ein Objekt O gespeichert ist) publiziert in gleich bleibenden
Abständen dieses Objekt durch Senden einer Publish-Nachricht an die Wurzel. Jeder Knoten,
den diese Nachricht passiert, speichert einen Pointer <O, S>.
94
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
Ist ein Client-Knoten an einem Objekt interessiert, sendet er eine Anfrage mit der gewünschten
Objekt-ID. Diese wird in Richtung des Wurzel-Knotens dieses Objekts geroutet. Besitzt ein
Router jedoch einen direkten Pointer auf den zuständigen Server, wird die Anfrage dorthin
umgeleitet. Neben der Ersparnis von Routing-Hops kann dadurch auch gewährleistet werden,
dass der zum Client-Knoten nächste Server angesprochen wird, falls mehrere Server das Objekt
zur Verfügung stellen.
95
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
E
Klassen- und Paketübersicht
Dieser Abschnitt gibt einen Überblick über alle im Rahmen dieser Arbeit erstellten JavaKlassen und Pakete und beschreibt kurz deren Funktion.
E.1 Transaktionssystem
diane.pflueger.maintainance.core
Kernkomponenten des Transaktionssystems
TransactionManager
Benutzerschnittstelle und Transaktionsverwaltung
Transaction
Repräsentation einer Transaktion und transaktionslokale Speicherablage
MaintainanceConfiguration
Schnittstelle für den Zugriff auf die Konfigurationsdatei des Transaktionssystems
CommitToleranceConfiguration
Konfiguration des Toleranzniveaus beim Commit
diane.pflueger.maintainance.log
Transaktionslog
LogManager
Logverwaltung
TransactionLogEntryStorage
Verwaltung aller Logeinträge einer Tansaktion
LogEntry
Einzelner Logeintrag
diane.pflueger.maintainance.commit
Commitprotokoll
CommitProtocol
Oberklasse eines Commitprotokolls
CommitException
Ausnahme bei Fehlern beim Commit durch Netzwerkpartitionierung
diane.pflueger.maintainance.scheduler
Scheduler
ScheduleProtocol
Oberklasse eines Schedulers
ScheduleFactory
96
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
Fabrik zur Erzeugung einer spezifizierten Scheduler-Instanz
NOProtectionScheduleProtocol
Scheduler, der den transaktionalen Schutz umgeht (nur zur Evaluation!)
OptimisticScheduleProtocol
Optimistischer Scheduler
TwoPhaseScheduleProtocol
Scheduler mit strengem 2-Phasen-Sperren
PreLockingScheduleProtocol
Vorab sperrender Scheduler
SequentialScheduleProtocol
Sequenzialisierendes Schedule-Protokoll
diane.pflueger.maintainance.overlay
Allgemeine Vorlagen für die Realisierung von Overlay-Protokollen
OverlayProtocol
Oberklasse eines Overlay-Protokolls
OverlayProtocolState
Oberklasse für einen Zustand eines Overlay-Protokolls (Stellt Transaktionsfunktionalität zur Verfügung)
OverlayModel
Allgemeines Modell eines Overlay-Protokolls
OverlaySwingView
Allgemeine Darstellung eines Overlay-Protokolls
TransactionTrackedMessage
Vom Transaktionssystem protokollierbarer Nachrichtentyp
TransactionFailureActionRepository
Sammlung möglicher Fehlerbehebungsaktionen bei Commitfehlern
OverlayConfiguration
Oberklasse für die Schnittstelle für
Konfigurationsdatei des Overlay-Protokolls
den
Zugriff
auf
diane.pflueger.maintainance.deadlock
Verklemmungsvermeidungssystem für sperrenbasierte Schedule-Protokolle
DeadlockPrevention
Verklemmungsvermeidung
AdjacencyMatrix
Adjazenzmatrix des Wartegraphen
DeadlockException
Ausnahme zur Anzeige einer verhinderten Verklemmung
97
die
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
E.2 Lanes-Protokoll
diane.pflueger.lanes
Lanes-Protokoll
LanesProtocol
Protokollklasse mit den Lanesbenutzerfunktionen (Login,
)
LanesConfiguration
Schnittstelle für den Zugriff auf die Konfigurationsdatei des LanesProtokolls
LanesTransactionFailureActions
Sammlung konkreter Fehlerbehebungsaktionen bei Commitfehlern
diane.pflueger.lanes.usercalls
Benutzerfunktionsaufrufe und -ergebnisse des Lanes-Protokolls
LoginCall
Anzeige eines Login-Wunschs durch den Benutzer
LoginResponse
Ergebnisanzeige eines Logins
LogoffCall
Anzeige eines Logoff-Wunschs durch den Benutzer
LogoffResponse
Ergebnisanzeige eines Logoffs
ServiceOfferCall
Anzeige eines Dienstangebots durch den Benutzer
ServiceOfferResponse
Ergebnisanzeige eines Dienstangebots
ServiceRevokeCall
Anzeige des Zurücknehmens eines Dienstangebots durch den Benutzer
ServiceRevokeResponse
Ergebnisanzeige einer Dienstangebotsrücknahme
ServiceSearchCall
Anzeige einer Dienstsuche durch den Benutzer
ServiceSearchResponse
Ergebnis einer Dienstsuche
98
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
diane.pflueger.lanes.structures
Modell und View des Lanes-Protokolls
LanesModel
Modell des Lanes-Protokolls
LanesSwingView
Darstellungsanweisungen einer Lane
diane.pflueger.lanes.messages
Nachrichten des Lanes-Protokolls
login.LoginRequestMessage
Loginwunsch
login.LoginOfferMessage
Loginangebot
login.LoginAcceptMessage
Akzeptieren eines Loginangebots
login.LoginInformationMessage
Informieren von Reaktor 2
login.LoginInformationConfirmationMessage
Informationsbestätigung durch Reaktor 2
login.LoginConfirmationMessage
Loginbestätigung an den Initiator
logoff.LogoffInformationMessage
Informieren von Vorgänger und Nachfolger beim Logoff
logoff.RemoveLaneMessage
Informieren einer Nachbarlane beim Logoff des letzten Laneknotens
ping.LanePingMessage
Ping-Nachricht
ping.ConnectivityCheckMessage
Verbindungsprüfung zu Vorgänger vor dem Start von LaneBroken
ping.NotLoggedMessage
Nachricht, um anzuzeigen, dass der angepingte Knoten ausgeloggt ist
lanebroken.LaneBrokenMessage
Starten der Lane-Reparatur
lanebroken.LaneBrokenConfirmationMessage
Bestätigung der Lane-Reparatur
splitting.SplitRequestMessage
Starten der Lane-Teilung
99
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
splitting.SplitCompleteMessage
Bestätigung der Lane-Teilung
merging.MergeRequestMessage
Starten der Lane-Wiedervereinigung
service.ServiceOfferMessage
Dienstangebot
service.ServiceRevokeMessage
Rücknahme eines Dienstangebots
service.ServiceSearchMessage
Dienstsuche
service.ServiceSearchResultMessage
Dienstsuche-Ergebnis
service.ServiceRefreshRequestMessage
Starten der Dienstaktualisierung
service.ServiceRefreshCompleteMessage
Beenden der Dienstaktualisierung
other.InitalizationEvent
Event zur Anzeige eines erfolgreichen Logins zur Knoteninitialisierung
other.UpdatePredPredMessage
Aufforderung zur Aktualisierung des Vor-Vorgängers
interlaneconnectivity.MissingLaneMessage
Broadcast-Nachricht zur Suche nach neuem Lane-Nachbar
interlaneconnectivity.MissingLaneAnswerMessage
Antwort auf MissingLaneMessage
interlaneconnectivity.UpdateNeighborLaneMessage
Nachricht zur Aktualisierung der Nachbar-Lane
diane.pflueger.lanes.states
Zustände des Lanes-Protokolls
login.StartLoginState_Initiator
Beginn des Loginvorgangs (Initiator)
login.PerformLoginState_Initiator
Logindurchführung (Initiator)
login.LoginOfferProcessingState_Reaktor1
Versenden eines Loginangebots nach Erhalt von Anfragen (Reaktor 1)
login.InformSuccessorState_Reaktor1
Informieren des Nachfolgers nach Erhalt einer Accept-Nachricht (Reaktor
1)
100
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
login.WaitForInfoConfState_Reaktor1
Warten auf Bestätigung durch Nachfolger und Senden der Bestätigung an
neuen Knoten (Reaktor 1)
login.PerformLoginState_Reaktor2
Logindurchführung (Reaktor 2)
logoff.PerformLogoffState_Initiator
Logoffdurchführung (Initiator)
logoff.PerformLogoffState_Reaktor
Logoffdurchführung (Reaktor)
ping.SendPingState
Pingdurchführung (Vorgänger): Senden eines Pings
ping.WaitForPingState
Pingdurchführung (Nachfolger): Warten auf Ping
lanebroken.PerformLaneBrokenState_Predecessor
LaneBroken-Durchführung (Vorgänger)
lanebroken.PerformLaneBrokenState_Successor
LaneBroken-Durchführung (Nachfolger)
splitting.PerformSplittingState
Split-Durchführung
merging.PerformMergingState
Durchführung einer Wiedervereinigung mit den Nachbar-Lanes
service.announce.PerformServiceAnnounceState
Durchführung eines Dienstangebots
service.refresh.PerformServiceRefreshState
Durchführung der Dienstaktualisierung
service.revoke.PerformServiceRevokeState
Durchführung einer Dienstangebotslöschung
service.search.StartServiceSearchState_Initiator
Starten der Dienstsuche (Initiator)
service.search.
PerformServiceSearchState_Initiator
Warten auf Dienstsucheergebnisse (Initiator)
service.search. PerformServiceSearchState_Reaktor
Prüfung, ob gesuchte Dienste bekannt (Reaktor)
interlaneconnectivity.
PerformInterLaneConnectivityCheckState
Durchführung der Fehlerbehebung für Inter-Lane-Verbindungen
101
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
E.3 Zwei-Phasen-Commit-Protokoll
diane.pflueger.maintainance.commit.twopc
Zwei-Phasen-Commit-Protokoll
TwoPhaseCommitProtocol
Zwei-Phasen-Commit-Protokoll
TwoPCConfiguration
Schnittstelle für den Zugriff auf die Konfigurationsdatei des 2PCProtokolls
diane.pflueger.maintainance.commit.twopc.usercalls
Benutzerfunktionsaufrufe und -Ergebnisse des 2PC-Protokolls
CoordinatorCommitCall
Start des Commit-Protokolls als Koordinator
ParticipantCommitCall
Start des Commit-Protokolls als Teilnehmer
CommitResponse
Ergebnisanzeige des Commit-Protokolls
diane.pflueger.maintainance.commit.twopc.messages
Nachrichten des 2PC-Protokolls
VoteMessage
Abstimmungsnachricht über Transaktionsende
VoteResultMessage
Bekanntgabe des Ergebnisses der Transaktion
MissingVoteResultMessage
Suche nach Transaktionsergebnis, falls Verbindungsabbrüche eingetreten
sind
MissingVoteResultAnswerMessage
Antwort auf MissingVoteResultMessage mit Transaktionsergebnis
diane.pflueger.maintainance.commit.twopc.states
Zustände des 2PC-Protokolls
PerformCommitState_Coordinator
Commit-Durchführung als Koordinator
PerformCommitState_Participant
Commit-Durchführung als Teilnehmer
102
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
ProcessMissingVoteState
Bearbeitung nicht angekommener Transaktionsergebnismitteilungen
diane.pflueger.maintainance.commit.twopc.other
Sonstige Klassen des 2PC-Protokolls
VoteMessageRepository
Datenstruktur zur Verwaltung eingehender Votes beim Koordinator bis zu
deren Verarbeitung
VoteInformation
Teil der Datenstruktur zur Verwaltung von Votes beim Koordinator
E.4 Sonstiges
diane.pflueger.general
Allgemeine Klassen
ServiceDescription
Dienstbeschreibung
ServiceDescriptionStorage
Speicherstruktur für Dienstbeschreibungen
Tools
Allgemeine wiederverwendbare Funktionen
103
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
F Parameter-Einstellungen
Die folgenden Einstellungen des 2-Phasen-Commits und des Lanes-Protokolls wurden bei der
Evaluierung zu Grunde gelegt. Die Benchmark-Parameter wurden bereits in Tabelle 1 in Kapitel
6 beschrieben.
F.1 2-Phasen-Commit-Protokoll
Wartezeit (Abstimmung)
Wartezeit (Ergebnis)
Wartezeit (MissingResultAnswer-Nachricht)
Rücksetzen einer TA
(Verklemmung)
2 (s)
10 (s)
2 (s)
25 (s)
F.2 Lanes-Protokoll
Lane-Größe
Ping-Intervall
ServiceRefresh-Intervall
Wartezeit (Dienstsuche)
Wartezeit (LoginAngebote)
Wartezeit (Login-Conf.)
Wartezeit (LoginInform.-Conf.)
Wartezeit (LaneBrokenConf.)
Max. Login-Anzahl
(Merging)
Min. Intervall zw. 2
Loginversuchen eines
Knotens (Merging)
Min. Intervall zw. Login
2er Knoten (Merging)
Wartezeit (LaneMissingResult)
3 - 10
15 (s)
150 (s)
10 (s)
1,5 (s)
3 (s)
1 (s)
3 (s)
5
1 (s)
2 (s)
1,5 (s)
104
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Anhang
105
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Literatur
Literatur
[1]
J. Eberspächer, et al.; GSM Global System for Mobile Communication;
3. Auflage; Teubner Verlag; 2001
[2]
J. Schiller; Mobilkommunikation; Addison-Wesley; 2000
[3]
H. Höpfner, C. Türker, B. König-Ries; Mobile Datenbanken und
Informationssysteme; dpunkt.verlag; ISBN 3-89864-264-X; 2005
[4]
A. S. Tanenbaum; Computernetzwerke; Pearson Studium; München; 2003
[5]
A. S. Tanenbaum; Distributed Systems; Prentice Hall; 2002
[6]
E. Fromentin, F. Tronel; A Probabilistic Analysis of the Consensus Problem;
Centre National de la Recherche Scientifique, Institut de recherche en
informatique et systèmes aléatoires; Universität Rennes, Frankreich; Technical
Report 1226; 1999
[7]
H.Kudlich; Verteilte Datenbanken; Siemens Nixdorf Informationssysteme AG;
Berlin, München; 1992; ISBN 3-8009-1589-8
[8]
G. Weikum, G. Vossen; Transactional Information Systems; Morgan Kaufmann
Publishers; 2002
[9]
JAMES (Java-based Agent Modeling Environment for Simulation);
www.informatik.uni-rostock.de/FB/Praktik/Mosi/de/forschung/projekte
/james.html
[10]
DIANE (Dienste in Ad-Hoc-Netzen); http://hnsp.inf-bb.uni-jena.de/DIANE
[11]
M. Klein; DIANEmu A Java Based Generic Simulation Enviroment for
Distributed Protocols; 2003; Technical Report 2003/7; Universität Karlsruhe
(TH), Fakultät für Informatik
[12]
M. Klein, B. König-Ries, P. Obreiter; Lanes
A Lightweight Overlay for
Service Discovery in Mobile Ad Hoc Networks; Mai 2003; In Proc. 3. Workshop
on Applications and Services in Wireless Networks (ASWN2003), Bern
[13]
G. Papadopoulos; S-Lanes - Ein schlankes Overlay zur motivierten Dienstvermittlung in mobilen Ad-hoc-Netzen; Diplomarbeit; Institut für Programmstrukturen und Datenorganisation, Fakultät für Informatik, Universität
Karlsruhe (TH); Dez. 2003
106
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Literatur
107
[14]
M. Klein, B. König-Ries, P. Obreiter; Service Rings - A Semantic Overlay for
Service Discovery in Ad hoc Networks; Network for Business, Innovation and
Sustainability Conference (NBIS), Prag, Tschechische Republik; September
2003
[15]
M. Klein, M. Hoffman, D. Matheis, M. Müssig; Comparison of Overlay
Mechanims for Service Trading in Ad hoc Networks; Oktober 2004; Technical
Report 2004/2; Universität Karlsruhe (TH), Fakultät für Informatik
[16]
A.Rowstron, P. Druschel; Pastry: Scalable, distributed object location and
routing for large-scale peer-to-peer systems; In Proc. IFIP/ACM International
Conference on Distributed System Platforms, Heidelberg; Nov. 2001
[17]
FreePastry, Rice University, Houston (USA), http://freepastry.rice.edu
[18]
The Bamboo Distributed Hash Table; http://bamboo-dht.org/index.html
[19]
S.Rhea, D. Geels, T.Roscoe, J. Kubiatowicz; Handling Churn in a DHT; In
Proc. USENIX Annual Technical Conference, Boston, MA; Juni 2004
[20]
R. Domagalski; Chord: A scalable Peer-to-Peer Lookup Service for Internet
Applications; Seminar Internet Routing ; TU München; Juni 2003
[21]
I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, H. Balakrishnan; Chord: A
scalable Peer-to-Peer Lookup Service for Internet Applications; Technical
Report TR-819; MIT Laboratory for Computer Science; März 2001
[22]
S. Ratnasamy, P. Francis, M. Handley, R. Karp, S. Shenker; A scalable content
addressable network; In Proc. ACM SIGCOMM Conference (ACM Special
Interest Group on Data Communications), San Diego, CA; Aug. 2001
[23]
P. Baumung; Effiziente Endsystem-basierte Multicast-Dienste in Mobilen Adhoc-Netzwerken; E-Science und Grid, Ad-hoc-Netze, Medienintegration; 18.
Arbeitstagung des Deutschen Forschungsnetzes (DFN); Düsseldorf; Juni 2004
[24]
B. Zhao, A. Joseph, J. Kubiatowicz; Tapestry: A Infrastructure for Faulttolerant Wide-area Location and Routing; University of California, Berkeley;
Technical Report CSD-01-1141; April 2001
[25]
E. Buchmann, K. Böhm; Effizientes Routing in verteilten skalierbaren Datenstrukturen; Magdeburg; 10. GI-Fachtagung Datenbanksysteme für Business,
Technologie und Web (BTW) 2003, Leibzig
[26]
B. Zhao, L. Huang, J. Stribling, S. Rhea, A. Joseph, J. Kubiatowicz; Tapestry: A
Resilient Global-Scale Overlay for Service Deployment; IEEE Journal on
selected areas in communications Vol. 22 No. 1; Januar 2004
[27]
S. Rhea, C. Wells, P. Eaton, D. Geels, B. Zhao, H. Weatherspoon, J.
Kubiatowicz; Maintenance-Free Global Data Storage; In Proc. IEEE Internet
Computing; University of California, Berkeley; Oktober 2001
Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen -- Literatur
[28]
R. Winter, T. Zahn, J. Schiller; DynaMO: A Topology-Aware P2P Overlay
Network for Dynamic, Mobile Ad-Hoc Environments; Telecommunication
Systems, Vol. 27, S. 321-345; 2004
[29]
OMG; UML superstructure spezification version 2.0; Oktober 2004;
www.omg.org/cgi-bin/doc?ptc/2004-10-02
108