Experimentelle Evaluierung eines Ansatzes zur semantisch

Transcription

Experimentelle Evaluierung eines Ansatzes zur semantisch
entkoppelten Kommunikation in dynamischen, heterogenen
Netzwerken mittels Publish/Subscribe
Diplomarbeit
Universität Rostock
Fakultät für Informatik und Elektrotechnik
Institut für Informatik
Lehrstuhl für Informations- und Kommunikationsdienste
vorgelegt von:
Erstgutachter:
Zweitgutachter:
Betreuer:
Abgabedatum:
Roland Seuchter
Prof. Dr. Clemens H. Cap
Prof. Dr. Peter Forbrig
Henry Ristau
25.02.2010
Kurzfassung
In dieser Arbeit wird ASP (Announcement/Subscription/Publication), ein Routingverfahren für die Kommunikation in heterogenen Netzwerken, untersucht. Erstmals wird
das auf Publish/Subscribe basierende Verfahren in einem realen System umgesetzt. Das
Ziel der Arbeit ist es, zu prüfen, ob ASP in der Praxis als Middleware für die Kommunikation in heterogenen Netzen, wie sie zum Beispiel in intelligenten Umgebungen
vorkommen, geeignet ist. Bislang wurde ASP ausschließlich in Simulationen evaluiert. In
einem ausgewählten, realistischen Szenario sind die Experimente angesiedelt, mit denen
die Leistungsfähigkeit von ASP geprüft wird.
Abstract
This thesis analyses ASP (Announcement/Subscription/Publication). ASP is a routing
algorithm that is based on Publish/Subscribe. It has been designed to enable flexible
communication in heterogeneous networks. These networks can be found in smart environments and other systems. Earlier research used simulation to evaluate the concept
of ASP. This thesis marks the first time that ASP is implemented in a real system. The
objective of this thesis is to evaluate the approach and measure the performance of the
new system. A series of experiments in a realistic setting provide the data for assessing
ASP.
i
Inhaltsverzeichnis
Inhaltsverzeichnis
1. Einleitung
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Grundlagen und Stand der Technik
2.1. Überblick Publish/Subscribe . . . . . . .
2.2. Publish/Subscribe in heterogenen Netzen
2.3. Inhaltsbasiertes Routing . . . . . . . . . .
2.3.1. Datenmodelle . . . . . . . . . . . .
2.3.2. Adressierungsschemata . . . . . . .
2.3.3. Sprachen . . . . . . . . . . . . . .
2.3.4. Weitere Problemstellungen . . . .
2.4. Publish/Process/Subscribe . . . . . . . .
2.5. Announcement/Subscription/Publication
2.5.1. Interaktion . . . . . . . . . . . . .
2.5.2. Routing . . . . . . . . . . . . . . .
2.5.3. Anwendungsschnittstelle . . . . . .
2.5.4. Netzwerkabstraktionsschicht . . . .
2.5.5. Übertragungskategorien . . . . . .
2.6. Andere Publish-Subscribe-Middleware . .
2.7. Routingmetriken . . . . . . . . . . . . . .
2.7.1. Hop Count . . . . . . . . . . . . .
2.7.2. ETX . . . . . . . . . . . . . . . . .
2.7.3. ETT . . . . . . . . . . . . . . . . .
2.7.4. WCETT . . . . . . . . . . . . . . .
2.7.5. MIC . . . . . . . . . . . . . . . . .
2.8. Netzwerktechnologien . . . . . . . . . . .
2.8.1. IP . . . . . . . . . . . . . . . . . .
2.8.2. UDP . . . . . . . . . . . . . . . . .
2.8.3. Wireless LAN . . . . . . . . . . . .
2.8.4. Bluetooth . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
3
4
5
6
6
7
7
8
8
9
11
11
13
14
15
15
15
16
17
17
18
19
20
21
22
23
23
24
3. Konzept
26
3.1. Anwendungsszenarien für PPS . . . . . . . . . . . . . . . . . . . . . . . . 26
ii
Inhaltsverzeichnis
3.2. Szenario . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. Ziele von ASP . . . . . . . . . . . . . . . . . .
3.2.2. Überblick . . . . . . . . . . . . . . . . . . . . .
3.2.3. Variationsmöglichkeiten . . . . . . . . . . . . .
3.3. Abbildung auf ASP . . . . . . . . . . . . . . . . . . . .
3.3.1. Anwendungstypen und Übertragungskategorien
3.3.2. Plattformen und Netzwerktechnologien . . . . .
3.3.3. Anwendungsschnittstelle . . . . . . . . . . . . .
3.3.4. Interaktion . . . . . . . . . . . . . . . . . . . .
3.3.5. Caching . . . . . . . . . . . . . . . . . . . . . .
3.4. Metrik . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1. Datentransport . . . . . . . . . . . . . . . . . .
3.4.2. Datenverarbeitung . . . . . . . . . . . . . . . .
3.4.3. Metrik für ASP . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
28
30
31
32
33
34
35
37
40
40
42
42
4. Implementierung
4.1. Einleitung . . . . . . . . . . . . . . . .
4.2. Anwendungen . . . . . . . . . . . . . .
4.2.1. Rekorder . . . . . . . . . . . .
4.2.2. Speicherung . . . . . . . . . . .
4.2.3. Konverter . . . . . . . . . . . .
4.2.4. Download . . . . . . . . . . . .
4.2.5. Weitere Anwendungen . . . . .
4.3. Broker . . . . . . . . . . . . . . . . . .
4.3.1. Multithreading . . . . . . . . .
4.3.2. Priorisierung . . . . . . . . . .
4.3.3. Fragmentierung . . . . . . . . .
4.4. Protokollierung . . . . . . . . . . . . .
4.5. NAL . . . . . . . . . . . . . . . . . . .
4.5.1. Priorisierung . . . . . . . . . .
4.5.2. Ethernet und WLAN via UDP
4.5.3. Bluetooth via OBEX . . . . . .
4.6. Nachrichtenformat . . . . . . . . . . .
4.7. Metrik . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
44
44
45
45
45
46
46
46
46
47
47
48
48
48
49
50
51
52
5. Experimenteller Ansatz
5.1. Experimente . . . . . . .
5.2. Versuchsaufbau . . . . . .
5.2.1. Hardwareumfeld .
5.2.2. Softwareumfeld . .
5.2.3. Beispielaufbau und
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
53
55
56
56
56
. . . . .
. . . . .
. . . . .
. . . . .
-ablauf
.
.
.
.
.
.
.
.
.
.
6. Auswertung
59
6.1. Heterogenität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
iii
Inhaltsverzeichnis
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
6.8.
6.9.
Räumliche Entkopplung . . . . . .
Nachbarschaftsbeziehungen . . . .
Verwaltungsaufwand . . . . . . . .
Zeitliche Entkopplung . . . . . . .
Alternative Übertragungswege . . .
Gestörte Übertragungswege . . . .
Alternative Übertragungstechniken
Alternative Prozessoren . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
60
61
62
64
66
69
70
71
7. Schlussbetrachtungen
74
7.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
A. Nachrichtenformat
76
B. Versuche
B.1. Namensschema . . . . . . . . . . .
B.2. Übersicht der Experimente . . . .
B.3. Versuchsaufbau . . . . . . . . . . .
B.4. Hard- und Softwarespezifikationen
B.5. Ausgewählte Diagramme . . . . . .
77
77
77
79
83
84
Literaturverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
88
iv
Abbildungsverzeichnis
Abbildungsverzeichnis
2.1.
2.2.
2.3.
2.4.
Komponenten eines PPS-Knotens . .
Prozessor versendet Abonnements .
Verbindungsgewichtung durch ETX .
Beispiel Inter-Flow-Interferenz . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
12
19
20
3.1.
3.2.
3.3.
3.4.
3.5.
Szenarioskizze . . . . . . . . . . . . . . . . . . . .
Variationsmöglichkeiten im Szenario . . . . . . .
Schnittstellen zwischen Anwendungen und Broker
Nachrichtenverlust nach Routenänderungen . . .
Definition von tproc . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
35
38
43
5.1. Logische Trennung eines IP-Netzwerks in Subnetze . . . . . . . . . . . . . 54
6.1.
6.2.
6.3.
6.4.
Verwaltungsaufwand in Experiment 2, Reihe 2 . . . . . . . . .
Vergleich der Downloadzeiten . . . . . . . . . . . . . . . . . . .
Beispiel zeitlicher Ablauf der Ausbreitung von Ankündigungen
Störungen durch Bluetooth Inquiry Scans . . . . . . . . . . . .
B.1. Legende der Versuchsskizzen
B.2. Versuchsaufbau Experiment 1
B.6. Kosten der Ankündigungen in
B.10.Kosten der Ankündigungen in
B.11.Kosten der Ankündigungen in
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
X1v1R1@1M . .
X1v1R1@11M .
X1v1R1@54M .
X1v1R1@auto .
X1v1R2@dc80a .
X1v1R2@dc100 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
66
69
71
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
80
81
81
82
85
85
86
86
87
87
v
Tabellenverzeichnis
Tabellenverzeichnis
2.1.
2.2.
2.3.
2.4.
Publish-Subscribe-Beispielnachricht
ASP-Nachrichtentypen . . . . . . .
Übertragungskategorien . . . . . .
Vergleich der Metriken . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 8
. 14
. 15
. 21
3.1. Rollenverteilung in den Beispielszenarien . . . . . . . . . . . . . . . . . . . 27
3.2. Variationsmöglichkeiten der Vernetzung . . . . . . . . . . . . . . . . . . . 31
3.3. Variationsmöglichkeiten der Rollen und Plattformen . . . . . . . . . . . . 31
5.1. Kurzübersicht Versuchsrechner . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2. Rollenverteilung in Experiment 1, Variante 1, Reihe 2 . . . . . . . . . . . 57
6.1. Zuordnung der Versuche zu den Untersuchungsaspekten . . . . . . . . . . 60
6.2. Anzahl der Ankündigungen in Experiment 1, Variante 2, Reihe 1 . . . . . 62
6.3. Kosten und Hops in Experiment 1, Variante 1, Reihe 1 . . . . . . . . . . . 68
A.1. Nachrichtenformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
B.1.
B.2.
B.3.
B.4.
Durchgeführte Experimente
Softwareausstattung . . . .
Hardwareausstattung . . . .
Netzwerkperipherie . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
78
83
83
84
vi
1. Einleitung
1. Einleitung
1.1. Motivation
Intelligente Umgebungen sollen Menschen in ihren Arbeits- oder Wohnumgebungen
bei ihren Tätigkeiten unterstützen und sich an die Bedürfnisse ihrer Nutzer anpassen.
Dazu werden Räume mit Sensoren ausgestattet, die der Umgebung helfen, die Nutzer und ihren Kontext wahrzunehmen. Aktoren versetzen die Umgebung in die Lage, sich aktiv und selbstständig an die Situation anzupassen. Ein Beispiel sind ferngesteuerte Rollläden oder Zimmerlampen, die von einem Beleuchtungssensor gesteuert
werden, um eine gleichmäßige Beleuchtung zu gewährleisten. Die Flexibilität und Anpassungsfähigkeit intelligenter Umgebungen wächst sprunghaft, wenn neben einfachen
Sensoren und Aktoren weitere Geräte eingebunden werden. Angenommen, eine Person befindet sich in einem Wohnzimmer, das mit einem digitalen Videorecorder (DVR)
ausgestattet ist. Erkennt der Recorder, dass der Benutzer auf die Aufzeichnung eines
Spielfilms vom Vortag zugreift, wird die Zimmerbeleuchtung automatisch heruntergeregelt. Um dies zu erreichen, ist es notwendig, dass alle genannten Geräte miteinander
kommunizieren und kooperieren. Bei Sensoren, Aktoren und weiteren Geräten handelt
es sich aber um völlig unterschiedliche Geräte. Sie unterscheiden sich in ihrer Anzahl, in
der Rechen- und Speicherkapazität, in der Art und Leistungsfähigkeit der verfügbaren
Kommunikationsschnittstellen und in der Qualität der Stromversorgung. Ein Beleuchtungssensor mit ZigBee-Schnittstelle [Lüd07] und Solarbetrieb auf der einen Seite und
ein DVR mit 802.11n WLAN [Rec06] und Gigabit-Ethernet [Rec08] auf der anderen
Seite sind zwei Beispiele an gegenüberliegenden Enden eines breiten Spektrums. Diese
heterogene Vielfalt ist charakteristisch für intelligente Umgebungen.
Ein weiterer interessanter Aspekt intelligenter Umgebungen ist Mobilität. Betrachtet
man das eingangs genannte Beispiel erneut, so kann man sich leicht vorstellen, dass
der Benutzer, der den DVR steuert, ein Handy oder Smartphone besitzt. Intelligente
Umgebungen umfassen nicht nur Geräte, die fest installiert sind, sondern auch Geräte,
die mobil sind und die vom Nutzer in immer andere Umgebungen eingebracht werden. Im
Beispiel ist es wünschenswert, wenn sich das Telefon für die Dauer des Films selbstständig
in einen leisen Modus versetzt. Verlässt der Benutzer den Raum oder beendet er die
Aufzeichnung, kehrt das Telefon wieder in seinen ursprünglichen Betriebsmodus zurück.
Dazu muss es mit den anderen Geräten in der Umgebung kommunizieren. Kabellose
Verbindungstechniken eignen sich dafür besonders.
Die folgende Liste enthält zusätzliche charakteristische Eigenschaften für das Umfeld der
heterogenen Netze in intelligenten Umgebungen:
1
1. Einleitung
• paralleler Einsatz von Funkschnittstellen und Kabelverbindungen mit stark unterschiedlicher Reichweite, Bandbreite und Verfügbarkeit
• hohe Anzahl der Geräte
• unterschiedliche Hardware- und Programmierarchitekturen und damit verbunden
unterschiedliche Leistungsfähigkeit der Geräte
Das hat eine Reihe von Konsequenzen für das Netzwerk. Wegen der Vielzahl der Geräte
herrscht ein tendentiell hoher Kommunikationsbedarf. Arbeitet die Infrastruktur in dieser Situation nicht effizient, kann der Bedarf nicht gedeckt werden.
Dass es mobile Geräte und Geräte mit begrenzter Energieversorgung gibt, führt dazu, dass sich die Topologie des Netzes häufig ändert. Einzelne tragbare Geräte werden
bewegt und die Betriebszustände anderer Geräte ändern sich kurzfristig: An der einen
Stelle kommt ein mobiles Gerät hinzu, während am anderen Ende des Raumes ein batteriebetriebener Sensor den Dienst einstellen muss.
Vorhandene Funkschnittstellen verwenden ein geteiltes Medium und stellen eine Kommunikationsinfrastruktur vor weitere Probleme. Das Medium kann beträchtlichen Störungen ausgesetzt sein und die Verbindungsqualität kann schwanken. Auch dies hat
Änderungen in der Topologie zur Folge. Weiter kann eine festinstallierte, kabelgebundene Infrastruktur vorhanden sein, die im Allgemeinen eine höhere Bandbreite aufweist
und zuverlässiger ist als kabellose Netze, weshalb sie in die Kommunikationsvorgänge
einzubeziehen ist.
Nicht zuletzt führt die Vielfalt der Netzwerkschnittstellen der Geräte dazu, dass nur wenige Geräte unmittelbar miteinander kommunizieren können. Ein einheitlicher Adressraum existiert nicht. Die Kommunikation muss also koordiniert werden und kooperativ
sein. Einzelne Geräte müssen zwischen unterschiedlichen Techniken vermitteln.
Die genannten Eigenschaften heterogener Netze, wie sie in intelligenten Umgebungen
zu finden sind, und das Beispiel, veranschaulichen, dass es eine komplexe Aufgabe ist,
ein leistungsfähiges und flexibles Kommunikationskonzept zu entwerfen, dass die Geräte
miteinander verbindet.
1.2. Zielstellung
Mit Announcement/Subscription/Publication (ASP) existiert ein neuartiges Konzept,
das die Kommunikation in heterogenen Netzwerken ermöglichen kann. In einer Middleware kombiniert der Ansatz die Kommunikation mittels Publish/Subscribe mit einer flexiblen und aus Anwendungssicht transparenten Nachrichtenverarbeitung. Bislang wurde
der Ansatz von ASP in Simulationen evaluiert. Die Ergebnisse waren erfolgversprechend.
Erst eine reale Umsetzung kann zeigen, wie praxistauglich und ausgereift das in der Literatur beschriebene Konzept ist. In dieser Arbeit wird ASP daher erstmals in ein konkretes System überführt. Das entwickelte System ist die Grundlage für die experimentelle
2
1. Einleitung
Evaluierung des Ansatzes in einem praktischen Szenario. Aus dem Szenario werden in
dieser Arbeit vier unterschiedliche Experimente abgeleitet. Mit Hilfe dieser Experimente
werden Hypothesen geprüft, die sich wie folgt zusammenfassen lassen:
1. Das System funktioniert in einem heterogenen Umfeld.
2. Die Kommunikation ist räumlich entkoppelt und
3. erfolgt auf Grundlage von Nachbarschaftsbeziehungen.
4. Das System arbeitet mit einem niedrigen Verwaltungsaufwand.
5. Die zeitliche Entkopplung der Kommunikation ist gewährleistet.
6. Unter den alternativen Übertragungswegen wird ein effizienter gewählt.
7. Gestörte Übertragungswege werden vermieden und
8. unterschiedliche Übertragungstechnologien können genutzt werden.
9. Für die Datenverarbeitung werden die leistungsfähigsten der verfügbaren Geräte
eingebunden.
Ob ASP die gesteckten Erwartungen erfüllen kann, ergibt die Auswertung der praktischen Versuche. Es wird geklärt, wie effizient das implementierte System diese Ziele
erreicht und an welchen Stellen das Konzept gegebenenfalls verbessert oder konkretisiert
werden muss.
1.3. Überblick
Die vorliegende Arbeit ist neben der Einleitung in diesem Kapitel in sechs weitere Kapitel untergliedert. Kapitel 2 schildert die Grundlagen von Publish/Subscribe, dem darauf aufbauenden Ansatz Publish/Process/Subscribe und dem weiterführenden System
Announcement/Subscription/Publication (ASP). ASP ist der Untersuchungsgegenstand
dieser Arbeit.
Kapitel 3 erläutert das Szenario, in dem das implementierte System zum Einsatz kommt.
Fragestellungen, die einer erfolgreichen Implementierung vorausgehen, werden diskutiert.
Insbesondere wird die Metrik als ein Kernbereich der künftigen Middleware beschrieben.
Die Besonderheiten der Implementierung beschreibt Kapitel 4. Die Merkmale der Implementierung, die für das Verständnis des Ablaufs der Experimente und die spätere
Auswertung der Versuche von entscheidender Bedeutung sind, stehen dabei im Mittelpunkt.
Die Anforderungen an die Experimente und das Vorgehen bei den Versuchen enthält
Kapitel 5. Kapitel 6 diskutiert die durchgeführten Versuche und wertet sie aus. Die in
Abschnitt 1.2 genannten Hypothesen bilden den Leitfaden der Auswertung. Eine Zusammenfassung der Ergebnisse und einen Ausblick auf zukünftige Forschungsthemen
gibt Kapitel 7.
3
In Abschnitt 1.1 wurden die Merkmale intelligenter Umgebungen dargestellt. Damit die
Kommunikation in einem solchen Umfeld gewährleistet werden kann, wird eine geeignete Infrastruktur benötigt. Publish/Subscribe eignet sich als Grundlage einer solchen
Infrastruktur, denn die Kommunikation mittels Publish/Subscribe ist lose gekoppelt.
Client-Server-Architekturen sind zeitlich und räumlich eng gekoppelt. Client und Server
müssen zum Zeitpunkt der Kommunikation beide aktiv (und erreichbar) sein und der
Kommunikationspartner muss genau bekannt sein [TS08]. In einem heterogenen, dynamischen Netzwerk, in dem kein gemeinsamer Adressraum existiert und Verbindungen
instabil sind, werden diese Voraussetzungen nicht erfüllt.
Warteschlangensysteme entkoppeln die Kommunikation räumlich und zeitlich und sind
mit Publish/Subscribe sehr eng verbunden [EFGK03]. Publish/Subscribe ist jedoch noch
weiter entkoppelt, wie im folgenden Abschnitt beschrieben wird. Zudem ist die persistente Kommunikation, wie sie von Warteschlangensystemen angeboten wird, in intelligenten
Umgebungen im Allgemeinen nicht erforderlich. Die Infrastruktur ist somit zu komplex.
Im weiteren liegt der Schwerpunkt daher auf Publish/Subscribe. In diesem Kapitel werden zunächst die Grundlagen von Publish/Subscribe erläutert. Anschließend werden
schrittweise die Konzepte von Publish/Process/Subscribe (PPS) und Announcement/
Subscription/Publication (ASP) eingeführt. PPS ergänzt Publish/Subscribe um Mechanismen zur flexiblen Datenverarbeitung und unterstützt auf diese Weise die Kooperation
von Geräten in intelligenten Umgebungen. Auf PSP aufbauend, ist ASP ein Routingalgorithmus für die Kommunikation in heterogenen Netzwerken.
Metriken sind eine wesentliche Komponente von Routingalgorithmen. Auf Grundlage
einer Metrik wird die Auswahl der Verbindungen oder Pfade getroffen, auf denen Daten
transportiert werden. Für ASP wurde bislang keine Metrik festgelegt. Für die praktische
Umsetzung wird sie jedoch benötigt. Abschnitt 2.7 behandelt existierende Metriken. Sie
dienen später als Grundlage der Metrik für ASP.
Die praktische Umsetzung des entwickelten Systems greift auf eine Reihe verbreiteter
Netzwerktechnologien zurück. Das Kapitel schließt aus diesem Grund mit den wichtigsten Eckpunkten der eingesetzten Netzwerktechnologien.
4
2.1. Überblick Publish/Subscribe
Publish/Subscribe ist ein Kommunikationsparadigma [EFGK03], das unter anderem der
Interaktion von Komponenten in komplexen verteilten Systemen besser gerecht werden
möchte als andere Ansätze, zu denen das Client-Server-Modell, Remote Procedure Calls1
(RPC) und Warteschlangensysteme (bzw. nachrichten-orientierte Middleware, MOM)
gehören. Einen Überblick dieser Techniken bietet [TS08], sodass ihre Hintergründe hier
nicht weiter Gegenstand sind. Stattdessen veranschaulicht eine detaillierte Betrachtung
der Komponenten und der Funktionsweise von Publish/Subscribe dessen Potenzial und
unterstreicht die Vorzüge der zentralen Eigenschaften von Publish/Subscribe.
An der Kommunikation mittels Publish/Subscribe sind stets drei Parteien beteiligt: Subscriber, Broker und Publisher2 . Der Subscriber ist an den Nachrichten, die der Publisher
erzeugt, interessiert. Der Broker koordiniert die Kommunikation und leitet Nachrichten
ausschließlich weiter. Er hat selbst kein Interesse am Inhalt der Nachrichten und erzeugt
auch keine Botschaften, ist also weder Quelle noch Senke. Möchte der Subscriber Nachrichten empfangen, teilt er dem Broker sein Interesse mit, d.h. er abonniert bestimmte
Nachrichten. Erzeugt der Publisher eine Botschaft, sendet er diese an den Broker. Der
überprüft, ob es (einen oder mehrere) Subscriber gibt, die an der Nachricht interessiert
sind und leitet sie an alle interessierten Subscriber weiter. Bereits in seiner einfachsten
Form, weist das Modell zwei interessante Eigenschaften auf:
1. Die Kommunikation ist räumlich entkoppelt (anonym).
2. Je ein Publisher kann mit nur einer Operation Nachrichten an beliebig viele Subscriber übertragen (Multicast).
Versendet der Publisher eine Nachricht, adressiert er die Empfänger nicht direkt. Die
Verbreitung der Information wird dem Broker überlassen. In der Folge müssen sich die
Kommunikationspartner nicht kennen. Die Kommunikation gilt als räumlich entkoppelt [EFGK03]. Der zweite Punkt besagt, dass der Broker jede eintreffende Nachricht an
mehrere Empfänger weiterleiten kann, falls sie Interesse daran haben. Unabhängig davon können in einem Publish-Subscribe-System mehrere Publisher existieren und aktiv
Nachrichten versenden.
Neben der räumlichen Entkopplung ist die Kommunikation per Publish/Subscribe auch
zeitlich entkoppelt und erfordert keine Synchronisation von Publisher und Subscriber
[EFGK03]. Die Bedeutung der zeitlichen Entkopplung ist, dass Sender und Empfänger
einer Nachricht nicht zum gleichen Zeitpunkt aktiv sein müssen. So kann ein Publisher eine Nachricht versenden, während der Empfänger dieser Nachricht inaktiv ist, oder
falls die Verbindung auf Sende- oder Empfangsseite unterbrochen ist. Die Entkopplung
1
2
Vereinfachend soll dies auch Remote Method Invocation (RMI) umfassen.
Die Bezeichnung ist uneinheitlich. In einigen Veröffentlichungen heißt es Produzent und Konsument
statt Publisher bzw. Subscriber; anstelle von Nachrichten wird häufiger von Ereignissen gesprochen
[CRW00, EFGK03, MC02] u.a.
5
der Synchronisation bezieht sich auf das Blockieren der Kommunikationsvorgänge. Bei
Publish/Subscribe müssen sich weder Publisher noch Subscriber beim Versand bzw.
Empfang mit anderen Teilnehmern synchronisieren. Aldred et al. formalisieren die Entkopplung von Middleware entlang der drei Dimensionen Ort (Adresse), Zeit und Synchronisation [AADH05]. Sie argumentieren ferner, dass alle drei Dimensionen orthogonal
sind.
2.2. Publish/Subscribe in heterogenen Netzen
Stellt man den Ansatz von Publish/Subscribe den Charakteristika heterogener Netze
(siehe Abschnitt 1.1) gegenüber, stellt man fest, dass das Publish-Subscribe-Verfahren
gut für den Einsatz in intelligenten Umgebungen geeignet ist. Die räumliche Entkopplung
und die Multicast-Semantik helfen, viele Geräte zu verbinden. So müssen die Kommunikationspartner nicht aufwändig im Vorfeld einer Kommunikation ermittelt werden und
während des eigentlichen Kommunikationsvorgangs einzeln angesprochen werden. Die
veränderliche Topologie, hervorgerufen durch Geräte in unterschiedlichen Betriebszuständen, kann durch die zeitliche Entkopplung kompensiert werden, denn sie erlaubt die
Kommunikation auch dann, wenn einer der beteiligten Endpunkte inaktiv ist. Ähnliches
gilt für die Entkopplung der Synchronisation. Insbesondere erlaubt sie Applikationen
auf leistungsschwachen Geräten mit begrenzter Stromversorgung Nachrichten zu verschicken oder zu empfangen, ohne unter hohem Zeitaufwand auf andere Geräte warten
zu müssen.
2.3. Inhaltsbasiertes Routing
In Publish-Subscribe-Systemen spielt es eine entscheidende Rolle auf welcher Grundlage Nachrichten vom Broker weitergeleitet werden. Man spricht von inhaltsbasiertem
Routing, wenn der Broker auf Grundlage des Inhalts einer Nachricht entscheidet, wohin
diese übertragen werden soll. Daneben sind vordefinierte Multicastgruppen oder Flooding weitere Möglichkeiten zur Verbreitung der Nachrichten [CS04, MUHW04].
Das Datenmodell, die Adressierungsschemata und die Sprachen mit denen das
Interesse (oder das Angebot) an Inhalten beschrieben werden, sind grundlegend für
inhaltsbasiertes Routing, denn die Ausdrucksfähigkeit des Mechanismus, mit dem Interesse beschrieben werden kann, beeinflusst unmittelbar die Flexibilität des gesamten
Systems [CJ02]. Die folgenden Abschnitte geben einen Überblick zu den drei genannten
Bereichen. Abschließend werden in Abschnitt 2.3.4 weitere Problemstellungen vorgestellt
und einige konkrete Systeme genannt.
6
2.3.1. Datenmodelle
Es existieren unterschiedliche Datenmodelle um den Inhalt von Nachrichten zu beschreiben. Sie sind die Grundlage, um das Interesse an Nachrichten formulieren zu können.
Ein weit verbreitetes Modell ist das bei SIENA [CRW00] verwendete, das eine Nachricht
als eine typenlose Menge typisierter Attribute definiert3 . In einer leichten Abwandlung
sprechen die Autoren von Mercury von Listen typisierter Attribut-Wert-Paare [BRS02].
In jedem Fall sind dies die Modelle, die die wissenschaftlichen Veröffentlichungen dominieren. Sivaharan et al. nennen zusätzlich Zeichenketten, Tupel, XML-Dokumente und
Objekte als Datenmodell [SBC05].
2.3.2. Adressierungsschemata
Die Adressierung von Empfängern in Publish-Subscribe-Systemen kann auf unterschiedliche Art und Weise erfolgen. Die drei geläufigsten Ansätze arbeiten entweder
• kanalbasiert,
• themenbasiert oder
• inhaltsbasiert.
Kanalbasierte Ansätze berücksichtigen den Inhalt von Nachrichten nicht. Stattdessen werden Kommunikationskanäle über Namen identifiziert [CRW00]. Ein Subscriber
abonniert den Kanal und empfängt somit sämtliche Nachrichten, die über den gewählten
Kanal veröffentlicht werden. In der Implementierung lässt sich dieser Ansatz unmittelbar
auf existierende Architekturen wie IP-Multicast abbilden. In Tabelle 2.1 ist ein Beispiel
für eine Nachricht gegeben. In einem kanalbasierten Publish-Subscribe-System könnte
sie z.B. in dem Kanal Börsennachrichten“ veröffentlicht werden. Es steht dem Publisher
”
frei, welche Nachrichten er in welchem Kanal veröffentlicht.
Der Mechanismus themenbasierter Adressierung ist ausdrucksstärker als kanalbasierte Adressierung [HGM04,BCM+ 99,EFGK03]. Ein Publisher kennzeichnet jede Nachricht mit einem sogenannten Thema. Subscriber abonnieren Nachrichten mit einem bestimmten Thema. Stimmt das gewünschte Thema mit dem einer Nachricht überein,
wird die Nachricht an den interessierten Subscriber ausgeliefert. So könnte das Beispiel
(Tab. 2.1) das Thema Kursänderung“ haben.
”
Am flexibelsten ist die inhaltsbasierte Adressierung [BCM+ 99,HGM04]. Anstatt lediglich ein einzelnes Attribut oder Thema mit einem vorgegebenen Wert zu vergleichen,
erlauben inhaltsbasierte Verfahren die Auswertung der kompletten Nachricht (z.B. aller
Attribute). Erst wenn alle untersuchten Eigenschaften einer Nachricht erfüllt sind, d.h.
mit dem Interesse des Subscribers übereinstimmen, wird sie an diesen weitergeleitet. Eine
3
untyped set of typed attributes“ [CRW00]
”
7
Ausnahme bildet das System A-ToPSS [CJ02], welches auch teilweise Übereinstimmungen (n aus m ; n < m) zulässt. Zusammenfassend lässt sich sagen, dass die kanalbasierte
und insbesondere die themenbasierte Adressierung Spezialfälle der inhaltsbasierten Verfahren sind [HGM04,CRW00]. Das Beispiel aus Tabelle 2.1 würde die folgende komplexe
Bedingung erfüllen:
Unternehmen = ’Friendface’ UND Preis > 21,60 UND
(Handelsplatz = ’Hannover’ ODER Handelsplatz = ’Stuttgart’)
Neben den genannten Ansätzen schlagen Eugster et al. ein typbasiertes Verfahren vor,
welches eine engere Integration von Middleware und Sprache (siehe Abschnitt 2.3.3)
sowie Typsicherheit ermöglichen soll [EFGK03].
Attribut
Unternehmen
Wertpapier
Datum
Uhrzeit
Preis
Handelsplatz
Wert
Friendface
AKTIEFF
2009-07-27
14:06 CEST
21,64 e
Hannover
Tabelle 2.1.: Eine Beispielnachricht in einem Publish-Subscribe-System.
2.3.3. Sprachen
Die Ausdrucksfähigkeit eines inhaltsbasierten Publish-Subscribe-Systems hängt von der
Sprache ab, die genutzt wird, um Interesse – d.h. Abonnements – zu beschreiben. Gängig
ist die Formulierung als Zeichenkette wobei neben proprietären Sprachen auch SQL oder
XPath zur Anwendung kommen können [HBS+ 02, TRP+ 04, EFGK03]. Letzteres ist die
naheliegende Wahl, wenn Nachrichten in XML kodiert werden. Allgemein sind boolesche
Ausdrücke vorherrschend. Sie verknüpfen Vergleiche von Attributwerten und Konstanten
miteinander. Unterschiedliche Vergleichsoperatoren wie =,6=,<,> usw. kommen dabei
zum Einsatz, soweit sie auf den Datentypen der Attribute definiert sind [CRW00, SA97,
EFGK03].
2.3.4. Weitere Problemstellungen
In der Literatur werden spezielle Problemfragen von inhaltsbasiertem Routing diskutiert.
Häufig finden die Ergebnisse Eingang in Routingalgorithmen oder Prototypen. Eines der
Probleme ist die effiziente Auswertung von Prädikaten, d.h. der Vergleich von Nachrichten mit den Interessen der Kommunikationspartner. So wurden Überdeckungsrelationen
vorgeschlagen, um die Anzahl und Komplexität von Prädikaten zu reduzieren [CRW04].
8
Suchbäume sollen die Zahl der Vergleiche auf das für das Weiterleiten von Nachrichten
nötige Minimum reduzieren [BCM+ 99].
Über das Wann und Wo der Auswertung von Prädikaten gibt es unterschiedliche Meinungen. Das System Kyra [CS04] unterteilt den Raum möglicher Nachrichten und strukturiert zusätzlich das Netzwerk der Broker in Cliquen, die in Bäumen organisiert sind,
um die Vergleiche auf nahegelegenen und (pro Nachricht) weniger Knoten durchführen
zu müssen.
Vor dem Hintergrund der Multicast-Eigenschaft von Publish/Subscribe muss man das
Argument aus [CRW00] sehen, wonach Prädikate möglichst früh, d.h. wenige Stationen
vom Publisher entfernt auszuwerten sind, Verzweigungen, d.h. Kopien von Nachrichten,
möglichst spät, also nahe an den Subscribern durchgeführt werden sollen. Beides soll
die Belastung des Netzwerks minimieren. Konsequenterweise sollten Nachrichten für die
momentan kein Interesse besteht, überhaupt nicht versendet werden. Diese Optimierung
ist unter dem Begriff source quenching bereits seit längerem bekannt [SA97].
Die Anonymität der Kommunikationspartner und das Multicasting in inhaltsbasierten Publish-Subscribe-Systemen erschweren die verlustfreie Ende-zu-Ende-Übermittlung
von Nachrichten, was in vielen Anwendungen eine wichtige Anforderung an die Dienstgüte ist. Mit Gryphon wurde eine komplexe Lösung vorgestellt, die auf Zeitschlitzen
basiert [BSB+ 02] und die Nachrichtenübermittlung absichert.
Mobile Geräte und insbesondere MANETs4 stellen besondere Anforderungen. Huang und
Garcia-Molina beschreiben in [HGM04] Szenarien wie inhaltsbasiertes Publish-Subscribe
für mobile und Ad-Hoc-Umgebungen erweitert werden kann. Sie untersuchen den Einsatz
von zentralen, verteilten und replizierten Brokern. Zusätzlich untersuchen sie weitere
allgemeine Fragen des mobilen Publish/Subscribe.
Mit zwei unterschiedlichen Vorstellungen von Mobilität beschäftigt sich [FGKZ03]. Fiege
et al. unterscheiden die transparente Mobilität von Anwendungen, aber auch Mobilität
und Ortsbezug als Anwendungskontext. In ihrem Ansatz setzen sie auf Stellvertreter von
Subscribern, die Nachrichten empfangen, während der echte Subscriber keine Verbindung
zum Netz hat. GREEN und STEAM befassen sich ebenfalls mit dem mobilen Umfeld
[SBC05,MC02]. Sie sehen Anwendungen insbesondere im Verkehrsbereich und VANETs5
und erweitern Publish/Subscribe für ihre Beispielanwendungen um räumliche Nähe als
weitere Filterdimension.
2.4. Publish/Process/Subscribe
Um die volle Leistungsfähigkeit einer intelligenten Umgebung auszuschöpfen, müssen
alle vorhandenen Geräte miteinander kommunizieren. Wie bereits erläutert wurde (siehe S. 1), sind intelligente Umgebungen sehr heterogen. Ziel des in [Ris08] vorgestellten
4
5
Mobile ad hoc networks; siehe [Per01].
Vehicular ad hoc networks; siehe [MSJ09].
9
Publish/Process/Subscribe (PPS) ist es, den Geräten zu ermöglichen, unabhängig von
ihrer Kommunikationstechnologie Daten auszutauschen. Existierende Ansätze sind ungenügend und müssen von zentralen Komponenten und dem Bedarf manueller Konfiguration befreit werden [Ris08]. Um maximale Flexibilität zu erreichen, setzt das Konzept
von PPS auf Publish/Subscribe auf (siehe Abschnitte 2.1 und 2.2). Dabei macht es
sich dessen Vorzüge der räumlichen und zeitlichen Entkoppelung zunutze. Ergänzt wird
die Architektur aus Publisher, Subscriber und Broker um Prozesse, die Daten verarbeiten können (Prozessoren). Diese Prozesse können (Sensor-)Daten auswerten und Geräte
steuern oder sie unterstützen andere Geräte beim Datenaustausch durch die transparente
Wandlung von Daten in unterschiedlichen Formaten [Ris09a]. Ohne derartige Prozessoren werden Daten mit klassischem Publish/Subscribe lediglich verteilt.
Das Konzept von PPS, welches explizit auf die Anwendung in intelligenten Umgebungen
zugeschnitten ist, sieht für jeden Knoten eine bestimmte Struktur aus unterschiedlichen
Komponenten vor (siehe Grafik 2.1). Im heterogenen Netz verfügt jeder (physische)
Knoten über einen eigenen Broker (lokaler Broker), der die Kommunikation mit benachbarten Knoten bzw. deren Brokern übernimmt. Anwendungen, die auf dem Knoten
aktiv sind, werden in die drei Kategorien Quelle, Senke und Prozessor unterteilt. Jede
Anwendung ist mit dem lokalen Broker ihres Knotens über eine definierte Schittstelle
verbunden. Die Existenz von Brokern auf jedem Knoten wird damit begründet, dass auf
diesem Wege lokales Wissen über den Knoten und seine unmittelbaren Nachbarn für den
Betrieb genügt. Eine globale Sicht und damit die Kenntnis aller Knoten im Netzwerk
ist nicht erforderlich. Wegen der Heterogenität der Umgebung wäre sie unzweckmäßig.
Für ein Smartphone, welches per Bluetooth mit dem Netzwerk verbunden ist, ist die
Information, dass es in einem anderen Bereich des Netzes zwei per Ethernet verbundene
Knoten gibt, nutzlos. Das Smartphone kann nicht direkt mit den Knoten kommunizieren. Häufige Topologieänderungen wie sie im Einsatzumfeld von PPS zu erwarten sind,
treiben zudem die Kosten für das Vorhalten einer konsistenten und aktuellen Sicht auf
das gesamte Netz in die Höhe. Informationen über die Topologie müssten nach jeder
Änderung an jeden Knoten im Netz verteilt werden, was das Netzwerk belasten würde.
Eine weitere Komponente ist der sog. Network Abstraction Layer (NAL), die Netzwerkabstraktionsschicht. Sie verbirgt die Eigenheiten einer konkreten Kommunikationstechnik vor den darüberliegenden Schichten, also insbesondere vor dem Broker.
Die Interaktion der Broker und Anwendungen untereinander ist ein Routingproblem
[Ris08]. Nachrichten müssen von den Quellen, durch das Netzwerk aus Brokern hindurch,
zu den Senken transportiert werden. Auf dem Weg kann es erforderlich sein, dass ein oder
mehrere Prozessoren die Daten verarbeiten. Es können mehrere Wege von der Quelle zur
Senke existieren. Die Komplexität wird dabei durch die Einbeziehung der Prozessoren
erhöht. Um ein Datum d nach d0 abzubilden, können unterschiedliche Verknüpfungen
von Funktionen existieren, die sich in der Reihenfolge und Anzahl der Einzeloperationen
und damit den beteiligten Prozessoren unterscheiden. Es müssen also Wege durch ein
Netzwerk gefunden werden, die möglichst kostengünstig sind. In [Ris08] werden drei
Strategien für das Routing vorgestellt, von denen ein auf Flooding basierender Ansatz
10
Quelle
Quelle
Prozessor
Prozessor
Senke
Senke
Anwendungss.
Nachbarn
Broker
NAL
Abbildung 2.1.: Die Komponenten von PPS auf einem Knoten: Anwendungen (Quelle,
Prozessor, Senke), die Anwendungsschnittstelle, der Broker und die Netzwerkabstraktionsschicht (NAL). NAL und Broker sammeln Informationen
über Nachbarknoten. Abbildung nach [Ris08].
weiter verfolgt wird und in das Konzept Announcement/Subscription/Publication (ASP)
mündet. Einer der beiden weiteren Vorschläge basiert auf der Abbildung von Prozessoren
auf je eine Quelle und Senke, dem anderen liegt die netzweite Verbreitung des Interesses
an Publikationen zu Grunde.
2.5. Announcement/Subscription/Publication
Mit Announcement/Subscription/Publication (ASP) existiert ein Konzept, dass das zuvor beschriebene PPS umsetzen möchte. Die grundlegende Architektur von ASP ist
daher gleich der von PPS: In einem Netzwerk aus Knoten kommunizieren Anwendungen
(Quelle, Senke oder Prozessor) untereinander per Publish/Subscribe. Auf jedem Knoten
existiert dazu ein Broker mit Applikationsschnittstelle und Netzwerkabstraktionsschicht.
ASP konkretisiert einige dieser Konzepte und ergänzt einen Routingalgorithmus [Ris09a].
2.5.1. Interaktion
Die Interaktion zwischen den Brokern und den restlichen Komponenten des ASP-Systems läuft in drei Phasen ab: Ankündigung, Abonnement und Veröffentlichung. Jede
dieser Phasen wird auf einen separaten Nachrichtentyp abgebildet. Sämtliche Nachrichten tragen Identifikationsnummern. Sie werden fortan als ASP ID oder verkürzend als
ID bezeichnet. Trägt eine Ankündigung zum Beispiel die ID 7e44a5e4, so tragen alle
nachfolgenden Abonnements und Veröffentlichungen, die auf die Ankündigung bezug
nehmen dieselbe ID. Dies entspricht der themenbasierten Adressierung (siehe Seite 7).
Mit Ankündigungen (Announcement) signalisieren Quellen, dass sie Daten im Netz
zur Verfügung stellen. Ankündigungen werden grundsätzlich an alle Broker im Netzwerk
11
verteilt. Broker erhalten auf diese Weise eine Übersicht über die verfügbaren Datenquellen und lernen den Nachbarn kennen, über den die Nachrichten bezogen werden
können. Eine Ankündigung kann eine Beschreibung der Daten enthalten, die die Quelle in Zukunft unter der gegebenen ID veröffentlichen wird. Handelt es sich bei einer
Quelle beispielsweise um eine Webcam, die regelmäßig Aufnahmen macht, kann eine
Ankündigung Informationen wie den Standort der Kamera, Bildmaße usw. enthalten.
ASP legt weder die Form noch den Inhalt von Ankündigungen fest. Die Erzeugung
und Interpretation einer Ankündigung ist den Anwendungen (Quelle, Prozessor, Senke)
überlassen. Erzeugt eine Quelle Nachrichten von geringem Umfang oder werden sie nur
selten versendet, kann eine Ankündigung statt einer Beschreibung das komplette Datum
enthalten. Ein Temperatursensor kann auf diese Weise den jüngsten Messwert mit einer Ankündigung verbreiten. Neben Quellen können auch Prozessoren den Versand von
Ankündigungen auslösen. Dies geschieht als Reaktion auf Ankündigungen von anderen
Quellen oder Prozessoren, wenn ein Prozessor aus den bisher empfangenen Ankündigungen A1 , A2 usw. beziehungsweise den entsprechenden Veröffentlichungen P1 , P2 usw.
eine neue Ankündigung A0 (bzw. P 0 ) erzeugen kann.
Ein Abonnement (Subscription) wird als Reaktion auf eine Ankündigung verschickt.
Bevor eine Senke ein Abonnement auslösen kann, muss sie eine Ankündigung empfangen
haben. Wird eine Ankündigung eines Prozessors abonniert, abonniert dieser alle Ankündigungen, die nötig sind, um die gewünschten Veröffentlichungen erzeugen zu können
(siehe Grafik 2.2).
S1
S’
Proz.
Broker
S2
S3
Abbildung 2.2.: Ein Prozessor erhält ein Abonnement S 0 und versendet daraufhin Abonnements für S1 , S2 , S3 .
Neben Abonnements existieren Kündigungen. Sind ein Prozessor oder eine Senke nicht
länger an den Daten einer Quelle interessiert, versendet der zuständige Broker eine
Kündigung, die dieselbe ID wie die Ankündigung trägt. Spätere Veröffentlichungen mit
dieser ID werden dem Prozessor oder der Senke nicht zugestellt.
Die von Quellen angebotenen Daten werden in Form von Veröffentlichungen (Publication) verbreitet. Jede Veröffentlichung trägt die zur jeweiligen Ankündigung und
dem Abonnement gehörende ID. Liegt einem Broker kein Abonnement zu einer ID vor,
versendet der Broker die von den lokalen Anwendungen erzeugten Veröffentlichungen
nicht.
12
2.5.2. Routing
ASP sieht einen Routingalgorithmus vor, der lediglich voraussetzt, dass Knoten ihre
unmittelbaren Nachbarn kennen, mit denen sie direkt kommunizieren können.
Ankündigungen werden wie bereits erwähnt, an alle Broker im Netz verteilt. Um dies zu
erreichen, werden Ankündigungen im Netzwerk geflutet. Eine neue Nachricht (Ankündigung) wird an alle benachbarten Broker und lokalen Prozessoren und Senken verteilt.
Empfängt ein Broker bi eine Ankündigung von einem Nachbarn, speichert er, von welchem Nachbarbroker bj die Ankündigung versendet wurde. Außerdem merkt der Broker
bi sich die Kosten der Nachricht. Eine Metrik akkumuliert die Kosten der Weiterleitung
der Ankündigung vom erzeugenden Broker b0 bis zum empfangenden Broker bi . Anschließend reicht der Broker die Ankündigung an lokale Anwendungen und leitet die Nachricht
an alle ihm bekannten Nachbarn mit Ausnahme des Absenders bj weiter. Dabei werden
die Kosten der Nachricht entsprechend den Kosten der Verbindung, über die die Ankündigung weitergeleitet wird, angepasst. Broker speichern die IDs von Ankündigungen, die
sie bereits weitergeleitet haben. Eine Ankündigung wird von jedem Broker nur einmal
an seine Nachbarn weitergeleitet. Dadurch ist sichergestellt, dass die Weiterleitung der
Nachrichten terminiert.
Erhält eine Senke von ihrem Broker eine Ankündigung und ist sie an zukünftigen Veröffentlichungen, wie sie in der Ankündigung beschrieben werden, interessiert, signalisiert
die Senke dies ihrem Broker. Dieser erzeugt ein Abonnement mit der ID der Ankündigung. Kann das Abonnement nicht von einer lokalen Quelle oder Prozessor bedient
werden, verschickt der Broker die Nachricht an einen seiner Nachbarn. Der Broker wählt
den Nachbarn, dessen Kosten laut Metrik für die gegebene ID minimal sind. Abonnements gelangen schrittweise zum Broker, der die ursprüngliche Ankündigung versandt
hat. Empfängt ein Broker ein Abonnement, nimmt er den sendenden Nachbarn mit der
ID und den Kosten in eine Tabelle sogenannter aktiver Pfade auf. Das Abonnement wird
wie zuvor an den Nachbarn mit der günstigsten Ankündigung weitergeleitet. Stammt die
günstigste Ankündigung A0 von einem lokalen Prozessor, wird die Nachricht an diesen
weitergegeben. Für alle Ankündigungen A1 bis An (n ≥ 1), die der Prozessor verarbeiten
muss, um A0 erzeugen zu können, werden Abonnements verschickt. Erreicht ein Abonnement die Quelle der Ankündigung, wird die Nachricht nicht weitergeleitet. Der Broker
merkt sich von welchem Nachbarn das Abonnement gesendet wurde. Kündigungen werden auf dieselbe Weise weitergeleitet wie Abonnements.
Veröffentlicht eine Quelle Daten, erzeugt der Broker eine Veröffentlichung und sendet sie
an alle Nachbarn, die Teil eines aktiven Pfades für die gegebene ID sind. Beim Empfang
einer Veröffentlichung reicht ein Broker die Daten an lokale Anwendungen (Prozessor
oder Senke), falls diese die ID der Veröffentlichung abonniert haben. Danach wird die Veröffentlichung an alle Nachbarn weitergeleitet, von denen Abonnements der ID vorliegen.
Damit die Zahl der von einem Broker gespeicherten aktiven Pfade und weitergeleiteten
Ankündigungen nicht beliebig zunimmt, wird jede Ankündigung bei ihrer Erzeugung
mit einer Gültigkeitsdauer versehen. Ist die Gültigkeit einer Ankündigung abgelaufen,
13
werden alle damit verbundenen aktiven Pfade ungültig. Veröffentlichungen werden dann
von den Brokern entlang dieser Pfade nicht mehr weitergeleitet. Ein ungültiger Pfad
und die zugrunde liegende Ankündigung werden von Brokern gestrichen. Quellen und
Prozessoren bzw. deren Broker verlängern Ankündigungen vor Ablauf ihrer Gültigkeit.
Um eine eventuell aufgetretene Verdopplung einer Ankündigung von einer Verlängerung
derselben unterscheiden zu können, tragen Ankündigungen Sequenznummern.
Ein weiterer Nachrichtentyp wird verwendet, wenn es bei der Weiterleitung von Veröffentlichungen entlang eines aktiven Pfades zu Ausfällen von Knoten oder Verbindungen
kommt. Erkennt ein Broker ein solches Problem wird eine Störungsmeldung ( broken
”
path“, siehe [Ris09a]) erzeugt. Die Meldung trägt die ID der Ankündigung, die dem
gestörten aktiven Pfad vorausging und wird nach demselben Verfahren wie Abonnements zur Quelle einer Ankündigung weitergeleitet. Dort erzeugt der betreffende Broker
eine neue Ankündigung, die im Netzwerk geflutet wird. Interessierte Senken oder Prozessoren reagieren darauf mit einem erneuten Abonnement, wodurch die aktiven Pfade
wiederaufgebaut werden.
Tabelle 2.2 fasst die unterschiedlichen Nachrichtentypen und ihre Funktionen zusammen.
Nachrichtentyp
Ankündigung
Abonnement
Kündigung
Störungsmeldung
Veröffentlichung
Kurzbeschreibung
Information über die Verfügbarkeit von Daten,
Routenfindung
Ausdruck von Interesse, Aufbau aktiver Pfade
Abbau aktiver Pfade
Reparatur kaputter, aktiver Pfade
Transport von Daten zwischen Quelle, Prozessor
und Senke
Tabelle 2.2.: Eine Übersicht der Nachrichtentypen von ASP.
2.5.3. Anwendungsschnittstelle
Die Anwendungsschnittstelle dient dem Datenaustausch zwischen Quelle, Senke oder
Prozessor auf der einen und dem Broker auf der anderen Seite. In [Ris09a] wird sie umrissen. Demnach müssen sich Anwendungen zunächst beim lokalen Broker registrieren.
Dadurch werden der Versand und Empfang von Daten ermöglicht. Für Senken und Prozessoren – die einzigen möglichen Empfänger von Nachrichten – ist vorgesehen, dass sie
bei der Registrierung einen Filter angeben. Ein Filter schränkt die Menge der Ankündigungen, die vom Broker an die jeweilige Anwendung weitergereicht werden, ein. So
erhält die Anwendung nur Ankündigungen, die den Filter passieren. Ohne Filter werden
alle gültigen Ankündigungen zugestellt, die den Broker erreichen.
Für die Schnittstelle zwischen Prozessoren und Broker ist vorgesehen, dass ein Prozessor
Angaben über die Kosten der Datenverarbeitung macht. Der Broker bestimmt daraus
die Gesamtkosten.
14
2.5.4. Netzwerkabstraktionsschicht
Zu den Aufgaben der Netzwerkabstraktionsschicht (NAL) gehört das Erkennen und Verwalten von Nachbarknoten. Nachrichten soll der NAL bei der Übertragung zwischen
Nachbarn vor Verlust schützen. Außerdem sammelt die Schicht Informationen über Verbindungen, um die Metrik zu berechnen, die die Weiterleitung von Nachrichten steuert. Existiert ein NAL für die darunterliegende Sicherungsschicht ( [data] link layer“),
”
spielt es keine Rolle, ob das Gerät über Bluetooth-, ZigBee- oder IEEE 802.11b WLANSchnittstellen verfügt. Dabei muss der NAL nicht notwendigerweise von diesem Niveau
abstrahieren, sondern kann z.B auch auf UDP/IP aufsetzen.
2.5.5. Übertragungskategorien
Die Art der Nachrichten (Veröffentlichungen) und damit der Daten, die in einem ASPNetzwerk verteilt werden, kann von Anwendung zu Anwendung stark variieren. Eine
Unterteilung aller denkbaren Übertragungen in vier Kategorien wird daher in [Ris09a]
vorgenommen. Die Einteilung in die Kategorien erfolgt anhand der Nachrichtengröße
bzw. der Häufigkeit von Veröffentlichungen. Daraus ergeben sich folgende Kategorien:
Kategorie
1
2
3
4
Nachrichtengröße
klein
klein
groß
groß
Häufigkeit
Einzelnachrichten
Nachrichtenstrom
Einzelnachrichten
Nachrichtenstrom
Tabelle 2.3.: Einteilung der Übertragungen in Kategorien nach [Ris09a].
Die Einteilung wird vorgenommen um unterschiedliche Optimierungen bei der Verteilung
der Nachrichten anwenden zu können. So wird unter anderem vorgeschlagen, kleine,
selten versendete Nachrichten (Kategorie 1) im gesamten Netzwerk zu fluten.
Große Nachrichten (Kategorien 3 und 4), insbesondere Veröffentlichungen, sind größer
als einzelne Nachrichten auf der Sicherungsschicht6 des Netzwerks sein können. ASP
sieht daher einen Mechanismus zur Fragmentierung von Veröffentlichungen in mehrere
Nachrichten vor.
2.6. Andere Publish-Subscribe-Middleware
Es gibt Middleware, die Publish/Subscribe in heterogenen Netzen oder intelligenten Umgebungen umsetzt. Erwähnenswert sind STEAM, GREEN, Rebeca und MundoCore. Im
Fokus von STEAM [MC02] stehen MANETs nach IEEE 802.11. Die Autoren verwenden
6
OSI-Layer 2. OSI-Referenzmodell siehe [Tan03, S. 37 ff.]
15
als Pub-Sub-Terminologie Produzent, Konsument und Ereignis. Als größte Schwierigkeit
in Ad-Hoc-Umgebungen sehen sie das Fehlen systemweiter Dienste, weshalb existierende Kommunikations-Middleware wie CORBA ungeeignet sei. Als Einsatzbereich ihrer
Technik beschreiben sie Verkehrsanwendungen. Aus diesem Grund integrieren sie das
Konzept der räumlichen Nähe in die Verbreitung von Nachrichten.
Die Fähigkeit, die Middleware schnell an andere Umgebungen anzupassen und somit
schnell zwischen infrastrukturbasiertem und Ad-Hoc-Funk wechseln zu können, sind
die herausragenden Eigenschaften von GREEN [SBC05]. Der modulare Aufbau und die
Möglichkeit der Rekonfiguration zur Laufzeit erlauben GREEN die Verwendung themenund inhaltsbasierter Publish-Subscribe-Adressierung. Darüber hinaus werden Ereignisse
im Netz je nach Konfiguration über Multicast-Overlay-Netze oder strukturierte OverlayNetze transportiert. Die Middleware kann bei Bedarf für bestimmte Dienstgütemerkmale
konfiguriert werden. Als Beispiel nennen die Autoren die Zustellung von Nachrichten innerhalb festgelegter zeitlicher Fristen.
Die Publish-Subscribe-Middleware Rebeca wurde erweitert, um Mobilität von Clients
(Publisher oder Subscriber) zu ermöglichen [FGKZ03]. Die Autoren unterscheiden dabei
zwei Formen von Mobilität: Physische und logische Mobilität. Darunter verstehen sie
Standortänderungen von Clients auf der einen Seite und die Änderung der Position als
Anwendungskontext auf der anderen Seite. Sie schlagen Verfahren vor, wie beide Arten
der Mobilität in die bestehende Publish-Subscribe-Middleware integriert werden können.
Der Umgang mit der physischen Mobilität basiert auf einem virtuellen Subscriber, an
den Nachrichten ausgeliefert werden, während sich der reale Subscriber (vom Netzwerk
getrennt) bewegt [ZF03]. Wenn der Subscriber wieder Anschluss an das Netz findet,
werden zwischenzeitlich veröffentlichte Nachrichten zugestellt.
Aitenbichler et al. haben mit MundoCore ein umfangreiches Middleware- und Programmier-Framework für den Einsatz in intelligenten Umgebungen entwickelt [AKM07]. Es
bietet kanalbasiertes und inhaltsbasiertes Publish/Subscribe. In der Transportschicht7
werden IP, serielle Bluetoothverbindungen und Infrarotverbindungen unterstützt. Die
modularen Protokollstapel erlauben den Einsatz unterschiedlicher Routingstrategien wie
hierarchisches Routing und strukturierte Overlay-Netze. MundoCore ist u.a. für die JavaPlattformen J2SE8 und J2ME/CLDC9 verfügbar und unterstützt damit eine Vielzahl
von Endgeräten.
2.7. Routingmetriken
Wie in Abschnitt 2.4 beschrieben, handelt es sich bei der Kommunikation von Brokern
und den an sie angebundenen Anwendungen um ein Routingproblem. Das Netzwerk in
dem geroutet werden soll, wird an dieser Stelle als gerichteter Graph G abstrahiert, wobei
7
transport layer“ [AKM07]. Gemeint ist die Transportschicht von MundoCore, nicht OSI-Layer 4.
Java 2 Standard Edition. Siehe [Ull07].
9
Java 2 Micro Edition / Connected Limited Device Configuration. Siehe [Sun03].
8”
16
G = (V, E). Die Rolle einer Routingmetrik ist es, die Kanten des Graphen (E) zu gewichten. Im Allgemeinen handelt es sich um eine Funktion d : E → R+ . Existieren zwischen
zwei Knoten im Graph unterschiedliche Pfade (Bogenzüge), so wählt ein Routingprotokoll den Pfad mit dem minimalen Gewicht. Das Gewicht eines Pfades ergibt sich dabei
aus der Summe der Gewichte seiner Kanten. Es existieren unterschiedliche Metriken, die
sich darin unterscheiden, wie gut sie an die Bedürfnisse einer bestimmten Netzwerkinfrastruktur angepasst sind. Außerdem sind die Berechnungen zur Gewichtung einzelner
Kanten unterschiedlich aufwändig und erfordern jeweils anderes Wissen über den Zustand einzelner Verbindungen oder des gesamten Netzes. In den letzten Jahren wurden
unterschiedliche Routingmetriken entwickelt, die zunehmend besser an die spezifischen
Eigenschaften von drahtlosen Netzwerken angepasst sein sollen. Die Metriken wurden
mit dem Ziel entwickelt, vor allem den Durchsatz im Netzwerk zu erhöhen. Im folgenden
werden die Metriken Hop Count, ETX, ETT, WCETT und MIC überblicksartig vorgestellt. Die Entwickler der Metriken sind davon ausgegangen, dass die Funknetze statisch
sind, d.h. dass die teilnehmenden Knoten nicht mobil sind. Abschließend fasst Tabelle
2.4 die Eigenschaften der betrachteten Metriken vergleichend zusammen.
2.7.1. Hop Count
Eine weit verbreitete Metrik trägt die Bezeichnung Hop Count. Der Begriff bezieht sich
auf die Anzahl der Verbindungen, über die eine Nachricht übertragen werden muss, damit sie von einem Knoten zu einem anderen gelangt. Die Zahl ist äquivalent zur Anzahl
der Kanten, die ein Pfad zwischen zwei unterschiedlichen Knoten enthält. Es ergibt sich
dhopcount (e) = 1 mit e ∈ E. Die Metrik wird oft verwendet, weil bei ihrer Verwendung das
Netzwerk dazu tendiert, die Übertragungsverzögerung und die beanspruchte Bandbreite
zu minimieren [Tan03, S. 351]. OLSR (Optimized Link State Routing Protocol) ist ein
Routingprotokoll, welches die Hop-Count-Metrik verwendet [CJ03]. Auch RIPv1 (Routing Information Protocol), RIPv2 und RIPng verwenden Hop Count [MR07, S. 162].
2.7.2. ETX
Ein Nachteil der Hop-Count-Metrik ist, dass keinerlei Informationen über die Verbindungsqualität in die Gewichtung von Kanten eingehen. Dies ist insbesondere in Funknetzen eine Schwäche des Ansatzes. Während die kabelgebundene Übertragung z.B. im
Ethernet oder entlang von Lichtwellenleitern stabil ist, wird die Übertragung per Funk
von vielen Faktoren beeinträchtigt. Dazu gehören Interferenzen und Rauschen, die unter
anderem auftreten, wenn mehrere Technologien zeitgleich im selben Band funken wie z.B.
WLAN nach IEEE 802.11g und Bluetooth [Lüd07]. So kann es vorkommen, dass Daten
beim Empfänger nicht empfangen werden oder nicht dekodiert werden können. In solchen Fällen muss die Übertragung wiederholt werden. An dieser Stelle setzt die Expected
Transmission Count Metric (ETX) an [DABM05]. Für jede Verbindung zwischen zwei
Stationen wird ermittelt, wie oft ein Datenpaket voraussichtlich versendet werden muss,
17
bis es erfolgreich empfangen werden kann. Dadurch berücksichtigt die Metrik Störungen
auf dem Übertragungskanal. Ein stark gestörter Kanal, der eine hohe Paketverlustrate
aufweist, wird schlechter bewertet als eine Verbindung, deren Verlustrate nahe 0 % liegt.
Konkret bedeutet dies [DABM05]:
ETX =
1
df · dr
(2.1)
Dabei ergeben sich df und dr aus der relativen Häufigkeit, dass ein versandtes Paket
beim Empfänger eintrifft (forward ) bzw. dass der Absender eine Bestätigung über den
Erhalt eines Pakets empfängt (reverse). Die konkreten Werte werden über regelmäßig
ausgesandte Testpakete gemessen. Die Summe der Kosten der einzelnen Verbindungen
entlang eines Pfades ergeben dessen Kosten.
In [DABM05] präsentieren die Entwickler des Verfahrens die Ergebnisse einer experimentellen Evaluation. ETX erzielt dabei einen höheren Durchsatz als die Hop-CountMetrik. Der Hauptgrund ist, dass ETX es ermöglicht, längere Pfade zu nutzen, die im
Gegenzug allerdings stabiler sind und damit einen höheren Durchsatz erreichen können.
Bei Hop Count werden Verbindungen mit einer hohen Reichweite bevorzugt, die aufgrund der hohen Entfernung jedoch häufiger höhere Verlustraten aufweisen als Verbindungen über kürzere Strecken [DABM05]. Der Einfluss dieses Effektes steigt, wenn man
berücksichtigt, dass drahtlose Netzwerke nach IEEE 802.11abg mit unterschiedlichen Datenraten arbeiten können, aber nur bei den geringsten Datenraten die höchsten Reichweiten erzielen [AHR06]. Ein Routingprotokoll, welches ETX nutzt, ist Link-Quality
Source Routing (LQSR) [DPZ04].
2.7.3. ETT
Die Metrik Expected Transmission Time (ETT) erweitert den Ansatz von ETX, indem es
neben der Verlustrate auch die Bandbreite von Verbindungen in die Bewertung einbezieht
[DPZ04]. Angenommen, es existieren zwischen den zwei Knoten A und D zwei Pfade
(siehe Abb. 2.3). Die Verbindungen entlang eines der Pfade funken mit je 54 MBit/s
Bruttodatenrate, der Pfad über den Knoten C nur mit 11 MBit/s. Die Verbindung über
Knoten C ist jedoch stabiler: Jede der beiden Kanten hat ein Gewicht von nur 1,1 (ETXMetrik), während die Verbindungen über Knoten B den Wert 1,2 haben, also geringfügig
unzuverlässiger sind. In einem solchen Fall würde ETX stets den Pfad über Knoten C
bevorzugen, auch wenn der Pfad über Knoten B einen höheren Durchsatz verspricht.
ETT bezieht die Bandbreite einer Verbindung ein, und das Gewicht einer Kante berechnet sich wie folgt:
S
ETT = ETX
(2.2)
B
S ist die Paketgröße, B repräsentiert die Bandbreite der Verbindung. Die Bandbreite
ist entweder konstant, d.h. fest eingestellt wie bei den Experimenten in [DABM05] oder
sie muss anderweitig ermittelt werden. Die Information über die aktuelle Bandbreite
18
B
1,2
1,2
A
D
1,1
1,1
C
54 MBit/s
11 MBit/s
Abbildung 2.3.: Vier Verbindungen unterschiedlicher Datenrate werden mit ETX gewichtet (Kantenbeschriftung).
liegt zwar im Netzwerkadapter vor, über die Treiber der Hardware ist sie jedoch nicht
immer zugänglich. Draves et al. schlagen eine Methode vor um die Bandbreite zu messen [DPZ04]. Zwei Pakete, ein kleines und ein großes, werden unmittelbar nacheinander
versendet. Der Empfänger misst die Zeit zwischen dem Empfang des ersten und des zweiten Paketes und informiert den Sender, der aus mehreren dieser Messungen die Bandbreite der Verbindung berechnet. ETT wurde laut Campista et al. für OLSR und AODV-ST
(Ad hoc On-demand Distance Vector Spanning Tree) implementiert [CEM+ 08].
2.7.4. WCETT
Zwei weitere Effekte, die sog. Intra-Flow-Interferenz und die Inter-Flow-Interferenz, welche spezifisch für Funknetzwerke sind, werden von den bisher besprochenen Metriken
nur unzureichend oder gar nicht berücksichtigt [YWK05]. Beiden Effekten liegt die Eigenschaft zugrunde, dass ein Funkkanal ein geteiltes Medium ist. Zu jedem beliebigen
Zeitpunkt kann immer nur ein Sender aktiv sein und das Medium belegen. Die IntraFlow-Interferenz bezeichnet dabei die Störungen, die Stationen (Knoten) entlang eines
Pfades untereinander verursachen. Die Inter-Flow-Interferenz (Abb. 2.4) tritt zwischen
Stationen unterschiedlicher Pfade auf. Beide Effekte vermindern den erzielbaren Durchsatz.
Verfügen die Knoten über mehrere Funkadapter, die es ihnen ermöglichen auf unterschiedlichen Kanälen oder in unterschiedlichen Bändern zu funken, kann die negative
Wirkung beider Effekte verringert werden. Die Weighted Cumulative ETT (WCETT),
vorgeschlagen von Draves et al. [DPZ04], bewertet solche Routen besser, die Intra-FlowInterferenz durch die Nutzung unterschiedlicher Kanäle auf einzelnen Teilstrecken entlang eines Pfades vermeiden. Dies stellt einen Unterschied zu den bisher beschriebenen
Metriken dar: ETX bzw. ETT registrieren, wenn die Verlustrate durch eine der beiden
19
B
A
D
C
F
E
G
Abbildung 2.4.: Inter-Flow-Interferenz: Laufen parallel Übertragungen zwischen A-C-D
und E-F-G, stören sich die Signale der Knoten C und F. Die Route AB-D wäre die bessere Wahl für den ersten Datenfluss. Grafik angelehnt
an [YWK05].
Interferenzen steigt. Sie bevorzugen jedoch keine Pfade, die eine erhöhte Verlustrate
durch geeignete Kanalwahl vermeiden.
Einzelne Kanten können nicht sinnvoll durch WCETT gewichtet werden. Es muss immer
der gesamte Pfad bewertet werden, wozu die folgende Formel dient [DPZ04]:
WCETT = (1 − β) ·
n
X
i=1
ETTi + β · max Xj
1≤j≤k
(2.3)
Die Variable i bezeichnet die Nummer der Kante eines gegebenen Pfades bestehend aus
n Kanten, auf dem k unterschiedliche Kanäle genutzt werden. Xj ist die Summe der
zu erwartenden Übertragungsdauer ETT entlang derjenigen Kanten, die auf Kanal j
funken. Der Faktor β gewichtet die beiden Summanden gegeneinander. Die WCETTMetrik wurde für das Protokoll MR-LQSR10 umgesetzt und Experimente mit Knoten,
die durchgängig über zwei Funkadapter (nach 802.11g und 802.11a) verfügten, ergaben eine Steigerung des durchschnittlichen Durchsatzes von über 80 % gegenüber ETX
und über 250 % gegenüber Hop Count [DPZ04]. Während der Messungen war immer
nur eine Übertragung aktiv. Inter-Flow-Interferenz konnte nicht auftreten. Die Metrik
berücksichtigt sie auch nicht.
2.7.5. MIC
Yang et al. stellen die Metric of Interference and Channel-switching (MIC) vor, die
die Kanalqualität, Bandbreite, Intra- und Inter-Flow-Interferenz von Verbindungen und
10
Multi-Radio Link-Quality Source Routing
20
Netzen berücksichtigt [YWK05]. Für Pfade berechnet sie sich nach der Formel:
MIC(p) =
X
1
IRUl +
N · min (ETT)
link l∈p
X
CSCi
(2.4)
node i∈p
Die beiden Summanden berücksichtigen die unterschiedlichen Eigenschaften von Verbindungen in vermaschten Funknetzen. IRUl entspricht hierbei der zu erwartenden Übertragungsdauer entlang einer Verbindung l multipliziert mit der Zahl benachbarter Knoten,
die durch Übertragungen auf l beeinträchtigt werden. Die Summe aller dieser Werte
wird anschließend anhand der Gesamtzahl N der Knoten im Netz und der langsamsten
Einzelverbindung normalisiert. Das Verfahren konzentriert sich dabei ganz auf statische
Netze, denn die Mengen der sich jeweils störenden Stationen sollen
P zum Zeitpunkt der
Einrichtung des Netzes bestimmt werden11 . Der zweite Summand node i∈p CSCi quantifiziert die Intra-Flow-Interferenz entlang des Pfades p, wird jedoch in [JLZZ07] als
unzureichend kritisiert.
Symmetrie
Kapazität
Intra-Flow-I.
Inter-Flow-I.
Metrik
Hop Count
ETX
ETT
WCETT
MIC
Verlustrate
Die Autoren von MIC argumentieren, dass die Metrik anders als WCETT auch dann
nicht zu Routing-Schleifen führen kann, wenn auf Source Routing verzichtet wird. Sie
implementieren ein eigenes Routing-Protokoll (LIBRA) und präsentieren die Ergebnisse
von Simulationen wonach IRU / LIBRA leistungsfähiger sind als ETT / WCETT.
◦
X
X
X
X
◦
X
X
X
X
◦
◦
X
X
X
◦
◦
◦
X
X
◦
◦
◦
◦
X
Tabelle 2.4.: Vergleich der Verbindungs- und Pfadeigenschaften, die von den vorgestellten
Metriken berücksichtigt werden.
2.8. Netzwerktechnologien
In diesem Abschnitt werden die für diese Arbeit wichtigsten Aspekte ausgewählter Netzwerktechnologien vorgestellt. Auf weiterführende Literatur wird in den Unterabschnitten
verwiesen.
11
Since mesh networks are static, existing research results have shown that it is possible to measure
”
whether two nodes are in each other’s interference range at the time when the network is established.“
[YWK05, S. 6]
21
2.8.1. IP
Das Internet Protocol (IP) ist ein sehr weit verbreitetes Protokoll zur Verbindung von
paketorientierten Netzwerken. Es lässt sich in Schicht 3 (Netzwerkschicht) des OSIReferenzmodells einordnen [Tan03, Kapitel 1.4]. Die für diese Arbeit relevantesten Punkte werden ausgewählt und kurz erläutert. Weitere Details können [Com00] entnommen
werden.
Das Internet Protocol verwendet Adressen, die einzelne Computer bzw. die einzelnen
Netzwerkverbindungen eines Computers (Host) identifizieren. Bei IP Version 4 (IPv4)
sind diese Adressen 32 Bit lang und werden entweder bitweise als Binärzahlen oder
byteweise in Gruppen von vier Dezimalzahlen notiert. Ein Beispiel ist 192.168.2.33.
Eine IP-Adresse ist unterteilt in einen Internetanteil, einen Teil, der das Netzwerk
bestimmt, und einen Hostanteil. Sogenannte Subnetze erlauben es Adressbereiche zu
unterteilen. Jedes Netzwerk erhält dazu eine Subnetzmaske. Sie hat mit 32 Bit dieselbe Länge wie IP-Adressen. Die gesetzten Bits einer Subnetzmaske bestimmen welche
Bits der IP-Adresse deren Netzwerkanteil ausmachen. Subnetzmasken werden wie IPAdressen notiert, z.B. 255.255.255.0. Zwei Computer im selben physischen Netzwerk,
die unterschiedliche IP-Adressen haben, können auf Ebene von IP direkt miteinander
kommunizieren, wenn der Netzwerkanteil ihrer Adressen identisch ist. Ein Beispiel verdeutlicht dies. Sei die Subnetzmaske aller drei Rechner A, B und C 255.255.255.224.
Ihre Adressen sind 192.168.5.20, 192.168.5.30 und 192.168.5.40. Wegen ihrer Adressen
und der gegebenen Netzmaske können die Rechner A und B direkt miteinander kommunizieren. Der Netzwerkanteil der Adresse von Rechner C unterscheidet sich von dem
der beiden anderen. Er kann ohne Router nicht mit den beiden anderen Rechnern kommunizieren. Adressen und Netzwerkmasken werden häufig gemeinsam dargestellt, z.B.
192.168.5.30/255.255.255.224 [FLYV93]. Eine verkürzende Darstellung (CIDR Notation) derselben Adresse ist 192.168.5.30/27, wobei die 27 ersten Bits der Adresse ihren
Netzwerkanteil ausmachen.
Neben der Adressierung einzelner Hosts erlaubt IP die Adressierung mehrerer Rechner
mit einer einzigen Adresse. Im weiteren Verlauf sind zwei Arten von Broadcasts relevant.
Gerichtete Broadcastadressen12 erlauben es, alle Rechner in einem bestimmten Netzwerk
anzusprechen. Diese Adressen sind ebenfalls aus Netzwerkanteil und Hostanteil aufgebaut. Alle Bits im Hostanteil der Broadcastadresse sind gesetzt z.B. 192.168.5.31/27.
Pakete an die spezielle Adresse 255.255.255.255/32 werden grundsätzlich nicht geroutet
und sprechen alle Computer im lokalen Netzwerk an. Die Adresse wird als eingeschränkte
Broadcastadresse13 bezeichnet. IP-Broadcastadressen werden soweit wie möglich auf die
Broadcastadressen der konkreten darunterliegenden Technologie (z.B. Ethernet) abgebildet.
12
directed broadcast address“ [Com00, S. 65 f.]
limited broadcast address“ [Com00, S. 66 f.]
”
13 ”
22
2.8.2. UDP
Das User Datagram Protocol (UDP) ist ein auf IP basierendes Protokoll zur Übertragung von Nachrichten zwischen unterschiedlichen Prozessen (auf unterschiedlichen
Rechnern). Diese Nachrichten werden Datagramme genannt und haben eine definierte
Länge. UDP sichert die Datenübertragung nicht gegen Verlust ab. Die Integrität der
Nachrichten wird optional mit Prüfsummen sichergestellt. Datagramme lassen sich an die
IP-Adressen von einzelnen Computern senden und daneben auch an die oben genannten
Broadcastadressen. Weitere Informationen zu UDP können [Com00, Kapitel 12] und
besonders mit Blick auf Broadcasting auch [SFR04, Kapitel 20] entnommen werden.
2.8.3. Wireless LAN
Ein Wireless Local Area Network (WLAN) ist ein lokales Funknetz, das innerhalb eines Radius von einigen hundert Metern Geräte miteinander verbindet [Lüd07]. Besonders verbreitet sind WLANs, nach den Standards der Gruppe 802.11 des Konsortiums IEEE14 . Momentan zählen die Standards 802.11, 802.11b, 802.11g, 802.11a und
das kürzlich verabschiedete 802.11n zu den wichtigsten der Gruppe. Sie werden hier
verkürzend als 802.11abgn wiedergegeben. Die Standards spezifizieren die physischen und
logischen Parameter der Funkschnittstelle wie das Frequenzband, die Datenrate und das
Modulationsverfahren. Die Verfahren nach 802.11bg arbeiten im 2,4-GHz-ISM-Band15 .
Das Frequenzband darf lizenzfrei für zivile Anwendungen genutzt werden, wobei die maximale Sendeleistung begrenzt ist. In demselben Frequenzband arbeiten auch Bluetooth
und ZigBee [Lüd07]. WLAN nach 802.11bg, Bluetooth und ZigBee beeinträchtigen sich
wechselseitig. Mikrowellenherde strahlen im oberen Bereich des 2,4-GHz-Bandes Signale
ab und sind eine weitere Störquelle beim Betrieb von 802.11bg WLANs.
Das von WLANs genutzte Frequenzband wurde in unterschiedliche Kanäle unterteilt. Die
Wahl unterschiedlicher Kanäle ist ein Mittel um mehrere Funkzellen parallel und vonein”
ander unabhängig innerhalb eines Empfangsbereichs betreiben zu können, [...]“ [Rec06,
S. 102]. Nicht alle Kanäle sind überlappungsfrei. Bei Übertragungen auf zwei unterschiedlichen Kanälen kann es zu Interferenzen kommen. In der Praxis wurde beobachtet, dass
sich bei parallelem Betrieb sogar Geräte beeinträchtigen können, die in unterschiedlichen
Frequenzbändern (2,4 GHz und 5 GHz) arbeiten [DPZ04, S. 120].
WLANs nach 802.11 können in unterschiedlichen Betriebsmodi verwendet werden. Einer
davon ist der sogenannte Ad-Hoc-Modus, der andere der Infrastrukturmodus. Der AdHoc-Modus ist der simpelste Betriebsmodus. Die Funkzellen, die von den Geräten aufgespannt werden, werden IBSS (Independent Basic Service Set) genannt. Zwei oder mehr
Geräte mit Funkadapter können in einem Ad-Hoc-Netzwerk Daten austauschen, wenn
sich ihre IBSS gegenseitig räumlich überlappen und sie einen gemeinsamen Adressraum
14
15
Institute of Electrical and Electronics Engineers, http://www.ieee.org/
Industrial, Scientific, Medical
23
haben. Die Adresse des gemeinsamen Netzwerks wird als SSID (Service Set Identifier)
bezeichnet. Es handelt sich dabei um eine kurze Zeichenkette.
In einem Infrastrukturnetzwerk existieren neben den Geräten, die das Netzwerk nutzen
möchten ein oder mehrere Access Points (APs). Sie stellen eine Verbindung zwischen
dem drahtlosen und einem drahtgebundenen Netzwerk wie z.B. Ethernet her. Um Daten
auszutauschen werden diese Daten grundsätzlich erst an einen AP gesendet, der die
Daten an den Empfänger oder, wenn dieser nicht erreichbar ist, an einen anderen AP
weiterleitet. Um an dem Infrastrukturnetzwerk teilzunehmen, muss sich ein Gerät mit
einem AP assoziieren und sich gegebenenfalls authentifizieren.
WLAN-Geräten stehen für die Datenübertragung unterschiedliche Datenraten zur Verfügung. Bei 802.11 sind dies 1 und 2 MBit/s, bei 802.11b zusätzlich 5,5 und 11 MBit/s und
bei 802.11g mehrere Stufen zwischen 6 und 54 MBit/s. Im normalen Betrieb wird stets die
höchstmögliche Rate verwendet. Lässt die Übertragungssituation das nicht zu, wird die
Rate automatisch gesenkt. Üblicherweise werden Broadcasts mit anderen Datenraten
versendet als Unicasts. Die genauen Verfahren zur Auswahl der Datenrate sind nicht
spezifiziert. Eine genauere Erklärung kann [Rec06, S. 242 f.] entnommen werden. Bei
einigen Systemen kann die Datenrate fest gewählt werden. Davon wird bei den später
beschriebenen Versuchen Gebrauch gemacht.
2.8.4. Bluetooth
Bluetooth wurde mit dem Ziel entwickelt, eine kostengünstige und energiesparende Technologie für die Verbindung von Computern, Computerperipherie und mobilen Geräten
über kurze Strecken zu schaffen [Mul01]. Die erste Spezifikation wurde von der Bluetooth
SIG16 1999 vorgelegt. 2009 wurden die Versionen 3.0 und 4.0 veröffentlicht [Blu09a,
Blu09b].
Bluetooth arbeitet wie WLAN (nach 802.11bg, siehe oben) im Frequenzbereich von
2,4 GHz. Je nach Version des Standards und dem genutzten Übertragungsmodus können
Netto-Datenraten zwischen 0,4 MBit/s und 2,2 MBit/s (Bluetooth 2.0 + EDR) erreicht
werden [Lüd07].
Möchten mehrere Bluetooth-Geräte Daten austauschen, bilden sie ein sogenanntes Piconetz, das bis zu 8 aktive Geräte umfassen kann. Eines der Geräte im Piconetz übernimmt
die Rolle des Masters, alle anderen sind Slaves. Der Verbindungsaufbau für die Teilnahme
am Piconetz läuft in mehreren Stufen ab [Lüd07, S. 242 ff.]. Einer davon ist der Inquiry
Scan. Bluetooth-Geräte müssen in einem speziellen, sichtbaren Modus sein, damit sie von
anderen Bluetooth-Geräten im Rahmen eines Inquiry Scans gefunden werden können. Inquiry Scans sind zeitaufwändig. Wird ein Inquiry Scan nicht vorzeitig abgebrochen, kann
ein einzelner Scan in einem fehlerfreien Umfeld 10,24 s dauern [Blu07, Abschnitt 8.4.2].
Der Bluetooth-Protokollstapel ist aus vier Schichten aufgebaut [Mul01]. Eines der Protokolle ist OBEX (Object Exchange Protocol). Es kann genutzt werden um beliebige
16
http://www.bluetooth.com/
24
Objekte zwischen Geräten auszutauschen, wie zum Beispiel elektronische Visitenkarten
oder Klingeltöne. In seinem Funktionsumfang ähnelt es HTTP. Das GOEP (Generic Object Exchange Protocol) ist die Grundlage um OBEX über Bluetooth nutzen zu können.
Es spezifiziert die Anforderungen an die unteren Protokollschichten [Mul01].
GOEP / OBEX arbeitet nach dem Client-Server-Modell. Zwischen Client und Server
wird eine Sitzung eingerichtet. Anschließend kann der Client mittels der Operationen
Push oder Pull Objekte zum bzw. vom Server übertragen.
25
3. Konzept
3. Konzept
In diesem Kapitel werden zunächst einige motivierende Anwendungsszenarien für PPS
genannt. Sie veranschaulichen die breiten Einsatzmöglichkeiten des Konzepts. Aus einem speziellen Anwendungsbereich stammt das in Abschnitt 3.2 beschriebene Szenario.
Es bildet den Ausgangspunkt der weiteren Untersuchungen. Im weiteren Verlauf dieses Kapitels wird das Szenario auf das Konzept von ASP abgebildet. Dieser Schritt ist
erforderlich, um das Szenario auf Grundlage von ASP implementieren zu können.
Den Abschluss des Kapitels bildet die Diskussion der Metrik für ASP. Die in Abschnitt
2.7 vorgestellten Metriken werden auf ihre Eignung überprüft. Eine der Metriken wird
so ergänzt, dass sie in einer Implementierung von ASP zum Einsatz kommen kann.
3.1. Anwendungsszenarien für PPS
Die Möglichkeit der Kooperation der unterschiedlichsten Geräte einer intelligenten Umgebung eröffnet eine ganze Reihe neuer Anwendungsfälle. Vier Szenarien sollen zunächst
den Bedarf und die breiten Einsatzmöglichkeiten von PPS unterstreichen.
Bereits in [Ris08] wurde eine Anwendung für eine Büroumgebung vorgestellt. Eine Person hat auf ihrem tragbaren Gerät (z.B. ein Smartphone) Dokumente gespeichert, die
gedruckt werden sollen. An einen Desktop-PC im Büro ist ein Drucker angeschlossen.
Dieser PC kann das Format, in welchem die Dokumente auf dem tragbaren Gerät gespeichert sind, nicht interpretieren. Auf der anderen Seite kennt das Mobilgerät weder
den Drucker noch hat es einen passenden Treiber. Mit PPS können weitere Prozesse
oder Geräte aus der intelligenten Umgebung in den Kommunikationsvorgang integriert
werden, die die Daten konvertieren und auf diese Weise das Ausdrucken ermöglichen.
Ein ähnliches Szenario ist das eines Beamers, der Urlaubsbilder wiedergeben soll, die
auf einem Handy gespeichert sind. Auf Grundlage von PPS könnten die Bilder an das
Gerät, welches mit dem Beamer verbunden ist, übertragen werden und mit Musik aus
einer weiteren Quelle zu einer Diashow verbunden werden.
Weitere Einsatzgebiete gibt es an öffentlichen Orten. Auf einem Bahnhof oder Flughafen
ließen sich die Nachrichtenmeldungen, die prominent über große Monitore angezeigt werden, in Echtzeit übersetzen – entsprechende Übersetzungstechnologie vorausgesetzt. So
könnte ein Geschäftsreisender aus Japan, der kein Russisch spricht, auf dem Moskauer
Flughafen die Nachrichten verfolgen, die ihm von einem leistungsfähigen Rechner in der
26
3. Konzept
intelligenten Umgebung übersetzt werden und dann über das Headset seines Smartphones wiedergegeben werden.
Und auch in der Heimautomatisierung gibt es interessante Anwendungen. Kommunizieren sie per PPS, können der intelligente Stromzähler und schaltbare Steckdosen oder
netzwerkfähige weiße Ware wie Waschmaschine oder Geschirrspüler zusammenarbeiten,
um den idealen Zeitpunkt für die Inbetriebnahme zu finden. Bei einem viertelstündlich
neu festgesetzten Strompreis werden die Geräte dann aktiv, wenn der Strompreis mehrmals in Folge gesunken ist.
Szenario
1
Gerät / Inhalt
Handheld
Desktop-PC mit Drucker
weitere Geräte
Handy
PC mit Beamer
Musikquelle
weitere Geräte
Nachrichtensendung
leistungsfähige Rechner
Smartphone
intelligenter Stromzähler
Steuerrechner
schaltbare Steckdosen
2
3
4
Quelle
•
Rolle
Prozessor
Senke
•
•
•
•
•
•
•
•
•
•
•
•
Tabelle 3.1.: Übersicht der Beispielszenarien mit Rollenverteilung.
3.2. Szenario
Die Ziele und Anforderungen, denen ASP gerecht werden möchte, werden im folgenden
Abschnitt zunächst zusammengefasst. Anschließend wird das Szenario, welches den Hintergrund für die weiteren Untersuchungen und die durchgeführten Experimente bildet,
genau erläutert. Die Hypothesen (siehe Abschnitt 1.2 und 6 und folgende) dienen bei
der Konzeption der Experimente als Richtschnur.
3.2.1. Ziele von ASP
PPS und damit ASP möchte die von Publish-Subscribe-Systemen bekannten Vorteile der
räumlichen und zeitlichen Entkopplung mit denen einer semantischen Entkopplung durch Prozessoren kombinieren. Die Systemarchitektur von ASP und dessen Routingalgorithmus bildet die Grundlage einer flexiblen Kommunikationsinfrastruktur. Sie
27
3. Konzept
basiert ausschließlich auf Kenntnis der Nachbarschaftsbeziehungen einzelner Knoten
in dynamischen, heterogenen Netzwerken.
3.2.2. Überblick
Ein Konferenzraum, Hörsaal oder Büro bilden den Ausgangspunkt des untersuchten
Szenarios. Es finden dort regelmäßig Besprechungen oder Vorlesungen statt. Die Teilnehmer dieser Veranstaltungen sind häufig noch lange über die Dauer der Veranstaltung
hinaus an dem Gesagten interessiert. Dies trifft insbesondere für Interessenten zu, die
an der Veranstaltung nicht persönlich teilnehmen konnten. Aus diesen Gründen ist es
wünschenswert, dass die Veranstaltung aufgezeichnet wird. Es Bedarf dazu einer Infrastruktur, die den spontanen Mitschnitt einer Veranstaltung ermöglicht. Nach dem Ende
der Veranstaltung müssen die Teilnehmer und weitere Interessenten einen möglichst
komfortablen Zugriff auf die Aufzeichnung haben.
Konkret könnte es den folgenden Ablauf geben. Ein Dozent und zwei Dutzend Studenten oder Gäste nehmen an einem Seminar teil. Zu Beginn der Veranstaltung startet der
Dozent auf seinem Smartphone oder einem Netbook mit Mikrofon die Aufnahme. Zwei
Studenten halten nun ihre Vorträge mit anschließender Diskussion. Ein an das Netzwerk
des Hörsaals angeschlossener Computer empfängt und archiviert die Aufzeichnung automatisch in bester Qualität. Kurz vor Ende der Veranstaltung beendet der Dozent die
Aufzeichnung. Einige der Studenten benutzen ihre Handys um auf die einzelnen Vorträge
zuzugreifen. Für den zügigen Download wählen sie die in einem komprimierten Format
angebotenen Mitschnitte. Eine Woche später sind andere Studenten in dem Hörsaal. Aus
Interesse greifen jedoch auch einige von ihnen auf die Aufzeichnung der Vorwoche zu und
laden sie auf ihr Mobilgerät herunter.
ASP bietet sich als Technologie an, um ein Szenario wie das genannte zu realisieren. Mit
einem heterogenen Umfeld, großem zeitlichen Versatz und transparenter Datenverarbeitung finden sich im Szenario einige der Kernpunkte von PPS / ASP. Das Szenario wird
im Folgenden abstrahiert und genauer beschrieben. Abbildung 3.1 stellt es bereits dar.
Im Szenario findet sich ein Netzwerk aus Rechnern, die vier unterschiedliche Rollen
annehmen. Die erste Rolle nimmt das für die Aufzeichnung gewählte Gerät ein. Es digitalisiert Sprache und gibt das Ergebnis weiter (recorder, Kürzel R in Abb. 3.1). Es handelt sich dabei um einen Rechner, der inklusive Mikrofon fester Bestandteil des Raumes
ist oder um ein Mobilgerät, welches nicht ständig vor Ort ist. Ein weiterer Computer
übernimmt die Speicherung und Archivierung der Aufnahme (storage, S). Es wird im
folgenden davon ausgegangen, dass der Rechner über einen ausreichend großen nichtflüchtigen Speicher verfügt und über große Zeiträume verfügbar ist. Die Skizze nennt
ein NAS-System (Network Attached Storage) als Beispiel. Da solche und vergleichbare Geräte nicht in jedem Fall über sehr große Rechenkapazitäten verfügen, wird die
Umwandlung in ein komprimiertes Format (converter, C) auf einem dritten Rechner
vorgenommen. Es kann sich dabei grundsätzlich um einen beliebigen, ausreichend leistungsfähigen Rechner handeln. Dort, wo gerade Kapazitäten frei sind, wird die Aufgabe
28
3. Konzept
WLAN-Router oder -AP mit USB
oder NAS-System
S
C
Ethernet oder WLAN
Bluetooth oder WLAN
PC oder Server
WLAN oder Bluetooth
Smartphone,
PDA, portabler
Medienspieler
D
R
Notebooks, Smartphones,
portable Medienspieler
WLAN Bluetooth
Abbildung 3.1.: Skizze des Szenarios mit den Rollen Aufzeichnung (R), Speicherung und
Weitergabe (S), Umwandlung (C) und Download (D).
ausgeführt. Die vierte Rolle, den Download eines Mitschnitts (download, D), übernehmen
ein oder mehrere Geräte. Sie sind wie ihre Benutzer nur gelegentlich vor Ort. Darüber
hinaus wird davon ausgegangen, dass sie keine ständige Verbindung zum Netzwerk des
Veranstaltungsraumes haben, die möglicherweise langsam ist. Handelt es sich um mehrere Geräte, können diese untereinander vernetzt sein.
Das gegebene Szenario ist beispielhaft für eine Anwendung in einer heterogenen, dynamischen Umgebung. Es eignet sich für die Untersuchung und die Bewertung eines Ansatzes
wie ASP. Um dies zu belegen, wird auf die in Abschnitt 3.2.1 zusammengefassten Ziele verwiesen. Da die Rollen Aufzeichnung und Download (R und D) von wechselnden
Geräten wahrgenommen werden, ist das Szenario geeignet, die räumliche und zeitliche
Entkopplung zu testen. Die transparente Umwandlung der Aufzeichnungen und die Aufbereitung für den Download erfordert eine semantische Entkopplung, wie sie in PPS /
29
3. Konzept
ASP vorgesehen ist. Neben einer Umwandlung sind weitere Anwendungen wie eine automatische Transkription oder das automatische Schneiden der Aufzeichnung denkbar. Ein
weiterer Aspekt, der das Szenario auszeichnet, die Grenzen und Möglichkeiten von ASP
zu evaluieren, ist die Heterogenität des Umfelds. Es kommen Geräte unterschiedlicher
Leistungsklassen zum Einsatz. Diese sind über unterschiedliche Techniken miteinander
vernetzt. Die Skizze nennt Bluetooth, WLAN und Ethernet.
3.2.3. Variationsmöglichkeiten
Die grundsätzliche Eignung des Szenarios zur Evaluierung von ASP wurde bereits gezeigt. Bei genauer Betrachtung ergeben sich Möglichkeiten das Szenario in einigen Aspekten zu variieren. Dazu zählen insbesondere:
• die Art der Netzwerkverbindung
• die Hardwareplattform
• die Art des Netzwerkverkehrs
Unterschiedliche Varianten eignen sich um gewisse Eigenschaften von ASP gezielt zu untersuchen. Damit bilden sie die Ausgangspunkte der Experimente, mit denen im weiteren
Verlauf gearbeitet wird. Die Grafik 3.2 und die folgenden Tabellen fassen die Vielfalt des
Szenarios zusammen.
S
2
C
3
1
D
4
R
D
4
D
Abbildung 3.2.: Vereinfachte Skizze des Szenarios mit Aufzeichnung (R), Speicherung und
Weitergabe (S), Umwandlung (C) und Download (D). Die Ziffern bezeichnen die Verbindungen. Siehe Tabelle 3.2 und 3.3.
Tabelle 3.2 zeigt exemplarisch, welche Techniken sich für den Einsatz auf unterschiedlichen Verbindungen eignen. Die Nummern beziehen sich auf die Abbildung 3.2. Die
Übersicht erhebt keinen Anspruch auf Vollständigkeit.
Unterschiedliche Geräte können die vorgestellten Rollen übernehmen. Neben PCs (einschließlich Notebooks und Netbooks), kommen im Szenario Smartphones und eingebettete Systeme wie NAS-Systeme vor. Tabelle 3.3 führt einige Konstellationen auf.
30
1
2
3
1
3
4
Bluetooth
802.11abgn (Ad-Hoc)
2
802.11abgn (Infrastr.)
Verbindungstechnik
Verbindung
Ethernet
3. Konzept
3
4
Tabelle 3.2.: Unterschiedliche Varianten der Vernetzung. Siehe Abb. 3.2.
Plattform
Rolle
Embedded
Smartphone
R
S
D
PC
R
S
C
D
Tabelle 3.3.: Unterschiedliche Rollen können auf unterschiedlichen Plattformen ausgeführt
werden. Siehe Abb. 3.2.
Bei der Aufzeichnung und dem anschließenden Download von Tonmitschnitten gibt es
zwei charakteristische Arten von Datenverkehr. Während der Aufzeichnung fallen in
regelmäßigen, kurzen Intervallen relativ kleine Datenmengen an. Bei einer unkomprimierten Aufzeichnung in Telefonqualität wären dies z.B. 8 Bit/s · 8000 = 64 kBit/s. Auf
der anderen Seite ergibt sich für einen Download eines einstündigen Vortrages in derselben Qualität in einem komprimierten Format mit einer angenommenen Kompressionsrate von 1:10 ein Datenvolumen von rund 22 MByte. Diese Datenmenge muss möglichst
zügig auf einmal übertragen werden.
Zusammenfassend wird festgehalten, dass je nach Hard- und Softwareplattform, Kommunikationstechnik und Art der Datenübertragung gänzlich unterschiedliche Bedingungen
vorliegen. Damit stellt das Szenario eine realistische und vielseitige Ausgangsbasis für
die Untersuchung von ASP dar.
3.3. Abbildung auf ASP
Für die Untersuchung von ASP wird das Szenario auf dessen Konzepte abgebildet. Im
folgenden werden die von ASP genutzten Anwendungstypen und Übertragungskategorien
31
3. Konzept
zugeordnet. Die Umsetzung auf unterschiedliche Plattformen und Netzwerktechnologien
ist ein weiterer entscheidender Punkt.
Andere, spezifischere Parameter von ASP wie z.B. die Gültigkeitsdauer von Ankündigungen haben Einfluss auf die Leistungsfähigkeit und Zuverlässigkeit der auf ASP aufbauenden Anwendungen. Da sie jedoch einen starken Bezug zum konkreten Einsatzumfeld
bis hin zur Implementierung haben, werden sie an geeigneter Stelle wieder aufgegriffen.
3.3.1. Anwendungstypen und Übertragungskategorien
Den in Abschnitt 3.2.2 eingeführten Rollen werden zunächst die in Abschnitt 2.4 besprochenen Anwendungsklassen Quelle, Prozessor oder Senke zugeordnet.
Die erste Rolle, die Digitalisierung von Sprache, ist eine typische Eingabeoperation und
damit charakteristisch für eine Informationsquelle. Die Rolle der Aufzeichnung nimmt
also eine Anwendung vom Typ Quelle wahr. Umgekehrt ist der Download eines Audiomitschnitts mit der späteren Wiedergabe charakteristisch für eine Datensenke.
Die Umwandlung vorhandener Aufzeichnungen in ein geeignetes, komprimiertes Format
ist der Fall einer Anwendung vom Typ Prozessor, denn ein Prozessor verarbeitet die Daten und nimmt eine definierte Konvertierung vor. Dabei stammen die Eingabedaten von
einer Quelle (oder einem weiteren Prozessor) und die Ausgabe erreicht dann (eventuell
über weitere Prozessoren) eine Senke.
Die Rolle, die bislang als Speicherung oder Archivierung (Kürzel S) bezeichnet wurde,
lässt sich nicht unmittelbar auf einen der Typen Quelle, Prozessor oder Senke abbilden.
Um eine einzige Quelle oder Senke kann es sich nicht handeln, denn es werden Daten
sowohl empfangen als auch versendet. Dieses Verhalten trifft jedoch auf Prozessoren zu.
Allerdings kann es sich bei der Rolle S nicht um einen Prozessor handeln. Ein Prozessor
im Sinne von PPS ist insofern zustandslos als dass er (gegenwärtig) verfügbare Daten
soweit möglich in andere Daten verarbeitet. Die Rolle eines Archivs ist es jedoch Daten
über lange Zeiträume verfügbar zu halten. Die Aufgaben der Speicherung und Weitergabe der Audiodaten werden daher jeweils auf eine Senke und eine Quelle abgebildet.
Rolle S wird von zwei Anwendungen auf einem Knoten gemeinsam übernommen.
Die Datenübertragungen lassen sich in die in Abschnitt 2.5.5 genannten Kategorien
einordnen. Dabei müssen drei Übertragungen getrennt betrachtet werden.
1. Von der Aufzeichnung (R) zur Senke des speichernden Knoten (S).
2. Von der Quelle des Speichers (S) zum Konverter (C).
3. Vom Konverter (C) zu den Geräten, auf denen der Download (D) stattfindet.
Bei der Übertragung der Mitschnitte zum Knoten, auf dem sie abgespeichert werden,
handelt es sich um einen Strom kleiner Nachrichten1 (Kategorie 2). Berücksichtigt man,
1
Bei ASP heißen die Nachrichten für den Datentransport Veröffentlichungen (siehe S. 14).
32
3. Konzept
dass der verfügbare Speicher und die Stromversorgung des Geräts, welches die Sprache
unmittelbar aufzeichnet und digitalisiert, stark begrenzt sein können, so ist dieser Modus
der effektivste.
Die Übertragung der Aufzeichnung zum Prozessor und der Download von dort, können
als einzelne große Veröffentlichungen übertragen werden (Kategorie 3). Anzumerken ist,
dass in [Ris09a] der Fokus auf kleinen Einzelübertragungen lag (Kategorie 1).
Analog zu den drei unterschiedlichen Datenübertragungen, müssen mindestens drei unterschiedliche ASP IDs (siehe Abschnitt 2.5.1) pro durchgeführtem Mitschnitt zum Einsatz kommen. Andernfalls können die beteiligten Anwendungen nicht zweifelsfrei zwischen den Veröffentlichungen unterscheiden. Die Wahl der konkreten IDs und des Inhalts
von Ankündigungen ist dabei anwendungsabhängig und für ASP transparent.
3.3.2. Plattformen und Netzwerktechnologien
Das vorliegende Szenario umfasst eine Reihe unterschiedlicher Hard- und Softwareplattformen. Weiterhin kommen mit Ethernet, WLAN und Bluetooth drei sehr unterschiedliche Netzwerkverbindungstechnologien zum Einsatz. Diese beiden Aspekte müssen für die
experimentelle Evaluierung von ASP angemessen berücksichtigt und umgesetzt werden.
Die im Szenario vorkommenden Hardwareplattformen unterscheiden sich vor allem
in der verfügbaren Rechen- und Speicherkapazität. Die vorhandene Hardware muss ausreichend Ressourcen bereitstellen, damit die darauf laufende Anwendung ihre Aufgabe
erfüllen kann. Für die Sprachaufzeichnung ist ein Mikrofon erforderlich und die Netzwerkverbindung des Aufzeichnungsgerätes sollte ausreichend sein, um die unkomprimierten
Daten in Echtzeit übertragen zu können.
Für die Speicherung und Archivierung der Aufnahmen wird genügend Speicherplatz auf
einem nicht-flüchtigen Speichermedium benötigt. Wie bereits erwähnt wurde, ist für die
Rolle der Speicherung eine hohe Verfügbarkeit wünschenswert, damit Nutzer jederzeit
auf vergangene Aufzeichnungen zugreifen können. Ein batteriebetriebenes Mobilgerät
kommt somit nicht in Frage.
Die Konvertierung der Aufzeichnungen in ein komprimiertes Format sollte möglichst
schnell ablaufen. Das erfordert eine leistungsfähige Verbindung zwischen dem Aufzeichnungsarchiv und dem Konverter und eine möglichst große Rechenleistung beim Konverter, damit dieser die Aufgabe schnell abschließen kann.
Wie die Hardware muss auch die Softwareumgebung gewisse Anforderungen erfüllen,
damit ASP und die Anwendungen des Szenarios umgesetzt werden können. Die Sprachaufzeichnung erfordert Schnittstellen und Softwarekomponenten um auf den Strom der
Audiodaten zugreifen und ihn verarbeiten zu können. Die Daten müssen zudem in einem Format vorliegen, welches die weiteren Stationen – Speicherung und Konvertierung
– verarbeiten können. Der Konverter benötigt Software, die es ermöglicht, die Audiodaten zu komprimieren. Sie muss auf allen Plattformen verfügbar sein, die für die Rolle
der Audiokonvertierung in Betracht kommen.
33
3. Konzept
Im Bereich der Netzwerkverbindungen, die als NAL (siehe Abschnitt 2.5.4) gekapselt
und dem Broker bereitgestellt werden, gibt es weitere Anforderungen. Der Broker kommuniziert über eine einheitliche Schnittstelle mit dem NAL. Um welche darunterliegende
Technologie es sich im einzelnen handelt, ist dabei aus Sicht des Brokers unerheblich.
Es ist erforderlich, dass die Soft- und Hardwareplattform für die Kommunikation des
Brokers mit benachbarten Brokern transparent ist. Nachrichten sollen ungeachtet der
Plattform des Nachbarn weiterverarbeitet werden können.
Im Szenario ist beschrieben, dass einige Knoten Nachrichten über Technologie A empfangen und mit Technologie B an den Nachbarn weitergeben. Nur so kann die Heterogenität
der Netzwerkverbindungen überbrückt werden. Der Broker muss grundsätzlich in der
Lage sein, bei Bedarf und Verfügbarkeit mehrere unterschiedliche Netzwerktechnologien
parallel nutzen zu können. Es ist Aufgabe der Netzwerkabstraktionsschicht, dem Broker
dies zu ermöglichen.
Zuletzt ist der NAL dafür zuständig, gewisse Dienstmerkmale bereitzustellen. Die kleinste Kommunikationseinheit, die ASP einsetzt, ist die Nachricht. Eine Nachricht hat einen
definierten Typ und eine definierte Länge, die variabel sein kann. Einzelne Nachrichten müssen dem Broker komplett zugestellt werden. Die Fragmentierung auf Ebene von
ASP bleibt davon unberührt. Wird eine Veröffentlichung von einem Broker in mehrere
Nachrichten aufgeteilt, stellt der NAL die einzelnen Nachrichten dem Broker komplett
zu. Dieser fügt sie zu einer Veröffentlichung zusammen. Weiter schützt die Netzwerkabstraktionsschicht die Übertragung zwischen zwei benachbarten Brokern vor Verlust.
Die Reihenfolge von Nachrichten stellt der NAL nicht sicher und die Schicht vermeidet Verdopplung nicht. Dies sind Aufgaben, die bei Bedarf vom Broker oder sogar der
Anwendung übernommen werden können.
3.3.3. Anwendungsschnittstelle
PPS (ASP) ist ein Publish-Subscribe-System. Die zentralen Interaktionsprimitive aus
Anwendungssicht sind also Publish, Subscribe und der Nachrichtenempfang. Um diese
Semantik zu erhalten und nicht zu verfälschen, bildet eine geeignete ASP-Anwendungsschnittstelle zwischen Anwendungen und dem lokalen Broker diese Operationen ab. Daneben sollten nur unbedingt nötige Schnittstellen existieren. Diese Schnittstellen sind
für eine Umsetzung von ASP unerlässlich. Dazu gehört der Umgang mit Ankündigungen, also das Erzeugen und Empfangen. Die Beschränkung auf das Nötigste minimiert
den Aufwand, bestehende Publish-Subscribe-Anwendungen auf ASP zu portieren. In
Abschnitt 2.5.3 wurde die bislang vorgeschlagene Schnittstelle kurz umrissen. Sie wird
für die weiteren Untersuchungen nicht unverändert übernommen. Die folgenden Absätze
beschreiben die verwendete Schnittstelle. Grafik 3.3 fasst das Ergebnis zusammen.
Die Schnittstelle für den Datenaustausch zwischen einer Anwendung und dem Broker
ist abhängig vom Typ der Anwendung. Lediglich die Verwaltung der Anwendungen,
d.h. ihre An- und Abmeldung am Broker, ist bei allen Anwendungstypen gleich. Dabei
teilt die Anwendung dem Broker ihren Typ mit. Anhand des Typs entscheidet dieser,
34
3. Konzept
welche Nachrichten an die Anwendung zugestellt werden. So braucht eine Quelle weder
Ankündigungen, noch Veröffentlichungen empfangen.
Zum Empfang von Ankündigungen und Veröffentlichungen halten Senken und Prozessoren Schnittstellen bereit. Eine weitere Schnittstelle erlaubt es dem Broker die Anwendungen zu informieren, wenn Veröffentlichungen einer bestimmten ASP ID nicht länger
zugestellt werden können, etwa weil sie nicht weiter angekündigt werden. Die ASP ID
wird in Abschnitt 2.5.1 beschrieben.
Eine Quelle kann Veröffentlichungen erzeugen und versenden (Publish) und benötigt
dafür eine Schnittstelle. Für ASP ist es zusätzlich erforderlich, dass die Quelle den Inhalt von Ankündigungen setzen und die weitere Ankündigung von Veröffentlichungen
beenden kann.
Wichtigste Aufgabe einer Senke ist der Empfang von Veröffentlichungen. Damit dies geschehen kann, erhält die Anwendung Ankündigungen. In diesem Zusammenhang wird das
Konzept der Filter, wie es in Abschnitt 2.5.3 beschrieben wird, unverändert übernommen.
Der Broker erhält daher eine Schnittstelle über die die Senke den Filter festlegen kann.
Weiter sind Schnittstellen vorgesehen, um Veröffentlichungen zu abonnieren und Abonnements wieder zu kündigen. Die für das Abonnement nötigen Informationen erhält die
Senke als Teil der Ankündigungen.
Prozessoren empfangen und versenden Veröffentlichungen. Prozessoren legen über eine
separate Schnittstelle, die sich von der von Quellen genutzten Schnittstelle unterscheidet,
den Inhalt von Ankündigungen fest. Auf die gleiche Weise teilen sie dem Broker mit,
welche Veröffentlichungen sie benötigen, um aus ihnen eine neue Veröffentlichung erzeugen zu können. Für die korrekte Berechnung der Metrik ist es nötig, dass Prozessoren
die Dauer der Operation abschätzen und das Ergebnis dem Broker ebenfalls mitteilen.
Die Metrik wird in Abschnitt 3.4 ausführlich diskutiert.
Abbildung 3.3.: Die Schnittstellen zwischen Anwendungen und Broker.
3.3.4. Interaktion
Der vorherige Abschnitt untersucht vor allem die Daten, die zwischen Anwendungen und
Broker ausgetauscht werden, und die Schnittstellen, über die dieser Austausch abgewi-
35
3. Konzept
ckelt wird. Ebenso entscheidend sind die Interaktionen, die zwischen Anwendungen und
Broker und zwischen unterschiedlichen Brokern stattfinden. Wie die Kommunikation von
Brokern untereinander abläuft, wird in den Abschnitten 2.5.1 und 2.5.2 beschrieben. Es
bleiben jedoch weitere Punkte offen. Erst wenn sie geklärt sind, kann ASP erfolgreich
implementiert werden.
Einer dieser Punkte betrifft Prozessoren. Ein Prozessor verarbeitet Veröffentlichungen
(P1 , P2 usw.) anderer Prozessoren oder Quellen in neue Veröffentlichungen wie zum
Beispiel P 0 . Damit die Veröffentlichungen Pi (i ≥ 1) zum Prozessor gelangen, müssen
sie abonniert werden. Bislang wurde keine Festlegung getroffen, wann und auf welche
Weise dies geschehen soll. Es gibt zwei Möglichkeiten. Bei der ersten abonniert die Prozessoranwendung selbstständig jede der benötigten Veröffentlichungen. Dieser Ansatz
widerspricht jedoch dem Kerngedanken von ASP. Abonnieren Prozessoren eigenmächtig
Veröffentlichungen, so stammen diese möglicherweise von weiteren Prozessoren. Diese
anderen Prozessoren abonnieren wiederum Veröffentlichungen usw. Im Ergebnis werden
alle Quellen, deren Veröffentlichungen direkt oder indirekt von einem Prozessor verarbeitet werden, aufgefordert ihre Veröffentlichungen zu übertragen. Das Netzwerk wird
belastet und die Entscheidung der Middleware, welcher der günstigste Pfad ist, ist praktisch irrelevant. Die Alternative zu diesem Verhalten ist, dass der Broker stellvertretend
für eine Prozessoranwendung die Veröffentlichungen abonniert. Dies hat den Vorteil, dass
der Broker jederzeit weiß, ob Abonnements für die Veröffentlichungen P 0 vorliegen. Liegen keine Abonnements vor, müssen auch P1 , P2 usw. nicht abonniert werden. Dies hat
zur Folge, dass das Netzwerk und der Prozessor nicht unnötig belastet werden. Dies gilt
umgekehrt auch, wenn das Interesse an den Veröffentlichungen P 0 versiegt. Dann kündigt
der Broker die Abonnements von P1 usw. Der Prozessor wird nicht länger belastet.
Ein weiterer Komplex betrifft die Erkennung und Reparatur von Pfaden. Sie werden
mit Ankündigungen und Abonnements aufgebaut. Bricht eine der Verbindungen entlang eines Pfades ab, wird eine Störungsmeldung erzeugt. Abschnitt 2.5.2 schildert die
Abläufe genauer. Unklar ist, wie ein Broker angemessen auf eine verlängerte Ankündigung reagieren soll. Da Störungsmeldungen gezielt an den Prozessor oder die Quelle, die
die Ankündigungen erzeugt, weitergeleitet werden, wissen nicht alle Broker entlang des
Pfades, dass er repariert werden muss. Insbesondere dürfen sie sich nicht darauf verlassen, dass die folgende Ankündigung vom selben Nachbarn stammen wird, von dem die
letzte Ankündigung empfangen und mit einem Abonnement quittiert wurde. Damit Pfade repariert werden können, müssen Broker zunächst jede Ankündigung übernehmen,
die aktueller als die vorangegangene ist, ungeachtet der Kosten, die die Metrik liefert.
Dies kann zur unnötigen Änderung von Routen (Pfaden) führen. Insbesondere könnte es
bedeuten, dass eine schlechter Pfad gegenüber einem besseren bevorzugt wird, weil die
Ankündigungen auf dem schlechten Pfad (kurzfristig) schneller zugestellt wurden als auf
dem besseren Pfad. Es gibt unterschiedliche Strategien, um die Stabilität von Pfaden
(im Sinne der Anzahl und Reihenfolge der Zwischenstationen) zu erhöhen. Grundlage
der Ansätze ist die verzögerte Aktivierung von Pfaden. Trifft eine Ankündigung Ax mit
den Kosten c beim Broker b ein, beginnt ein kurzes Zeitintervall. Trifft Ax0 mit derselben Sequenznummer wie Ax aber niedrigeren Kosten c0 < c innerhalb des Intervalls ein,
36
3. Konzept
gilt Ax0 als beste Ankündigung. Erst bei Ablauf des Intervalls wird das Abonnement,
welches nötig ist, um den Pfad zu aktivieren, an den Absender der besten Ankündigung
versendet. Soll der Pfad besonders stabil sein, genügt es, nicht die vermeintlich beste
Ankündigung zu übernehmen, sondern während des gesamten Intervalls auf die Ankunft
derjenigen Ankündigung zu warten, die vom selben Nachbarn stammt wie die vorherige.
Sie ist dann ausschlaggebend für den Versand des Abonnements. Dieses Verfahren wird
im weiteren Verlauf eingesetzt. Eine weitere Maßnahme ist, bessere Ankündigungen nur
dann zu übernehmen, wenn sie signifikant – das heißt z.B. mindestens 10 % – besser sind
als die vorherige. Weitere Ansätze werden hier nicht verfolgt. Für die experimentelle Evaluation ist es vorteilhaft, wenn ASP nicht in besonderem Maße über den bereits in der
Literatur beschriebenen Umfang hinaus weiterentwickelt wird. Jede Optimierung oder
Erweiterung könnte bislang unbekannte Folgen haben. Das würde die Übertragbarkeit
der Erkenntnisse auf das existierende ASP-Konzept einschränken. Komplexe Erweiterungen sollten zunächst in separaten Untersuchungen oder Simulationen betrachtet werden.
Verbunden mit der Stabilisierung von Pfaden ist ein weiterer Effekt. Angenommen, der
Verlauf eines aktiven Pfades ändert sich. Werden zeitgleich Veröffentlichungen entlang
des alten Pfades übertragen, kann dies dazu führen, dass einzelne Veröffentlichungen
verloren gehen. Die Grafik 3.4 illustriert das Phänomen an einem Beispiel. Als Schutz
gegen diese Art von Datenverlust, wird ein Verfahren eingeführt, das hier als Fading
bezeichnet wird. Ändert ein Broker den Verlauf eines aktiven Pfades, indem er ein Folgeabonnement nicht wie bisher an den Nachbarn Na , sondern Nn schickt, so schickt er
ein zusätzliches Abonnement an Na . Auf diese Weise bleibt der alte Pfad länger aktiv.
Veröffentlichungen, die noch auf dem alten Pfad unterwegs sind, können ihr Ziel erreichen. Der alte Pfad wird nicht beliebig lange erhalten. Nach einer festen Wartezeit oder
einer maximalen Anzahl von Folgeabonnements, wird er nicht länger aktiviert.
3.3.5. Caching
Eine wichtige Eigenschaft von Publish-Subscribe-Systemen wie ASP ist die zeitliche Entkopplung. Es sind Maßnahmen nötig, um diese Eigenschaft sicherzustellen. Von großer
Bedeutung ist dabei das Caching. Im Falle von ASP ist vor allem das Caching von Veröffentlichungen wichtig, doch auch das Caching von Ankündigungen bietet Vorteile. Ohne
jede Zwischenspeicherung von Veröffentlichungen, käme in vielen Situationen keine zeitliche Entkopplung von Publisher und Subscriber zustande. Angenommen, ein Publisher
veröffentlicht Daten. Die Subscriber, die ihr Interesse geäußert haben, erhalten die Veröffentlichung. Bei ASP sind das jene Prozessoren oder Senken, die über ihre Broker Pfade für diese Veröffentlichung aktiviert haben. Alle anderen potenziellen Subscriber, die
(vorübergehend) ihr Interesse an der Veröffentlichung nicht mitteilen konnten, erhalten
sie nicht. In einem Umfeld wie dem Szenario aus Abschnitt 3.2 sind Verbindungsabbrüche nicht ausgeschlossen. Sie verhindern unter Umständen, dass Subscriber Pfade
aktivieren, wenn Abonnements verloren gehen oder wegen Sendewiederholungen zu spät
beim Publisher eintreffen.
37
3. Konzept
C
A
E
B
O
D
F
Veröffentlichung
C
A
E
B
O
D
F
Verlust der
Veröffentlichung
Abbildung 3.4.: Durch Routenänderungen kann es zum Verlust von Veröffentlichungen
kommen. Wird ein aktiver Pfad (durchgezogene Linie; von A nach O)
durch einen anderen ersetzt, können Nachrichten, die noch auf dem alten
Pfad unterwegs sind, verloren gehen (unten).
38
3. Konzept
Außerdem kann es vorkommen, dass einzelne Anwendungen oder Geräte erst nach einer
Veröffentlichung aktiviert werden. Im Szenario wäre dies zum Beispiel dann der Fall,
wenn zunächst ein Benutzer einen Mitschnitt P auf sein Gerät herunterlädt. In diesem
Fall hat der Audiokonverter (Prozessor) eine Veröffentlichung erzeugt und verschickt.
Möchte ein weiterer Nutzer später denselben Mitschnitt herunterladen, kann er einen
aktiven Pfad aufbauen, denn Ankündigungen versendet der Prozessor nach wie vor. War
der Pfad zum Zeitpunkt der Veröffentlichung nicht aktiv, weil der Benutzer gar nicht
anwesend war, empfängt er die Veröffentlichung nicht. Der Grund ist, dass in PublishSubscribe-Systemen nicht vorgesehen ist, dass eine Anwendung ihre Veröffentlichung
gezielt erneut versendet. Die Nachrichtenzustellung ist allein Aufgabe der Broker. Für
Publisher und Subscriber ist sie transparent. Ein Broker kann die Veröffentlichung nur
dann zustellen, wenn er über eine Kopie von P verfügt. Daraus folgt, dass die Umsetzung
eines ASP-Systems zwingend Caches für Veröffentlichungen bereithalten muss. Werden
Pfade nach dem Versand einer oder mehrerer Veröffentlichungen aktiv, werden diese
Veröffentlichungen aus dem Cache zugestellt. Im einfachsten Fall, speichert jeder Broker die Veröffentlichungen, die seine lokalen Anwendungen erzeugt haben, zwischen. Im
Rahmen dieser Arbeit ist die Notwendigkeit von Caches entscheidend. Deren Struktur
oder Verteilung, wird nicht weiter untersucht.
Durch den Einsatz von Caches ist es notwendig, dass Broker zweifelsfrei zwischen Duplikaten von Veröffentlichungen, neuen Veröffentlichungen und Veröffentlichungen aus
Caches unterscheiden. Dazu sind Sequenznummern für Veröffentlichungen vorgesehen.
Um das Netzwerk nicht mit überflüssigen Veröffentlichungen aus Caches zu belasten, ist
es hilfreich, wenn ein Broker zwischen aktiven Pfaden derselben ASP ID unterscheiden
kann. Es wird vorgeschlagen, dafür die bereits in [Ris09a] eingeführten Subscriber IDs
zu nutzen. Für den dort ursprünglich genannten Zweck, mehrere Subscriber an einem
Broker zu unterscheiden, sind sie in dieser Form ausdrücklich nicht erforderlich. Die Subscriber ID wird in dem hier konzipierten System also genutzt, um aktive Pfade, die von
unterschiedlichen Brokern ausgehen, unterscheiden zu können.
Betrachtet man neben Veröffentlichungen auch Ankündigungen, ergibt sich ein weiterer
interessanter Anwendungsfall für Caches. Er betrifft die Eingliederung von neuen Knoten (Brokern) in das Netzwerk. Werden Ankündigungen nicht zwischengespeichert, muss
ein neu hinzugekommener Broker warten, bis alle im System existierenden Ankündigungen verlängert wurden. Der Zeitraum ist von der Gültigkeitsdauer der Ankündigungen
abhängig. Cachen Broker jedoch Ankündigungen, können sie einem neuen Nachbarn
sofort alle ihnen bekannten Ankündigungen übergeben. Dadurch wird die Latenz verringert, mit der der neue Broker sein Interesse an den Veröffentlichungen verbreiten kann.
Dem steht als Nachteil gegenüber, dass ein kleiner Teilbereich des Netzwerks kurzzeitig
stärker belastet wird. Lernen mehrere Broker zeitgleich einen neuen Nachbarbroker kennen, werden die Ankündigungen zudem redundant verschickt. Der Vorteil der geringen
Latenz überwiegt die Nachteile nach Meinung des Autors. Das Caching von Ankündigungen kommt deshalb im untersuchten System zum Einsatz.
39
3. Konzept
3.4. Metrik
Eine offene und zugleich wichtige Frage, deren Antwort Einfluss auf die Leistungsfähigkeit von ASP hat, ist: Was ist die geeignete Routingmetrik? In Abschitt 2.7 wurden
existierende Metriken vorgestellt, die in statischen Funknetzen eingesetzt werden oder
dafür konzipiert wurden. Es folgt eine Betrachtung der Faktoren, die in dem konkreten
Szenario (siehe Abschnitt 3.2) die Übertragungsleistung beeinflussen. Eine Metrik muss
diese Faktoren angemessen berücksichtigen. Die zuvor vorgestellten Metriken werden
anhand dieser Faktoren und der Kosten (besonderer Kommunikations- oder Rechenaufwand), die durch ihren Einsatz entstehen, bewertet. Neben dem Datentransport muss
eine Metrik für ASP auch die Kosten der Datenverarbeitung in den Prozessoren einbeziehen. Dieser Aspekt wird in Abschnitt 3.4.2 betrachtet.
3.4.1. Datentransport
Beim Transport von Daten zwischen zwei Knoten in einem Netzwerk sind die Übertragungskapazität und die Verlustrate zwei zentrale Verbindungseigenschaften. Die Übertragungskapazität einer Verbindung zwischen zwei benachbarten Stationen, also die Datenmenge, die in einem bestimmten Zeitintervall maximal übertragen werden kann, begrenzt den Datenfluss nach oben. Je höher die Kapazität, umso schneller können Daten
ausgetauscht werden. Die Verlustrate nimmt Einfluss auf die verfügbare Kapazität und
die Übertragungslatenz einer Verbindung. Angenommen, eine Netzwerktechnologie verwendet einen Mechanismus aus Bestätigungen und Wiederholungen zur Sicherung der
Verbindung vor Nachrichtenverlust, was allgemein als ARQ (Automatic Repeat Request,
siehe [Tan03, S. 200 ff.]) bekannt ist. In diesem Fall führt der Verlust von Datenpaketen
unmittelbar zu einer Erhöhung der Latenz, weil verlorene Daten erneut übertragen werden müssen. Analog sinkt die verfügbare Übertragungskapazität, wenn Übertragungsverluste auftreten. Wegen Sendewiederholungen werden effektiv weniger Nutzdaten pro
Zeiteinheit übertragen.
Wegen ihrer großen Bedeutung, sollte eine Metrik für ASP die Übertragungskapazität
und die Verlustrate vorrangig berücksichtigen. Die Metrik sollte es ermöglichen, zwischen
unterschiedlichen Pfaden denjenigen Pfad zu wählen, der eine hohe Kapazität aufweist
und dessen einzelne Verbindungen möglichst verlustarm sind. Letzteres hilft die Latenz
zu minimieren und die erzielbare Übertragungsrate zu maximieren.
Symmetrie von Verbindungen (nicht Routen oder Pfaden) ist für das Funktionieren
von ASP notwendig. Der Grund ist die Art und Weise wie ASP aktive Pfade etabliert.
Empfängt ein Broker ein Abonnement Sx , das er nicht selbst bedienen kann, leitet er die
Nachricht weiter und sendet sie an denjenigen Nachbarn, von dem er die Ankündigung
Ax mit den minimalen Kosten empfangen hat. Das gilt analog für die Verbreitung von
Veröffentlichungen, denn sie werden an Nachbarn gesendet, von denen Abonnements
empfangen wurden. Die Hop-Count-Metrik erlaubt keine Aussagen über die Symmetrie
von Verbindungen. Sie scheidet daher für den Einsatz in ASP aus.
40
3. Konzept
Neben Bandbreite, Verlustrate und Symmetrie einer Verbindung, hat die Auslastung
Einfluss auf die Leistungsfähigkeit. Keine der in Abschitt 2.7 genannten Metriken berücksichtigt unmittelbar die Auslastung einer Verbindung. Dadurch wird das Oszillieren
von Routen vermieden [DABM05]. Metriken wie ETT, die die Kapazität berücksichtigen, können für Oszillieren anfällig werden, wenn sie die verfügbare Bandbreite und
damit auch die Auslastung ausmessen [DPZ04]. Wird die Verbindungsauslastung nicht
berücksichtigt, kann es bei ASP dazu kommen, dass Verbindungen, die eine gute Bewertung erhalten, in viele aktive Pfade eingebunden werden. Wird eine Verbindung bei
steigender Auslastung nicht abgewertet, steigt das Risiko, dass bei entsprechend starkem
Datenverkehr die betreffende Verbindung überlastet wird.
Die ebenfalls in Abschnitt 2.7 erläuterten Phänomene Intra- und Inter-Flow-Interferenz
können in einem Netzwerk auftreten, sobald mehr als eine Funkverbindung im selben
Frequenzband existiert. Davon ist im Szenario auszugehen (siehe Abschnitt 3.2). Die
Phänomene können in diesem Umfeld bei Einsatz von ASP jedoch nicht durch den
Einsatz der Metriken MIC oder WCETT vermieden werden. Broker besitzen nur ein
sehr beschränktes Wissen über die Topologie des Netzwerkes. Sie kennen lediglich ihre
Nachbarn. Um Inter-Flow-Interferenz vermeiden zu können, sind jedoch sehr detaillierte
Informationen über den Zustand eines größeren Teils des Netzwerks erforderlich. ASP
sieht keinen Mechanismus vor, solche Informationen auszutauschen oder zu erheben. Der
Einsatz eines Protokolls zum Austausch solcher Statusinformationen würde das Netzwerk zusätzlich belasten. Eine Metrik wie MIC ist für den Einsatz in ASP ungeeignet,
da die nötigen Informationen zur Bewertung der Pfade nicht zur Verfügung stehen. Das
heterogene Umfeld für das ASP konzipiert ist, erschwert zusätzlich die Vermeidung von
Intra-Flow-Interferenz. So funkt der WLAN-Standard IEEE 802.11g im 2,4-GHz-Band,
genau wie Bluetooth [Rec06, S. 2 ff.]. Besitzt eine Station je eine Schnittstelle beider
Technologien, sind Interferenzen unvermeidbar. Ähnlich wie MIC benötigt WCETT detailliertes Wissen über die Eigenschaften der Verbindungen entlang eines Pfades. Die
Wechselwirkungen zwischen einzelnen Übertragungstechnologien müssten zudem in geeigneter Weise modelliert werden und in sämtlichen ASP-Stationen vorliegen. Aus den
genannten Gründen eignet sich WCETT nicht für den Einsatz in ASP.
Verglichen mit WCETT und MIC werden zur Berechnung von ETX und ETT wenige
Daten benötigt. Konkret sind dies bei ETX die Verlustrate in Sende- und Empfangsrichtung zwischen zwei benachbarten Stationen. Voraussetzung für die Berechnung von ETT
sind zusätzlich Informationen über die Bandbreite einer Verbindung und die Größe der
zu sendenden Pakete. Verlustrate und Bandbreite betreffen ausdrücklich Paare jeweils
unmittelbarer Nachbarn. Damit sind die Metriken kompatibel zu ASP, welches sich ausdrücklich auf Wissen über Nachbarschaftsbeziehungen beschränkt. ETT wird in [Ris09b]
als Grundlage für eine Metrik gewählt.
41
3. Konzept
3.4.2. Datenverarbeitung
Auf die Geschwindigkeit der Verarbeitung von Veröffentlichungen durch Prozessoren
haben die Anzahl und Größe der Eingabeveröffentlichungen großen Einfluss. Große
Eingabedaten oder eine Vielzahl kleiner Veröffentlichungen können je nach Hardware
nicht im Primärspeicher bearbeitet werden. Unabhängig davon ist der Verarbeitungsaufwand stark anwendungsabhängig. Der ASP-Broker sollte bei der Ermittlung der Verarbeitungsmetrik daher auf Informationen zurückgreifen, die von der Prozessoranwendung stammen. In [Ris09b] wird eine zeitbasierte Verarbeitungsmetrik angeregt. Machen die Prozessoranwendungen Schätzungen über die zu erwartende Verarbeitungszeit,
so werden die beiden zuletzt genannten Punkte kombiniert. Auf welcher Grundlage eine Prozessoranwendung die Schätzung macht, ist von Anwendung zu Anwendung stark
unterschiedlich und muss daher im Einzelfall betrachtet werden. Generell lassen sich
Erfahrungs- oder Messwerte (zum Beispiel Benchmarks) nutzen, um den zu erwartenden Aufwand und die Leistungsfähigkeit des Systems abzuschätzen.
3.4.3. Metrik für ASP
Eine Metrik, die für den Einsatz in ASP geeignet ist, verknüpft die Kosten des Datentransports und der Datenverarbeitung in geeigneter Weise. Als Transportmetrik sind
sowohl ETX als auch ETT geeignet (siehe Abschnitt 3.4.1). ETT ermöglicht es, genauere
Aussagen über die Qualität einer Verbindung zu treffen als ETX. Deshalb soll die Metrik ETT als ein Baustein für eine Metrik für ASP dienen. Da die Kontrollnachrichten
von ASP kompakt sind und Veröffentlichungen einen sehr geringen Datenumfang kleiner
oder gleich 100 Byte haben können, tritt insbesondere bei hohen Bandbreiten ein Problem auf. Rechnerisch beträgt die Übertragungsdauer für 100 Byte bei 100 MBit/s nur
etwa 0,08 ms. Ein vernachlässigbar kleiner Wert verglichen mit Latenzen im Millisekundenbereich. ETT verliert unter diesen Umständen an Aussagekraft. Aus diesem Grund
wird die Latenz einer Verbindung in Form der RTT (round trip time) zusätzlich für die
Berechnung der Verbindungskosten herangezogen.
Als Metrik für die Datenverarbeitung soll die geschätzte Dauer zur Erzeugung einer
Veröffentlichung durch den Prozessor dienen. Wird eine Veröffentlichung P 0 aus den
Veröffentlichungen P1 , P2 bis Pn erzeugt, so beziffert die Prozessoranwendung den Zeitraum tproc , der wahrscheinlich zwischen dem Zeitpunkt, zu dem alle n Eingabeveröffentlichungen vorliegen und dem Zeitpunkt, bis P 0 erzeugt ist, vergehen wird. In Grafik
3.5 wird die Definition illustriert.
Allgemein ergeben sich die Kosten eines kompletten Pfades aus n Kanten aus der Summe
der Kosten aller einzelnen Kanten.
m=
n
X
d(ei )
(3.1)
i=1
42
P3 trifft ein
P’ steht bereit
P4 trifft ein
P2 trifft ein
P1 trifft ein
3. Konzept
t0
t1
Zeit
Abbildung 3.5.: Die Zeit für die Umwandlung von P1 bis P4 nach P 0 ergibt sich als tproc =
t1 − t0 .
Für die Kosten einzelner Kanten (Verbindungen) e ergibt sich:
d(e) =
trtt
+ ETT + tproc
2
(3.2)
Bei von Prozessoren verarbeiteten Veröffentlichungen ist zusätzlich die Summe der Kosten aller Ausgangsveröffentlichungen zu berücksichtigen.
k
d(e) =
X
trtt
+ ETT + tproc +
mj
2
(3.3)
j=1
ETT berechnet sich nach der auf Seite 18 genannten Formel.
Die Metrik, die die Gleichungen 3.1 und 3.3 definieren, unterscheidet sich von der in
[Ris09b] vorgeschlagenen Metrik. Die hier verwendete Metrik berücksichtigt Änderungen
der Größe von Veröffentlichungen nicht ausdrücklich. Die gewählte Metrik ist in diesem
Punkt simpler. Das erleichtert das Nachvollziehen eines konkreten Routingvorgangs. Im
vorgestellten Szenario mit genau einer Art Prozessor ist es zudem unerheblich, ob und
mit welcher Genauigkeit die Größe einzelner Veröffentlichungen bei der Berechnung der
Metrik berücksichtigt wird. Erst wenn mehrere Prozessoren unterschiedlich verknüpft
werden können, ist die genaue Größe von Veröffentlichungen entscheidend. Für umfangreichere Szenarien könnte die exakte Größe bei der Berechnung der ETT einfließen. Dafür
wäre es notwendig, dass die (voraussichtliche) Größe von Veröffentlichungen mit den zugehörigen Ankündigungen verbreitet wird. Das ist bislang für ASP nicht vorgesehen. Der
Ansatz wird hier aus den genannten Gründen nicht weiter verfolgt.
43
4. Implementierung
4. Implementierung
Bislang existierte keine Implementierung von ASP für ein reales System. Der gesamte
ASP-Stack wurde daher neu implementiert. Für die vollständige Umsetzung des Szenarios wurden die Anwendungen ebenfalls neu implementiert oder falls bestehende Lösungen
verfügbar waren, wurden diese eingebunden (siehe Abschnitt 4.2). In diesem Kapitel werden die Kernpunkte der Implementierung vorgestellt.
4.1. Einleitung
Die Implementierung der ASP-Middleware folgt der in den Abschnitten 2.4 und 2.5 beschriebenen Systemarchitektur: Auf jedem Knoten des Netzwerks ist ein Broker aktiv.
Dieser Broker nutzt die Netzwerkabstraktionsschicht für die Kommunikation mit Brokern auf benachbarten Knoten. Anwendungen sind über die Anwendungsschnittstelle
mit ihrem lokalen Broker verbunden.
Die Middleware und der Großteil der Anwendungen wurden in Java auf der gleichnamigen Plattform implementiert. Ausschlaggebend für die Wahl von Java waren die
hohe Codeportabilität, die Verfügbarkeit der Laufzeitumgebung auf vielen gängigen Betriebssystemen und die umfangreiche Standardbibliothek (siehe [Ull07]). Ein weiteres
Argument für Java war zunächst die Option, die Software ohne eine komplette Neuimplementierung auf Mobilgeräte mit der Plattform J2ME zu portieren (siehe [BM06]).
Dieses Vorhaben wurde wegen des hohen zu erwartenden Zeitaufwands verworfen. Aus
Rücksicht auf das für die Versuche verfügbare Softwareumfeld wurde Java Version 5
benutzt.
Die Implementierung verbindet Anwendungen und Middleware in einem gemeinsamen
Prozess. Diese Entscheidung wurde getroffen, um die Entwicklung zu vereinfachen.
4.2. Anwendungen
Die vier aus dem Szenario (siehe Abschnitt 3.2) bekannten Anwendungen werden in den
folgenden Absätzen umrissen.
44
4. Implementierung
4.2.1. Rekorder
Die Anwendung zur Sprachaufnahme nutzt die Java Sound API für den Zugriff auf ein
vorhandenes Mikrofon [Ora10]. Sie erlaubt die Aufzeichnung von Sprache in einem unkomprimierten Format in einer vorgegebenen Qualität. Die Aufzeichnung wird mit ASP
an interessierte Subscriber übertragen. Die Ankündigungen enthalten das Datum der
Aufzeichnung und Informationen zum Format der Audiodaten. Für die Übertragung
(Veröffentlichung) wird der Strom der Audiodaten in Abschnitte von je ca. 1280 Byte
aufgeteilt. Jeder dieser Abschnitte wird eigenständig veröffentlicht. Im Rahmen einer
Aufzeichnung werden je nach Länge hunderte oder tausende Veröffentlichungen erzeugt.
In das Programm wurde zudem ein Modus zum Playback bereits aufgezeichneter Aufzeichnungen aus Dateien integriert. In diesem Modus stammen die Audiodaten aus einer
Datei, werden aber in Echtzeit veröffentlicht, wie es beim normalen Modus auch der
Fall ist. Dieser Modus erleichtert es, die Experimente unter gleichen Bedingungen zu
wiederholen und mindert den Aufwand bei der Durchführung der Experimente. Nicht
zuletzt lässt sich die Audioaufnahme an Geräten simulieren, die Sprache nicht aufzeichnen können.
4.2.2. Speicherung
Das Programm zur Speicherung empfängt die Audiodaten des Rekorders und gibt sie
weiter. Wie in Abschnitt 3.3.1 gefordert, wurde die Anwendung in eine Senke und eine
Quelle aufgeteilt. Die Senke der Anwendung prüft zunächst den Inhalt der Ankündigungen. Bei Interesse abonniert die Anwendung die Veröffentlichungen und schreibt sie
in eine Datei. Die Aufzeichnung wird beendet, wenn die Middleware der Senke meldet,
dass Veröffentlichungen mit der ASP ID nicht länger zu erwarten sind. Die Informationen
über das Aufzeichnungsdatum werden ebenfalls abgespeichert. Regelmäßig überprüft die
Quelle der Anwendung, ob neue Aufzeichnungen abgespeichert wurden. Liegt eine neue
Aufzeichnung vor, wird diese umgehend angekündigt. Die gespeicherte Aufzeichnung
wird als eine große Veröffentlichung veröffentlicht.
4.2.3. Konverter
Die Anwendung zum Umwandeln der Audiodaten in ein komprimiertes Format untersucht ständig eingehende Ankündigungen. Kann das Programm die angekündigten Veröffentlichungen einer ASP ID verarbeiten, macht es eine entsprechende Ankündigung der
verarbeiteten Daten. Dabei schätzt die Anwendung auch die zu erwartende Dauer der
Umwandlung ab. Sie benutzt dazu die Dauer der angekündigten Audiodatei als Grundlage. Diese Dauer wird durch die bekannte Umwandlungsgeschwindigkeit dividiert. Zum
Beispiel beträgt der geschätzte Aufwand für die Umwandlung einer fünf Minuten langen
Aufzeichnung auf einem Rechner, der mit 20facher Geschwindigkeit umwandeln kann
5·60s
20 = 15s. Der konkrete Geschwindigkeitsfaktor wird über eine Konfigurationsdatei
festgelegt.
45
4. Implementierung
Geht eine gespeicherte Aufnahme ein, wird sie als Datei zwischengespeichert. Die Komprimierung übernimmt ein externes Programm. Für die Experimente wurde oggenc verwendet. Es ist Teil der freien vorbis-tools 1 . Das Programm wandelt die Audiodaten in
das komprimierte Format Ogg/Vorbis um und wurde gewählt, weil es kostenlos für die
Betriebssysteme Windows, Mac OS X und Linux auf unterschiedlichen Architekturen
(x64/amd64, x86, ppc) verfügbar ist. Nach der Umwandlung wird das Ergebnis den
interessierten Subscribern in Form einer Veröffentlichung zur Verfügung gestellt.
4.2.4. Download
Das Programm zum Download enthält nur die nötigsten Funktionen. Es zeigt dem Benutzer alle derzeit angekündigten ASP IDs und auf Wunsch den Inhalt der entsprechenden
Ankündigungen an. Wählt der Anwender eine ID für den Download aus, abonniert das
Programm die Veröffentlichung. Die erste Veröffentlichung dieser ID schreibt es in eine
Datei und kündigt das Abonnement der ID umgehend.
4.2.5. Weitere Anwendungen
Neben den oben genannten Anwendungen wurden einige weitere Anwendungen entwickelt. Sie wurden in erster Linie während der Entwicklung der Middleware zu Testund Diagnosezwecken eingesetzt. Eine der dabei entstandenen Anwendungen, kam auch
während der Experimente zum Einsatz. Es handelt sich dabei um eine Dummy-Anwendung. Sie registriert sich beim Broker der Middleware als Senke. Die Anwendung arbeitet
passiv. Ankündigungen werden auf dem Bildschirm ausgegeben, jedoch nie abonniert.
Die ASP-Middleware dieser Anwendung verhält sich dabei wie bei allen anderen beschriebenen Anwendungen.
4.3. Broker
Der Broker ist die zentrale Komponente der implementierten ASP-Middleware. Unter anderem initialisiert der Broker die Netzwerkabstraktionsschicht, verwaltet Nachbarn und
Pfade, leitet Nachrichten weiter, überwacht Ankündigungen und stellt den registrierten
Anwendungen die abonnierten Veröffentlichungen zur Verfügung.
4.3.1. Multithreading
Die Aufgaben des Brokers sind auf mehrere Threads verteilt. Es gibt je einen Thread
für die Nachrichtenverarbeitung in Sende- und Empfangsrichtung. Daneben existieren
zwei weitere Threads, die regelmäßige bzw. zeitlich verzögerte Operationen ausführen.
1
http://www.vorbis.com/
46
4. Implementierung
Der Thread, der die empfangenen Nachrichten bearbeitet, ist zudem für das Starten und
Beenden der Middleware verantwortlich. Zu seinen weiteren Aufgaben zählen das Zusammensetzen fragmentierter Nachrichten und die Übergabe von Ankündigungen und
Veröffentlichungen an die beim Broker registrierten Anwendungen. Der Sender“ ge”
nannte Thread fragmentiert Nachrichten falls nötig, und übergibt die Nachrichten an
die NAL-Implementierung.
Der Thread TimeoutMonitor“ überwacht die Gültigkeit eingehender und ausgehender
”
Ankündigungen. Sobald eine ausgehende Ankündigung zu verfallen droht, löst dieser
Thread die Verlängerung der Ankündigung aus. Für die Implementierung wurde ein
Wert von 80 % der Gültigkeit der Ankündigung gewählt. Hat eine Ankündigung zum
Beispiel eine Gültigkeit von 10 s, wird sie nach 8 s automatisch verlängert. Wird eine
eingehende Ankündigung nicht rechtzeitig verlängert, wird dies protokolliert und die
bekannte Ankündigung wird komplett verworfen. Lokale Anwendungen, die Veröffentlichungen der betroffenen ASP ID abonniert haben, werden benachrichtigt.
Der vierte Thread löst nach einer geringen Verzögerung den Versand von Abonnements
aus. Auf diese Weise muss der Thread, der das Abonnement ursprünglich auslöst, seine
Ausführung nicht pausieren. Die Verzögerung ist auf 100 ms festgelegt.
4.3.2. Priorisierung
Zum Aufbau aktiver Pfade verwendet ASP Ankündigungen und Abonnements (siehe
Abschnitt 2.5.2). Die Ankündigungen werden regelmäßig aktualisiert. Erreicht eine Folgeankündigung einen Broker zu spät, hat dieser die Ankündigung und alle mit ihr
verbundenen Pfade bereits verworfen. Damit Ankündigungen mit möglichst niedriger
Verzögerung im Netz geflutet werden, werden Kontrollnachrichten und Veröffentlichungen unterschiedlich priorisiert. Dadurch wird vermieden, dass die Übertragung einer
großen Veröffentlichung (bzw. ihrer Fragmente) die rechtzeitige Zustellung von Ankündigungen und anderen Kontrollnachrichten verhindert.
Jede ausgehende oder weiterzuleitende Nachricht wird innerhalb des Brokers in genau
eine von zwei Warteschlangen eingefügt. Veröffentlichungen werden an die eine, alle
anderen Nachrichten an die andere Warteschlange angehängt. Der zuständige Thread
bearbeitet immer erst die Warteschlange mit den Kontrollnachrichten und erst wenn
sie leer ist, wird geprüft, ob in der zweiten Warteschlange Veröffentlichungen sind, die
bearbeitet werden müssen.
4.3.3. Fragmentierung
Die Fragmentierung von Nachrichten wird getrennt für jeden Nachbarn vorgenommen.
Der Broker kann dazu für jeden einzelnen Nachbarn die MTU (maximum transfer unit)
erfragen. Veröffentlichungen werden erst dann fragmentiert, wenn sie größer als die MTU
sind. Kontrollnachrichten werden generell nicht fragmentiert. Sind sie zu groß, werden
47
4. Implementierung
sie verworfen. Die Fragmentierung wurde so implementiert, dass eine eingehende, fragmentierte Veröffentlichung an jedem Broker zusammengesetzt wird. Erst danach wird
sie bei Bedarf erneut fragmentiert und weitergeleitet. Dadurch wird vermieden, dass unvollständige Veröffentlichungen voreilig weitergeleitet werden und das Netzwerk unnötig
belasten. Entlang jeder Verbindung wird zudem stets die höchstmögliche MTU verwendet. Im Gegenzug steigt die Übertragungslatenz jedoch an. Die Reihenfolge, in der die
Fragmente einer Veröffentlichung beim Broker eintreffen, ist unbedeutend.
4.4. Protokollierung
Damit der Verlauf der Experimente nachvollzogen werden kann, protokolliert die Middleware relevante Aktionen in Dateien. Es wurden die von der Java-Standardbibliothek
angebotenen Programmierschnittstellen genutzt, um diese Funktion zu realisieren. Zu
den protokollierten Ereignissen zählen u.a. Ein- und Ausgang von Nachrichten, der Verlust von Nachbarschaftsbeziehungen und die Operationen Publish und Subscribe. Der
genaue Umfang der zu protokollierenden Daten kann über eine Konfigurationsdatei festgelegt werden.
4.5. NAL
Die Netzwerkabstraktionsschicht wurde getrennt für Bluetooth auf der einen und Ethernet und WLAN auf der anderen Seite implementiert. Die beiden Implementierungen
werden vom Broker über identische Schnittstellen angesprochen und auch in der Gegenrichtung werden dieselben Schnittstellen verwendet. Beide Implementierungen lassen
sich unabhängig voneinander oder parallel betreiben. Über eine Konfigurationsdatei des
Brokers lässt sich festlegen, welche NAL-Implementierung(en) geladen und verwendet
werden. Damit die Middleware den Betrieb aufnimmt, müssen alle konfigurierten NALImplementierungen korrekt starten.
In den nächsten Unterabschnitten werden die beiden Implementierungen genauer vorgestellt.
4.5.1. Priorisierung
Die in Abschnitt 4.3.2 beschriebene Priorisierung von Kontrollnachrichten und Veröffentlichungen wird in beiden NAL-Implementierungen fortgesetzt. Kontrollnachrichten
werden mit einer höheren Priorität behandelt als Veröffentlichungen. Es sind Implementierungen der Netzwerkabstraktionsschicht denkbar, die anders vorgehen, um Kontrollnachrichten zügig zu verbreiten. In der vorliegenden Implementierung wurde darauf jedoch verzichtet und auf dasselbe Verfahren zurückgegriffen, dass sich im Broker bewährt
hat.
48
4. Implementierung
4.5.2. Ethernet und WLAN via UDP
Die NAL-Implementierung für Ethernet und WLAN basiert auf UDP/IP. Die für diese
Arbeit wichtigsten Eckpunkte von IP und UDP werden in Abschnitt 2.8.1 und 2.8.2
genannt. Auf weitere Literatur wird verwiesen. Die Implementierung des NAL für UDP
wird im folgenden als UdpNAL bezeichnet.
ASP wurde so konzipiert, dass die Netzwerkabstraktionsschicht von beliebigen Techniken der Sicherungsschicht (OSI-Layer 2) oder höher abstrahiert [Ris09a]. Um den Implementierungsaufwand zu reduzieren, wurde entschieden, die Implementierung des NAL
für Ethernet und WLAN auf UDP/IP aufzubauen. Mit der Socket-Schnittstelle existiert
eine verbreitete API für die Datenübertragung mit UDP/IP (und anderen Protokollen) [Tan03, SFR04]. In Java ist sie auf allen genutzten Plattformen identisch [Ull07].
Das Protokoll UDP ist auf der Transportschicht (Layer 4) des OSI-Referenzmodells angesiedelt und damit über der Sicherungsschicht angesiedelt. Es wurde soweit wie möglich
darauf verzichtet, besondere Eigenschaften oder Merkmale von IP oder UDP zu nutzen.
UDP/IP wird in der implementierten Software weitgehend so genutzt, als sei es ein
Protokoll der Sicherungsschicht. Insbesondere wird die Fähigkeit von IP, zwischen unterschiedlichen Netzen zu routen, nicht genutzt. Die Kommunikation über UDP beruht
in der Implementierung, wie von ASP gefordert, auf Nachbarschaftsbeziehungen.
Um Nachbarn zu erkennen, sendet der UdpNAL in regelmäßigen Abständen spezielle
Nachrichten per Broadcast an das eigene Subnetz aus. Je nach Konfiguration wird dafür
eine gerichtete oder die eingeschränkte Broadcastadresse genutzt (siehe Abschnitt 2.8.1).
Diese regelmäßigen Signale wurden mit der Ermittlung der Verlustraten in Sende- und
Empfangsrichtung verknüpft. Die Raten werden ermittelt, damit die Kosten der Verbindungen berechnet werden können. Ferner ermittelt der UdpNAL eigenständig die RTT
(round trip time) zu allen bekannten Nachbarn. Wird von einem Nachbarn über einen
längeren Zeitraum gar nichts empfangen, gilt dieser Nachbar als verloren.
Eine weitere Aufgabe des UdpNAL ist die Sicherung der Übertragungen zu den Nachbarn. Für diese Funktion wurde ein einfaches Stop-and-Wait-Protokoll implementiert
[Tan03, S. 208 ff.]. Es hat den Nachteil, dass es aufgrund hoher Latenz- und Verarbeitungszeiten sehr ineffizient arbeitet. Übertragungen sind daher langsam. Es ist davon
auszugehen, dass der Einsatz von TCP/IP dieses Problem behoben hätte. Allerdings ist
TCP in seinen Diensteigenschaften weit weniger mit Ethernet oder WLAN vergleichbar
als UDP, weshalb darauf verzichtet wurde.
Auch die Aufgaben des UdpNAL sind auf mehrere Threads aufgeteilt. So sind einige der
Operationen wie der Nachrichtenempfang (receive()) blockierend und werden von separaten Threads ausgeführt. Andere Aktionen, wie die Messung der Verlustrate, müssen
in regelmäßigen zeitlichen Abständen ausgeführt werden und wurden deshalb ebenfalls
in eigene Threads ausgelagert.
49
4. Implementierung
4.5.3. Bluetooth via OBEX
Die Implementierung der Bluetooth-Netzwerkabstraktionsschicht wird nachfolgend kurz
als BtNAL bezeichnet. Für den Zugriff auf die Bluetooth-Hard- und Software nutzt sie
die in JSR-82 spezifizierten Schnittstellen [Mot08]. Um sie zur Laufzeit nutzen zu können,
wird ein Bluetooth-Stack für Java benötigt, der diese Spezifikation implementiert. Die
implementierte Middleware verwendet dazu die freie Software BlueCove2 . Der Stack
wurde während der Entwicklung der ASP-Middleware erfolgreich auf allen genutzten
Plattformen eingesetzt und funktionierte auch mit unterschiedlicher Bluetooth-Hardware ohne nennenswerte Probleme.
Für die Datenübertragung verwendet der BtNAL OBEX auf Grundlage von GOEP (siehe Abschnitt 2.8.4). Möchte ein Broker b1 via BtNAL eine Nachricht zu einem benachbarten Broker b2 versenden, etabliert b1 eine OBEX-Sitzung. Die Operation PUT wird
anschließend genutzt, um ASP-Nachrichten vom Client b1 zum Server b2 zu übertragen.
Der Client nutzt GET um die Übertragungslatenz (RTT) zwischen den beiden BluetoothNachbarn zu ermitteln.
Der BtNAL scannt die Umgebung periodisch nach neu hinzugekommenen BluetoothGeräten. Da die Scans sehr zeitintensiv sind und andere Übertragungen stören können,
kommt ein adaptives Verfahren zum Einsatz. Der zeitliche Abstand zwischen zwei aufeinanderfolgenden Scans wird beträchtlich erhöht, sobald mindestens ein anderes BluetoothGerät bekannt ist, auf dem die ASP-Middleware erreicht werden konnte. Der BtNAL
nimmt keinen Einfluss auf die Sichtbarkeit des genutzten Bluetooth-Adapters bezüglich
Inquiry Scans. Der Modus ist daher bei Bedarf mit den Mitteln des Betriebssystems zu
konfigurieren.
Ähnlich wie beim UdpNAL werden auch die Aufgaben des BtNAL von mehreren Threads
gemeinsam erfüllt. Einer von ihnen löst die zuvor beschriebenen regelmäßigen Scans
aus. Zusätzlich wird für jeden Nachbarn, der eine Verbindung zum BtNAL aufbaut, ein
Thread erzeugt. Weil Bluetooth-Operationen vergleichsweise hohe Verzögerungen aufweisen können, wird auch in Senderichtung bei Bedarf für jeden Nachbarn ein separater
Thread gestartet. Die dabei aufgebauten OBEX-Sitzungen bleiben so lange wie möglich
bestehen.
Der BtNAL enthält keine Maßnahmen zur Sicherung der Bluetooth-Übertragungen vor
Verlust. Der Schutz wird von den genutzten Protokollen bereits sichergestellt. Da die
verwendete Programmierschnittstelle keinen Zugriff auf die tatsächlichen Fehlerraten
gewährt, wird bei allen Bluetoothübertragungen 1 als Wert für ETX (siehe Abschnitt
2.7.2) angenommen. Das heißt, der BtNAL geht von fehlerfreien Verbindungen aus. Aus
Sicht des BtNAL ist dies korrekt. Es gibt jedoch die reale Situation nicht optimal wieder,
da es in der Praxis durchaus zu Störungen und damit zur Wiederholung von Übertragungen kommen kann.
2
http://bluecove.org/
50
4. Implementierung
Die Fragmentierung die vom Bluetooth-Stack automatisch vorgenommen wird, wird nur
eingeschränkt benutzt. Damit ein zeitliches Multiplexing von ASP-Kontrollnachrichten
und Veröffentlichungen ausgeführt werden kann, veranlasst der BtNAL den Broker Nachrichten zu fragmentieren. Alle Nachbarn, die über Bluetooth verbunden sind, geben dazu
eine feste MTU vor. Ohne die Fragmentierung würde der Bluetooth-Stack auch eine mehrere Megabyte große Veröffentlichung – für den BtNAL transparent – zu einem Nachbarn
übertragen. Alle anderen Übertragungen zu diesem Nachbarn müssten jedoch auf das
Ende der anhaltenden Übertragung warten. Dies würde bei Bluetooth aufgrund der
verglichen mit Ethernet und WLAN niedrigen Übertragungsraten und den daraus resultierenden langen Übertragungszeiten häufig zum Ablauf von Ankündigungen führen.
4.6. Nachrichtenformat
Für die Implementierung der ASP-Middleware war es erforderlich das Format der Nachrichten, die die Broker untereinander austauschen, zu spezifizieren. Grundlage bildet der
Vorschlag aus [Ris09a], der jedoch ergänzt und konkretisiert wurde. Die Struktur der
Nachrichten ist im Anhang auf Seite 76 wiedergegeben. In diesem Abschnitt werden
einzelne, besonders interessante Aspekte des Nachrichtenformats beschrieben.
Die beiden ersten Felder (TYPE, TTL; je ein Byte) sind bei allen Nachrichten vorhanden
und wurden neu eingeführt. Das erste Byte dient der Identifizierung des Nachrichtentyps.
Es werden die fünf Nachrichtentypen Announcement, Subscription, Unsubscription, Publication und Brokenpath unterschieden. Das zweite Byte beinhaltet die TTL (time to
live) der Nachricht. Sie wird vor jeder Weiterleitung einer Nachricht verringert. Sie dient
in der Auswertung der Experimente zum besseren Verständnis der Abläufe. Von der
Implementierung wird das Feld stets mit dem Wert 127 initialisiert. Insbesondere hat
eine neue Nachricht, die erstmals zu einem Nachbarn verschickt wird, bei ihrer Ankunft
die TTL 127.
Die Werte der Felder Kosten (8 Byte) und die Gültigkeit (4 Byte) werden als ganzzahlige
Anzahl von Millisekunden interpretiert. Bei typischen Werten von einigen hundert Millisekunden bis zu einigen zehn oder hundert Sekunden bleiben im Feld für die Kosten eine
Reihe von Bytes ungenutzt. Sie können für zukünftige Erweiterungen genutzt werden. So
wurde in Abschnitt 3.4.3 bereits angedeutet, dass es bei einer möglichen Erweiterung der
Metrik notwendig werden könnte, Schätzungen über die Größe von Veröffentlichungen
in den Ankündigungen zu transportieren.
Für die Fragmentierung von Veröffentlichungen enthalten Nachrichten vom Typ Publication zwei Felder (je vier Byte). In einem ist die Größe der gesamten Nutzlast gespeichert,
im anderen der Byteoffset der Daten, die in der jeweiligen Nachricht transportiert werden.
An dieser Stelle wird noch einmal betont, dass die Nachrichten keine Informationen
über ihre Länge enthalten. Diese Information wird auf Ebene der Broker nicht explizit
51
4. Implementierung
benötigt. Dies folgt aus den Anforderungen, dass die Netzwerkabstraktionsschicht Nachrichten stets komplett an den Broker übergibt. Diese und weitere Anforderungen an die
Netzwerkabstraktionsschicht stehen in Abschnitt 3.3.2 beschrieben.
4.7. Metrik
Die Implementierung folgt dem in Abschnitt 3.4.3 beschriebenen Ansatz. Als Einheit der
Kosten wurden Millisekunden gewählt. Die Auflösung beträgt eine ganze Millisekunde.
Die zur Berechnung nötigen Angaben werden von dem NAL, den Prozessoranwendungen und den Ankündigungen geliefert. Die Kosten sämtlicher eingehender und lokaler
Ankündigungen sind dem Broker bekannt. Löst ein Prozessor eine Ankündigung aus,
informiert er den Broker über die ASP IDs, die der Ankündigung zugrunde liegen. Die
Kosten werden aufsummiert. Daneben gibt der Prozessor die verlangte Schätzung über
den Bearbeitungsaufwand für das Verarbeiten der Veröffentlichung(en) ab. Die Berechnungsgrundlage für die Konverteranwendung wird in Abschnitt 4.2.3 erläutert. Sie wird
zu den Kosten der neuen Ankündigung addiert.
Die beiden Implementierungen der Netzwerkabstraktionsschicht liefern die verbleibenden
Daten (siehe Seite 48 ff.). Dazu gehört die RTT. Sie wird, wie in der Formel 3.3 (S. 43)
beschrieben ist, in die Kostenberechnung einbezogen.
Besonders die Parameter S (Größe) und B (Bandbreite) zur Berechnung der ETT (siehe
Abschnitt 2.7.3) sind mit Blick auf die Implementierung im NAL interessant. Für den
Parameter S wurde im gesamten System ein fester Wert von 200.000 Byte gewählt. Ein
S
Kompromiss, da niedrigere Werte dazu führen können, dass der Faktor B
gerade bei hohen Bandbreiten einen ebenfalls sehr niedrigen Wert annimmt und damit das Produkt
(ETX) an Gewicht verliert und keinen Vergleich von unterschiedlich guten Verbindungen
auf Basis von ETX mehr ermöglicht. Die Bandbreite B wird über eine Konfigurationsdatei vorgegeben. Während der Entwicklung wurde zunächst ein Verfahren implementiert,
dass die verfügbare Bandbreite sowohl über Bluetooth als auch über UDP misst. Es zeigte sich jedoch, dass die Ergebnisse dieser Messungen sehr lastabhängig und außerdem
plattformabhängig waren. Dies kann im Endeffekt zu Oszillation von Routen führen. Das
Verfahren wurde aus diesem Grund verworfen. Die fest konfigurierten Werte vermeiden
das Problem und ermöglichen zusätzliche eine bessere Reproduzierbarkeit der Versuche.
52
Es wird ein experimenteller Ansatz verfolgt, um die Leistungsfähigkeit von ASP zu beurteilen. In Experimenten, die so konzipiert sind, dass sie gezielt relevante Teilaspekte
von PPS / ASP untersuchen, werden die nötigen Daten gesammelt. Das in Abschnitt
3.2 beschriebene Szenario und die dort präsentierten Anwendungen bilden die Grundlage der Experimente. Diese Experimente und welche Eigenschaften von ASP, mit ihnen
geprüft werden können, werden im folgenden erläutert. Die Anforderungen, denen die
Experimente gerecht werden müssen, stehen dabei im Vordergrund. Nur wenn die Rahmenbedingungen erfüllt sind, lassen die Experimente Aussagen über das implementierte
System zu.
Die Versuche werden mit der in Kapitel 4 vorgestellten Software ausgeführt. Zum besseren Verständnis der Versuchsergebnisse (siehe Kapitel 6) wird der allgemeine Versuchsaufbau in Abschnitt 5.2 umrissen.
5.1. Experimente
Bevor einzelne Experimente vorgestellt werden, wird ein weiteres Mal auf die in Abschnitt 3.2.1 zusammengefassten Ziele von ASP verwiesen. Die Experimente helfen,
schrittweise die Erfüllung der aus den Zielen abgeleiteten Hypothesen in einem realen System zu überprüfen. Konnte gezeigt werden, dass eines oder mehrere der Ziele
zufriedenstellend erfüllt werden, dienen weitere Experimente, die Effizienz zu ermitteln,
mit der das Ergebnis erreicht wurde. Dabei spielen Punkte wie der Ressourcenverbrauch
eine Rolle. Weiterhin ist interessant wie das praktische System auf Störungen reagiert.
Die räumliche Entkopplung ist dann gegeben, wenn ein Publisher im Experiment einem Subscriber Nachrichten übermitteln kann, ohne dass die einzelnen Akteure wissen,
wer genau die Nachrichten empfängt bzw. von wo sie stammen. Es wird angenommen,
dass dies erfüllt ist, wenn Publisher und Subscriber nicht auf direktem Wege Nachrichten
miteinander austauschen können. Zwischen den beiden Seiten vermittelt allein die ASPMiddleware. Direkte Kommunikation ist insbesondere dann nicht möglich, wenn beide Seiten unterschiedliche Kommunikationstechniken verwenden, also physisch getrennt
sind. Verwenden sie kompatible Netzwerktechniken, müssen diese so abgeschottet werden, dass der Nachrichtenaustausch auf herkömmlichem Wege nicht möglich ist (logische
Trennung). Die logische Trennung kann bei IP-basierten Netzwerken dadurch erfolgen,
dass diese in mehrere Subnetze unterteilt werden (siehe Abschnitt 2.8.1). Für die Un-
53
tersuchung der räumlichen Entkopplung ist kein eigenständiges Experiment vorgesehen,
denn der Aspekt spielt in jedem der Experimente eine Rolle.
D
S
R
C
139.30.3.5/26
139.30.216.58/22
Abbildung 5.1.: Die logische Trennung eines Netzwerks in zwei IP-Subnetze. D und R
sind per WLAN mit einem Access Point verbunden, der mit Knoten S
verbunden ist. S hat eine zweite Verbindung in ein weiteres Subnetz, an
das C angeschlossen ist.
In einem weiteren Experiment wird die zeitliche Entkopplung von ASP geprüft.
Empfängt ein Subscriber, eine Veröffentlichung, die zu einem Zeitpunkt verbreitet wurde,
als der Subscriber nicht aktiv oder erreichbar war, ist die zentrale Anforderung erfüllt.
Ein Experiment ( X5“) widmet sich besonders diesem Aspekt. Entscheidend ist dabei
”
der zeitliche Ablauf der Aktionen. Am Experiment sind mehrere Knoten beteiligt. Einige
von ihnen übernehmen die Rollen Aufzeichnung, Speicherung und Umwandlung (siehe
Seite 28 ff.). Sie werden zuerst gestartet. Die Rolle Download wird von mehreren weiteren Knoten übernommen. Daneben existieren Knoten, auf denen keine Anwendung
läuft, sondern nur die ASP-Middleware. Erst nachdem eine Aufzeichnung abgeschlossen
wurde, wird die Download-Anwendung (und mit ihr die Middleware) auf einem der betreffenden Knoten gestartet. Nach erfolgtem Download wird sie beendet und dann ein
weiterer Download auf einem anderen Knoten gestartet. Dieser Ablauf stellt sicher, dass
• die Operation Publish ausgeführt wird, wenn kein Subscriber aktiv ist, und
• die Veröffentlichung bei ihrer ersten Verbreitung nicht von allen potenziellen Subscribern empfangen werden kann.
Die semantische Entkopplung ermöglicht Senken durch Einbeziehung von Prozessoren Daten zu empfangen, die sie nicht selbstständig verarbeiten können oder möchten.
Um ihre Funktionsfähigkeit im Szenario zu überprüfen, ist es notwendig mindestens einen
Prozessor in die Kommunikation zwischen Publisher und Subscriber einzubinden. Das
Szenario hält dafür die Weitergabe eines Audiomitschnitts mit anschließender Konvertierung und Download bereit. Da dies ein wichtiger Bestandteil des Szenarios ist, spielt
dieser Vorgang in allen Experimenten eine Rolle.
Kann ASP die zentralen funktionalen Anforderungen erfüllen, ist es weiter interessant zu
betrachten, wie effizient ASP / PPS diese Ziele erreicht. In Abschnitt 2.1 wird ausgeführt,
54
dass ASP im Kern ein Routingproblem lösen möchte. In einem Experiment ( X1“) wird
”
ASP daher mit unterschiedlichen Routingalternativen konfrontiert. Dies bedeutet,
dass mehrere mögliche Routen zwischen Publisher und Subscriber existieren. Dabei wird
in unterschiedlichen Varianten des Experiments untersucht, wie ASP bei äquivalenten
Bedingungen reagiert. Die Bandbreite, erreichbare Zuverlässigkeit und Übertragungstechnik ausgewählter Verbindungen sind in diesen Experimenten vergleichbar. Da jedoch
in einem heterogenen Umfeld die Bedingungen häufig variieren, wird zusätzlich das Verhalten bei unterschiedlichen Bedingungen untersucht. Diese lassen sich durch Nutzung
unterschiedlicher Übertragungsraten und Verbindungstechniken herstellen.
Unterschiedliche Routen können sich auch durch unterschiedlich leistungsfähige
Prozessoren ergeben. Daher wird in einem weiteren Experiment ( X3“) das Verhal”
ten des Systems untersucht, wenn entweder gleich leistungsstarke oder unterschiedlich
leistungsstarke Prozessoren für die Aufgabe der Konvertierung zur Verfügung stehen.
Dabei ist wichtig, dass sich die Leistungsfähigkeit der Hardware im einen Fall gleicht
oder im anderen Fall signifikant unterscheidet.
Ein weiteres Maß mit dem sich die Effizienz von ASP beschreiben lässt, ist die Höhe
des Verwaltungsaufwands. Die Anzahl der Nachrichten und die Datenmenge, die
übertragen werden müssen, sind zwei Kenngrößen. Sie werden in einem weiteren Experiment ( X2“) erfasst. Um die Vergleichbarkeit der Messwerte zu gewährleisten, wer”
den Werte auf Ebene der Broker gemessen. Alle weiteren Nachrichten, die z.B. zum
Verbindungsauf- oder -abbau auf Ebene der Netzwerkabstraktionsschicht oder zur Sicherung der Übertragung usw. genutzt werden, werden nicht gezählt. Es werden nur die
in Tabelle 2.2 auf Seite 14 genannten Nachrichten bzw. deren Umsetzung in der realen
Implementierung (siehe Abschnitt 4.6) berücksichtigt.
Es wird auch untersucht, wie ASP mit Störungen umgeht. In einer Variante eines der
Experimente zur Untersuchung der Routen werden einzelne Verbindungen gezielt beeinträchtigt. ASP sollte in der Lage sein, seine Aufgabe in der Gegenwart von Störungen
so gut wie möglich zu erfüllen und zum Beispiel zuverlässige Routen bevorzugen.
Wie bereits beschrieben wurde, ist für einige Experimente der Einsatz unterschiedlicher Verbindungstechniken vorgesehen. Dieses Ziel wird bei der Wahl der Hard- und
Softwareplattformen für die Experimente berücksichtigt. Jedes Experiment ist ferner
so angelegt, dass zumindest zwei gänzlich unterschiedlich leistungsstarke Knoten an den
Versuchen beteiligt sind. Dabei kommen auch unterschiedliche Plattformen zum Einsatz.
5.2. Versuchsaufbau
In den folgenden Abschnitten wird der Versuchsaufbau skizziert. Die Details zum Aufbau
der einzelnen Experimente können den Abbildungen in Anhang B.3 sowie den Versuchsprotokollen entnommen werden. Die Protokolle befinden sich auf dem Datenträger.
55
5.2.1. Hardwareumfeld
Bei den praktischen Versuchen kam eine Reihe von Computern zum Einsatz. Sie unterscheiden sich in ihrer Prozessorarchitektur, Rechen- und Speicherkapazität, den Netzwerkschnittstellen und im Formfaktor. In Tabelle 5.1 werden die wichtigsten Informationen zu den Rechnern zusammengefasst. Detaillierte Angaben stehen in Anhang B.4.
Auf der einen Seite standen drei unterschiedliche PCs. Diese sind (1) ein Desktop-PC
mit moderner 64-Bit-x86-CPU, 8 GB Speicher und einer Ethernetverbindung, (2) ein
Apple iBook G4 mit PowerPC-CPU und integriertem WLAN und Ethernet, und (3) ein
weiterer Desktop mit einer älteren x86-CPU, USB-WLAN-Adapter und Ethernet.
Daneben standen drei Linutops zur Verfügung. Es handelt sich dabei um kompakte
Rechner, die eine x86-CPU und eine Ethernet-Schnittstelle besitzen. Sie verfügen nicht
über eingebauten Festspeicher. Das Betriebssystem wurde von USB-Sticks gestartet, auf
denen auch die Nutzerdaten gespeichert waren.
Ein weiteres System wurde auf dem 64-Bit-Desktop-PC mit VirtualBox1 virtualisiert.
Zur Vernetzung standen ein WLAN-Router (802.11bg) mit eingebautem Ethernet-Switch
und ein weiterer Switch zur Verfügung. Bei Bedarf wurden die Rechner für einzelne
Experimente über USB mit WLAN- oder Bluetooth-Adaptern bestückt.
Die Versuche wurden in einem Wohnumfeld ausgeführt. In der Wohngegend existieren
viele Funknetze. In einer Messung konnten mit einem Notebook über 20 unterschiedliche
WLAN-Funkzellen erkannt werden. Daneben konnte gelegentlich die Anwesenheit weiterer Bluetooth-Geräte im Umfeld der Versuche registriert werden. Diese waren jedoch
sehr sporadisch.
5.2.2. Softwareumfeld
Es kamen während der Experimente mehrere Betriebssysteme und Java-Laufzeitumgebungen zum Einsatz. Genauere Details können der Tabelle B.2 im Anhang entnommen
werden.
Während der Experimente kamen die Betriebssysteme Debian, Ubuntu Server und openSUSE Linux sowie Mac OS X und Windows Vista zum Einsatz. Tabelle 5.1 gibt einen
Überblick, welches Betriebssystem auf welchem Rechner genutzt wurde.
5.2.3. Beispielaufbau und -ablauf
Eines der Experimente wird detaillierter besprochen. Auf diese Weise werden an einem
Beispiel der Aufbau und der Ablauf der Experimente veranschaulicht. Die weiteren Experimente ähneln dem hier vorgestellten Experiment (Nummer 1, Variante 1, Versuchsreihe
1
http://www.virtualbox.org/
56
Hostname
debian
Enif
Hyadum-II
Kajam
linutop (lt)
linutop2 (lt2)
linutopk (ltk)
Hardware
virtuell
iBook G4 (PPC)
x86 Desktop-PC
x64 Desktop-PC
x86 PC
x86 PC
x86 PC
Betriebssystem
Debian Linux
Mac OS X
openSUSE Linux
Vista 64 Bit
Ubuntu Server
Ubuntu Server
Ubuntu Server
Tabelle 5.1.: Kurzübersicht der Rechner, die für die Experimente genutzt wurden. Für
weitere Details siehe Anhang B.4.
2) in Aufbau und Ablauf. Sie unterscheiden sich vor allem in der jeweils untersuchten
Eigenschaft des Systems und in den bewusst gewählten Randbedingungen.
Ziel des Experiments X1v1R22 war es, das Verhalten des Systems in der Gegenwart von
Störungen zu untersuchen.
An den Versuchen waren fünf Knoten beteiligt. Es handelte sich dabei um die Systeme
debian, Enif, Kajam, linutop (lt) und linutop2 (lt2; siehe Tabelle 5.1). Bis auf Enif waren
alle Computer per Ethernet in einem gemeinsamen IP-Subnetz verbunden. Enif, lt und
lt2 waren in einem Ad-Hoc-WLAN (siehe dazu Seite 23 f.) zu einem zweiten IP-Subnetz
verbunden. Das heißt, dass lt und lt2 zwei aktive Netzwerkverbindungen besaßen. Die
Skizze auf Seite 80 stellt diese Konfiguration dar.
Die aus dem Szenario bekannten Rollen (siehe Abschnitt 3.2.2) waren wie folgt verteilt:
Hostname
debian
Kajam
Enif
Rolle
Speicherung (S)
Konverter (C)
Download (D)
Tabelle 5.2.: Die Rollenverteilung in Experiment 1, Variante 1, Versuchsreihe 2.
Auf einen Rechner zur Aufzeichnung (R) wurde bei diesem Experiment verzichtet. Die
Anwendung zur Speicherung (S) wurde immer mit derselben vorbereiten Aufzeichnung
gestartet. Auf den Knoten lt und lt2 lief die Dummy-Anwendung (siehe Abschnitt 4.2.5).
Aufgabe der beiden Rechner war es, jeweils eine alternative Verbindung zwischen Enif
und dem Rest des Netzwerks zu erlauben.
Um Störungen zu erzeugen, wurde ein spezielles Skript auf lt bzw. lt2 verwendet. Wird
es auf einem der beiden Rechner gestartet, deaktiviert es in regelmäßigen Intervallen
den angeschlossenen WLAN-Adapter. Nach einer Wartezeit wird er wieder aktiviert.
2
Gemeint ist Experiment 1, Variante 1, Reihe 2. Die verwendeten Kürzel zur Bezeichnung von Experimenten und Versuchen werden auf Seite 77 näher beschrieben.
57
Die Dauer der beiden Phasen WLAN an“ und WLAN aus“ konnten getrennt defi”
”
niert werden. Es wird darauf hingewiesen, dass die so erzeugten Störungen synthetisch
sind. Außerhalb der Versuchsumgebung sind andere Störungen zu erwarten. Für die
Experimente hatte dieses Vorgehen jedoch den entscheidenden Vorteil, dass die Versuche leichter zu wiederholen waren. Zudem konnten die Störungen erzeugt werden, ohne
zusätzliche Geräte einzusetzen. Diese hätten möglicherweise unbeteiligte Nutzer in der
Umgebung beeinträchtigen können.
Die Versuche liefen so ab, dass zunächst das Skript gestartet wurde, welches in regelmäßigen Intervallen das WLAN stört. Es wurde erst nach Abschluss des letzten Versuchs einer Reihe beendet. Der Ablauf eines einzelnen Versuchs begann mit dem Start
der Anwendungen auf allen Knoten. Die Reihenfolge wurde im Versuchsprotokoll festgehalten. Nach einer Wartezeit von etwa einer Minute begann der Download am Knoten
Enif. Nachdem er abgeschlossen war, wurden alle Anwendungen beendet. Damit war der
Versuch abgeschlossen.
Im konkreten Experiment wurden die Versuche mehrmals wiederholt, wobei das für die
Störungen verantwortliche Skript mit unterschiedlichen Parametern entweder auf lt oder
auf lt2 gestartet wurde. Zum Vergleich wurden die Versuche mit demselben Aufbau, aber
ohne die künstlichen Störungen wiederholt.
58
6. Auswertung
6. Auswertung
In den folgenden Abschnitten werden die Ergebnisse der Experimente beleuchtet. Tabelle
B.1 (S. 78) gibt eine Übersicht der durchgeführten Versuche. Die Versuche sind unterteilt
nach Experiment, Variante und Versuchsreihe. Die Versuche eines Experiments haben
einen ähnlichen Ablauf und eine gemeinsame Zielstellung. Die Versuche verschiedener
Varianten eines Experiments unterscheiden sich geringfügig im Messaufbau, wie z.B.
Verteilung der Rollen und der Art der Verbindungen zwischen Nachbarn. Bestimmte
Abkürzungen werden verwendet, um einzelne oder mehrere Versuche zu bezeichnen.
Eine ausführliche Erklärung dieser Bezeichner kann Anhang B.1 entnommen werden.
Das Schema kann ebenso verwendet werden, um auf die Messprotokolle und Rohdaten
der Versuche auf dem Datenträger zuzugreifen.
Die Auswertung der Versuchsergebnisse erfolgt dabei entlang der Hypothesen aus Abschnitt 1.2, die aus diesem Grund hier noch einmal wiedergegeben werden.
1. Das System funktioniert in einem heterogenen Umfeld.
2. Die Kommunikation ist räumlich entkoppelt und
3. erfolgt auf Grundlage von Nachbarschaftsbeziehungen.
4. Das System arbeitet mit einem niedrigen Verwaltungsaufwand.
5. Die zeitliche Entkopplung der Kommunikation ist gewährleistet.
6. Unter den alternativen Übertragungswegen wird ein effizienter gewählt.
7. Gestörte Übertragungswege werden vermieden und
8. unterschiedliche Übertragungstechnologien können genutzt werden.
9. Für die Datenverarbeitung werden die leistungsfähigsten der verfügbaren Geräte
eingebunden.
Welche Versuche vordergründig genutzt wurden, um die einzelnen Hypothesen zu untersuchen, gibt Tabelle 6.1 wieder. Bei der Auswertung werden Versuchsergebnisse, die
mit den Erwartungen übereinstimmen, zusammengefasst. Alle Fälle, in denen die Ergebnisse von den Erwartungen abwichen, werden anhand der vorliegenden Daten genauer
untersucht.
59
6. Auswertung
Untersuchungsaspekt
Heterogenität
Räumliche Entkopplung
Nachbarschaftsbeziehungen
Verwaltungsaufwand
Zeitliche Entkopplung
Alternative Übertragungswege
Gestörte Übertragungswege
Alternative Übertragungstechniken
Alternative Prozessoren
Versuche
alle
alle
alle, außer X3
X2
X5R2
X1v1, X1v2
X1v1R2
X1v2
X3
Tabelle 6.1.: Die untersuchten Aspekte und die Versuche, die genutzt wurden, um Aussagen über die Aspekte zu treffen. Siehe Tab. B.1.
6.1. Heterogenität
ASP wurde für den Einsatz in heterogenen Netzen konzipiert. Dieses Ziel wurde bei der
Implementierung berücksichtigt. Die in Abschnitt 5.1 eingeführten Experimente sind
so angelegt, dass sie eine heterogene Umgebung zugrunde legen. Für die Durchführung
der Experimente standen sehr unterschiedliche Rechner zur Verfügung. Damit sind die
Voraussetzungen erfüllt, um ASP in einem heterogenen Umfeld zu testen.
Es wird angenommen, dass die Implementierung von ASP in dem gegebenen Testumfeld auf allen verfügbaren Plattformen und mit unterschiedlichen Netzwerktechniken
funktioniert. Diese Hypothese konnte in den praktischen Versuchen bestätigt werden.
Bei den Experimenten kamen in Summe sieben verschiedene Rechner zum Einsatz, die
fünf verschiedene Hard- bzw. Softwareplattformen einsetzten. Für die Kommunikation
wurden die Technologien WLAN, Ethernet und Bluetooth verwendet, wobei unterschiedliche Hardware zum Einsatz kam. In sämtlichen Versuchen konnten die ASP-Middleware
und die darauf aufbauenden Anwendungen ausgeführt werden. Die Middleware hat stets
Nachrichten mit mindestens einem benachbarten Broker austauschen können.
Lediglich ein einziger Rechner (linutop2) konnte bei einem der Versuche keine Nachrichten austauschen (X5R2/X5O). Die Ursache für dieses Verhalten konnte anhand der
Logdateien nicht geklärt werden. Aus ihnen geht jedoch hervor, dass die Kommunikation nur teilweise eingeschränkt war. Der einzige Nachbar (Hyadum-II), mit dem linutop2
zum Zeitpunkt des Versuchs kommunizieren konnte, hat linutop2 als Nachbarn registriert. Das lässt darauf schließen, dass Übertragungen in eine Richtung funktionierten.
6.2. Räumliche Entkopplung
Das Ziel der räumlichen Entkopplung wurde bei der Gestaltung der Anwendungsschnittstelle berücksichtigt. Keine Quelle kann eine Nachricht veröffentlichen und dabei einen
60
6. Auswertung
oder mehrere Empfänger spezifizieren. Auf der anderen Seite erfährt keine Senke je den
Absender einer Veröffentlichung. Werden diese Schnittstellen im Experiment erfolgreich
eingesetzt um Veröffentlichungen zu verbreiten, wird angenommen, dass räumliche Entkopplung vorliegt.
In jedem der durchgeführten Experimente nutzten die Anwendungen die ihnen gegebenen Schnittstellen um mit anderen Anwendungen zu kommunizieren – unabhängig davon,
auf welchem Knoten diese aktiv waren. Mit der auf Grundlage von ASP implementierten Middleware ist es demnach möglich, dass Anwendungen mittels Publish/Subscribe
räumlich entkoppelt Daten austauschen können.
6.3. Nachbarschaftsbeziehungen
Grundlage der Betrachtungen in diesem Abschnitt ist die Definition des Begriffs Nachbarschaft. Zwei Broker seien benachbart, wenn sie ohne die Hilfe eines oder mehrerer
weiterer Broker, allein mit den ihnen zur Verfügung stehenden Netzwerkschnittstellen
Daten austauschen können. Es folgen Beispiele in denen Nachbarschaft angenommen
wird.
• Zwei Broker, die in einem Bluetooth-Piconetz organisiert sind.
• Zwei Broker, die in einem gemeinsamen IP-Subnetz verbunden sind.
Bis auf Experiment 3 sind alle durchgeführten Experimente geeignet, die Kommunikation
im Netzwerk auf Grundlage von Nachbarschaftsbeziehungen zu zeigen. Experiment 3
eignet sich nicht, weil alle teilnehmenden Rechner in einem IP-Subnetz verbunden sind
(siehe Abbildung S. 82) und im Experiment keine anderen Kommunikationstechniken zur
Verfügung stehen. Die Kommunikation über Nachbarschaftsbeziehungen ist hier trivial.
Es wird davon ausgegangen, dass die Kommunikation auf Basis von Nachbarschaftsbeziehungen dann korrekt funktioniert, wenn alle Broker eines Netzwerks, die nicht benachbart sind, dennoch Nachrichten austauschen können.
Aus den Experimenten geht deutlich hervor, dass Broker, die nicht benachbart gewesen
sind, dennoch Nachrichten austauschen konnten. Insbesondere waren auch die angebundenen Anwendungen in der Lage mit Hilfe der Middleware Veröffentlichungen zu
verbreiten und zu empfangen.
Der erfolgreiche Nachrichtenaustausch lässt sich zum Beispiel an den Ergebnissen von
Experiment X1v2R1 nachvollziehen. Bei dem Experiment hatte der Rechner linutop2,
an dem der Download ausgeführt wurde, zwei Verbindungen zum Rest des Netzwerks
(siehe Skizze auf Seite 80). Eine Verbindung bestand über ein Ad-Hoc-WLAN, die andere über Bluetooth. In jedem der Versuche konnte der Anwendung der Download, also die
transparent verarbeitete Veröffentlichung, zugestellt werden, obwohl Quelle und Senke
nicht benachbart waren und weder auf Ebene von IP noch Bluetooth direkt kommunizieren konnten. Parallel dazu wurden neben anderen Kontrollnachrichten vor allem
61
6. Auswertung
Ankündigungen verbreitet. Tabelle 6.2 illustriert dies anhand einiger Zahlen. Die Werte
geben wieder, wie viele Ankündigungen im Verlauf der Versuche beim Knoten linutop2
eingingen. Alle Ankündigungen wurden ursprünglich von Brokern versandt, mit denen
der Broker auf linutop2 nicht direkt kommunizieren kann.
Versuch
Ank. S
Ank. C
A
11
9
B
13
11
C
14
11
D
13
11
E
8
6
F
14
11
G
13
10
H
13
11
I
14
11
J
11
9
K
13
11
L
13
11
Tabelle 6.2.: Anzahl der in Experiment 1, Variante 2, Reihe 1 bei linutop2 eingegangenen
Ankündigungen der gespeicherten Aufzeichnung (Ank. S) und der konvertierten Aufzeichnung (Ank. C).
6.4. Verwaltungsaufwand
Experiment 2 wurde speziell durchgeführt um den Verwaltungsaufwand zu ermitteln, den
die ASP-Implementierung verursacht, um ihre Aufgaben zu erfüllen. Bevor detailliert auf
die Ergebnisse eingegangen wird, wird erläutert, wie die Datenmengen gezählt wurden
und wie der Verwaltungsaufwand berechnet wurde.
Die Erfassung der Datenmengen folgte dem in Abschnitt 5.1 vorgestellten Ansatz für
Experiment 2. Es wurden grundsätzlich nur die Nachrichten und ihr Umfang auf Ebene der Broker erfasst. Bei der weiteren Berechnung wurden alle übertragenen Daten
außer der Nutzlast, die mit Veröffentlichungen transportiert wurde, als Verwaltungsdaten betrachtet. Das bedeutet, dass insbesondere Ankündigungen, Abonnements, deren
Kündigungen usw. zu 100 % als Verwaltungsdaten betrachtet wurden.
Um die Effizienz der Implementierung zu bestimmen, wurde zunächst bestimmt, wie umfangreich die Nutzdaten sind. Das bedeutet, dass ermittelt wurde wieviele Audiodaten
in jedem der Versuche zu transportieren waren. Diese Zahl ist nicht bei allen Versuchen
identisch, sondern schwankt leicht. Es kam bei der Übertragung der Aufzeichnung zum
Speicher zu vereinzelten Verlusten von Veröffentlichungen. Die Gründe dafür werden
an anderer Stelle diskutiert. Verlust bei der Übertragung der Audiomitschnitte bedeutet, dass die Datei, die in das Archiv geschrieben wird, gegenüber einem vollständig
übertragenen Mitschnitt entsprechend kleiner ist. Dadurch ändert sich auch der Umfang der Daten, die an den Prozessor weitergegeben werden. Und auch die komprimierte
Audiodatei hat eine andere Größe, wenn sich die Ausgangsdaten ändern.
Die Vorgehensweise lässt sich an zwei Beispielen verdeutlichen. Bei Versuch X2R2/X2A
kam es nicht zum Verlust von Veröffentlichungen. Es wurden also alle 1105 Veröffentlichungen (1.413.166 Byte Audiodaten) vom Rekorder übertragen und der Speicheranwendung zugestellt. Zum Konverter wurden 1.413.210 Byte1 übertragen. Die komprimierte
Audiodatei hat eine Größe von 255515 Byte. In Summe sind dies 1413166 + 1413210 +
1
1.413.166 Byte + 44 Byte zusätzlicher Dateikopf
62
6. Auswertung
255515 = 3081891 Byte. Bei Versuch X2R2/X2L kam es zum Verlust einer Veröffentlichung. Die Zahlen, die sich in diesem Fall ergeben, sind 1413166 + 1411930 + 255688 =
3080784 Byte. Die Nutzdaten umfassen demnach bei Versuch X2A 3.081.891 Byte und
bei Versuch X2L 3.080.784 Byte. Die Effizienz wurde durch Division des Umfangs der
eben beschriebenen Nutzdaten durch den Datenumfang aller versendeten Nachrichten
berechnet. Dies hat zur Folge, dass redundate Übertragungen von Nutzdaten ebenfalls
als Verwaltungsaufwand gewertet werden. Unter idealen Bedingungen sollte jede Veröffentlichung nur so oft wie nötig übertragen werden.
Die Gültigkeit von Ankündigungen hat einen Einfluss auf das von der Middleware generierte Datenvolumen. Haben Ankündigungen eine kurze Gültigkeit, werden sie häufig
verlängert und es werden entsprechend mehr Ankündigungen im Netzwerk verbreitet.
Für alle Versuche zu Experiment 2 wurden folgende Werte gewählt:
• Rekorder: 4.000 ms
• Speicher: 20.000 ms
• Konverter: 10.000 ms
Für die Ankündigungen des Rekorders wurden 4 Sekunden gewählt, damit bei Bedarf
besonders schnell auf Störungen auf dem Übertragungsweg vom Rekorder zum Speicher
reagiert werden kann.
Es wurden zwei Versuchsreihen des X2 aufgenommen. Im folgenden werden die Ergebnisse der Versuche aus X2R2 betrachtet. X2R1 wurde verworfen. Die Versuche wurden mit
einer Softwareversion ausgeführt, die noch unvollständig war und einige kleinere Fehler
enthielt. Allerdings sind die vorläufigen Zahlen, die sich aus der Auswertung von X2R1
ergaben, durchaus mit denen von X2R2 vergleichbar.
Der Ablauf der Versuche war folgender: Zunächst wurden die Speicher-, die Konverterund die Downloadanwendung gestartet. Nach einer Minute Wartezeit wurde der Rekorder im Wiedergabemodus gestartet, d.h. das eine definierte und immer identische
Aufzeichnung aufgenommen wurde (siehe Abschnitt 4.2.1). Nach Abschluss der Aufzeichnung, wurde der Download gestartet. Nach erfolgtem Download wurden alle Programme beendet. Alle im Verlauf des Versuchs übertragenen ASP-Nachrichten gingen
in die Auswertung ein.
Die Auswertung der protokollierten Daten aus den Versuchen ergab nach deren Aufbereitung eine durchschnittliche Effizienz der Implementierung von 91,5 %. Abbildung 6.1
bietet einen genaueren Blick auf die Ergebnisse der Auswertung. Es fällt auf, dass bei
der Mehrheit der Versuche eine Effizienz von rund 97 % erreicht werden konnte.
Daneben fallen die anderen Versuche auf, bei denen die Effizienz auf bis zu 78 % (X2R2/
X2E) sank. X2R2/X2P wird weiter unten getrennt betrachtet. Der Grund für das Absinken der Effizienz sind redundate Übertragungen von Veröffentlichungen des Rekorders.
Diese Redundanz wurde durch Änderungen der Routen ausgelöst. Nach dem der neue
63
6. Auswertung
Pfad mit einem Abonnement aktiviert wurde, wurden bisher erzeugte Veröffentlichungen aus dem Cache des Publishers übertragen. Abhängig vom Zeitpunkt der Routenänderungen hatte sich der Cache für Veröffentlichungen bereits unterschiedlich stark
gefüllt.
Die niedrige Effizienz in Versuch X2R2/X2P kann nicht auf dieselbe Weise erklärt werden. Es kam zu einer doppelten Übertragung der gespeicherten Aufzeichnung zum Konverter. Sie war des Ergebnis einer nicht abgefangenen Race Condition. Es kam zu einer
zeitlichen Überschneidung von drei Ereignissen. Zunächst empfing der Konverter eine
Folgeankündigung des gespeicherten Mitschnitts (1). Zu diesem Zeitpunkt hatte der
Konverter Interesse an der Veröffentlichung und hatte diese bereits abonniert. Nur circa
90 ms nach dem Eintreffen der Ankündigung verschickte der Konverter die Kündigung
des Inhalts (2). Das verzögerte Abonnement, welches durch die Folgeankündigung ausgelöst wurde, wurde etwa 20 ms nach der Kündigung verschickt (3).
6.5. Zeitliche Entkopplung
Mit Experiment 5 diente das aufwändigste aller durchgeführten Experimente dem gezielten Test der zeitlichen Entkopplung des implementierten Systems. Alle Aussagen und
Ergebnisse, die sich auf die Versuchsreihe X5R2 beziehen, lassen den Versuch X5R2/X5K
gänzlich außen vor. Bei diesem Versuch kam es zu einem Bedienfehler. Im Gegenzug
wurde ein Versuch mehr durchgeführt, als ursprünglich geplant gewesen war. Die Versuchsanordnung ist auf Seite 81 abgebildet.
Es wird davon ausgegangen, dass das implementierte System die Kommunikation zwischen Publisher und Subscriber zeitlich entkoppelt, falls die Subscriber Veröffentlichungen unter bestimmten Randbedingungen empfangen können. Diese Randbedingungen
umfassen, dass der oder die Subscriber während der Ausführung der Operation Publish
nicht aktiv oder empfangsbereit waren. Der Versuchsablauf von Experiment 5 stellt diese
Bedingung dadurch sicher, dass auf zwei unterschiedlichen Rechnern nacheinander die
konvertierte Audiodatei heruntergeladen wird. Die Download-Anwendungen und mit ihnen die Middleware sind auf keinem der beiden Rechner zeitgleich aktiv.
In allen Versuchen des Experiments 5, Reihe 2 konnte auf beiden Knoten die konvertierte
Datei erfolgreich heruntergeladen werden. Das lässt den Schluss zu, dass das implementierte System die zeitliche Entkopplung korrekt umsetzt.
Die Aussage wird ebenfalls durch X5R1 untermauert. Allerdings müssen Einschränkungen gemacht werden. Der zweite Download konnte in einigen Fällen nicht korrekt abgeschlossen werden. Diese Probleme stehen jedoch in keinem Zusammenhang zur zeitlichen
Entkopplung. Bei den Versuchen X5R1/X5B, /X5F und /X5G musste der Versand der
Veröffentlichung auf der Verbindung zu dem zweiten Rechner (linutop2) wiederholt werden. Aufgrund eines Softwarefehlers schlug die Wiederholung fehl. Dieser Fehler wurde
bis zur Ausführung der Versuche X5R2 korrigiert. Die Situation in Versuch X5R1/X5O
wurden bereits in Abschnitt 6.1 beschrieben.
64
Datenmenge [Bytes]
0
500000
1000000
1500000
2000000
2500000
3000000
3500000
4000000
4500000
5000000
A
B
C
D
E
G
H
I
J
K
Versuch
Aufnahme (Nutzdaten)
Summe aller Daten (inkl. Kontrollnachrichten)
F
L
M
N
O
Q
R
S
gespeicherte Aufnahme (Nutzdaten)
konvertierte Aufnahme (Nutzdaten)
Effizienz (netto Soll : brutto Ist)
P
T
60 %
65 %
70 %
75 %
80 %
85 %
90 %
95 %
100 %
6. Auswertung
Abbildung 6.1.: Der Verwaltungsaufwand in Experiment 2, Reihe 2.
65
Effizienz
6. Auswertung
Es wurde weiterhin beobachtet, dass sich die Reaktionszeiten des Systems durch das
Caching von Veröffentlichungen verbessern. Der Konverter konnte sämtliche Publikationen, die von linutop2 abonniert wurden, aus dem Cache zustellen. Im Cache lag die
Veröffentlichung bereits vor, weil linutop diese zuvor abonniert hatte. Die gespeicherte
Aufnahme wurde daraufhin abonniert, übertragen, konvertiert, im Cache abgelegt und
an die Downloadanwendung auf linutop übertragen. In Abbildung 6.2 werden die Zeiten
zwischen Versand des Abonnements und dem Eingang der Veröffentlichung verglichen.
12000
Download auf linutop
Download auf linutop2
10000
Zeit [ms]
8000
6000
4000
2000
0
A
B
C
D
E
F
G
H
I
J
L
Versuch
M
N
O
P
Q
R
S
T
U
Abbildung 6.2.: Ein Vergleich der Downloadzeiten der konvertierten Audioaufnahme aus
X5R2. Durch den Einsatz des Caches für Veröffentlichungen konnte die
Übertragungszeit beim zweiten Download deutlich reduziert werden.
6.6. Alternative Übertragungswege
Das Routing von Nachrichten ist eine der Kernaufgaben von ASP. Um die (korrekte)
Funktionsweise des Routings zu ermitteln, wurde eine Vielzahl von Versuchen durchgeführt. In diesem Abschnitt werden die Ergebnisse der Versuche besprochen, die der
Middleware die Wahl zwischen unterschiedlichen Transportwegen ließen. In Abschnitt
6.9 werden die Ergebnisse von Versuchen beschrieben, die unterschiedlich leistungsstarke Prozessoren gegenüberstellen.
Die Experimente X1v1 und X1v2 untersuchen, ob das implementierte System Nachrichten korrekt und effizient transportiert. In X1v1R1 wurden Übertragungswege mit
unterschiedlichen Bandbreiten gegenübergestellt. X1v1R2 wurde durchgeführt, um das
Routing in Gegenwart von Störungen zu überprüfen. Die Middleware musste in X1v2R1
zwischen den beiden unterschiedlichen Netzwerktechniken WLAN und Bluetooth (siehe
Abschnitt 2.8.3 und 2.8.4) wählen.
Die Netzwerktopologie in den Versuchen X1v1R1 war so angelegt, dass der Download der
konvertierten Audiodatei über eine von zwei möglichen Verbindungen übertragen wer-
66
6. Auswertung
den musste. Beides waren WLAN-Verbindungen nach 802.11bg. Eine der beiden Verbindungen wurde während der Versuche mit einer festen Bitrate von 1 MBit/s, 11 MBit/s,
54 MBit/s oder mit automatischer Bitratenwahl betrieben, die andere durchgängig mit
automatischer Bitratenwahl. Durchsatzmessungen im Vorfeld der Versuche ergaben, dass
sich die erzielten Nettodatenraten bei 54 MBit/s nur geringfügig von denen bei automatischer Bitratenwahl unterschieden. Dies legt den Schluss nahe, dass bei automatischer
Bitratenwahl meistens 54 MBit/s verwendet wurden.
Vor diesem Hintergrund sind deshalb zunächst die Ergebnisse bei 1 und 11 MBit/s interessant. Es wurde eine Auswertung der Kosten vorgenommen, die die Metrik für Ankündigungen ermittelte, die bei dem Computer eingingen, auf dem der Download ausgeführt
wurde. Die durchschnittlichen Kosten der beiden alternativen Verbindungen wurden verglichen. Erwartungsgemäß sollte die Veröffentlichung auf der Verbindung transportiert
worden sein, die die niedrigsten Kosten hat. Hierzu ist anzumerken, dass es bei den
Versuchen bei 11 MBit/s einmal zum Verlust der Veröffentlichung kam. In allen anderen
Versuchen von X1R1 wurde die Veröffentlichung zugestellt.
Bei 1 MBit/s wählte die vorliegende Implementierung von ASP in 83 % der Versuche die
erwartete Route, bei 11 MBit/s waren es 85 %. Es gab zwei unterschiedliche Ursachen,
dass in Ausnahmefällen die vermeintlich langsamere Verbindung für die Übertragung
genutzt wurde. Der häufigere Grund war, dass Ankündigungen entlang der besseren
Verbindung (vorübergehend) überhaupt nicht oder zu spät eintrafen. Daraufhin wurde
die Route geändert und für den Rest des Versuchs beibehalten. Der andere Grund war,
dass eine der Verbindungen überhaupt nicht zustande kam oder in einer frühen Phase
des Experiments abbrach wie dies z.B. in Versuch X1v1R1@1M/X1I der Fall war. Hier
hat die Implementierung die einzige funktionierende Verbindung gewählt.
Tabelle 6.3 fasst die ermittelten durchschnittlichen Kosten über alle Versuche X1R1 zusammen. Es sind die Kosten der Pfade vom Speicher (Quelle) zum Download (Senke)
unter Einbeziehung des Konverters (Prozessor). Genauere Angaben können den Abbildungen B.6 bis B.9 im Anhang B.5 entnommen werden.
Aus der Tabelle geht hervor, dass sich die über linutop2 ermittelten Kosten in den Versuchen, bei denen linutop2 mit 54 MBit/s bzw. automatischer Bitratenwahl funkte, nur
minimal von den Werten entlang von linutop unterschieden. Umso überraschender ist es,
dass sich zum Beispiel bei den Versuchen mit 54 MBit/s in 10 von 12 Fällen die Route
über linutop durchsetzen konnte, die (immer) automatische Bitratenwahl nutzte. Zieht
man die Ergebnisse aus den Versuchen hinzu, in denen beide Verbindungen automatische Bitratenwahl verwendeten, zeichnet sich ab, dass die Verbindung über linutop im
Durchschnitt geringfügig besser eingeschätzt wurde.
Um die Ursache dieser Beobachtung zu klären, wurde für sämtliche Versuche aus X1R1
zusätzlich der Wert des Feldes TTL aus dem Nachrichtenkopf der Ankündigungen ausgewertet. Die Versuche bei 1 MBit/s und 11 MBit/s werden im folgenden nicht weiter
berücksichtigt, da sich die Kosten der beiden alternativen Routen erwartungsgemäß stark
unterscheiden. Mit Hilfe der TTL kann nachvollzogen werden, über wie viele Knoten eine
67
6. Auswertung
Nachricht bereits weitergeleitet wurde. Die Auswertung ergab die folgenden Beobachtungen. Bei 54 MBit/s sind die durchschnittlichen Kosten einer Route in 11 von 12 Fällen
dann geringer, wenn auch die Ankündigungen im Durchschnitt über weniger Knoten weitergeleitet wurden. Bei automatischer Bitratenwahl ist das Verhältnis 13 aus 17, wenn
man die Versuche unberücksichtigt lässt, in denen über linutop gar keine Ankündigungen
empfangen wurden. Tabelle 6.3 gibt die durchschnittliche Anzahl der Hops aller Ankündigungen des Downloads wieder. Es werden nur die Ankündigungen berücksichtigt, die
bei Enif eingingen.
Bitrate
bei linutop2
1 MBit/s
11 MBit/s
54 MBit/s
auto
Kosten Hops
via linutop
2900,31
2,6
2813,26
2,4
2752,62
2,3
2739,08
2,3
Kosten Hops
via linutop2
6363,26
2,5
3228,32
2,6
2752,66
2,6
2753,04
2,7
Tabelle 6.3.: Die durchschnittliche Kosten für die Übertragung der konvertierten Audiodatei in den Versuchen aus Experiment 1, Variante 1, Reihe 1. Daneben ist die
durchschnittliche Anzahl von Hops gegeben, die die entsprechenden Ankündigungen auf dem Weg zur Downloadanwendungen zurückgelegt haben.
Es wird vermutet, dass die Art und Weise mit der Ankündigungen im Netzwerk geflutet werden, die Hauptursache für die Unterschiede der Kosten der ansonsten nahezu
gleichwertigen Pfade ist. Jeder Broker leitet eine eingehende Ankündigung an alle Nachbarn mit Ausnahme des Absenders weiter. Eine einmal erhaltene Ankündigung wird
kein zweites Mal weitergeleitet. Die Weiterleitung an die Nachbarn erfolgt als Reihe
aufeinanderfolgender Unicasts. Dabei kann sich eine zeitliche Abfolge ergeben, wie sie in
Abbildung 6.3 dargestellt ist. Die erste Ankündigung, die b4 erhält, hat bereits drei Hops
zurückgelegt. Angenommen alle Verbindungen sind äquivalent in Bezug auf Bandbreite
und Latenz. Unter diesen Umständen hat die Metrik für die Ankündigung, die bei b4 zuerst eingeht, bereits höhere Kosten ermittelt als sie sie für die Übertragung von b1 zu b4
ermittelt. Im Ergebnis haben die Ankündigungen, die einen längeren Weg zurückgelegt
haben höhere Kosten.
Es wurden bereits Vorschläge gemacht, wie die Verbreitung von Ankündigungen weiter
optimiert werden kann [Ris09b]. Zusätzliche Optimierungen sind notwendig, damit sich
die Ankündigungen mit den niedrigsten Kosten ausbreiten und nicht jene, die lediglich
am schnellsten weitergeleitet werden.
Ein weiterer Erklärungsansatz ist, dass die Übertragungseigenschaften der Funkstrecke
zwischen linutop und Enif während der Versuche besser waren, als zwischen linutop2
und Enif. Anhand der vorliegenden Zahlen, kann darüber jedoch keine Aussage gemacht
werden. Die Versuche sind ungeeignet, die genauen (physikalischen) Übertragungseigenschaften der Verbindungen zu ermitteln.
68
6. Auswertung
b1
1.
b2
3.
2.
b4
5.
4.
b3
Abbildung 6.3.: Der Broker b1 verschickt eine Ankündigung. Gezeigt werden die ersten
fünf Schritte einer möglichen zeitlichen Abfolge bei der Verbreitung der
Nachrichten.
Obwohl die Routen über linutop häufig bevorzugt wurden, waren sie bei 54 MBit/s im
Durchschnitt nicht immer die günstigeren. Eine genauere Untersuchung der Versuche
X1R1@54M/X1C, /X1F, /X1G, /X1I und /X1L ergab, dass die gewählte Route unmittelbar vor Aktivierung eines Pfades die attraktivere war. Die Kosten der Routen über
linutop und linutop2 unterschieden sich zum entscheidenden Zeitpunkt dabei um weniger als ein Prozent. Bei automatischer Bitratenwahl auf beiden Verbindungen stellte
sich dieser Zustand nur zweimal ein (X1R1@auto/X1E, /X1G). In jedem Falle sind die
festgestellten Unterschiede der durchschnittlichen Kosten vergleichsweise gering.
Für das Routing in Gegenwart von unterschiedlich leistungsfähigen Verbindungen wird
festgehalten, dass die vorhandene Implementierung zuverlässig geeignete Routen wählt.
Nachrichten werden auf den besten verfügbaren Verbindungen übertragen. Sind zwei alternative Routen (nahezu) äquivalent, bevorzugte das System jedoch bestimmte Routen.
Es ist vorstellbar, dass dies in größeren Szenarien und bei höherem Datenaufkommen zu
Überlastung einzelner Verbindungen führen kann.
6.7. Gestörte Übertragungswege
In den Versuchen X1v1R2 wurde untersucht, wie sich das System verhält, wenn neben
einer intakten Route eine zweite, gestörte Route existiert. Im Laufe eines Versuchs musste
die Middleware eine der beiden Routen zur Übertragung nutzen. Aufbau und Ablauf
dieses Versuchs wurden bereits in Abschnitt 5.2.3 exemplarisch vorgestellt.
Die Versuche wurden in mehreren Gruppen wiederholt. Eine der beiden Funkverbindungen zwischen dem Rechner, an dem der Download ausgeführt wurde und dem Rest
des Netzwerks wurde nicht gestört. Die andere Verbindung wurde gezielt gestört. In regelmäßigen Intervallen wurde die Verbindung kurzzeitig deaktiviert. Die Versuche wurden so ausgeführt, dass die gestörte Verbindung 80 % der Zeit, 90 % und zum Vergleich
auch 100 % der Zeit aktiv und damit ungestört war. Die Rollen der gestörten und ungestörten Verbindung wurden getauscht. Bei den insgesamt 59 ausgeführten Versuchen
69
6. Auswertung
dieses Experiments konnte der konvertierte Audiomitschnitt dreimal nicht erfolgreich
zugestellt werden. Jeder dieser Verluste von Veröffentlichungen trat in Versuchen auf,
bei denen die gezielten Störungen am stärksten waren.
Wie beispielsweise dem Diagramm in Abb. B.10 (im Anhang) gut zu entnehmen ist,
spricht die Metrik gut auf die gestörten Verbindungen an. Das bedeutet, dass die Kosten
entlang der gestörten Verbindung höher sind als die Kosten, die für die Übertragung über
die ungestörte Verbindung ermittelt wurden. Zum Vergleich zeigt Abb. B.11 die gemessenen Kosten derselben Anordnung ohne die künstlichen Störungen. Da die Messungen
der Verlustrate periodisch ausgeführt werden, ist es möglich, dass nicht jede Störung erkannt wird. Tritt eine der Auszeiten zwischen zwei Messungen auf und finden in diesem
Zeitraum keine anderen Übertragungen statt, ist die implementierte Middleware nicht
in der Lage, die Störung zu erkennen.
In 54 von 59 Versuchen (92 %) hat die Middleware für die Übertragung diejenige Verbindung gewählt, die durchschnittlich die niedrigeren Kosten aufwies. Bei fünf Übertragungen wurde die gestörte Verbindung ausgewählt. Jede dieser fünf gestörten Routen
wurde zum Zeitpunkt der Aktivierung des Pfades als die bessere eingeschätzt. Das bedeutet, dass die Störungen bis zu diesem Zeitpunkt nicht erkannt worden sind. Da die
durchschnittlich für diese Verbindungen ermittelten Kosten jedoch über denen der ungestörten Verbindungen lagen, bedeutet dies, dass die Störungen bis zum Ende jedes der
Versuche noch erkannt wurden.
Zusammenfassend lassen die Ergebnisse die Aussage zu, dass die vorliegende Implementierung in der Lage ist, bei erkannten Störungen auf andere, ungestörte Routen
auszuweichen.
6.8. Alternative Übertragungstechniken
In einer Variante des Experiments 1 wurde erneut der Rechner, auf dem der Download
der Aufzeichnung stattfinden sollte, über zwei Verbindungen mit dem Rest des Netzwerks verbunden. Eine Verbindung wurde über WLAN hergestellt, die andere mittels
Bluetooth.
In jedem der Versuche konnte die Veröffentlichung übertragen werden. Einmal wurde
dafür die Verbindung über Bluetooth genutzt. In allen anderen Fällen wurde die WLANVerbindung genutzt. Das deckt sich mit den Erwartungen. Die WLAN-Verbindung hat
eine höhere Bandbreite. In vorbereitenden Tests wies sie zudem eine geringere Übertragungslatenz auf. Im Versuch X1v2R1/X1E, bei dem die Veröffentlichung über Bluetooth
übertragen wurde, riss die WLAN-Verbindung ab und konnte bis zum Ende des Versuchs
nicht wieder aufgebaut werden. Über die WLAN-Verbindung konnte bis zum Ausfall
nur eine einzige Ankündigung des konvertierten Audiomitschnitts übertragen werden.
Danach wurden keine weiteren Ankündigungen mehr auf diesem Wege zugestellt. Die
Route über die Bluetooth-Verbindung war somit zum Zeitpunkt des Abonnements der
einzige verfügbare Weg.
70
6. Auswertung
Eine weitere Beobachtung wurde bei der Auswertung der Zahlen aus X1v2R1 gemacht.
Insbesondere zu Beginn der Versuche, also noch während der Wartezeit bevor das Abonnement des Audiomitschnitts ausgelöst wurde, traten entlang der WLAN-Verbindung
häufige Verbindungsverluste auf. Dies führte dazu, dass die von der Metrik ermittelten
durchschnittlichen Kosten für die Route entlang der WLAN-Verbindung von Versuch zu
Versuch deutlich schwanken.
Eine erste Vermutung dazu war, dass die Bluetooth-Übertragungen bzw. die Übertragungsversuche die WLAN-Verbindung beeinträchtigen würden. Dazu wurde ein getrenntes Experiment durchgeführt. ASP und die Middleware spielten dabei keine Rolle. Es
ging lediglich darum zu ermitteln, ob es im verwendeten Versuchsaufbau einen signifikanten Zusammenhang zwischen den Bluetooth-Aktivitäten und der WLAN-Verbindung
gab. Diese Vermutung konnte deutlich bestätigt werden. Im Experiment sendete ein Linutop über ein Ad-Hoc-WLAN regelmäßig ICMP-Echo-Requests (ping; siehe [Pos81])
an einen zweiten Linutop, der zusätzlich mit einem Bluetooth-Adapter ausgestattet war.
Auf dem zweiten Gerät wurde ein Skript aktiviert, dass in regelmäßigen Abständen zwanzig Inquiry Scans ausführte. Im Protokoll der ICMP-Antwortzeiten sind diese Scans klar
wiederzuerkennen (siehe Grafik 6.4). Die genauen Umstände dieser Wechselwirkungen
wurden nicht untersucht. Für die Versuche aus X1v2R1 war es ausreichend zu wissen,
dass eine solche negative Wirkung von Bluetooth auf die WLAN-Verbindung existierte.
25
ICMP Echo Antwortzeit
Zeit [ms]
20
15
10
5
0
0
100
200
300
ICMP Sequenznummer
400
500
Abbildung 6.4.: Bluetooth Inquiry Scans stören in der Versuchsumgebung den Datenaustausch über WLAN – erkennbar an den 20 ausgeprägten Lücken.
Als Ergebnis des Experiments X1v2R2 wird festgehalten, dass die implementierte Middleware korrekt zwischen den verfügbaren Übertragungstechniken wählt. Die leistungsfähigste Technik kommt zum Einsatz und die Metrik bildet die Grundlage dieser Entscheidung. Im Übrigen ist die Übertragungstechnik für die Anwendungen, die die Middleware
nutzen, transparent.
6.9. Alternative Prozessoren
Die Versuche zu Experiment 2 beschäftigten sich ausführlich mit dem Routing entlang
unterschiedlicher Verbindungen. In diesem Abschnitt werden die Ergebnisse aus Expe-
71
6. Auswertung
riment 3 diskutiert. Die Versuchsskizze ist auf Seite 82. Ziel der Versuche dieses Experiments war es, das Verhalten zu untersuchen, wenn mehrere Prozessoren zur Verfügung
stehen. Die Rolle des Konverters, wie sie im Szenario auftritt (siehe Abschnitt 3.3.1)
wird dabei von mehr als nur einer Anwendung übernommen. Die Anwendungen werden
auf unterschiedlichen Computern ausgeführt, die je nach Variante über unterschiedlich
oder gleich leistungsfähige Hardware verfügen.
Damit allein die Leistungsfähigkeit der Prozessoren über die Wahl der Route entscheidet,
wurde der Einfluss der Netzwerkanbindung in den Versuchen so weit wie möglich minimiert. Zu diesem Zweck waren alle der vier Rechner, die in Experiment 3 zum Einsatz
kamen in einem IP-Subnetz verbunden. Alle hatten eine Fast-Ethernet-Verbindung zu
einem gemeinsamen Switch. Als Plattform kamen auf drei der vier Rechner Linux und
auf dem vierten Mac OS X zum Einsatz.
In Variante 1 von Experiment 3 wurden zwei Linutops mit baugleicher Hardware als Prozessoren verwendet. Auch die Softwareausstattung war identisch. Da die Betriebsbedingungen der beiden Prozessoren identisch waren, war zu erwarten, dass die Konvertierung
über alle Versuche gesehen zwischen beiden Linutops gleichverteilt ist. Die Auswertung
hat jedoch ein Verhältnis von ungefähr 2:1 zu Gunsten von linutop1 ergeben. Das heißt,
linutop1 hat bei zwei Dritteln der Versuche die Konvertierung übernommen. Der Versuchsablauf wurde daraufhin leicht abgewandelt, um die Diskrepanz von Erwartung und
beobachtetem Ergebnis aufzuklären. Bei Reihe 1 wurden die beiden Prozessoren unmittelbar nacheinander mit einer geringen Verzögerung gestartet. In den Versuchen der
Reihen X3v1R2 und X3v1R3 wurde zwischen dem Start des einen Prozessors und dem
Start des zweiten Prozessors 30 s gewartet. Bei Reihe 2 wurde linutop zuerst gestartet, bei Reihe 3 linutop2. Das Ergebnis ist eindeutig. Es kam immer der Prozessor zum
Einsatz, der zuerst gestartet wurde.
In Variante 2 des Experiments wurden die Prozessoren von Anfang an mit zeitlichem
Versatz gestartet. In Variante 2 waren die Prozessoren unterschiedlich leistungsstark.
Für den leistungsstärkeren wurde beim Umwandeln einer Referenzaudiodatei ein Geschwindigkeitsfaktor von 6,3 ermittelt und für den schwächeren 0,9. Gleichzeitig sind
dies die Zahlen, die der jeweiligen Konverteranwendung als Berechnungsgrundlage für
die Abschätzung des Aufwands der Konvertierung dienten. Die Auswertung der Logdateien der Middleware aus den Versuchen X3v2R1 bis X3v2R3 ergab dasselbe Resultat
wie zuvor in Variante 1 von Experiment 3. Es kam immer derjenige Prozessor zum Einsatz, der früher gestartet wurde. Dies galt auch dann, wenn der leistungsschwächere
zuerst gestartet wurde.
Die Ursache dieses Effekts konnte anhand der erfassten Protokolle gefunden werden.
Sie kann jedoch auch unabhängig davon theoretisch mit der Funktionsweise der implementierten Middleware begründet werden. Die Verlängerung von Ankündigungen ist ein
Mechanismus, der vorgesehen ist, um aktive Pfade aufrechtzuerhalten. Verlängert ein
Broker die Gültigkeit einer Ankündigung mit einer Folgeankündigung, müssen interessierte Subscriber den Pfad mit einem erneuten Abonnement reaktivieren. Bleibt das
Abonnement aus, weil die Verbindung des Subscribers zum Rest des Netzwerks abgebro-
72
6. Auswertung
chen ist oder ein Broker abgestürzt ist, wird der Pfad verworfen. Folgeankündigungen
können von Duplikaten oder alten Ankündigungen an ihrer fortlaufenden Sequenznummer im Kopf der Nachrichten unterschieden werden. Kündigen mehrere Prozessoren
Veröffentlichungen derselben ASP ID an, und verlängern sie ihre Ankündigungen im selben Intervall – was bei den Versuchen der Fall war – setzen sich die Ankündigungen des
Prozessors bzw. seines Brokers durch, der die höchsten Sequenznummern verwendet. Das
ist in der Regel der Broker, der am längsten aktiv ist. Verwendet einer der Prozessoren
ein kürzeres Intervall, wird er sich auf Dauer auch dann durchsetzen, wenn er nicht seit
längstem aktiv ist.
Die Versuche zeigen, dass dieses Fehlverhalten in der angefertigten Implementierung
auftritt. Das vorliegende System eignet sich deshalb nur unter Einschränkungen für den
gleichzeitigen Betrieb mehrerer identischer Prozessoranwendungen. Verwenden alle Prozessoren unterschiedliche ASP IDs, kann das Problem beim parallelen Betrieb mehrerer
Prozessoren nicht auftreten. Bei Verwendung identischer IDs handelt es sich jedoch um
ein grundsätzliches Problem. Das Verhalten eines ASP-Systems unter diesen Umständen
wurde bislang weder ausgeschlossen, noch spezifiziert. Da es grundsätzlich gewünscht ist,
dass mehrere alternative Prozessoren zum Verarbeiten einer Veröffentlichung existieren,
kann das Problem nicht durch entsprechende Vorgaben ausgeschlossen werden. Der geschilderte Fall muss demnach spezifiziert werden. Dies wird an dieser Stelle jedoch nicht
vorgenommen, da es nicht Bestandteil einer Evaluierung ist.
73
In diesem Kapitel wird die Arbeit zunächst zusammengefasst. In einem weiteren Abschnitt wird ein Ausblick auf mögliche zukünftige Entwicklungen und Untersuchungsschwerpunkte gegeben.
7.1. Zusammenfassung
In dieser Arbeit wurde mit Announcement/Subscription/Publication (ASP) ein System
untersucht, das die Kommunikation mittels Publish/Subscribe in heterogenen Netzwerken ermöglicht.
Erstmals wurde auf Grundlage von ASP eine Kommunikationsmiddleware für den Einsatz in einem realen Umfeld implementiert. Offene Fragen des Ansatzes, die im Vorfeld der Implementierung zu klären waren, wurden erläutert. In einem sehr heterogenen
Umfeld ist das Szenario angesiedelt, in dem das implementierte System geprüft wurde.
Dazu wurden die Konzepte von ASP auf das Szenario abgebildet. Aus dem Szenario
wurden gezielt Experimente abgeleitet, um die zentralen Eigenschaften von ASP in einer definierten Umgebung praktisch zu erproben. In über 200 Einzelversuchen wurde
das implementierte System getestet.
Die Auswertung der Testergebnisse ergab, dass die konkrete ASP-Middleware in der Lage
war, die große Mehrheit der Anforderungen zu erfüllen. Das entwickelte System konnte
erfolgreich die räumliche und zeitliche Entkopplung moderner Publish-Subscribe-Systeme demonstrieren. In allen Versuchen kam die Middleware auf mehreren Plattformen
erfolgreich zum Einsatz. Auch unterschiedliche Verbindungstechniken bereiteten dem
System keine Schwierigkeiten. Die semantische Entkopplung, die ein hervorstechendes
Merkmal von ASP ist, konnte ebenso gezeigt werden. Das Routing in Gegenwart unterschiedlicher Prozessoren funktionierte grundsätzlich. Für die Datenverarbeitung wurde
lediglich nicht immer das leistungsfähigste Gerät ausgewählt. Dieser Fall wurde bislang
noch nicht vollständig spezifiziert.
Aus den Versuchen ging zudem hervor, dass das implementierte System die vorhandenen
Ressourcen in dem heterogenen Versuchsumfeld effizient nutzt. Der Verwaltungsaufwand
ist gering. Auch mit Störungen, wie sie in den Versuchen erzeugt wurden, konnte das
System gut umgehen.
74
7.2. Ausblick
Es existieren unterschiedliche Ansätze das Konzept von ASP zu erweitern und weiter
zu optimieren. Es ist vielversprechend, besonders die Verbreitung von Ankündigungen
und die genauere Ermittlung aller Pfade und ihrer Kosten gegenüber dem verwendeten
Prototyp weiter auszubauen. Wegen der vielen Möglichkeiten, diese Aufgabe zu lösen,
empfehlen sich Simulationen, um die erfolgversprechendsten Ansätze zu identifizieren.
Die gefundenen Ansätze können dann in einem nächsten Schritt in der Praxis erprobt
werden.
Während der Entwicklung der Software und der Durchführung der Tests, stellte sich
die wichtige Rolle des Caching heraus. In den Versuchen wurde eine einfache CachingStrategie verwendet, die mit vertretbarem Aufwand implementiert werden konnte. Sowohl bei der Verteilung der Caches als auch beim Zugriff auf die Inhalte der Caches wird
weiteres Potenzial zur Effizienzsteigerung vermutet. Redundante Übertragungen sollten
sich weiter reduzieren lassen.
Mit Blick auf Dienstgütemerkmale wie die Latenz oder den Verlust von Nachrichten kann
den existierenden Übertragungskategorien in Zukunft eine wichtigere Rolle zukommen.
Die Möglichkeit die gewünschte Dienstgüte flexibel zu konfigurieren, kann dem Konzept
von ASP weitere Anwendungsbereiche erschließen.
Zu den Untersuchungsaspekten, die bislang nicht berücksichtigt werden konnten, gehört
die Evaluation größerer Netzwerke. Das Verhalten des Systems in realen Netzwerken mit
mehreren Dutzend Teilnehmern wurde nicht untersucht. Im Rahmen dieser Arbeit konnte dieser spannenden Frage mit den vorhandenen Mitteln nicht nachgegangen werden.
Aus demselben Grund konnte das Verhalten des Systems in Verbindung mit mobilen
Knoten bislang nicht getestet werden. Mit WLAN und Bluetooth unterstützt die erstellte Software jedoch bereits grundsätzlich Verbindungstechniken, die sich für die spontane
Vernetzung in einem mobilen Umfeld nutzen lassen.
Nicht zuletzt ist es eine interessante Aufgabe, die Middleware auf einer noch breiteren Basis von Plattformen und Endgeräten zum Einsatz zu bringen. Auch weitere
Übertragungstechnologien wie das bereits eingangs genannte ZigBee können in Zukunft
erschlossen werden. Auf diese Weise lässt sich prüfen, ob ASP für den Einsatz in Sensornetzen angepasst werden kann.
75
P
TTL
2
1
1
ID
METRIC
VALIDITY
SEQUENCE
PAYLOAD
≥ 33
1
1
16
8
4
2
≥1
ID
SUBSCRIBERID
METRIC
34
1
1
16
8
8
ID
SEQUENCE
PAYLOADSIZE
OFFSET
PAYLOAD
COMMON
Feldgröße in Byte und -bedeutung
TYPE
Nachrichtentyp
≥ 29
1
1
16
2
4
4
≥1
ANNOUNCEMENT
SUBSCRIPTION,
UNSUBSCRIPTION,
BROKENPATH
PUBLICATION
Tabelle A.1.: Das in der Implementierung verwendete Nachrichtenformat.
76
B. Versuche
B. Versuche
B.1. Namensschema
Die Benennung der Versuche folgt einem bestimmten Schema. Mit diesem Schema lassen
sich einzelne Versuche oder Versuchsreihen bis hin zu kompletten Experimenten sehr
kompakt bezeichnen. Die Ordnerstruktur, in der die Messergebnisse auf dem Datenträger
gespeichert sind, orientiert sich ebenfalls an diesem Schema.
Die Bezeichnung eines Versuchs setzt sich aus der Nummer des Experiments, der Nummer der Variante, der Nummer der Versuchsreihe mit einem optionalen Namenszusatz
und dem Bezeichner des Versuchs zusammen. Der Bezeichner identifiziert einen Versuch
innerhalb einer Versuchsreihe.
Die Kürzel, mit denen Versuche bezeichnet werden, entsprechen dem folgenden regulären
Ausdruck1 X[0-9]+(v[0-9]+)?R[0-9]+(@.+)?/.+
Die erste Zahl bezeichnet das Experiment. Die zweite Zahl nach dem Buchstaben v identifiziert die Variante und die Zahl nach dem R identifiziert die Versuchsreihe. Die Angabe
einer Variante ist optional, denn nicht alle Experimente liegen in unterschiedlichen Varianten vor. Ist keine Variante angegeben, ist Variante 1 gemeint. Der Namenszusatz
beginnend mit dem Zeichen @ ist optional und kommt nur vor, falls eine Versuchsreihe
weiter unterteilt wurde.
Zwei Beispiele veranschaulichen das Schema. X5R2/X5O bezeichnet den Versuch X5O
aus Versuchsreihe 2 des Experiments 5. X3v2R1/X3A bezeichnet Versuch X3A aus Experiment 3, Variante 2, Reihe 1.
Im Text wird manchmal eine verkürzende Schreibweise verwendet. So bezeichnet X3v2R1
alle Versuche der Reihe 1. X3v2 bezeichnet alle Versuche aller Reihen von Experiment
3 Variante 2.
B.2. Übersicht der Experimente
Die Tabelle B.1 auf Seite 78 listet die durchgeführten Versuchsreihen auf.
1
Es wird Perl-kompatible Syntax verwendet. Siehe [Vro02].
77
1
1
2
1
1
1
1
1
2
2
2
1
1
Reihe
1
2
1
1
2
1
2
3
1
2
3
1
2
Software
1781
1793
1799
1763
1820
1805
1805
1805
1805
1805
1808
1808
1816
57
59
12
10
20
25
10
10
15
15
15
16
21
Versuche
Experiment
Tabelle B.1.: Übersicht der durchgeführten Experimente mit Softwareversion und Anzahl der ausgeführten Versuche. Versuche, die
verworfen wurden, wurden bei der Auswertung zu keinem Zeitpunkt berücksichtigt.
Variante
1
1
1
2
2
3
3
3
3
3
3
5
5
Erläuterung
unterschiedliche Übertragungsraten im WLAN
unterschiedliche Duty Cycles (Störungen)
Bluetooth gegen WLAN
Verwaltungsaufwand – komplett verworfen
Verwaltungsaufwand
identische Prozessoren
identische Prozessoren – einer startet deutlich früher
identische Prozessoren – der andere startet deutlich früher
unterschiedliche Prozessoren – schwächerer startet deutlich früher
unterschiedliche Prozessoren – stärkerer startet deutlich früher
unterschiedliche Prozessoren – schwächerer startet deutlich früher
zeitliche Entkopplung
zeitliche Entkopplung – Versuch X5K verworfen
B. Versuche
78
B. Versuche
B.3. Versuchsaufbau
Die Grafiken auf den Seiten 80 bis 82 stellen den Versuchsaufbau dar. Abbildung B.1
zeigt die Legende.
ein Linutop
virtuelles
System
Notebook
Desktop
Hostname
Anwendung
IP
Bt
Subnetz (IP) /
Verbindungstechnik (Bt, Bluetooth)
Ethernet
WLAN im Infrastruktur-Modus
WLAN im Ad-Hoc-Modus
Bluetooth
direkte Verbindung möglich
keine direkte Verbindung
IP
IPn
Bt
IP1
IPx
Bt
IP
IPn
Bt
IP2
IPy
IP2
IP
IP
IP
IP
IP
IP
IP
IP
vereinfacht
Abbildung B.1.: Legende der Versuchsskizzen.
79
B. Versuche
Ethernet
debian
Speicher
Kajam
Konverter
IP1
IP1
Ad-Hoc
linutop
Dummy
Ad-Hoc
linutop2
Dummy
Enif
Download
IP1 IP2
IP1 IP2
IP2
(a) Variante 1
Ethernet
debian
Speicher
Kajam
Konverter
IP1
IP1
Ad-Hoc
linutopk
Dummy
IP1 IP2
Bluetooth
linutop2
Download
IP2
linutop
Dummy
Bt
IP1
Bt
(b) Variante 2
Abbildung B.2.: Versuchsaufbau von Experiment 1.
80
B. Versuche
Eth.
Inf.
Enif
Konverter
debian
Speicher
linutopk
Rekorder
IP1 IP2
IP1
IP1
Ad-Hoc
linutop2
Download
IP2
Inf.
Inf.
linutopk
Rekorder
debian
Speicher
Enif
Dummy
IP1
IP1
IP1
Ad-Hoc
linutop2
Download
IP2
IP3
Ethernet
Hyadum-II
Konverter
linutop
Download
IP3
IP2 IP3
81
B. Versuche
Ethernet
linutop
Konverter
Ethernet
debian
Speicher
IP
linutop2
Konverter
IP
IP
Ethernet
Ethernet
Enif
Download
IP
(a) Variante 1
Ethernet
linutop
Konverter
Ethernet
debian
Speicher
IP
IP
Ethernet
Enif
Konverter
IP
Ethernet
linutop2
Download
IP
(b) Variante 2
82
B. Versuche
B.4. Hard- und Softwarespezifikationen
Die Tabellen B.2, B.3 und B.4 geben Auskunft über die in den Versuchen genutzte Hardund Software. Das System debian wurde virtualisiert. Das Wirtssystem war Kajam.
Hostname
debian
Betriebssystem
Debian Linux 5.0
Enif
Mac OS X 10.4.11
Hyadum-II
openSUSE 11.1
Kajam
Windows Vista Home
Premium 64 Bit, SP 2
Ubuntu 9.04 Server
linutopX
Java Laufzeitumgebung
OpenJDK Runtime Environment (build 1.6.0 0-b11)
Java(TM) 2 Runtime Environment, Standard Edition
(build 1.5.0 19-b02-306)
OpenJDK Runtime Environment (IcedTea6 1.6.2) (suse0.1.1-i386)
Java(TM) SE Runtime Environment (build 1.6.0 17-b04)
OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b141.4.1-0ubuntu12)
Arbeitsspeicher [MB]
Prozessor
Intel Core 2 Duo CPU E8400
PowerPC G4
AMD Athlon XP 2000+
Intel Core 2 Duo CPU E8400
AMD Geode LX700
Taktfrequenz [MHz]
Hostname
debian
Enif
Hyadum-II
Kajam
linutopX
Prozessorkerne
Tabelle B.2.: Übersicht der Versuchsrechner und ihrer Softwareausstattung.
1
1
1
2
1
3.000
1.200
1.666
3.000
433
1536
768
1024
8192
256
Tabelle B.3.: Übersicht der Versuchsrechner und die Eckdaten ihrer Hardwareausstattung.
83
B. Versuche
Handelsmarke
Hama
Produkt
TP-Link
WLAN
USBStick (802.11g)
TL-WN321G
Anycom
USB-200
MSI
Star Key 3.0
MSI
BToes EDR Micro Dongle
Bluetooth V2.0
Dongle
Vivanco
Bezeichnung
unter
Linux
(lsusb)
Ralink
Technology,
Corp.
RT2501USB Wireless Adapter
Ralink
Technology,
Corp.
RT2501USB Wireless Adapter
Broadcom
Corp.
Bluetooth
2.0+EDR dongle
Integrated System Solution Corp.
KY-BT100 Bluetooth Adapter
Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Tabelle B.4.: Übersicht der externen Netzwerkperipherie.
B.5. Ausgewählte Diagramme
Einige ausgewählte Diagramme, die die Auswertung der Versuche veranschaulichen, befinden sich auf den Seiten 85 bis 87.
84
B. Versuche
7000
Ankündigungen via linutop
Ankündigungen via linutop2
6500
6000
Kosten
5500
5000
4500
4000
3500
3000
2500
A
B
C
D
E
F
G
Versuch
H
I
J
K
L
Abbildung B.6.: Durchschnittliche Kosten eingehender Ankündigungen des Downloads
am Download-Rechner in den Versuchen X1v1R1@1M. Die Verbindung
über linutop2 ist auf 1 MBit/s gedrosselt.
3500
3400
3300
3200
Kosten
3100
3000
2900
2800
2700
2600
2500
A
B
C
D
E
F
G
Versuch
H
I
J
K
L
M
85
B. Versuche
3500
3400
3300
3200
Kosten
3100
3000
2900
2800
2700
2600
2500
A
B
C
D
E
F
G
Versuch
H
I
J
K
L
3500
3400
3300
3200
Kosten
3100
3000
2900
2800
2700
2600
2500
A
B
C
D
E
F
G
H
I
J
K
Versuch
L
M
N
O
P
Q
R
S
T
am Download-Rechner in den Versuchen X1v1R1@auto. Die Verbindung
über linutop2 verwendet automatische Bitratenwahl.
86
B. Versuche
4000
3800
3600
Kosten
3400
3200
3000
2800
2600
A
B
C
D
E
F
G
Versuch
H
I
J
K
L
am Download-Rechner in den Versuchen X1v1R2@dc80a. Die Verbindung über linutop ist nur 80 % der Zeit aktiv.
4000
3800
3600
Kosten
3400
3200
3000
2800
2600
A
B
C
D
E
F
Versuch
G
H
I
J
K
am Download-Rechner in den Versuchen X1v1R2@dc100. Beide Verbindungen sind zu 100 % aktiv.
87
[AADH05] Aldred, Lachlan ; Aalst, Wil M. d. ; Dumas, Marlon ; Hofstede, Arthur H.: On the Notion of Coupling in Communication Middleware. In: On
the Move to Meaningful Internet Systems 2005: CoopIS, DOA, and ODBASE Bd. 3761, Springer, 2005, S. 1015–1033
[AHR06]
Awerbuch, Baruch ; Holmer, David ; Rubens, Herbert: The Medium
Time Metric: High Throughput Route Selection in Multi-rate Ad Hoc Wireless Networks. In: Mobile Networks and Applications 11 (2006), Apr, Nr.
2, S. 253–266
[AKM07]
Aitenbichler, Erwin ; Kangasharju, Jussi ; Mühlhäuser, Max: MundoCore: A light-weight Infrastructure for Pervasive Computing. In: Pervasive and Mobile Computing 3 (2007), Nr. 4, S. 332–361. – Middleware for
Pervasive Computing
[BCM+ 99] Banavar, G. ; Chandra, T. ; Mukherjee, B. ; Nagarajarao, J.
; Strom, R.E. ; Sturman, D.C.: An Efficient Multicast Protocol for
Content-Based Publish-Subscribe Systems. In: Distributed Computing Systems, 1999. Proceedings. 19th IEEE International Conference on, 1999, S.
262–272
[Blu07]
Bluetooth SIG: Bluetooth Core Specification v2.1 + EDR. http://www.
bluetooth.com/Bluetooth/Technology/Building/Specifications/.
Version: Jul 2007. – Abruf: 25.1.2010
[Blu09a]
Bluetooth SIG: Bluetooth Technology Gets Faster With Bluetooth 3.0.
Pressemitteilung.
http://www.bluetooth.com/Bluetooth/Press/SIG/
iBLUETOOTHi_TECHNOLOGY_GETS_FASTER_WITH_iBLUETOOTHi_30.htm.
Version: Apr 2009. – Abruf: 17.1.2010
[Blu09b]
Bluetooth SIG:
SIG Introduces Bluetooth Low Energy Wireless
Technology, the Next Generation of Bluetooth Wireless Technology. Pressemitteilung. http://www.bluetooth.com/Bluetooth/Press/SIG/SIG_
INTRODUCES_BLUETOOTH_LOW_ENERGY_WIRELESS_TECHNOLOGY_THE_NEXT_
GENERATION_OF_BLUETOOTH_WIRELESS_TE.htm.
Version: Dez 2009. –
Abruf: 17.1.2010
[BM06]
Breymann, Ulrich ; Mosemann, Heiko: Java ME : Anwendungsentwicklung für Handys, PDA und Co. München : Hanser, 2006
88
[BRS02]
Bharambe, Ashwin R. ; Rao, Sanjay ; Seshan, Srinivasan: Mercury: A
Scalable Publish-Subscribe System for Internet Games. In: NetGames ’02:
Proceedings of the 1st workshop on Network and system support for games.
New York, NY, USA : ACM, 2002, S. 3–9
[BSB+ 02]
Bhola, S. ; Strom, R. ; Bagchi, S. ; Zhao, Yuanyuan ; Auerbach, J.:
Exactly-once Delivery in a Content-based Publish-Subscribe System. In:
Dependable Systems and Networks, 2002. DSN 2002. Proceedings. International Conference on, 2002, S. 7–16
[CEM+ 08] Campista, Miguel Elias M. ; Esposito, Pedro M. ; Moraes, Igor M.
; Costa, Luı́s Henrique M. K. ; Duarte, Otto Carlos M. B. ; Passos,
Diego G. ; Albuquerque, Célio Vinicius N. ; Saade, Débora Christina M.
; Rubinstein, Marcelo G.: Routing Metrics and Protocols for Wireless
Mesh Networks. In: IEEE Network 22 (2008), Nr. 1, S. 6–12
[CJ02]
Cugola, Gianpaolo ; Jacobsen, H.-Arno: Using Publish/Subscribe
Middleware for Mobile Systems. In: SIGMOBILE Mob. Comput. Commun.
Rev. 6 (2002), Nr. 4, S. 25–33
[CJ03]
Clausen, T. ; Jacquet, P.: Optimized Link State Routing Protocol
(OLSR). RFC 3626 (Experimental). http://www.ietf.org/rfc/rfc3626.
txt. Version: Oktober 2003 (Request for Comments)
[Com00]
Comer, Douglas E.: Internetworking With TCP/IP. Bd. 1. Principles,
Protocols and Architecture. 4. Auflage. Upper Saddle River, New Jersey,
USA : Prentice Hall, 2000
[CRW00]
Carzaniga, Antonio ; Rosenblum, David S. ; Wolf, Alexander L.: Achieving Scalability and Expressiveness in an Internet-Scale Event Notification
Service. In: PODC ’00: Proceedings of the nineteenth annual ACM symposium on Principles of distributed computing. New York, NY, USA : ACM,
2000, S. 219–227
[CRW04]
Carzaniga, A. ; Rutherford, M.J. ; Wolf, A.L.: A Routing Scheme
for Content-Based Networking. In: INFOCOM 2004. Twenty-third Annual Joint Conference of the IEEE Computer and Communications Societies
Bd. 2, 2004, S. 918–928
[CS04]
Cao, Fengyun ; Singh, J.P.: Efficient Event Routing in Content-based
Publish-Subscribe Service Networks. In: INFOCOM 2004. Twenty-third
Annual Joint Conference of the IEEE Computer and Communications Societies Bd. 2, 2004, S. 929–940
[DABM05] De Couto, Douglas S. J. ; Aguayo, Daniel ; Bicket, John ; Morris,
Robert: A High-Throughput Path Metric for Multi-Hop Wireless Routing.
In: Wireless Networks 11 (2005), Jul, Nr. 4, S. 419–434
89
[DPZ04]
Draves, Richard ; Padhye, Jitendra ; Zill, Brian: Routing in Multi-Radio,
Multi-Hop Wireless Mesh Networks. In: MobiCom ’04: Proceedings of the
10th annual international conference on Mobile computing and networking.
New York, NY, USA : ACM, 2004, S. 114–128
[EFGK03]
Eugster, Patrick T. ; Felber, Pascal A. ; Guerraoui, Rachid ; Kermarrec, Anne-Marie: The Many Faces of Publish/Subscribe. In: ACM
Comput. Surv. 35 (2003), Jun, Nr. 2, S. 114–131
[FGKZ03]
Fiege, Ludger ; Gärtner, Felix C. ; Kasten, Oliver ; Zeidler, Andreas:
Supporting Mobility in Content-Based Publish/Subscribe Middleware. In:
Middleware 2003 Bd. 2672, Springer, 2003, S. 103–122
[FLYV93]
Fuller, V. ; Li, T. ; Yu, J. ; Varadhan, K.: Classless Inter-Domain
Routing (CIDR): an Address Assignment and Aggregation Strategy. RFC
1519 (Proposed Standard).
http://www.ietf.org/rfc/rfc1519.txt.
Version: September 1993 (Request for Comments). – Obsoleted by RFC
4632
[HBS+ 02]
Hapner, Mark ; Burridge, Rich ; Sharma, Rahul ; Fialli, Joseph ;
Stout, Kate: Java Message Service Specification. http://java.sun.com/
products/jms/docs.html. Version: 1.1, 2002
[HGM04]
Huang, Yongqiang ; Garcia-Molina, Hector: Publish/Subscribe in a
Mobile Environment. In: Wireless Networks 10 (2004), Nov, Nr. 6, S. 643–
652
[JLZZ07]
Jiang, Weirong ; Liu, Shuping ; Zhu, Yun ; Zhang, Zhiming: Optimizing
Routing Metrics for Large-Scale Multi-Radio Mesh Networks. In: Wireless
Communications, Networking and Mobile Computing, 2007. WiCom 2007.
International Conference on, IEEE, 2007, S. 1550–1553
[Lüd07]
Lüders, Christian: Lokale Funknetze : Wireless LANs (IEE 802.11), Bluetooth, DECT. 1. Auflage. Würzburg : Vogel Buchverlag, 2007
[MC02]
Meier, René ; Cahill, Vinny: STEAM: Event-Based Middleware for Wireless Ad Hoc Networks. In: Distributed Computing Systems Workshops,
International Conference on. Los Alamitos, CA, USA : IEEE Computer
Society, 2002, S. 639
[Mot08]
Motorola: Java APIs for Bluetooth Wireless Technology (JSR 82). http:
//jcp.org/en/jsr/detail?id=82. Version: 1.1.1, 2008
[MR07]
Medhi, Deepankar ; Ramasamy, Karthikeyan: Network Routing : Algorithms, Protocols, and Architectures. San Francisco, CA, USA : Morgan
Kaufman Publishers, 2007
[MSJ09]
Moustafa, Hassnaa ; Senouci, Sidi M. ; Jerbi, Moez: Introduction to
Vehicular Networks. In: Moustafa, Hassnaa (Hrsg.) ; Zhang, Yan (Hrsg.):
90
Vehicular networks : Techniques, Standards and Applications. Boca Raton,
FL, USA : Auerbach Publications, 2009, S. 1–20
[MUHW04] Mühl, Gero ; Ulbrich, Andreas ; Herrmann, Klaus ; Weis, Torben:
Disseminating Information to Mobile Clients Using Publish-Subscribe. In:
IEEE Internet Computing 8 (2004), S. 46–53
[Mul01]
Muller, Nathan J.: Bluetooth. Bonn : MITP-Verlag, 2001
[Ora10]
Oracle Corporation: Java Sound API Tutorial. http://java.sun.
com/docs/books/tutorial/sound/index.html. Version: Jan 2010. – Abruf: 1.2.2010
[Per01]
Perkins, Charles E.: Ad Hoc Networking : An Introduction. In: Perkins,
Charles E. (Hrsg.): Ad Hoc Networking. Addison-Wesley, 2001, S. 1–28
[Pos81]
Postel, J.: Internet Control Message Protocol. RFC 792 (Standard). http:
//www.ietf.org/rfc/rfc792.txt. Version: September 1981 (Request for
Comments). – Updated by RFCs 950, 4884
[Rec06]
Rech, Jörg: Wireless LANs : 802.11-WLAN-Technologie und praktische
Umsetzung im Detail. 2. Auflage. Hannover : Heise Zeitschriften Verlag,
2006
[Rec08]
Rech, Jörg: Ethernet : Technologien und Protokolle für die Computervernetzung. 2. Auflage. Hannover : Heise Zeitschriften Verlag, 2008
[Ris08]
Ristau, Henry: Publish/Process/Subscribe: Message Based Communication for Smart Environments. In: Intelligent Environments, 2008 IET 4th
International Conference on, IEEE, 2008
[Ris09a]
Ristau, Henry: Announcement/Subscription/Publication: Message Based
Communication for Heterogeneous Mobile Environments. In: MobileWireless Middleware, Operating Systems, and Applications Bd. 7, Springer, 2009,
S. 295–308
[Ris09b]
Ristau, Henry: Challenges in Content Based, Semantically Decoupled
Communication on Neighbor-Relations. In: Intelligent Interactive Assistence and Mobile Multimedia Computing, IMC 2009, Springer, Nov 2009
[SA97]
Segall, Bill ; Arnold, David: Elvin has left the building: A publish/subscribe notification service with quenching. In: Proceedings of AUUG97, 1997, S. 243–255
[SBC05]
Sivaharan, Thirunavukkarasu ; Blair, Gordon ; Coulson, Geoff:
GREEN: A Configurable and Re-configurable Publish-Subscribe Middleware for Pervasive Computing. In: On the Move to Meaningful Internet
Systems 2005: CoopIS, DOA, and ODBASE Bd. 3760. Berlin / Heidelberg
: Springer, 2005, S. 732–749
91
[SFR04]
Stevens, W. R. ; Fenner, Bill ; Rudoff, Andrew M.: Addison-Wesley
Professional Computing Series. Bd. 1: UNIX Network Programming : The
Sockets Networking API . 3. Auflage. Addison-Wesley, 2004
[Sun03]
Sun Microsystems: Connected Limited Device Configuration (CLDC)
Specification.
http://jcp.org/aboutJava/communityprocess/final/
jsr139/index.html. Version: 1.1, 2003
[Tan03]
Tanenbaum, Andrew S.: Computer Networks. 4. Auflage. Upper Saddle
River, NJ, USA : Prentice Hall PTR, 2003
[TRP+ 04]
Tian, Feng ; Reinwald, Berthold ; Pirahesh, Hamid ; Mayr, Tobias
; Myllymaki, Jussi: Implementing A Scalable XML Publish/Subscribe
System Using Relational Database Systems. In: SIGMOD ’04: Proceedings
of the 2004 ACM SIGMOD international conference on Management of
data. New York, NY, USA : ACM, 2004, S. 479–490
[TS08]
Tanenbaum, Andrew S. ; Steen, Maarten van: Verteilte Systeme : Grundlagen und Paradigmen. 2. Auflage. München : Pearson Studium, 2008
[Ull07]
Ullenboom, Christian: Java ist auch eine Insel : Programmieren mit der
Java Standard Edition Version 6. 6. Auflage. Galileo Computing, 2007
[Vro02]
Vromans, Johan: Perl Pocket Reference. 4. Auflage. Sebastopol, CA, USA
: O’Reilly Media, Inc., 2002
[YWK05]
Yang, Yaling ; Wang, Jun ; Kravets, Robin: Interference-aware Load
Balancing for Multihop Wireless Networks / Department of Computer
Science, University of Illinois at Urbana-Champaign. Version: Mär 2005.
http://hdl.handle.net/2142/10974. 2005. – Forschungsbericht
[ZF03]
Zeidler, Andreas ; Fiege, Ludger: Mobility Support with REBECA. In:
Proceedings of the 23rd International Conference on Distributed Computing Systems Workshops (ICDCSW’03). Los Alamitos, CA, USA : IEEE
Computer Society, 2003, S. 354
92
Selbstständigkeitserklärung
Ich erkläre, dass ich die vorliegende Arbeit selbstständig und nur unter Vorlage der
angegebenen Literatur und Hilfsmittel angefertigt habe.
Rostock, den 25. Februar 2010
Roland Seuchter

Experimentelle Evaluierung eines Ansatzes zur semantisch

Transcription

Similar documents

Technologien für eine interoperable und automatisierte Vernetzung

PDF Datei - Öko

Sputnik

NCH Software WavePad Audio

AUDIO- KOMPRESSION Weitere Top